Re: [Libguestfs] Xen drivers for virt-builder images
On Thu, Jun 12, 2014 at 07:04:06PM +0100, George Dunlap wrote:
Right, well after managing to work around our corporate transparent
caching proxy to actually get the new version, I've tested it and it
works great. Thanks.
Thanks for testing. I'll make the same change to CentOS, but
that will take a bit longer to build & upload.
On Thu, Jun 12, 2014 at 4:13 PM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> While I have your attention ...
>
> It'd be great if libguestfs could use Xen as a backend (in addition to
> current qemu, KVM and UML backends). Most likely that would involve
> one of two approaches:
>
> (1) Modify the libvirt backend (src/launch-libvirt.c) so it works
> properly when the hypervisor is Xen. If you buy into libvirt, this
> one is probably going to be less code.
>
> (2) Add a new backend (src/launch-xl.c ?) which uses native Xen APIs
> to create the appliance.
Considerations:
* libvirt has had basic libxl support for some time. I doubt you're
doing advanced things like migration or PCI pass-through, so I think
using a recent libvirt could be made to work without too much
difficulty.
* Depending on exactly what features you use, libvirt doesn't actually
abstract away the hypervisor details: you may need to have specific
options for Xen anyway. For example, you'll need to ask for Xen
devices rather than virtio devices.
We don't do anything complicated at all. However definitely different
from KVM assumptions made by the current libvirt backend. The current
libvirt backend is known not to work with Xen (in fact, it includes
code to tell you that if you try it).
Here is the libvirt backend code:
https://github.com/libguestfs/libguestfs/blob/master/src/launch-libvirt.c
XML generation starts on line ~826.
* Still, it's probably a lot less code / testing to just use
libvirt.
Yes, I definitely think #1 is going to be less code.
* But, it introduces another dependency that you need to have
installed in order to use virt-builder on xen.
* On the other hand, I suspect most distros will have a
libguestfs->libvirt dependency anyway.
Upstream, I have steered away from using the libvirt backend. Running
qemu directly is the default. The reason is that the libvirt backend
adds complexity without a great deal of benefit for most users.
[That's less true if we're talking about supporting Xen because there
it gives us benefit by moving much of the Xen support code into
libvirt.]
In Fedora & RHEL we are using the libvirt backend by default, partly
because me & Dan Berrange are around to support it, and partly because
it allows us to use SELinux + cgroups to contain the qemu process
(somewhat analogous to driver-domains in Xen).
AFAIK no other distro uses the libvirt backend by default, but they
all ship it and you can switch to it by setting an environment
variable (whether it actually works or not is another question).
So it seems like going with #1 is probably the best, overall.
I'm not going to implement the Xen backend myself, but patches welcome
as they say.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW