[Libvir] Virtual networking

[Daniel Veillard]

On Wed, Jan 17, 2007 at 04:53:38PM +0000, Daniel P. Berrange wrote:
> On Wed, Jan 17, 2007 at 04:37:56PM +0000, Mark McLoughlin wrote:
> > On Wed, 2007-01-17 at 06:50 -0500, Daniel Veillard wrote:
> > 
> > >  Thibgs which were dirt cheap become way more
> > > expensive when they don't need to, this is a severe regression from a
> > > library user standpoint.
> > 
> > 	Just a small point on this ...
> > 
> > 	Are you sure that's optimising for the right thing? What libvirt API is
> > so performance sensitive that a roundtrip on a unix domain socket would
> > be a problem?
> 
> We have 3 cases curently:
> 
>  - Local privileged user - we use hypercalls for performance criticl ops
>  - Local unprivileged user readonly - we use libvirt_proxy over unix socket
>  - Local unprivileged user readwrite - talk insecurely to XenD
> 
> Now we know from bitter experiance that talking to XenD is incredibly 
> slow / high overhead. IIRC something like x50 slower. What I've never
> benchmarked is how well the libvirt_proxy performs.
> 
> So currently the only time we can use the very fast pure hypercall path
> is when the app in question is running as root on local machine. I'd 
> really like to stop running virt-manager as root to be honest. If we can
> get a local daemon providing full read-write operation, without the
> horrific overhead of XenD, then really the direct root+hypercall path
> is fairly uninteresting.

  Okay that's true we lack data for the most critical paths, *but* I expect
people will build load aquisition daemon using libvirt and if we make this 
way slower with no way to get back to previous behaviour they will be
disapointed.

> > 	For example, even iterating the list of domain names is going to have a
> > negligible cost compared with loading libvirt from disk :-)
> 
> Well, loading libvirt from disk is irrelevant because it'll be cached
> after the very first load.
> 
> > 	However, the number of roundtrips to a management daemon *will* be an
> > issue where the daemon is remote. And we're going to have that whether
> > we use a daemon in the local case.
> 
> Yes, for remote management we will always have overhead. The key is whether
> using the same RPC daemon for local management will also have unacceptable
> overhead..

  agree that's a good point, the local daemon will have to keep the list
because it can do it cheaply. But I'm not sure what we have at the current
driver API is really the right operations for the RPCs.

> > 	i.e. even *if* daemon roundtrips turn out to be an issue for local
> > apps, we're going to have to fix that for the remote case anyway.
> 
> I'm going to run some tests/benchmarks to see what kind of performance
> difference there is between   root+direct hypercalls, and talking via
> the libvirt_proxy, and via XenD. This should give us a good basis for
> deciding whether the root+direct hypercall case has a compelling enough
> performance advantage to worry about.

  timing data will definitely help, but I hope we will also get feedback from
other people who built on top of libvirt.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/