[libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen

[Daniel P. Berrange]

On Thu, Aug 21, 2008 at 10:42:51AM +0100, Daniel P. Berrange wrote:
> Well, ok so let me step back a bit because there's actually several
> layers to this issue...
> 
>   - The libvirtd is single threaded. This was reasonable at first, but
>     some of our APIs take a long time to complete, so we need to have
>     libvirtd parallelized.
> 
>   - The QEMU/LXC drivers have state stored in the daemon, so even if
>     you merely allow libvirtd to parallelize by putting long running
>     connections in the 'background' you ned to have locking in the
>     QEMU/LXC drivers.
> 
>   - Given that we need to have locking anyway, might as well just make
>     the libvirtd daemon properly multi-threaded, rather than trying to
>     have a multi-request queuing system.
> 
>   - Once you've done all that, then solving the virError thread-local
>     issue is all that remains to allow virConnect to be accessed by
>     multiple threads
>  
> We need to do 1->3 in order to make libvirtd more scalable. At which
> point 4 becomes 'not very hard' :-)
> 
> That said, there is one other option I've thought about instead of 
> doing step 4, we could add a  'virConnectDup' method. This would take
> an existing connection object, and create an independant copy of it
> that another thread could use. The key would be that the internal
> driver would automagically pass authentication credentials somehow,
> so you wouldn't have to re-authenticate the 2nd connection. For the
> remote driver, this could be as simple as invoking an RPC call to
> fetch a one-time key, and passing that to the 2nd connection to use
> as their authentication credential.

Actually the one-time key idea wouldn't work because that wouldn't let
us negotiate the session encryption, which is done by SASL at the time
we authenticate the client. Rich suggested perhaps sharing a single
TCP connection and multiplexing messages on it - we have a serial number
with every message/reply so this is doable in theory. It'd require some
fun code to hand-off replies between the virConnect objects sharing the
connection, but might be more viable in general. 

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