Hi,
On 02/08/2013 10:34 AM, Dave Cahill wrote:
Hi,
Recently I encountered two "nested virtualization" use cases which made me
want QEMU hypervisor support in CloudStack. I'm interested to hear if
anyone else is interested in this feature, and any notes on how it should
be implemented.
Here is a good explanation from OpenStack docs [2] on why they support QEMU:
"From the perspective of the Compute service, the QEMU hypervisor is very
similar to the KVM hypervisor. Both are controlled through libvirt, both
support the same feature set, and all virtual machine images that are
compatible with KVM are also compatible with QEMU. The main difference is
that QEMU does not support native virtualization. Consequently, QEMU has
worse performance than KVM and is a poor choice for a production
deployment."
So, I've been reading into the code and found this on my Ubuntu systems.
root@stack01:~# ls -l /usr/bin/kvm
lrwxrwxrwx 1 root root 18 Oct 4 02:44 /usr/bin/kvm -> qemu-system-x86_64
root@stack01:~#
Imho Qemu is Qemu and KVM only comes into play when the kernel module
'kvm' and 'kvm_amd' or 'kvm_intel' is loaded.
Here are the use cases I encountered:
[Use case: Dev environment]
Wanted to use Vagrant [1] to create a portable multi-node dev
environment; however Vagrant uses VirtualBox, which doesn't support KVM.
Also, devcloud uses VirtualBox and devcloud-kvm uses kvm-within-kvm. I
imagine maintenance of devcloud and devcloud-kvm would be easier if
devcloud-kvm could use VirtualBox too.
Note: Of course, I'm aware of devcloud-kvm as an alternative for this
use case, and I'll be looking into that next.
[Use case: Demo environment]
We may want to spin up a multi-node CloudStack install in Amazon AWS
for demo purposes.
Again, AWS instances don't support KVM, so this is not possible without
QEMU support.
[Implementation ideas]
The management server currently does a check for KVM support ("kvm-ok")
on the host, and refuses to add the host if that fails. I think this check
could be removed, as the agent setup scripts will fail anyway if the user
is trying to setup a certain hypervisor on a machine which doesn't support
it.
This way you could do nested virtualization indeed, but it could also
hurt users who have their BIOS set to disabled and could lead to long
debugging.
Create a new setting in agent.properties like "use_qemu", with a
default of "false". If the person deploying CloudStack agent sets this to
"true", cloud-setup-agent and other setup scripts would ignore lack of KVM
support as long as QEMU support was available.
cloud-setup-agent generates a agent.properties, so at that point it
doesn't know that the user intents to use the system without KVM support.
Lastly, when creating the libvirt XML file for a VM, set hypervisor to
QEMU rather than KVM in the XML file depending on the config setting.
That's not hard coded. The Agent does a getCapabilities() call to
libvirt which returns a list of possible emulators.
/usr/bin/kvm is just one of them which is returned and matches the
architecture.
Wido
Thanks for reading,
Dave.
[1] http://www.vagrantup.com/
[2]
http://docs.openstack.org/trunk/openstack-compute/install/yum/content/qemu.html
