Re: Virtual networking

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

 



On Tue, Jan 16, 2007 at 04:19:37PM -0500, Aron Griffis wrote:
> Daniel P. Berrange wrote:  [Tue Jan 16 2007, 10:57:03AM EST]
> > 2. The way I was always anticipating remote use of libvirt to work. The
> >    app uses libvirt locally which opens a connection to the remote machine
> >    using whatever remote management protocol is relevant for the hypervisor
> >    in question. eg, HTTP/XML-RPC for Xen, or the TLS secured binary format
> >    for the prototype QEMU backend.
> > 
> >    http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-1.png
> 
> So this works to manage a remote host that might not have libvirt
> installed...

Provided the host in question provided a secure remote management system.
Until Xen-API is supported, even Xen doesn't have a useful remote management
system since its currents APIs have zero auth. Other non-Xen virt produces
don't have any remote management.

> 
> > 3. The way I think you re suggesting - a libvirt server on every remote
> >    host which calls into the regular libvirt internal driver model to
> >    proxy remote calls. So even if the hypervisor in question provides a
> >    remote network management API, we will always use the local API and
> >    do *all* remote networking via the libvirt server
> > 
> >    http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-2.png
> 
> ...and this requires each managed host to have libvirt(d).
> 
> This is considered a reasonable requirement?

Personally it doesn't worry me too much - by all means though, I'm open to 
arguments against it too.....

The way I currently look at the problem, needing to deploy a small C based
management daemon (merely linked to an SSL library for secure comms) isn't 
very onerous in comparison to the enourmous pile of python code Xen already 
requires. For non-Xen backends we'll definitely need a daemon of some form,
since QEMU / KVM / UML / etc don't have any management daemon at all. For 
administrators there's a certain benefit to only having to worry about 
opening up one daemon to the public network regardless of which virt system
in use.

But then maybe we actually need to support both remote management models ? 

Would a requirement for a libvirtd be a problem for your use cases ?

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


[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]