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