We hear some people chanting that the Hypervisor is a commodity. What they actually mean is that for an administrator it doesn’t really matter that much if his Windows VM / Application is running on an ESXi, Hyper-V or KVM host. We have a certain level of maturity in virtualization that the differentiation of choice is in higher levels of management.
What is a commodity?
A commodity is a service/product where the choice of manufacturer/vendor is irrelevant and interchangeable without any impact on the consumarization. In technology we can plug a server in 220V power off the grid the same way as we can use 220V battery backed power. In virtualization the hypervisors can run on any x86 server, whether it comes from HP, DELL, Lenovo, SuperMicro, Quanta, Cisco, … and the running VM is completely interchangeable without any impact. Some may argue for Intel being a common denominator that doesn’t make it commodity but for the sake of making a case I’ll accept Intel being a commodity for me.
Why is the hypervisor NOT commodity?
Moving a VM from one hypervisor to another will still need a migration. There are at least 3 reasons for this;
- the VM config file is proprietary to the hypervisor
- the VM disk format is proprietary to the hypervisor
- the VM guest drivers are proprietary to the hypervisor
As long as I am not capable of booting a KVM machine with QCOW2 disks and RedHat VirtIO drivers on an ESXi, the hypervisor is not a commodity. As long as I can’t live migrate a VM from Hyper-V to ESXi, the hypervisor is not a commodity.
My $0.02
How many of you actually need to run multi-hypervisor environments in which VMs need to be interchangeable? I know there are (every day better) migration tools to get you from one platform to another but how much do you want this? And how many times? I’d rather do application migrations between different Windows Machines than changing machine config files, disk formats and guest drivers. What about you?
Hi Hans,
There are a couple of flaws in your reasoning.
First you can’t compare a power plug with running a vm on a hypervisor. If I want to unplug an re-plug somewhere else, my apparatus requiring the power might go down. Same goes for VMs that move from one to another.
Second, in light of the first, I can convert VMs. I need to when moving from say an ESX to KVM or vice versa. Yes it scares the living daylights out if me too for production VMs, but so did VMware converter when I still worked for VMware.
Commodity can also mean that a method is commoditized. Running a VM on a hypervisor, even with the differences out there, all has a similar end result. I can run more on one system and may even have the capability to move them while running.
However, having said all this… I do agree with the you that using the term commodity hypervisor is a bit far fetched, but running virtual machines isn’t.
One final thought, why does it have to be about the hypervisor? Isn’t it about the service or application your trying to provide and not the VM?
Hi Yvo,
Thanks for chiming in and your two cents on the matter. The power analogy is actually quite accurate. Not only is the electricity grid a classic example of a commodity in any industry (the same product from any vendor), it even applies to what I was saying: on a server with 2 PSUs (power supplies) you can easily have 1 outlet on the grid and one on battery backed power and you can change as much as you want as long as at least one of them stays connected at all times.
The whole idea of commodity is the interchangeability without any impact. If you want to call it migration or converting, that’s just a matter of choosing the right words in the right context. Bottomline is that you cannot run a VM of one hypervisor on another without changing core bits and bytes of the VM. Hence the Hypervisor is not a commodity in the true meaning of the word. This was the only intent to point out in this post.
Of course it’s about delivering a service. That’s exactly the distinction I made in the introduction where I point at the differentiation is in the management and control layers. But that’s a whole other discussion for another time 😉
[…] De Leenheer wrote on his blog in 23 April […]