On Thu, Jun 12, 2014 at 4:13 PM, Richard W.M. Jones <rjones@redhat.com> wrote:> On Thu, Jun 12, 2014 at 03:12:46PM +0100, Richard W.M. Jones wrote: >> >> Not quite as easy as I imagined. However by using the attached patch >> I have managed to add the two Xen drivers to the initramfs. (I >> haven't been able to test that it boots in Xen however) >> >> I'm just building an updated Fedora 20 image which I'll upload later >> today. > > The F20 image has been uploaded. You should notice when you install > it that it will download the full disk image again, and also that > a file "fedora-20.x86_64.2" will be created in ~/.cache/virt-builder/ > (.2 == revision 2) > > I tried various experiments, and it seems as if the Xen modules are > included in the initramfs even if you upgrade the kernel when running > virt-builder itself. So all looks good over here, but I didn't > actually try booting the disk image on Xen itself.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.> 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. * Still, it's probably a lot less code / testing to just use libvirt. * 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. So it seems like going with #1 is probably the best, overall. -George> > 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 > > _______________________________________________ > Libguestfs mailing list > Libguestfs@redhat.com > https://www.redhat.com/mailman/listinfo/libguestfs
Richard W.M. Jones
2014-Jun-12 18:27 UTC
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@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
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