cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: Support pure Xen as a hypervisor follow-up
Date Wed, 14 May 2014 08:53:34 GMT

On Apr 9, 2014, at 2:37 PM, Dave Scott <> wrote:

> Hi,
> Following up from Tim's "Support pure Xen as a hypervisor" proposal last month[1] I'd
like to start working on this and maybe even make a little bit of progress while I'm at CCC
in Denver.
> Helpfully James Bulpin managed to get CS + libvirt + xen to start an instance in a simple
configuration. Although the patches[2] are not intended to be production-ready :) they help
highlight some of the areas we need to change.

Dave, just to let you know that Tim has done some important "refactoring" to split up XenServer
hypervisor in CS between Xen and XenServer. That way we could keep using xapi for XS but start
moving to libvirt for Xen.

Tim worked in the xen2server branch (don't ask about the name, I messed it up…:) ).;a=shortlog;h=refs/heads/xen2server

Would be nice to see some of the libvirt stuff in that branch to handle a new driver for Xen.

Since the two hypervisors will be split up, we could still drop in some early libvirt patches
to handle Xen and put this in 4.5 as a wip.


> Some of the areas are:
> 1. hypervisor detection
> Where we currently look for KVM specifically ("lsmod | grep kvm") we could switch to
either detecting any Linux hypervisor (by reading /sys/hypervisor/type) and assuming if a
hypervisor is present then we can use libvirt on it (is this a fair assumption?) Or we could
white-list “kvm” or “xen”. Or we could query libvirt directly (perhaps via 'virsh
> 2. fiddling with the domain.xml
> When starting a domain via libvirt the XML configuration has hypervisor-specific stuff
in it. Some of this is easy to change like:
>  <domain type='kvm'>
> obviously becomes
>  <domain type='xen'>
> and
>  <emulator>/usr/libexec/qemu-kvm</emulator>
> should probably be
>  <emulator>/some/other/path/qemu-dm</emulator>
> Some is a bit more invasive (to the VM) such as the virtual hardware type should be switched
from "virtio" to "xen" (and the block device in Linux will change from /dev/vd* to /dev/xvd*)
and we'll have to either implement or work around the lack of
>  <channel type='unix'> ...
> -- I presume this is a control channel into the system VM. Perhaps we could implement
this in libvirt/libxl using vchan?
> 3. system VMs?
> It would be very convenient if the system VM images could work on both xen and KVM. This
is probably doable as long as we don't bake in virtual hardware specific information (such
as /dev/vda) in the image. We could use the qcow2 format in both cases. What do you think?
> … and I’m sure there’s more.
> Anyway, feedback would be welcome. If anyone else in Denver wants to chat, then come
grab me later!
> Cheers,
> Dave Scott
> [1]
> [2]

View raw message