Re: Virtual networking

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

 



On Thu, Jan 25, 2007 at 04:07:57PM +0000, Mark McLoughlin wrote:
> On Thu, 2007-01-25 at 16:02 +0000, Daniel P. Berrange wrote:
> 
> > That's an interesting idea - your description..
> > 
> >   "a virConnectPtr is a connection to a specific hypervisor 
> >    *and* the virtual network supervisor"
> > 
> > ..makes me thing of a slightly alternative impl. We currently have
> > a single internal driver API  'virDriverPtr' which is just a list of
> > function pointers for all the HV related calls. Rather than making that
> > struct bigger to add in networking calls, how about we define two separate
> > internal driver APIs
> > 
> >    virHypervisorDriver
> >    virNetworkDriver
> >
> > It strikes me that most of the different hypervisor backends will simply
> > want to re-use the same network driver backend, so why not properly
> > de-couple them. The virConnectOpen  function would thus first lookup
> > a hypervisor driver, and then lookup a networking driver. This avoids
> > the somewhat nasty issue of having to figure out how to activate 
> > multiple non-conficting drivers to get the correct combo of HV & network 
> > stuff. 
> 
> 	Yep, that'd be the best way to do it.
> 
> > The only small complication would be ensuring that the HV driver and
> > network driver didn't need to open 2 separate TCP connections to the
> > same place, but I'm sure we'd be able to figure that out.
> 
> 	Yep.
> 
> 	(Also, if we go with this approach, we should probably also do
> s/qemud/libvirtd/ or something ... but we need to figure out what to do
> wrt. the "other libvirtd" first :-)

Indeed - since Rich Jones is looking at a more general purpose libvirtd, 
we can adapt QEMU impl to play nicely with the generic daemon.

I figure separate out the QEMU bits from qemud and turn them into a regular
libvirt driver. Then set it up so that this driver is only used when invoked
by the libvirtd, and not ever directly by the client lib - that way we still
ensure a single daemon managing QEMU per node, without coupling the QEMU
impl to the daemon itself.

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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]