Re: [Libguestfs] 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);