On Thu, Jun 12, 2014 at 7:27 PM, Richard W.M. Jones <rjones@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