[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Preliminary patch to support remote driver / libvirtd



On Thu, Feb 01, 2007 at 11:45:27AM +0000, Mark McLoughlin wrote:
> 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?

The proxy only allows read-only access. If we have a daemon giving full
read-write access I see little need for the proxy anymore

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

If a system required binding separately to IPv4 & 6 sockets, then the
getaddrinfo() function on that platform would return as many entries
as was neccessary to do it correctly. This is one of the benefits of
using getaddrinfo() instead of the legacy inet function.

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

I don't think we want to restrict ourselves to inaddr_any - there are 
certainly times I'd want to only bind on 127.0.0.1 / ::1, or a specific
network interface for a multi-homed server

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

Its useful to have this rants sometimes, in case we missed something dumb :-)

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]