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 I've had the misfortune of doing SMB work for quite a few years, and it's always been "just fix this now" and "we've no budget for that, we're an accounting firm and not an IT shop". So when I see SMB mentioned, I go into power saving mode
That's generally true, but you are looking at it from a partial perspective when you look at it that way. The question and/or advice would have been for the person designing the environment. Not for someone "just fixing something." At some point that SMB had all of the same opportunity and need to do things well, and therefore needed the advice and will need it again sometime.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller I've had the misfortune of doing SMB work for quite a few years, and it's always been "just fix this now" and "we've no budget for that, we're an accounting firm and not an IT shop". So when I see SMB mentioned, I go into power saving mode
both hyper-v and KVM fit the no budget budget.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Last time I checked with an MS licensing specialist, that was the case for the DC edition, and even then MS weren't too happy to activate your machines unless you also got a site license, a VLK or a select-6 pack. For SMBs, even if you do technically have the option to activate windows servers on non-MS virtual hardware, the procedure of doing that will hurt.
My information is a bit dated though, they might have improved things since 2010-2012-ish.
If you have the option to actually do things right and you are able to activate your windows vms without problems, KVM is a great choice, especially since if you have to scale, you can deploy oVirt
It's dead simple and universal now. Everyone with Windows does this, essentially. I've not seen a deployment not taking advantage of all the extra standard licenses in a decade. It's "just how Windows is", now. You get two VMs for every Standard license you buy, and that's how all capacity planning is done.
-
@Donahue 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 I've had the misfortune of doing SMB work for quite a few years, and it's always been "just fix this now" and "we've no budget for that, we're an accounting firm and not an IT shop". So when I see SMB mentioned, I go into power saving mode
both hyper-v and KVM fit the no budget budget.
And the Xen family, too.
-
@scottalanmiller Actually, what you say is both correct and incorrect. A hypervisor is simply the driver for the VT/SVM CPU extensions, nothing else. In that sense, it does work with the hardware directly, obviously. But it does not work in a vacuum - a driver is only part of a set of drivers of which a kernel consists. The kernel also contains other software like schedulers, and with a bit of utilities added, you get a barebones OS. It might be extremely stripped down, but it is still an OS.
Having said that, when people say "hypervisor" they mean a means of getting a VM to run, that usually means the drivers, a kernel to utilize the drivers, a set of utilities to manage the VM and emulate virtual hardware. So really, there is no "baremetal", unless you have a box that doesn't even boot up
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
@scottalanmiller Actually, what you say is both correct and incorrect. A hypervisor is simply the driver for the VT/SVM CPU extensions, nothing else. In that sense, it does work with the hardware directly, obviously. But it does not work in a vacuum - a driver is only part of a set of drivers of which a kernel consists. The kernel also contains other software like schedulers, and with a bit of utilities added, you get a barebones OS. It might be extremely stripped down, but it is still an OS.
Not an OS. An OS has a definition, and true hypervisors don't meet it. It's like an OS, yes. But it's different. KVM/Linux is unique in that depending on configuration it can be either or both.
But remember, Linux isn't an OS, it's not enough on its own. It's only a kernel. It's a kernel meant for an OS, but that doesn't make it an OS.
But Xen, Hyper-V, and ESXi don't contain kernels even meant for an OS.
A hypervisor is never a driver. To be a hypervisor, you must be a kernel. If it is only a driver, it's not a hypervisor. Or not a type 1, at least.
A type 2 hypervisor has a driver, but must be more than a driver to be the hypervisor.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Having said that, when people say "hypervisor" they mean a means of getting a VM to run, that usually means the drivers, a kernel to utilize the drivers, a set of utilities to manage the VM and emulate virtual hardware. So really, there is no "baremetal", unless you have a box that doesn't even boot up
Except that all of those things go on the bare metal in type 1 systems. Hence why they are called bare metal hypervisors. (Except the utilities portion.)
And keep in mind that bare metal virtualization exists even without the hardware pieces you mentioned. Some of us come from the virtualization world prior to that stuff existing. In the SMB world these days, those tend to be considered foregone conclusions, but in the bigger sense, they are not. Xen, for example, predates that stuff by quite a bit, as does ESX.
Most virtualization systems only provide an API on the bare metal, and put the management utilities for end users elsewhere. But that's not the hypervisor.
But the hypervisor... including the kernel, any drivers, and the hardware emulation sit on bare metal with all bare metal hypervisors.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Not an OS. An OS has a definition, and true hypervisors don't meet it. It's like an OS, yes. But it's different. KVM/Linux is unique in that depending on configuration it can be either or both.
But remember, Linux isn't an OS, it's not enough on its own. It's only a kernel. It's a kernel meant for an OS, but that doesn't make it an OS.
But Xen, Hyper-V, and ESXi don't contain kernels even meant for an OS.
That's semantics. A kernel and a set of tools to perform a function, comprise an OS, maybe not a generic universal OS that can do anything, but an OS nonetheless. An RTOS that guides a rocket is tiny and very narrow in it's use, but it's an OS nonetheless. Like I said - semantics.
A hypervisor is never a driver. To be a hypervisor, you must be a kernel. If it is only a driver, it's not a hypervisor. Or not a type 1, at least.
Actually, a hypervisor in it's cleanest form is exactly that - a driver made to address the extra CPU features that allow for proper virtualization instead of tricks with optimized emulation, like VMWare did before VT. But nobody uses that word in that sense, because if we did - the only actual hypervisor out there would be KVM, all others are a stack of driver plus emulators, plus hardware drivers, schedulers and userspace tools.
A type 2 hypervisor has a driver, but must be more than a driver to be the hypervisor.
Hypervisor types have been made moot by KVM's emergence 12 years ago.
-
@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:
Not an OS. An OS has a definition, and true hypervisors don't meet it. It's like an OS, yes. But it's different. KVM/Linux is unique in that depending on configuration it can be either or both.
But remember, Linux isn't an OS, it's not enough on its own. It's only a kernel. It's a kernel meant for an OS, but that doesn't make it an OS.
But Xen, Hyper-V, and ESXi don't contain kernels even meant for an OS.
That's semantics. A kernel and a set of tools to perform a function, comprise an OS, maybe not a generic universal OS that can do anything, but an OS nonetheless. An RTOS that guides a rocket is tiny and very narrow in it's use, but it's an OS nonetheless. Like I said - semantics.
It's all semantics. Semantics is just another term for accuracy. A kernel plus tools for a function has never been the description of an OS. An OS has to be a specific general purpose platform for applications. If you narrow the use, it has to stop being an OS.
If we weren't worried about semantics, we'd just call it a "kitten" and that would be correct.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Except that all of those things go on the bare metal in type 1 systems. Hence why they are called bare metal hypervisors. (Except the utilities portion.)
Nothing is on bare metal. It is all software loaded into memory by a kernel loaded after POST. The drivers work with the "baremetal" directly, everything else works through a driver, or is emulated in software. Does the VNC console to a Xen VM work on baremetal?
And keep in mind that bare metal virtualization exists even without the hardware pieces you mentioned. Some of us come from the virtualization world prior to that stuff existing. In the SMB world these days, those tend to be considered foregone conclusions, but in the bigger sense, they are not. Xen, for example, predates that stuff by quite a bit, as does ESX.
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.
Most virtualization systems only provide an API on the bare metal, and put the management utilities for end users elsewhere. But that's not the hypervisor.
API on the baremetal. Really. Can you show me the chip that API is implemented in?
But the hypervisor... including the kernel, any drivers, and the hardware emulation sit on bare metal with all bare metal hypervisors.
the hypervisor is part of the kernel, like all other hardware drivers. It IS a driver, for the CPU extensions. Exactly what I've been saying. Only the kernel isn't on baremetal, it's software that gets loaded by the BIOS and is the lowest level talking to the hardware.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Actually, a hypervisor in it's cleanest form is exactly that - a driver made to address the extra CPU features that allow for proper virtualization instead of tricks with optimized emulation, like VMWare did before VT. But nobody uses that word in that sense, because if we did - the only actual hypervisor out there would be KVM, all others are a stack of driver plus emulators, plus hardware drivers, schedulers and userspace tools.
Not at all. Hypervisors pre-date those features. It's redefining hypervisor after the fact that makes that seem plausible. But it's not. Hypervisors are not drivers, and hypervisors don't require CPU extensions. That's a very recent thing considering we've had hypervisors for many decades, but the extensions only for about fifteen years.
If you were in the virtualization and hypervisor world before that stuff existed, it would make it obvious how silly it is to say that hypervisors require something that is decades younger than they are.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
It's all semantics. Semantics is just another term for accuracy. A kernel plus tools for a function has never been the description of an OS. An OS has to be a specific general purpose platform for applications. If you narrow the use, it has to stop being an OS.
That is extremely arguable. Actually, my wife, a VHDL/VLSI/FPGA developer, would laugh if she heard that
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
API on the baremetal. Really. Can you show me the chip that API is implemented in?
Ah, I think the issue is that you don't know how bare metal is used in IT terms. Bare metal never means running on in the chip, it's the code that is run directly on the chip rather than being virtualized a layer up. If you were thinking that bare metal means in the chip's code itself, that would explain the misunderstanding of how hypervisors work.
That term does not mean that. There are things that run on the chip. And there are hypervisors that run in the hardware. Those are called hardware, not bare metal.
-
@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:
It's all semantics. Semantics is just another term for accuracy. A kernel plus tools for a function has never been the description of an OS. An OS has to be a specific general purpose platform for applications. If you narrow the use, it has to stop being an OS.
That is extremely arguable. Actually, my wife, a VHDL/VLSI/FPGA developer, would laugh if she heard that
Well, it's not very arguable. It's the accepted definition for decades. "An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs. "
New definitions to old, existing things are never right. That's "playing semantics". These are well established, well understood, universal terms. You can't just change them suddenly.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Not at all. Hypervisors pre-date those features. It's redefining hypervisor after the fact that makes that seem plausible. But it's not. Hypervisors are not drivers, and hypervisors don't require CPU extensions. That's a very recent thing considering we've had hypervisors for many decades, but the extensions only for about fifteen years.
OK, replace that with "modern hypervisor". I'm sure you know 15 years in IT is quite the eternity
If you were in the virtualization and hypervisor world before that stuff existed, it would make it obvious how silly it is to say that hypervisors require something that is decades younger than they are.
I was not, but I specialized in the modern version of virtualization for the past 10 years or so
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
Well, it's not very arguable. It's the accepted definition for decades. "An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs. "
I see no negation to needing to narrow down the functionality of the OS here.
-
@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
You can't just change them suddenly.
Actually, you can, if you get most other to agree. That is part of how languages evolve and change over time.
-
@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:
Not at all. Hypervisors pre-date those features. It's redefining hypervisor after the fact that makes that seem plausible. But it's not. Hypervisors are not drivers, and hypervisors don't require CPU extensions. That's a very recent thing considering we've had hypervisors for many decades, but the extensions only for about fifteen years.
OK, replace that with "modern hypervisor". I'm sure you know 15 years in IT is quite the eternity
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".
You can say "some hypervisors today" to things a certain way. That's fine. But are trying to redefine what has been there in the past, based on misconceptions about a subset of things today.
-
@dyasny said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:
I was not, but I specialized in the modern version of virtualization for the past 10 years or so
In a modern form of virtualization. It's still just one of many kinds. And I think that people in the Type-C space would argue that it's not that modern relatively speaking.
The virtualization space, when Intel and AMD started their extensions, and virtualization hit the SMB created a huge explosion in misunderstandings and people trying to reuse existing, very well defined terms for things that they were seeing but not understanding.
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?
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.
-
@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.
