Ask Your Question
1

Is it possible to use nested KVM w/ Nova?

asked 2013-10-24 07:19:07 -0500

jasonbrooks gravatar image

It's my understanding that the removal of the Cheetah templating ( https://www.berrange.com/posts/2012/11/16/what-was-new-in-libvirt-for-the-openstack-nova-folsom-release/ ), in Folsom, removed the option of using nested KVM with nova. Is there, or will there be, another way to accomplish this?

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted
0

answered 2013-10-24 08:12:52 -0500

sgordon gravatar image

updated 2013-10-24 11:02:23 -0500

As per the blog post you linked [1][2], the libvirt_cpu_mode and libvirt_cpu_model configuration keys were added when Cheetah was removed. These should, when set appropriately, facilitate the use of nested KVM:

Thus the second big change in the Nova libvirt driver was to introduce explicit support for configuration the CPU model. This involves two new Nova config parameters, libvirt_cpu_mode which chooses between host-model, host-passthrough and custom. If mode is set to custom, then the libvirt_cpu_model parameter is used to specify the name of the custom CPU that is required. Again there is a wiki page describing this in a little more details.

Once the ability to choose CPU models was merged, it was decided that the default behaviour should also be changed. Thus if Nova is configured to use KVM as its hypervisor, then it will use the host-model CPU mode by default. This causes the guest CPU model to be a (almost) exact copy of the host CPU model, offering maximum out of the box performance. There turned out to be one small wrinkle in this choice when using nested KVM though. Due to a combination of problems in libvirt and KVM, use of host-model fails for nested KVM. Thus anyone using nested KVM needs to set libvirt_cpu_model=none as a workaround for now. If you’re using KVM on bare metal everything should be fine, which is of course the normal scenario for production deployments.

These flags are used to determine the CPU exposed to virtual machine instances running on libvirt hypervisors (virtual or other wise) managed by Nova. Note that based on Christian's findings [3] you may find that libvirt_cpu_mode=host-passthrough might be what you after these days (remembering that Dan's post suggesting the use of libvirt_cpu_mode=none was based on the state of the code base in the Folsom release).

[1] https://www.berrange.com/posts/2012/11/16/what-was-new-in-libvirt-for-the-openstack-nova-folsom-release/

[2] https://wiki.openstack.org/wiki/LibvirtXMLCPUModel

[3] http://www.cberendt.de/2013/03/usage-of-nested-virtualization-inside-instances/

edit flag offensive delete link more

Comments

Also, **libvirt_cpu_model=”none”** is a fix for migration problems if you have slightly different CPUs.

dasp gravatar imagedasp ( 2013-10-24 08:21:23 -0500 )edit

I understood this to mean: make these config tweaks to allow for running openstack under nested KVM, I've done this. What I'm interested in is hosting VMs in openstack that are capable of running guests themselves using nested KVM. I thought this wasn't possible, but I hope I'm wrong!

jasonbrooks gravatar imagejasonbrooks ( 2013-10-24 10:37:00 -0500 )edit

Running Nova as a VM under nested KVM doesnt require these nova.conf changes as the nesting would instead be configured on the underlying hypervisor. These flags are used to determine the CPU exposed to virtual machine instances running on libvirt hypervisors (virtual or other wise) managed by Nova.

sgordon gravatar imagesgordon ( 2013-10-24 10:56:37 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-10-24 07:19:07 -0500

Seen: 2,074 times

Last updated: Oct 24 '13