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.
-
@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.
Doesn't Proxmox do this as well?
-
Even in the Xen vs. KVM space, it's hard to tell who does it better. The gap between the type 1 and the type 2 world tends to be big, but the gaps within the type 1 world are very small, and testing often shows Xen beating KVM, even recently. Part of the problem is that they are not always directly comparable, and your workload matters a lot. Xen tends to have a Linux advantage, but KVM has a Windows one. So your mix of workloads matters heavily.
And, of course, if you run pure Linux workloads, one has to wonder why you'd consider either when Type-C, like LXC, is going to beat the pants off of them either way.
https://www.phoronix.com/scan.php?page=article&item=ubuntu-1510-virt&num=5
That's really where Xen loses, the place where it is the strongest against KVM is also where it is the weakest against LXC.
-
@DustinB3403 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.
Doesn't Proxmox do this as well?
I doubt that they can, since they are repackaging things that would allow it. Not sure how they could make a EULA in that way.
They just threaten people who talk about them.
-
@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*
-
@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.
