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