Re: [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: > > 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).

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