Thanks for the update. This is good news.
On Wed, May 14, 2014 at 4:53 AM, sebgoa <run...@gmail.com> wrote: > > On Apr 9, 2014, at 2:37 PM, Dave Scott <dave.sc...@citrix.com> 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…:) ). > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;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. > > -Sebastien > > > > > 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 > capabilities'?) > > > > 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] > http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e > > > > [2] > https://github.com/jamesbulpin/cloudstack/commits/jamesb_xen_exploratory > >
