Nested hypervisors?
-
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.
-
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?
ThoughtWorks uses Centos 6.7 for there Bahmin EMR and it is the recommended without updates, also as vendor they dont want the complexity of Virtualization so they love to deploy real iron
https://bahmni.atlassian.net/wiki/spaces/BAH/pages/33128505/Install+Bahmni+on+CentOS
Future plans to fix this is docker, and containers which I get but performance will suffer, currently they use centos + ansible + scheduled remote sessions which works great we just need the base updated (for the last 2 years this is still feature request), Centos latest is already behind.
And dont get me started on the cost, cost has nothing to do it, it is always decisions made without IT people and after the decision is made, IT people raise concerns and they get cock blocked and treated like they are harming the project.
Point = TW are way over rated, dont ever consider them.
-
@emad-r said in Nested hypervisors?:
also as vendor they dont want the
complexityadvantages of Virtualizationftfy
