11:47 a.m.
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 :|
4:14 a.m.
New subject: 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
4:36 a.m.
On Sat, Apr 17, 2010 at 10:14:06AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 15, 2010 at 05:47:10PM +0100, Daniel P. Berrange wrote:
>
> 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).
I've been trying to think of flaws in this approach, but can't, so I
think this sounds good to me.
> 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.
Yep, I'd like APIs to retrive the kernl/initrd to avoid having to place
any knowledge of installed paths/prefixes in the app code.
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 :|
5252
days inactive
5259
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Richard W.M. Jones