xcp-ng. You can use a built-in mini-management tool (xo-lite) to build the full-featured management tool (Xen Orchestra) from git. There are a couple of maintained scripts that automate the process.
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
> 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.
This article is a great example of the limits of LLM technical writing.
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.
And what's so tiring is that with humans, there's often (not always) a coherent meaning there to be untangled. With the LLMs, probably not, because if there was, it would have been in the prompt and the rambling wouldn't be as bad.
Why is Xen a thing when we have great and free KVM virtualization? Honest and dumb question.
KVM has a much larger attack surface than Xen
Why is KVM a thing when we have great and free Xen virtualization?
Which hypervisors are free with Xen?
xcp-ng. You can use a built-in mini-management tool (xo-lite) to build the full-featured management tool (Xen Orchestra) from git. There are a couple of maintained scripts that automate the process.
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
So I should ditch Proxmox for this?
a couple of reasons:
> 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.
Very far fetched and was almost two decades ago, never seen that sentiment in regards for Xen. Xenserver seems a bit mismanaged though.
The original question was vague, but we are getting a bit all over the place. Hyperscalers and most other uses don't really overlap that much.
This article is a great example of the limits of LLM technical writing.
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.</i>
Where are we going here and why?!
And what's so tiring is that with humans, there's often (not always) a coherent meaning there to be untangled. With the LLMs, probably not, because if there was, it would have been in the prompt and the rambling wouldn't be as bad.