Testing oVirt 3.3 with Nested KVM

We’re nearing the release of oVirt 3.3, and I’ve been testing out all the new features — and using oVirt to do it, courtesy of nested KVM.

KVM takes advantage of virtualization-enabling hardware extensions that most recent processors provide. Nested KVM enables KVM hypervisors to make these extensions available to their guest instances.

Nested KVM typically takes takes a bit of configuration to get up and running: on the host side, you need to make sure that nested virtualization is enabled, and on the guest side, you need to make sure that your guest VM’s is emulating a virt-capable processor.

With oVirt, you can take care of both the host and guest configuration chores by installing a vdsm hook on your host machine(s):

$> sudo yum install -y vdsm-hook-nestedvt

Depending on your networking configuration, there’s a separate hook required to allow your nested host to pass traffic from its guests up through the machine in which it's hosted:

$> sudo yum install -y vdsm-hook-macspoof

Next, you need to enable the mac-spoofing option in oVirt’s web admin console, restart the engine for that setting to take effect, and restart vdsm for the two vdsm hooks to take effect:

$> sudo engine-config -s "UserDefinedVMProperties=macspoof=(true|false)" $> sudo service ovirt-engine restart $> sudo service vdsmd restart

After vdsm restarts, you can check to see that your hooks are installed in your host’s "Host Hooks" tab:

With the nestedvt vdsm hook installed, every guest launched from your nested-enabled hosts will inherit its own KVM-hosting capability. To enable the mac-spoofing, you have to visit the Custom Properties tab of the Edit Server Virtual Machine dialog, select "macspoof" from the "Please select a key" dropdown menu, and set the value to "true."

On my test machine, an HP ProLiant DL380p Gen8 with Sandybridge-family processors, I found that shortly after launching Fedora guest VM on my nested KVM hypervisor, the nested guest would pause and refuse to re-start. Casting about online for a solution, I found other, similar-sounding nested VM pause reports, with a suggested solution of running the problematic VMs with a earlier processor definition.

I got around this issue by changing the processor definition for my guest hypervisor from Sandybridge to Nehalem. oVirt makes this switch fairly easy — I took care of it by changing my cluster CPU type Sandybridge to Nehalem.

Nested KVM comes with a performance hit, but I’ve had no trouble testing oVirt (and other forms of KVM-based virtualization, such as OpenStack) in oVirt-hosted virtual machines.

Stay tuned for more coverage of oVirt 3.3, and be sure to follow us on Twitter at @redhatopen for news on oVirt and other open source projects in the Red Hat world.