Nested hypervisors?
-
@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
-
@storageninja said in Nested hypervisors?:
@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
But that isn't the conversation we're having. We're discussing an App vendor specifying a Hypervisor that the guest has to be installed on.
Which 99.9999% of the application vendors in the world, don't operate at the hypervisor, but a guest on the hypervisor. Which is where this weird conversation of nested hypervisors came from.
-
An app vendor saying "you have to use X guest on X hypervisor" is a weird requirement. Unless there was a very specific feature/function that the guest somehow can can flex by using a specific hypervisor, and is the reason you as the customer engaged the app vendor.
-
@dustinb3403 said in Nested hypervisors?:
An app vendor saying "you have to use X guest on X hypervisor" is a weird requirement. Unless there was a very specific feature/function that the guest somehow can can flex by using a specific hypervisor, and is the reason you as the customer engaged the app vendor.
It comes from a few cases....
- VDI often hooks the hypervisor.
- It comes from the fact that customers often ask the app vendor for performance and configuration advice, and to be fair it's kinda nice when everyone doesn't live in a silo at their ring.
- It boils down to who gets blamed for an outage. An Application vendor is often expected to produce or support a RCA, and if the storage platform is Ceph running on BSD and they can't provide it the customer management may throw the baby out with the bathwater (It's not right, but it happens enough).
- Nested Hypervisors have a lot of CPU overhead issues (Good luck finding a NUMA boundary through it), and storage latency is rarely consistent without taking extreme measure. Both of these can represent themselves as application layer problems. The complaints start at the app layer, as do RCA's on issues. They carry a lot of costs if people are constantly calling them and they are constantly having to investigate and say "it's your wacky Jenga pile of hypervisors".
If we lived in a mythical land where people didn't hold application vendors accountable to performance and availability this might work. Sadly that's not how things work. I can't tell you how many times people yelled and blamed and replaced "Shitrix" when the problem was a bad storage config.
-
@storageninja The hypervisor is to the guest what hardware was to a physical OS install. There are plenty of examples where the vendor says hardware x,y,z works and is approved, aka HCL. That the vendor specifies what hypervisors are tested and compatible is equally logical and common.
And of course most applications don't have any requirements on the hypervisor and they didn't have it on the hardware either.
