@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.

@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).

[1] https://github.com/siemens/jailhouse

@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

@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

@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

@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 there are a few companies I avoid like that, but the ones that demand I move to Moscow for a job take the cookie

@scottalanmiller maybe, I've been avoiding them like the plague. Even when they tried to hire me a few years ago

@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 "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 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.

@scottalanmiller now that IS funny - Dell was where I worked at the time, and all the demos MS tried to give us for weeks failed one after the other. Compared to a perfectly stable vsphere 2 lab we had on the floor then, it was especially fun.

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

But I would say that making wild counter-industry claims of a conspiracy to cover up systems architectures, going against a decade of discussion on this very topic, is something that should be held back if you don't have the time to really delve into it. Knowing that you are trying to completely redefine OS, kernel, hypervisor, hypervisor types, Hyper-V history... all of those things are fine, but it is a bit of a crusade that takes a lot of time.

I specifically remember this being a huge problem for MS, because they couldn't pretty much go the KVM route on server 2008, and them fixing the issue by changing direction and replicating Xen's architecture (and actually hiring Xen engineers to do that).

I also remember some private demos MS gave us for hyper-v on pre-release versions of 2008 and experimental 2003 builds that were, frankly, horrible. But all that was in 2007, so I might be confusing the dates here a bit.

As for crusades, I don't really care enough to make a real issue out of it, I'm just annoyed by marketing people peddling "baremetal", double kernel design as better because "baremetal". to illustrate my point, I'll just leave this here:

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

What do you think that I've been doing?

Sorry, don't have as much time for online debates as you do, I'm looking at what you posted right now, thanks for taking the time

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

LIke I said, you need to provide your documentation that goes against everything in the industry. You made the claim.

Here you go again with "everything in the industry". Show me this "everything"

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

And I'm saying it is not an OS if you do so. Calling it an OS makes it seem like it must be. But the real answer is "if you implement an system that falls short of being an OS, it's not an OS." You are starting the statement by claiming it is an OS, so no matter how limited it is, it can't be so limited as to not be an OS. You are using it being an OS as the starting point.

Because it is an OS, by the very definition you provided yourself.

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

I just did twice.

By referring to a post you wrote? Not good enough

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

It's not relevant because it's not under the kernel, so unrelated to what we are discussing. You can layer on as many schedulers on top of things that you want. But we were talking about X and this simply doesn't relate to that discussion.

Your statement of "how is it more efficient than..." doesn't make any sense in this context. It implies something said that wasn't, so there is nothing clear to answer.

Replace "efficient" with "better architecture" and try again, if you prefer to stick to the exact wording, I really don't mind

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

Now you are mixing apps with the OS. An RTOS can still do basically anything. As could a phone OS. You are mixing the concept of "general purpose" with the amount of power systems had in the past. Very different concepts.

Nothing to do with power, just the ability to perform a set of operations on given hardware. If you implement an OS that is limited in what it can do, it is still an OS, that's all I'm saying

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

I have, for years. You are claiming that those proofs are not true. You are claiming that not only I am wrong, but Wikipedia, Microsoft, and the industry. Yet don't even have a suggestion of supporting documentation. Based on what do you make these wild claims?

I'm simply agreeing that the sky is blue. You are claiming it red. But have nothing to support that theory.

Oh no, you don't get to turn this one around. You claim hyper-v had the same architecture as xen since its first versions - you prove that.