Daniel P. Berrange
2010-Apr-15 16:47 UTC
[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); 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 :|
Richard W.M. Jones
2010-Apr-17 09:14 UTC
[Libguestfs] RFE: reuse of the libguestfs daemon + host API in a externally managed VM
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
Maybe Matching Threads
- plot.times error -- missing or illegal tck parameter (PR#601)
- How to generate 'minor' ticks in lattice (qqmath)
- `mgp[1:3]' are of differing sign (PR#14130)
- Re: [libvirt] [PATCH tck] Relabel SELinux when customizing virt-builder image
- 2.4.0 and lattice 0.14-9: Changed behaviour of scales-argumenttck