Libguestfs - Jun 2014 - Re: Xen drivers for virt-builder images

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.

Are there other guests that need to be updated in the same way?
The RHEL 7 RC guest probably no longer works, since it looks like
we've got and deleted the binary packages from ftp.redhat.com.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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.

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.

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 3:12 PM, Richard W.M. Jones <rjones@redhat.com>
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.
>
> Are there other guests that need to be updated in the same way?
Is there an easier way to tell than just trying them all? :-)

Assuming there's not, I'll do that as a background task, and let you
know what I find.  (That may be next week sometime.)

Thanks,
 -George

On Thu, Jun 12, 2014 at 04:37:56PM +0100, George Dunlap
wrote:
> On Thu, Jun 12, 2014 at 3:12 PM, Richard W.M. Jones
<rjones@redhat.com> 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.
> >
> > Are there other guests that need to be updated in the same way?
> 
> Is there an easier way to tell than just trying them all? :-)
> 
> Assuming there's not, I'll do that as a background task, and let
you
> know what I find.  (That may be next week sometime.)
Actually best thing to do now is to check the Fedora 20 image works on
Xen.  If it doesn't, then we'll have to go back to the drawing board.

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 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