Re: [Libguestfs] Xen drivers for virt-builder images
On Thu, Jun 12, 2014 at 7:27 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
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.
The CentOS 6 and Scientific Linux 6 templates work fine already for some reason.
In fact, I've now tested all the templates, and they *all* have the
proper drivers, with the exception of fedora-19. (And of course
rhel-7rc, which I guess will be going away soon now that RHEL 7 has
been released.)
fedora-18, all the ubuntus, all the debians, centos-6 and
scientificlinux-6 all boot out-of-the-box already.
> * 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.
Of course. :-)
Well I'll put it on a list of things to take a look at.
Thanks for your help,
-George