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