> XenSource got acquired by Citrix, who closely aligned with Microsoft in order to leverage the Xen commercialization against VMware ~ and the opensource community is hyper-aware of the long term damaging outcomes of these types of alliances with Redmond's powers for FUD.
> KVM's parent org. got acquired by Red Hat and that makes it more palatable for those same reasons.
> Hyperscalers who use KVM to manage multiple client VM instances on the same hardware via over-provisioning get to have kernel level insight into the KVM instances behavior via native, low-latency access to the hardware and direct integration with the Linux kernel's performance framework (perf) - this makes the noisy neighbor problem easier to mitigate than the same task on Xen which requires another layer of abstraction and has less out of the box native support choice of tools.
> KVM is/became a kernel module, and its development is now 'in-tree' for mainline kernel which also meant the kernel can perform the type-1 hypervisor activities using the standard Linux memory and hardware management toolkit. i.e. less maintenance
> there are more reasons, having to do with Xen pre-existing from the days when hardware didn't natively support virtualization and thus the need to modify the VM kernels to be PV (paravirtualized) - but putting KVM into mainline made the vanilla kernel hypervisor-aware as both host and guest
but mostly it's the first reason, and the rest sort of cascade from that one - the 'lack of support' from the standard tools developing opensource community is probably the largest reason.
Say what you will about—or try to prompt out—their rhetorical flourishes, they can link together a series of background, observations, implications, …
But man, they are hopeless at crafting a high-level narrative. It’s one big hedge maze of a garden path:
This part makes good on that - and along the way it covers two things we did not plan to fix. One we hit before the real work could start: dom0's own memory placement was so skewed that synthesising a topology for dom0 without fixing it first would have been an exercise in lying to a kernel that had no memory to back the lie with. That one is a prerequisite, not a detour - everything else in this part is built on top of it. The other we hit after the work was nominally done: a memory-placement bug in our own toolstack that had been silently broken for as long as multi-vnode vNUMA had existed in our tree, and only ever surfaced under a memory-bandwidth benchmark. That one is the genuine detour, and it waits until the end.
Let's start with the prerequisite.
Where are we going here and why?!
[deleted]
I like it because it is not a bag of parts. Everything is included. It is a VM toolkit that JFW, and it is not what keeps me awake at night