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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list