[libvirt] RFC: configuring host interfaces with libvirt

[Daniel P. Berrange]

On Fri, Jan 16, 2009 at 01:24:53PM +0000, John Levon wrote:
> On Fri, Jan 16, 2009 at 10:11:02AM +0000, Daniel P. Berrange wrote:
> 
> > Integrating with host networking meanwhile is a fundamental requirement 
> > for virtualization for all apps using libvirt, since guests need network
> > connectivity, and thus managing NICs should be within scope.
> 
> I don't think that's much of an argument. Plenty of things can be
> considered fundamental. My kernel version certainly is, so why isn't
> libvirt letting me upgrade that? What about my firewall? Why isn't
> libvirt configuring my iSCSI target for me?

The kernel version isn't fundamental to the task of provisioning and
configuring a guest VM. When deploying a VM there is no general
requirement to upgrade the host kernel. When deploying a VM there
very much is a requirement to configure physical resources in the 
host such as storage, and networking.

> We should be considering why libvirt is /well-placed/ to configure the
> host. I think it should be pretty clear that it's actually not: the
> problems around distro differences alone is a good indication. The
> proposed API is anaemic enough to not be of much use.

The existance of many different impls is exactly the reason for libvirt
to have this capability. Libvirt is providing a consistent mgmt API
for management of guests and host networking interfaces is as much a
part of this as the storage management. Libvirt is providing this 
capability across virtualization technology. If we did not include
the NIC mgmt then apps using libvirt would not only need to write 
different code for each OS, but also for Xen, VMWare, etc each of
have their own APIs for network management which is just not helpful
for apps using libvirt. We already have this problem in apps using
libvirt needing to cope with different OS networking setups and thus
duplicating all this horrible code in every user of libvirt, which
is why networking mgmt is a important goal within scope.

> This is way beyond carving out the physical system into virtual chunks
> and it's a big step towards lib*virt* becoming libmanagement.

Not really - it is precisely about carving up / managing physical 
resources that are related to the guest configuration. It is not
about arbitrary OS management - we don't want an API to deploy 
RPMs, or configure Apache, or any other things related to general
OS management.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|