Libguestfs - Apr 2010 - RFE: reuse of the libguestfs daemon + host API in a externally managed VM

The libvirt-TCK is a integration test suite we are using to validate the
correct operation of libvirt drivers. Currently it is just checking the
basic operation & functionality of drivers from the host side. we just 
boot a random Fedora kernel + initrd since we don't actually care that 
the guest OS boots into any particular state, we only care that its 
running in some form.

We would like to extend our tests, to include validation of changes inside
the guest. For example, in the TCK test case for CDROM media change, we 
want to be able to validate that the guest OS can actually see the new 
media. Or in disk hotplug we want to validate that the new PCI device 
appeared in the guest. etc etc.  This requires that we have a real guest
OS image running + some form of channel to get data out of the guest OS.

To me it looks like the libguestfs appliance image / guest daemon would
fit our needs just fine. On the host side, the libguestfs Perl bindings
also fit the bill nicely.

The only issue is that the guest VM can't be under libguestfs' control.
The libvirt TCK test cases need to spawn / control the guest in whatever
config it needs. 

My thought is that anytime the libvirt TCK needs a guest OS it can talk
to, it can simply configure its VM to point at the libguestfs appliance 
image. Then tell the libguestfs API to attach to this pre-running VM via 
whatever chardev channel libvirt configured.

IIUC, this could be a change such that instead of:

  guestfs_launch(h);

the app could do:

  guestfs_attach(h,
"/var/run/libvirt-tck/virtio-serial-guestfs.sock");

But perhaps also allow query of the expected kernel/initrd, so apps
don't have to hardcode those location

  vmlinuz = guestfs_appliance_kernel(h);
  initrd = guestfs_appliance_initrd(h);

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Thu, Apr 15, 2010 at 05:47:10PM +0100, Daniel P. Berrange
wrote:
> The libvirt-TCK is a integration test suite we are using to validate the
> correct operation of libvirt drivers. Currently it is just checking the
> basic operation & functionality of drivers from the host side. we just 
> boot a random Fedora kernel + initrd since we don't actually care that 
> the guest OS boots into any particular state, we only care that its 
> running in some form.
> 
> We would like to extend our tests, to include validation of changes inside
> the guest. For example, in the TCK test case for CDROM media change, we 
> want to be able to validate that the guest OS can actually see the new 
> media. Or in disk hotplug we want to validate that the new PCI device 
> appeared in the guest. etc etc.  This requires that we have a real guest
> OS image running + some form of channel to get data out of the guest OS.
> 
> To me it looks like the libguestfs appliance image / guest daemon would
> fit our needs just fine. On the host side, the libguestfs Perl bindings
> also fit the bill nicely.
> 
> The only issue is that the guest VM can't be under libguestfs'
control.
> The libvirt TCK test cases need to spawn / control the guest in whatever
> config it needs. 
> 
> My thought is that anytime the libvirt TCK needs a guest OS it can talk
> to, it can simply configure its VM to point at the libguestfs appliance 
> image. Then tell the libguestfs API to attach to this pre-running VM via 
> whatever chardev channel libvirt configured.
> 
> IIUC, this could be a change such that instead of:
> 
>   guestfs_launch(h);
> 
> the app could do:
> 
>   guestfs_attach(h,
"/var/run/libvirt-tck/virtio-serial-guestfs.sock");
As a matter of the API, I'd prefer if we could configure the handle so
that guestfs_launch(h) would do the right thing.  The reason is that
there's a lot of existing code and we don't want to have to change all
those existing calls to guestfs_launch().  A suitable API might be:

  g = guestfs_create ();
  guestfs_set_method (g, "attach");
  guestfs_set_path (g, "/path/to/socket");
  guestfs_launch ();

And then allow these calls to guestfs_set* to be omitted by setting
environment variables.  (Note that guestfs_set_path already exists,
and there is already a corresponding environment variable called
LIBGUESTFS_PATH).

Now you don't need to change existing code at all.  Just change its
behaviour by exporting some environment variables.
> But perhaps also allow query of the expected kernel/initrd, so apps
> don't have to hardcode those location
> 
>   vmlinuz = guestfs_appliance_kernel(h);
>   initrd = guestfs_appliance_initrd(h);
Might be more regular to use guestfs_get_appliance_kernel and
guestfs_get_appliance_initrd.

Note that you can already get this using external tools: either just
read the appliance from $libdir/guestfs (in the non-supermin case) or
use libguestfs-supermin-helper program (in the supermin case).  This
requires some knowledge of how libguestfs works internally which has
changed in the past and might change in the future, so as you say,
adding guestfs_get_appliance_kernel / _initrd functions might be
better.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw