Re: [libvirt] RFC: configuring host interfaces with libvirt
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 :|