Nested hypervisors?
-
@scottalanmiller said in Nested hypervisors?:
Why not do permission based limitations so you can provide a Dev with access to create/destroy as many VM's as he/she needs within the constraints of your pool or resource limits?
This is commonly done with a Cloud Management Product that overlays the hypervisor (OpenStack, vRealize Autiomation, etc, PKS etc) that can manage the multi-tenancy etc.
Now some hypervisors support some provisioning options others don't (Instant Clones are a unique one, that allow cloning a running VM with thin memory) that may make some things more efficient -
@obsolesce said in Nested hypervisors?:
Nested (virtual) ESXi is not officially supported by VMWare, so that's not a production scenario anyways.
Technically it's used for the vSAN Witness (which is just a ESXi VM). It's used internally for QE testing, It's used for the hands on labs also.
-
@dustinb3403 said in Nested hypervisors?:
I haven't ever had the need to even look at attempting this so I don't know. But lets say you're a Hyper-V shop and have a business requirement you have to run an appliance of some kind that is tailored to ESXi, this would be a case where you'd likely nest.
Rather than building another hypervisor fleet.This wouldn't be supported by any VMware appliance vendor I"m aware of, and VMware certainly wouldn't support it.
-
@storageninja This was just a random example of a fictitious scenario.
-
@storageninja said in Nested hypervisors?:
@obsolesce said in Nested hypervisors?:
@wirestyle22 said in Nested hypervisors?:
@emad-r said in Nested hypervisors?:
Yup go figure for value, Virtualbox has no intention of doing this amazing feature since 2011
Maybe I'm missing something but why in the world would I ever want to use nested hypervisors? Vendor requirements?
Vendors never require a specific hypervisor. If they did, you certainly wouldn't nest it. And if it was a consideration, you'd find a different vendor.
Really, it's for lab/testing.
This would work, as only one vendor supports the virtualization of another hypervisor (and only for a niche use case) that I'm aware of.
Most vendors specify that X hypervisor must be there, and specify nothing of what is beneath it.
-
@storageninja said in Nested hypervisors?:
@dustinb3403 said in Nested hypervisors?:
I haven't ever had the need to even look at attempting this so I don't know. But lets say you're a Hyper-V shop and have a business requirement you have to run an appliance of some kind that is tailored to ESXi, this would be a case where you'd likely nest.
Rather than building another hypervisor fleet.This wouldn't be supported by any VMware appliance vendor I"m aware of, and VMware certainly wouldn't support it.
But would be supported by the application vendor.
-
@scottalanmiller said in Nested hypervisors?:
@storageninja said in Nested hypervisors?:
@dustinb3403 said in Nested hypervisors?:
I haven't ever had the need to even look at attempting this so I don't know. But lets say you're a Hyper-V shop and have a business requirement you have to run an appliance of some kind that is tailored to ESXi, this would be a case where you'd likely nest.
Rather than building another hypervisor fleet.This wouldn't be supported by any VMware appliance vendor I"m aware of, and VMware certainly wouldn't support it.
But would be supported by the application vendor.
I've never seen a application vendor that mandates a hypervisor, but doesn't care if it's deployed in a non-supported configuration. I could see EPIC and the like having a good laugh though if you ask them.
-
@storageninja said in Nested hypervisors?:
@scottalanmiller said in Nested hypervisors?:
@storageninja said in Nested hypervisors?:
@dustinb3403 said in Nested hypervisors?:
I haven't ever had the need to even look at attempting this so I don't know. But lets say you're a Hyper-V shop and have a business requirement you have to run an appliance of some kind that is tailored to ESXi, this would be a case where you'd likely nest.
Rather than building another hypervisor fleet.This wouldn't be supported by any VMware appliance vendor I"m aware of, and VMware certainly wouldn't support it.
But would be supported by the application vendor.
I've never seen a application vendor that mandates a hypervisor, but doesn't care if it's deployed in a non-supported configuration. I could see EPIC and the like having a good laugh though if you ask them.
You mean you've never seen a good vendor do that right? I've definitely seen it.
-
@wirestyle22 said in Nested hypervisors?:
I've never seen a application vendor that mandates a hypervisor, but doesn't care if it's deployed in a non-supported configuration. I could see EPIC and the like having a good laugh though if you ask them.
You mean you've never seen a good vendor do that right? I've definitely seen it.
Who is a better EMR vendor than EPIC? They are kinda the gold standard and the #2 (Cerner) isn't going to support it either.
Even if we get into the smaller players (Care4, AllScripts) that are not supported either. That's also ignoring that the DB vendors in these cases (Cache, Oracle, etc) are going to not support it.Try telling a chief medical officer, or head a practice "Hey... so we are going to go with this no-name vendor for the application you spend 90% of your time in, because they would support Hyper-V on KVM on ESXi!"
What vendor and what nesting have you seen supported?
-
@storageninja said in Nested hypervisors?:
@wirestyle22 said in Nested hypervisors?:
I've never seen a application vendor that mandates a hypervisor, but doesn't care if it's deployed in a non-supported configuration. I could see EPIC and the like having a good laugh though if you ask them.
You mean you've never seen a good vendor do that right? I've definitely seen it.
Who is a better EMR vendor than EPIC? They are kinda the gold standard and the #2 (Cerner) isn't going to support it either.
Even if we get into the smaller players (Care4, AllScripts) that are not supported either. That's also ignoring that the DB vendors in these cases (Cache, Oracle, etc) are going to not support it.Try telling a chief medical officer, or head a practice "Hey... so we are going to go with this no-name vendor for the application you spend 90% of your time in, because they would support Hyper-V on KVM on ESXi!"
What vendor and what nesting have you seen supported?
Epic and Cerner are insanely expensive EMR's, EPIC even more so than Cerner. I used Cerner at Barnabas Health. It doesn't apply to most people here.
-
@scottalanmiller said in Nested hypervisors?:
This would work, as only one vendor supports the virtualization of another hypervisor (and only for a niche use case) that I'm aware of.
Most vendors specify that X hypervisor must be there, and specify nothing of what is beneath it.
Beyond the performance hit on the IO path (lot of interrupts make this not efficient) this is the same as running on non-supported hardware.
If a vendor uses Oracle DB and says "We use Oracle" and you run Oracle on a x86 emulator on a Raspberry Pi, I can see you trying to claim a loophole, and I can also see the vendor not wanting to support you.
-
@wirestyle22 said in Nested hypervisors?:
Epic and Cerner are insanely expensive EMR's, EPIC even more so than Cerner. I used Cerner at Barnabas Health. It doesn't apply to most people here.
All-Scripts support (Small Clinical EMR) is not going to support this config either.
-
@storageninja said in Nested hypervisors?:
If a vendor uses Oracle DB and says "We use Oracle" and you run Oracle on a x86 emulator on a Raspberry Pi, I can see you trying to claim a loophole, and I can also see the vendor not wanting to support you.
haha. . . now I have a project to go work on, thanks for that. . . JERK!
-
@dustinb3403 said in Nested hypervisors?:
@storageninja said in Nested hypervisors?:
If a vendor uses Oracle DB and says "We use Oracle" and you run Oracle on a x86 emulator on a Raspberry Pi, I can see you trying to claim a loophole, and I can also see the vendor not wanting to support you.
haha. . . now I have a project to go work on, thanks for that. . . JERK!
I mean, X86 Emulator, on ARM emulator, on SPARC. I mean... TECHNICALLY it's supported Oracle hardware! I mean come on, I thought this was America, Why CAN"T I GET SOME DAMN SUPPORT AROUND HERE!
-
I think the case to be made here can be equated to "We can only support you if you are using X server platform".
I've had vendors outright tell me they refuse to support anything newer than Windows Server 2008 SP1, and that it had to be physical. This was in 2012. . .
The same argument is kind of being made here "We can only support the workload if it's on <hypervisor>" Which you have to ask, if you only support the workload on <hypervisor> does that also mean you're supporting the entire stack?
If not, why the heck do you care what hypervisor the workload is residing on?
-
Which I won that argument with the vendor, it's virtual and running on Server 2012 SP2 (at least it was when I left) and they had no complaints with it.
For the money that was spent on JobBOSS they had better support us so long as we're using a Windows server guest.
-
Now if you bought a product from a vendor, and they state it does these AMAZING things, look for the fine print. I bet it states under what conditions the system is capable of performing those things, and the configurations to achieving them.
And the expectation at that point is that the vendor is supporting the entire stack because of that fine print.
-
@dustinb3403 said in Nested hypervisors?:
Now if you bought a product from a vendor, and they state it does the AMAZING things, look for the fine print. I bet it states under what conditions the system is capable of performing those things, and the configurations to achieving them.
And the expectation at that point is that the vendor is supporting the entire stack because of that fine print.
A lot of the ISV stuff isn't just testing, but joint engineering relationships. If I have an issue with Cache, It's nice to know that the storage vendor, hypervisor vendor, and cache all have a strong working relationship so I don't get stuck as the integrator (or person trying to force groups to work together and burn costs that don't have an incentive to otherwise).
-
@storageninja absolutely, but in a lot of cases this is where your HCL comes into play.
Sure you might get XenServer installed on an Pi, but it doesn't mean that Citrix would ever sell you support.
-
@dustinb3403 said in Nested hypervisors?:
@storageninja absolutely, but in a lot of cases this is where your HCL comes into play.
Sure you might get XenServer installed on an Pi, but it doesn't mean that Citrix would ever sell you support.
Bingo. Hence my doubt that an Application vendor would be cool with supporting a hardware configuration that isn't supported by a hypervisor vendor. Given that they CAN"T really fix that problem (App vendors don't write nested paravirtual VMTools and drivers) It would actually be a sign of a bad app vendor to say "ohh yah that's cool".
Fun fact, ESXi actually offers nested VMTools (vmtoolsd VIB) to help with nesting it on itself. Nesting it on another hypervisor and trying to mitigate a lot of the quirks would require you port paravirtual drivers to ESXi VIBs. That would get fun
