Re: [Libguestfs] [libvirt] [PATCH libguestfs 0/4] Add a libvirt backend to libguestfs.
On Mon, Jul 23, 2012 at 11:21:37AM +0100, Daniel P. Berrange wrote:
On Mon, Jul 23, 2012 at 11:02:41AM +0100, Richard W.M. Jones wrote:
> It's using NULL and expecting libvirt to choose the appropriate
> connection URI, which does appear to work.
Apps should only rely on NULL, if they are able to work with any
possible hypervisor. If you have specific requirements for QEMU
you should always request QEMU explicitly. A local sysadmin may
well have set a different default URI using an env variable or
$HOME/.libvirt/libvirt.conf which will give you an unexpected
choice.
Currently the administrator can set the attach-method to one of:
"appliance" (default): run qemu directly
"libvirt": run libvirt with conn URI = NULL
"libvirt:URI": run libvirt with conn URI = "URI"
We could make "libvirt" mean "choose qemu:///session or
qemu:///system".
Then if they want NULL, we could have "libvirt:" (colon followed by
empty string) or "libvirt:NULL" or something else.
Alternatively you could just say to hell with it, and require
the application to pass in a pre-opened virConnectPtr that
you use. This is actually quite desirable, since it will avoid
the user having to authenticate multiple times, when the app
already has an open connection
Unfortunately this is hard to implement. Specifically we cannot
generally convert a language-specific object (eg. a Perl Sys::Virt
object) into a virConnectPtr. Been discussed before a few years back
when we wanted to pass virDomainPtr to a libguestfs call. There is
even non-working support in the generator for this ...
In true garbage-collected languages it's even harder to get it right.
How would you stop the connection object 'conn' from getting collected
and closed too early in OCaml code such as:
conn = Libvirt.Connect.connect_readonly ()
g#attach_libvirt conn;
(* as far as OCaml is concerned, conn is unreferenced from here onwards *)
g#launch ();
g#do_lots_of_stuff ();
g#close ()
The language bindings would have to model the lifetime of every object
that could potentially be attached to the libguestfs handle.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top