Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Ah, and appears the operation has been quite successful ...
Good job!
Also completed successful live migration of the balug VM back from physical host "vicki" ... which nominally resides under the brain of the patient, but was live-migrated away to "vicki" while the patient's brain was in suspended animation for a while during the patient's operation.
See, this is one of the reasons I am trying to move production systems into VMs: It means you can snapshot systems and migrated them between hardware-disparate physical hosts as necessary.
Starting years ago, I repeatedly tried to have a discussion on the SVLUG mailing list about hardware selection and system design for _home servers_ that took advantage of recent advances, and it was a bust because all participants did was advocate I buy whatever they'd been buying but ignoring both the home-server role's requirements and the recent advances.
I suggested a server inside my home should ideally have no moving parts (no fans, SSDs instead of hard drives) so as to not be noisy, and be low-power and low-heat: They suggested units with lots of fans and hard drives. I suggested it needed to do RAID1 on real, i.e., better than USB, mass-storage interfaces: They suggested Raspberry Pis. I suggested it needed to be x86_64 to avoid requiring out-of-tree kernels (security risk if there's a kernel exploit requiring an updated kernel _now_) and special-snowflake bootloaders: They suggested ARM.
And, the one that really disappointed me: I suggested it'd be cool to run at least a couple of VMs, production host alongside beta, and that for a production full-service Internet host I really cannot do it in less than 512 MB RAM for a production host because of SMTP antispam: My friend Joey Hess, one of the key people in the Debian Project at the time, responded saying he uses a BeagleBone Black, a nice small ARM-based server he uses -- that maxes out at 512 MB RAM total.
I pointed out that this just didn't support the VM-based architecture I thought was the future way forward (unless there were some way in the 2010s to do Web serving, SMTP, mailing lists, DNS nameservice, ssh, and the usual server tasks in radically less RAM), and all people could say was 'Shift tactics and divide processes up among a farm of tiny computers.' Eh, no, I don't think a data centre of Raspberry Pis is a reasonable alternative. So, I've had to mostly drive iterations of that discussion myself, first on the SVLUG list and more recently on CABAL's.
Anyway, this is why I think small, silent or quiet, x86_64-based machines able to run at least 8GB RAM are coo and the proper way forward: primarily because hypervisors solve a bunch of problems including live-migration, and decoupling what you run from the specific hardware chipsets you run it on.
But this weekend's motherboard purchase is actually for a family car, FWIW, because the current one went Pfft! https://store.allcomputerresources.com/20chptcrpcme10.html
Ca-ching!
Man, my dad, who before he became a Pan American World Airways captain sold and worked on 'computers' when they were made by Marchant (https://en.wikipedia.org/wiki/Marchant_calculator) in Oakland would hardly recognise the current world, where you end up having to reboot your oven, and where your automatic transmission misbehaves because the car's motherboard has burned itself out.