I had an interesting conversation with a colleague of mine about, “what is vmware?”, “how does a VM access hardware features, like disk encryption (OPAL, TCG)?”, “what happens if two VMs want to use the same hardware, is that SRIOV or MRIOV allowing that?”, “if I add feature Z to the hardware, how much better will the VM be able to do Y?”, and so on…
The list of questions was quite long, and until I understood the perspective and experience base of my colleague, nothing I was using made any sense to him. After muddling through it I realized that for some folks, hardware folks in particular, the things we virtualization lovers live and breath everyday are completely foreign. It is not simple enough to say things like “hardware is abstracted”, or “its software defined”. A hardware engineer understands that there are special page tables, registers and instructions in the CPU for memory management, DMA between devices, interrupts to signal events, and caches to optimize performance. They understand there are AHCI controllers for SATA and RAID controllers for SAS and that NVMe will change the future.
What a hardware engineer struggles with is how hardware can be abstracted to the point that a guest operating system running in a VM can’t see the hardware, yet still depend on the hardware features to do its normal job as it would if it was on physical hardware. VMs have to see a chipset, a memory controller, a graphics card, a storage device, right? More importantly, some don’t understand why hardware should be abstracted at all. For them, hardware a beautiful creation with millions and billions of transistors that can push electrical pulses at blazing speeds from point A to point B. The moment I mention that a the VM can’t see any specialized hardware feature unless the hypervisor exposes it, the wheels start turning and even more questions pop up. Questions like, “what about SRIOV and how it allows VMs to share the hardware?”, and “what about the isolation that the CPU, MMU and IOMMU provide to VMs?” What is missing is how the hardware is used by the hypervisor and how the hardware is ultimately presented to the virtual machine.
There is no easy or quick answer to these questions but, I do have advice for anyone reading this. If you are a software engineer trying to explain to a hardware engineer what virtualization is, don’t focus on the buzzwords like software defined, or paravirtual device. Instead, focus on the why things like hardware abstraction exist, and why software defined anything is simpler to manage for the 100’s or 1000’s of servers and applications that are running on your virtual infrastructure. Also, make sure to explain why virtualization is around in the first place; to utilize hardware resources to their fullest and getting the most for your investment without sacrificing performance or manageability.
If you are a hardware engineer trying to make sense of what your hardware can do to improve, benefit or add value, focus on the hypervisor rather than the VM. The hypervisor is the OS, and it has drivers just like any other OS. The hypervisor uses the hardware, and presents the VM with a view to the hardware and neither the VM nor its applications are interested in doing something proprietary to take advantage of your new bits and bytes. Rather the VM wants to take advantage of the hardware features (performance, scalability, reliability) without knowing what the hardware is, or how it does its magic. It should just work so that regardless of the host the VM is running on, it continues to run, and continues to be a reliable service to the enterprise.