What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options
-
@scottalanmiller "bloat" isn't really relevant, because KVM doesn't really use or involve a lot of the stuff the Linux kernel has. Sure, some disk space gets wasted and boot times might be slightly longer, but that's not really a problem. But the fact that new schedulers and subsystems don't need to be written, and a lot of the stuff that already exists and works can be simply reused is very appealing (to me and probably any unixway geek out there)
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller oh I've had a distrust for VMWare from the very start. When I see an explicit ban on publishing benchmarks in the EULA, I know something is fishy.
*cough* Nutanxi *cough*
Maybe that's who it was Nuti ! I knew it was one of them
-
@scottalanmiller KVM is a hypervisor, pure and simple. Xen has two modes, where PV is somewhere mid-way to container-like performance, but is very limited in the way of supported guest OS, and HVM which is pretty much on par with KVM feature-wise, but usually slower than KVM (see the pic above). So comparing them directly is only possible when you compare KVM to Xen-HVM, or some form of containerization to Xen-PV. Either way Xen is slower for most workloads, excepting maybe synthetic stuff tailored for it.
In fact, KVM was invented when an engineer working on Xen thought the architecture was flawed and overbloated, and things could have been done better. That engineer is my current CTO
-
@scottalanmiller maybe, I've been avoiding them like the plague. Even when they tried to hire me a few years ago
-
@dyasny there are a few companies I avoid like that, but the ones that demand I move to Moscow for a job take the cookie
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller "bloat" isn't really relevant, because KVM doesn't really use or involve a lot of the stuff the Linux kernel has. Sure, some disk space gets wasted and boot times might be slightly longer, but that's not really a problem. But the fact that new schedulers and subsystems don't need to be written, and a lot of the stuff that already exists and works can be simply reused is very appealing (to me and probably any unixway geek out there)
Hence why they do it, but there is a bit of advantage to the ESXi approach. Absolutely everything is so lean all the time.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Hence why they do it, but there is a bit of advantage to the ESXi approach. Absolutely everything is so lean all the time.
Which comes at the expense of vmware having to maintain their own drivers, schedulers, etc etc etc. Back when I was doing field deployments, just showing the HCL for ESXi compared to the RHEL HCL was sometimes enough to convince a client.
Not to mention, the Linux kernel has decades of development and enhancement on the ESXi kernel in all aspects.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller KVM is a hypervisor, pure and simple. Xen has two modes, where PV is somewhere mid-way to container-like performance, but is very limited in the way of supported guest OS, and HVM which is pretty much on par with KVM feature-wise, but usually slower than KVM (see the pic above).
In the last many years, the HVM approach even within Xen has become faster than the PV approach. Mostly due to there being way more focus there. There was hope that the project would get more attention to get PV up to par with HVM and get its speed up again.
But Xen remains a hypervisor, even when used in PV rather than HVM mode. The term hypervisor doesn't imply any particular virtualization type or model.
-
@scottalanmiller of course, PV simply adds some shortcuts in (mainly) the IO path, assisted by a special driver in the guest. VirtIO is pretty much the same, and it's not exclusive to KVM any longer
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
In fact, KVM was invented when an engineer working on Xen thought the architecture was flawed and overbloated, and things could have been done better. That engineer is my current CTO
It's a good idea, but one that hasn't proven to make all that much of a difference. In reality, what KVM ended up doing was splitting the community too far making the Xen / KVM world much weaker than it should have been with engineering and customer efforts split, rather than unified. Either approach works fine. KVM's is slightly better on paper, Xen was already good enough in practice. KVM is simpler, but not simpler enough to justify creating two competing ecosystems. Now things like XO that would have been amazing to have had with KVM are only for Xen, and things like CBD that are amazing for KVM don't exist for Xen. Imagine if all that effort was put into one project!
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller of course, PV simply adds some shortcuts in (mainly) the IO path, assisted by a special driver in the guest. VirtIO is pretty much the same, and it's not exclusive to KVM any longer
You are thinking of PV Drivers, like KVM, ESXi, and Hyper-V use. No driver needed for full PV like Xen has. Instead, the entire kernel has to be recompiled for it!
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
It's a good idea, but one that hasn't proven to make all that much of a difference. In reality, what KVM ended up doing was splitting the community too far making the Xen / KVM world much weaker than it should have been with engineering and customer efforts split, rather than unified. Either approach works fine. KVM's is slightly better on paper, Xen was already good enough in practice. KVM is simpler, but not simpler enough to justify creating two competing ecosystems. Now things like XO that would have been amazing to have had with KVM are only for Xen, and things like CBD that are amazing for KVM don't exist for Xen. Imagine if all that effort was put into one project!
A lot of the development went into QEMU and its various subprojects (virtio especially), and QEMU is utilized by both systems. But in any case, KVM is native to Linux, while Xen is a separate, foreign kernel that will never be a part of Linux. So, IMO, things would be better suited completely switched to KVM, instead of people insisting on sticking with Xen.
On the other hand, when you have a newer, better, faster and much more Linux-native design, why dump it just to keep the community effort in one place? Especially when Xen got scooped up by Citrix, a company that was never known for it's benevolence and support for the OSS community? I think everything took it's natural course, with Xen getting phased out by KVM as soon as feature parity was reached, and then easily surpassed in terms of uptake and installbase
-
I want to know how old this table is, because I think that it is out of date.
https://wiki.xen.org/images/thumb/4/4b/XenHVM-All.png/700px-XenHVM-All.png
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
You are thinking of PV Drivers, like KVM, ESXi, and Hyper-V use. No driver needed for full PV like Xen has. Instead, the entire kernel has to be recompiled for it!
But the kernel is, essentially, a blob of drivers
whether you compile or install modules, you get a new set of drivers in the end -
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
But in any case, KVM is native to Linux, while Xen is a separate, foreign kernel that will never be a part of Linux. So, IMO, things would be better suited completely switched to KVM, instead of people insisting on sticking with Xen.
Had KVM been the original project, I would agree completely. But I'm not sure that sharing the Linux kernel for two different purposes is best. It seems to come with a lot of benefits, but a lot of negatives, too. There is a reason that no one else goes down that path for this.
-
I think Xen's future is to follow ESXi's path. Removing the Dom0, growing the kernel, and moving to limited, enterprise only, hardware support.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Had KVM been the original project, I would agree completely. But I'm not sure that sharing the Linux kernel for two different purposes is best. It seems to come with a lot of benefits, but a lot of negatives, too. There is a reason that no one else goes down that path for this.
ESXi went down that path, didn't they? Nobody else[1] did because KVM is already there and available, all you need is to build a suitable kernel and maybe your own take on QEMU (like Amazon did).
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
I think Xen's future is to follow ESXi's path. Removing the Dom0, growing the kernel, and moving to limited, enterprise only, hardware support.
I'm pretty sure they don't have the resources to do that. Nor is there any need - Xen as a commercial offering isn't anything to write home about, and as opensource, there isn't much demand for a slim hypervisor-only OS without cluster-level management abilities. Citrix might do something like that for the same reasons ESXi is available for free - as a first dose to get people hooked, but I'm not sure they can or want to invest so much in such an offering.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Had KVM been the original project, I would agree completely. But I'm not sure that sharing the Linux kernel for two different purposes is best. It seems to come with a lot of benefits, but a lot of negatives, too. There is a reason that no one else goes down that path for this.
ESXi went down that path, didn't they? Nobody else[1] did because KVM is already there and available, all you need is to build a suitable kernel and maybe your own take on QEMU (like Amazon did).
Hyper-V and Xen made separate kernels, but not their own driver sets.
-
@scottalanmiller oh there are SOME drivers in those separate kernels, else they wouldn't be able to work at all.
