Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, Jan 16, 2009 at 02:20:27PM +0000, Mark McLoughlin wrote:
Just to be clear - I am very sympathetic to the need for this stuff
and
the conclusion that it belongs in libvirt. I just think we need to be
fairly clear on where the line is.
On Fri, 2009-01-16 at 13:41 +0000, Daniel P. Berrange wrote:
> 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.
There may be a requirement to install certain packages before VMs can be
deployed.
That is true, you also need to installl an OS before you can manage
a physical host, and you need to build a machine before you can
install an OS on it. We could go on for ever here, which is why
I'm trying to make define the boundary line as being related to
the management of hardware resources on the host. WRT the need to
install certain packages for, say KVM, libvirt's role is to provide
information about what capabilities are present. So the host XML
for capablities indicates whether KVM virtualization is available.
Libvirt is managing what is available on the host, not trying to
install more thing. Installing RPMs is not hardware resource
management, hence I class it out of scope.
> When deploying a VM there
> very much is a requirement to configure physical resources in the
> host such as storage, and networking.
When "deploying a VM" or when "configuring a host to run VMs"?
Configuring resourcs on the host to connect to a VM. So finding or
creating a LVM LUN, creating a VLAN devices on NIC and putting it
into a bridge to guest to a guest.
i.e. is this isn't an API to list the available bridges which a
user
could choose to connect a VM to, this is an API to configure bonded NICs
etc.
Mere listing of host devices is already provided by the node device
enumation APIs.
The Virtual Network and Storage Pool stuff is different as well - it's
about virtualizing those resources. Configuring a bonded NIC or setting
a static IP address on eth0 is not about virtualizing eth0.
I don't think there is such a distinction between the storage pool
stuff and the network stuff. In storage pools we are taking phys
devices and putting them into a LVM volume groups - this is directly
akin to taking two NICs and bonding them. Likewise managing FibreChanel
with NPIV is directly akin to managing VLANs on a NIC. So I class
configuration of bonding, bridges and VLANs within scope fo the
network mgmt API.
What remote management tools can benefit from is piggy backing on top
of
libvirt's authenticated connection to a host. What would be so wrong
with adding a TCP stream tunnel (c.f. SSH tunnel) over the libvirt
connection and allow the management tool talk to a separate host
configuration agent?
That isn't providing an API that is consistnet across virt manangement
platforms. It is not providing an API and XML model that is consistnet
with the rest of the model exposed through libvirt's hypervisor, node
capability, node device & virtual network APIs. Network interface APIs
are the core missing piece of libvirt API functionality IMHO.
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 :|