How can you designate nested versus unnested hypervisors, and where would the technology best be used?
Nested virtualization allows a hypervisor to run within a virtual machine. In theory, there is no limit to the level of nesting that can occur, and it can be confusing to know just how "deep" a nested VM actually is. One common means of designating a hypervisor's nesting level is to use a "level" -- or L -- designation starting at zero and ascending with each additional level. For example, the original host hypervisor that runs on the server's bare metal is dubbed Level 0, or L0, while the guest hypervisor that runs atop the host hypervisor (L0) would be Level 1 (L1). From a practical standpoint, there is little compelling reason to nest further, but a guest hypervisor that runs atop an L1 guest would be called Level 2 (L2) and so on.
So why use nested virtualization at all? Isn't one hypervisor enough? There's little question that virtualization has brought powerful benefits to the enterprise, but one notably absent capability has been heterogeneity -- the ability to mix hypervisors on the same server. For example, when a bare-metal hypervisor (L0) was installed, VMs and supporting tools, like snapshot or migration tools, had to run on that hypervisor, period. If you wanted to work with a different hypervisor, you typically had to set up another server and install the alternate L0 hypervisor and supporting tools there.
Nested virtualization is a way of addressing this niche limitation by allowing a server with hypervisor X to host VMs with hypervisors Y, Z and more without additional hardware. For example, nested virtualization can be used to host a virtual desktop infrastructure and endpoint instances atop a different hypervisor, or mix VMs with application virtualization platforms atop VMs created with server virtualization products. It's also a convenient way to create and support flexible, nonproduction development environments that use differing hypervisors and tool sets.
But the real long-term benefit for nested virtualization can eventually come in data center hosting or outsourcing scenarios. Today, if you engage a hosting or outsourcing provider, you basically need to use the same hypervisor employed by the provider. This could limit your choice of provider or force time-consuming VM conversions. The advent of nested virtualization could allow you to simply migrate any VMs to any provider -- or even switch providers -- regardless of the prevailing L0 host hypervisor; your VMs would just exist as L1 or even L2 VMs in the provider's environment. It's the ultimate flexibility.
Does VMware Converter make a difference using nested VMs?
How do VDI hardware requirements differ from virtualization?
Hyper-V nested virtualization makes Windows containers a reality
Dig Deeper on Virtual machine monitoring, troubleshooting and alerting
Related Q&A from Stephen J. Bigelow
OpenStack scheduled numerous hypervisors for deprecation in 2014's OpenStack Icehouse, but no others are scheduled for future releases, up to and ...continue reading
There are many differences between OpenStack-supported hypervisors, but only some features are mandatory. Adopters need to review feature sets as ...continue reading
VIC supports container creation and image deployment through virtual container hosts, which suit well-proven workloads, or Docker container hosts, ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.