[Libguestfs] RFE: reuse of the libguestfs daemon + host API in a externally managed VM

Daniel P. Berrange berrange at redhat.com
Thu Apr 22 09:36:26 UTC 2010


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




More information about the Libguestfs mailing list