incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: QEMU support in CloudStack
Date Fri, 08 Feb 2013 18:01:58 GMT
I'm running a quick sanity test here... just seeing if switching out
kvm with qemu works, all else the same. Looks like there's a
setHvsType for the LibvirtVMDef as well, that's hardcoded to 'kvm'.
That should be easy to adjust as well, assuming everything just runs
with these changes.

On Fri, Feb 8, 2013 at 10:54 AM, Alex Huang <Alex.Huang@citrix.com> wrote:
> In that case, why not create two resources with the kvm resource extending the qemu resource
and do what Marcus suggests here in the qemu resource?
>
> Effectively then we have an agent for qemu and one for kvm and they each can carry their
own capabilities.
>
> --Alex
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Friday, February 08, 2013 9:41 AM
>> To: Sebastien Goasguen
>> Cc: Wido den Hollander; cloudstack-dev@incubator.apache.org
>> Subject: Re: QEMU support in CloudStack
>>
>> You would in theory have to disable the check in the agent startup
>> code that looks for the kvm kernel modules, and then libvirt should
>> just fall back to qemu for everything automatically.
>>
>> In LibvirtComputingResource.java, comment out the check for
>> IsHVMEnabled, and then rmmod any kvm modules, then try to do stuff
>> with that version of cloudstack.
>>
>> On Fri, Feb 8, 2013 at 10:10 AM, Sebastien Goasguen <runseb@gmail.com>
>> wrote:
>> >
>> > On Feb 8, 2013, at 3:07 PM, Wido den Hollander <wido@widodh.nl> wrote:
>> >
>> >> 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,
>> >
>> > So can I add a "KVM" host that would in fact just use qemu ?
>> > How would I do that ?
>> >
>> > -sebastien
>> >
>> >
>> >> Wido
>> >>
>> >>> Thanks for reading,
>> >>> Dave.
>> >>>
>> >>> [1] http://www.vagrantup.com/
>> >>> [2]
>> >>> http://docs.openstack.org/trunk/openstack-
>> compute/install/yum/content/qemu.html
>> >>>
>> >>
>> >

Mime
View raw message