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:
Okay, but now you are excluding other modern hypervisors. You have picked a subset of hypervisors particular to your use case that doesn't include Xen even now, and ignores the hypervisors from vendors like Oracle and IBM today. It's not modern vs. old, it's "things you are thinking of versus ones you aren't thinking about".
Wrong. Xen is loading it's own stripped down kernel with a minimal set of features, aka domU (yes, a tiny little OS) which loads up dom0 to manage it all.
Vbox (if that is what you meant) uses an OS and actually has it's own VT drivers nowadays.
All I'm saying is that there is no real true baremetal, it's just not possible unless the stack is implemented in hardware, which isn't the case on commodity hardware.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
The only real baremetal VMs were on mainframes (and I suppose there might be some exotic FPGA implementations), but we're not discussing those right now.
Was on a call, sorry for the delay. But this is the same as I said before... this is called "hardware virtualization". Not bare metal. And it isn't just mainframes, it's available on every class of hardware, including PC. Very rare on PC and totally ubiquitous no mainframes and minis, but every class has had it for a while now. PCs, like always, were the last to get it, but they have it (Hitachi provides this, I believe.)
So this is a key understanding to what we are saying.
Type 1 hypervisor means that the hypervisor itself runs without being "managed" by another layer of code, it is the "controlling" kernel that controls access to the CPU through scheduling.
A Type 2 hypervisor gets scheduled by the OS it is running on top of. A type 2 hypervisor relies on the OS kernel that you describe.
-
@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:
Okay, but now you are excluding other modern hypervisors. You have picked a subset of hypervisors particular to your use case that doesn't include Xen even now, and ignores the hypervisors from vendors like Oracle and IBM today. It's not modern vs. old, it's "things you are thinking of versus ones you aren't thinking about".
Wrong. Xen is loading it's own stripped down kernel with a minimal set of features, aka domU (yes, a tiny little OS) which loads up dom0 to manage it all.
How is that not what I've been saying?
But Xen doesn't have a "stripped down" kernel. Xen IS a type 1 hypervisor. That means it IS a kernel (Type 1 Hypervisor = kernel running on bare metal), not an little OS. It doesn't do enough to be considered an OS by any reasonable standard, no one uses OS in that way. If you did that, SNES video games were operating systems, obviously they were not.
That Dom0 provides some tooling doesn't change that Xen itself is the kernel on the bare metal.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Virtualization proved to be beyond comprehension for a lot of IT, so misuse of terms was rampant. For example, most IT pros, even those in the Windows space, actually believe that Hyper-V is loaded on top of Windows and don't realize it is bare metal. Even explaining how it works, or showing that the load method is decades old and very standard, it's still super confusing. Or explaining that things like RDP is not a form of virtualization - because they RDP into virtual servers so the two must be the same thing, right?
The early versions of hyper-v were loaded on top of windows actually. Later in the game, MS got tired of lagging behind so they hired some of the Xen folks to do a complete architectural rewrite. Now hyper-v works just like Xen. In fact, VMWare also rewrote their stuff to the same model more or less, when they moved from ESX to ESXi.
So terms have gotten really murky when only looking at the most recent years where we've been immersed in misinformation. But these are all things that have been around a long time.
Terms in IT are very fluid, true. This is exactly why I don't like the hypervisor types distinction, and this "baremetal" nonsense
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
All I'm saying is that there is no real true baremetal, it's just not possible unless the stack is implemented in hardware, which isn't the case on commodity hardware.
Right, and this is what is wrong. If they did what you are describing, that's not bare metal, that's hardware virtualization (aka, IBM, Oracle, HPE implementation.)
There IS true bare metal. It's how we all do it. You could argue that Xen and Hyper-V aren't bare metal, but that requires redefining bare metal hypervisors to do so. But KVM and ESXi have no possibility but being bare metal, there is nothing beneath them at all, and no helpers anywhere.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Terms in IT are very fluid, true. This is exactly why I don't like the hypervisor types distinction, and this "baremetal" nonsense
I dont' agree here at all. People try to make terms fluid for some reason, but they are not. It's not loose English meaning "whatever people who don't know use them to mean", it is technical jargon and well known, documented, and clear.
Baremetal is a very well established term and I've never once heard anyone not know what it meant before. Not across any community or media. It's not non-sense and is an extremely important term.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Now hyper-v works just like Xen. In fact, VMWare also rewrote their stuff to the same model more or less, when they moved from ESX to ESXi.
Opposite. ESX worked like Xen. ESXi does not. There is no "Dom0" at all.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Type 1 hypervisor means that the hypervisor itself runs without being "managed" by another layer of code, it is the "controlling" kernel that controls access to the CPU through scheduling.
A Type 2 hypervisor gets scheduled by the OS it is running on top of. A type 2 hypervisor relies on the OS kernel that you describe.
I still don't like the description (and the fact you managed to twist it quite a bit). The official description of the types is that type 1 works directly with the hardware without an assisting OS (which is absurd) and type 2 needs to go through an OS before it gets to the hardware. What you did here is basically remove the CPU extensions drivers and start talking about schedulers. Folks who don't know any better might even think type 2 (the way you describe it) isn't as good as type 1, because "schedulers".
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
The early versions of hyper-v were loaded on top of windows actually. Later in the game, MS got tired of lagging behind so they hired some of the Xen folks to do a complete architectural rewrite.
I think you are thinking of Microsoft Virtual Server, not Hyper-V. Virtual Server was a type 2 hypervisor from MS that they used prior to Hyper-V. Hyper-V was bare metal (aka native, aka Type 1) from the start (2008.) While MS can apply the same name to two unrelated products (Windows 95 and Windows 2000), they rarely do and I am pretty sure that they did not with Hyper-V. Hyper-V was type 1 on its first day on the market.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Right, and this is what is wrong. If they did what you are describing, that's not bare metal, that's hardware virtualization (aka, IBM, Oracle, HPE implementation.)
And it isn't available on commodity hardware.
There IS true bare metal. It's how we all do it. You could argue that Xen and Hyper-V aren't bare metal, but that requires redefining bare metal hypervisors to do so. But KVM and ESXi have no possibility but being bare metal, there is nothing beneath them at all, and no helpers anywhere.
Not quite. There is direct access to the CPU extensions, scheduled by the OS kernel (even if you prefer to call that OS vmkernel or DomU). And there is a ton of supporting software emulated stuff attached, because a VM is more than just a CPU.
-
@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:
Type 1 hypervisor means that the hypervisor itself runs without being "managed" by another layer of code, it is the "controlling" kernel that controls access to the CPU through scheduling.
A Type 2 hypervisor gets scheduled by the OS it is running on top of. A type 2 hypervisor relies on the OS kernel that you describe.
I still don't like the description (and the fact you managed to twist it quite a bit). The official description of the types is that type 1 works directly with the hardware without an assisting OS (which is absurd) and type 2 needs to go through an OS before it gets to the hardware. What you did here is basically remove the CPU extensions drivers and start talking about schedulers. Folks who don't know any better might even think type 2 (the way you describe it) isn't as good as type 1, because "schedulers".
I've twisted nothing. And you aren't repeating that definition accurately. It's close, but modified just enough to make it not make sense. Type 1 runs directly ON the hardware, and there is nothing about if an assisting OS exists (that would be weird and makes no sense, hence your confusion.) If you use the standard definitions, it's all clear and sensible. It's your modification of them that makes it all seem crazy.
Type 2 is definitely not as good as type 1 architecturally. More to fail, more layers. Type 2 has its place, but not for production workloads. It's really used for testing. Even there, it is losing popularity quickly.
I've not removed the CPU extensions, because they have never been relevant. They aren't part of any definition, and aren't needed for the conversation. You bring them up and by adding them in as part of your definitions make the simple, straightforward, and sensible definitions that everyone accepts and has accepted for decades seem crazy. If you don't inject a need for them into the definitions, suddenly the standard definitions are totally logical.
CPU extensions are great, but at the end of the day, they are "helpers" and remain optional. A good option, but an option nonetheless.
-
@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:
Right, and this is what is wrong. If they did what you are describing, that's not bare metal, that's hardware virtualization (aka, IBM, Oracle, HPE implementation.)
And it isn't available on commodity hardware.
Sure. Because we define commodity hardware as not having that feature. Add that feature, to anything, and we stop calling it commodity.
It isn't like virtualization is unique to commodity hardware. In the past, it was the one type that didn't have virtualization (hence why that market was left with a knowledge cap leading to confusion when it was suddenly introduced to something that the rest of IT had long ago standardized on and accepted.)
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
I dont' agree here at all. People try to make terms fluid for some reason, but they are not. It's not loose English meaning "whatever people who don't know use them to mean", it is technical jargon and well known, documented, and clear.
Baremetal is a very well established term and I've never once heard anyone not know what it meant before. Not across any community or media. It's not non-sense and is an extremely important term.
It is nonsense in the way it is peddled by the major vendors' marketing teams. What they keep pouring into people's ears is what I've been explaining to the more junior IT folks to be wrong - baremetal is not software-free, on-hardware. Hypervisor types do not make sense (because if you ask a vmware salesman you'll hear the baremetal-not-baremetal argument right there). Nothing works on the hardware directly, everything goes through layers. A VM you start has to go through a layer to get CPU time, luckily it's just one layer, but you also need to get scheduled inside and outside the VM, so you'll have overhead (and gang scheduling if you paid for vmware
). In short, there is no magic in virtualization, and saying something is "baremetal" does not make your VMs actually run on the real hardware. -
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
There IS true bare metal. It's how we all do it. You could argue that Xen and Hyper-V aren't bare metal, but that requires redefining bare metal hypervisors to do so. But KVM and ESXi have no possibility but being bare metal, there is nothing beneath them at all, and no helpers anywhere.
Not quite. There is direct access to the CPU extensions, scheduled by the OS kernel (even if you prefer to call that OS vmkernel or DomU). And there is a ton of supporting software emulated stuff attached, because a VM is more than just a CPU.
You are using the false term "OS Kernel" instead of the correct term "hypervisor or hypervisor kernel" making it seem like you didn't just say "not quite" while agreeing with what I said. DomU, or Xen, or the kernel (all the same thing) is what schedules the CPU. Thereby making it the very definition of bare metal. That it schedules its own tasks or the tasks of its helpers is exactly what bare metal means here.
Don't keep calling the hypervisor an "OS kernel", there is no purpose for that confusion. It's obviously not correct. And there is no reason for it except to avoid stating the obvious... that the hypervisor is what is running on the bare metal. Once you call it what it is, it's clear where it runs.
There is a reason why semantics is the most important part of communications. Get the semantics accurate, and most confusion tends to go away. It seems that it is only because of non-standard semantics that it seems confusing.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
I think you are thinking of Microsoft Virtual Server, not Hyper-V. Virtual Server was a type 2 hypervisor from MS that they used prior to Hyper-V. Hyper-V was bare metal (aka native, aka Type 1) from the start (2008.) While MS can apply the same name to two unrelated products (Windows 95 and Windows 2000), they rarely do and I am pretty sure that they did not with Hyper-V. Hyper-V was type 1 on its first day on the market.
Nope, Hyper-V on 2008 and 2008R2 relied on the windows kernel, in 2012 it got separated into a separate kernel. Xen folks managed the overhaul, don't remember the names right now.
-
@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:
I dont' agree here at all. People try to make terms fluid for some reason, but they are not. It's not loose English meaning "whatever people who don't know use them to mean", it is technical jargon and well known, documented, and clear.
Baremetal is a very well established term and I've never once heard anyone not know what it meant before. Not across any community or media. It's not non-sense and is an extremely important term.
It is nonsense in the way it is peddled by the major vendors' marketing teams. What they keep pouring into people's ears is what I've been explaining to the more junior IT folks to be wrong - baremetal is not software-free, on-hardware.
What vendor, even in marketing, is saying this? I'm not disagreeing with you, but this goes against all experience that I've had. I've never heard anyone hint and there being junior IT folks making this crazy mistake.
I've seen some insanity out there with what people don't understand, so I totally understand that this would be possible. But I see two issues here...
- I'm not confident that this is a widespread issue. Look at ML or SW, even on SW I've never heard of a single person making this particular mistake.
- You are arguing that something isn't bare metal to people who actually know what it is, based on the assumption we are using the term to mean something very different than what it means.
If someone IS having this confusion, I would warn against assuming it is common. Maybe it is and somehow ML, SW, and all IT walks of life I've seen have avoided it in a bubble, that can happen. but I talk to a lot of people and have seen a lot of crazy misconceptions. This feels like something I'd have been extremely likely to have seen if it was happening much at all. Maybe Reddit is worse than SW and doing it?
-
@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:
I think you are thinking of Microsoft Virtual Server, not Hyper-V. Virtual Server was a type 2 hypervisor from MS that they used prior to Hyper-V. Hyper-V was bare metal (aka native, aka Type 1) from the start (2008.) While MS can apply the same name to two unrelated products (Windows 95 and Windows 2000), they rarely do and I am pretty sure that they did not with Hyper-V. Hyper-V was type 1 on its first day on the market.
Nope, Hyper-V on 2008 and 2008R2 relied on the windows kernel, in 2012 it got separated into a separate kernel. Xen folks managed the overhaul, don't remember the names right now.
Relied on, but didn't run on. That's the common myth that started in that era. It was absolutely a type 1 at the time, and we were having these exact discussions at the time about how everyone thought it ran on top of Windows, but didn't. It's been improved since then, but being its own kernel and not running on the Windows one hasn't changed in that time.
It still "relies on" the Windows kernel today, but only in the Dom0. The Windows kernel runs on top of the Hyper-V kernel, and always has.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
I've twisted nothing. And you aren't repeating that definition accurately. It's close, but modified just enough to make it not make sense. Type 1 runs directly ON the hardware, and there is nothing about if an assisting OS exists (that would be weird and makes no sense, hence your confusion.) If you use the standard definitions, it's all clear and sensible. It's your modification of them that makes it all seem crazy.
Wait, you're saying an assisting OS doesn't exist? What is the DomU then? It is way more than just a driver for VT/SVM.
Type 2 is definitely not as good as type 1 architecturally. More to fail, more layers. Type 2 has its place, but not for production workloads. It's really used for testing. Even there, it is losing popularity quickly.
That's funny, having double the schedulers and double the drivers is better architecturally because..? And since we are there, how can you efine KVM to be type 1 if it uses an OS instead of implementing it's own set of schedulers and interfaces?
I've not removed the CPU extensions, because they have never been relevant. They aren't part of any definition, and aren't needed for the conversation. You bring them up and by adding them in as part of your definitions make the simple, straightforward, and sensible definitions that everyone accepts and has accepted for decades seem crazy. If you don't inject a need for them into the definitions, suddenly the standard definitions are totally logical.
CPU extensions are great, but at the end of the day, they are "helpers" and remain optional. A good option, but an option nonetheless.
Without CPU extensions what you have is emulation (well, binary translation at best) which takes you even further from "baremetal".
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Sure. Because we define commodity hardware as not having that feature. Add that feature, to anything, and we stop calling it commodity.
It isn't like virtualization is unique to commodity hardware. In the past, it was the one type that didn't have virtualization (hence why that market was left with a knowledge cap leading to confusion when it was suddenly introduced to something that the rest of IT had long ago standardized on and accepted.)
I call standard x86 servers commodity. And you?
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Hypervisor types do not make sense (because if you ask a vmware salesman you'll hear the baremetal-not-baremetal argument right there). Nothing works on the hardware directly, everything goes through layers.
They make a lot of sense. The issue is that non-technical salesmen do not make sense. That's a completely different issue.
Something always runs on bare metal. If you use the standard definition of bare metal, then it's a requirement for a computer to work. Bare metal cannot be avoided. The question is only "what" runs on the bare metal.
So this is critical, you can't argue that the definitions of hypervisors are wrong unless you accept the universal definition for bare metal. Because one relies on the other. All hypervisors are defined in relationship to that standard. You can argue all you want that the definition of bare metal is bad, but it is what it is and is universally accepted.
So your issue is not with the definition of the hypervisors, but not liking a part of the definition on which they rely.
Example: you don't like calling blue blue, but call it green because that's your opinion.
Then you claim the US flag is red, white and green. Because to you, it is.
That doesn't change the colours of the flag. So you can't tell someone that uses blue to mean blue that they don't know the flags colours. But if you want to argue that he uses a different word for blue than you use, that's a different thing.
