[Libvir] Preliminary patch to support remote driver / libvirtd

[Mark McLoughlin]

On Wed, 2007-01-31 at 20:06 +0000, Daniel P. Berrange wrote:
> On Wed, Jan 31, 2007 at 07:07:13PM +0000, Mark McLoughlin wrote:

> >   - If libvirtd is going to be a pure proxy, I don't think the UNIX 
> >     transport is going useful.
> 
> It will be useful for the local Xen case - letting us have a full
> read-write connection to Xen even when unprivileged - so we would no
> longre have to run virt-manager as root. 

	Isn't that what the existing proxy does? Are we talking about dumping
that?

	(Which reminds me, we can and should auth by uid with the UNIX
transport)

> >   - Also, if it's just a proxy, couldn't this be launched by xinetd?
> 
> That sounds like a reasonable option to allow - at the same time its 
> nice to have a persistently running daemon to avoid having to re-init
> all the one-time TLS stuff for every connection because that can take
> a non-negligable time & deplete /dev/random unneccessarily

	Yep, agreed - you can mitigate the problem by continuing to handle new
requests once started and hang around for a time when the last client
disconnects ... but bleh.

	(Total tangent - since xinetd is supposed to be a "resource conserving
super-server", I wonder if you could do something where xinetd keeps a
cache of TLS params and passes them to servers when they start ... that
might be cool)

> >   - getaddrinfo() is a pretty complicated function, so the code above 
> >     is pretty obtuse without a thorough read of the getaddrinfo() man
> >     page
> 
> It may be complicated - but this is only because doing the correct thing
> for IPv6 is complicated - the traditional getaddr/host  related functions
> all have a number of flaws which make them unsuitable for modern day
> usage.

	Seriously, if you see that the code I posted *isn't* correct, then I'd
like to hear it ... but I don't think you are saying that ...

	(I'm not being a smartass ... this code is recent and could well be
buggy)

> >   - you really want to end up with *either* a single IPv6 socket or and 
> >     IPv4 socket ... the above code can end up with multiple sockets. 
> 
> It can end up with multiple sockets because if a machine has multiple NICs,
> it is perfectly possible for a single address to  be associated with multiple
> NICs. Thus to bind to all interfaces associated with an address, it may be
> neccessary to have multiple sockets.  

	Absolutely. But we're not binding to a specific address. Hence, we do
only want a single socket.

	Or to put it another way, if you just want to bind to inaddr_any, then
getaddrinfo() just complicates things.

	For example, on a host with IPv4 and IPv6 address configured, does
make_sockets() attempt to bind an ipv6 socket to the port, or an ipv4
one, or both?

	I suspected it would first try ipv6, then fail at bind() with the ipv4
socket, but I had to write some test code to be sure.

	There's one caveat to all this - if the code is ported to a system
which *requires* both an IPv4 and IPv6 socket because it doesn't allow
IPv4 connections to be accepted on an IPv6 socket, then you would need
two sockets. Reading:

  http://httpd.apache.org/docs/trunk/bind.html

	it suggests that's true on the various BSDs.

> >     Here's what I prefer to do:
> 
> [snip]
> 
> IMHO, this code isn't simpler /shorter by any significant amount, and it is
> far less capable than the code already written above to deal with getaddrinfo.

	I'd agree that if you intended to allow libvirtd to bind to specific
addresses, then you'd need getaddrinfo().

	But I do firmly believe that using getaddrinfo() for the inaddr_any
case just makes the code obtuse and re-affirms this notion that sockets
coding is somehow a black art.

	If you had to explain the two different versions to someone, I think
the getaddrinfo() version would be harder, without being any more
correct.

> The semantics of the getaddrinfo code are also well documented by Uli if any 
> reference is needed http://people.redhat.com/drepper/userapi-ipv6.html

	When I was implementing IPv6 support for Vino, Uli's writeup was my
starting point (along with dear old R. Stevens, RIP) ... but I preferred
to seriously consider alternatives rather than just copying and pasting
it.

	Anyhow, I never intended to get into such a rant about
getaddrinfo() ... it was just a friendly suggestion :)

Cheers,
Mark.