On Wed, Aug 19, 2009 at 09:49:45AM -0400, Miloslav Trmac wrote:

----- "Daniel Veillard" <veillard@redhat.com> wrote:

...

On Sun, Aug 16, 2009 at 10:47:58PM +0200, Miloslav Trma?? wrote:

...

+static virDrvOpenStatus +remoteSecretOpen (virConnectPtr conn, + virConnectAuthPtr auth, + int flags) +{ + if (inside_daemon) + return VIR_DRV_OPEN_DECLINED; + + if (conn && + conn->driver && + STREQ (conn->driver->name, "remote")) { + struct private_data *priv; + + /* If we're here, the remote driver is already + * in use due to a) a QEMU uri, or b) a remote + * URI. So we can re-use existing connection + */

Hum, is that comment right ? We are certainly using a remote URI in any case there, isn't it ? The same comment is in in all of the other "subdriver" remote...Open () routines. It's not quite clear what "remote" means where, as far as I can see "remote" means an "explicitly remote" URL, e.g. anything+tls://hostname/..., and "QEMU" means "qemu://hostname/..." (rejected by qemu_driver).

This is a bit of a hairy area of libvirt. There are 3 scenarios in which this bit of code may execute: - A local stateful driver like qemu/lxc. The main hypervisor driver connection is going via remote daemon. So all security open methods like this one use that existing connection - A remote driver - any. All libvirt APIs go over the remote driver - A local stateless driver like Xen. The main hypervisor driver talks directly to the host. Only a subset of APis go to the demon Basically just copy the existing code from one of the other secondary driver open methods, as you have done, and all will be well :-) Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|