[libvirt] RFC: configuring host interfaces with libvirt

Mark McLoughlin markmc at redhat.com
Fri Jan 16 14:20:27 UTC 2009


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.

>  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"?

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.

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.

With the exception, perhaps, of configuring a NIC to be a shared
physical interface, this stuff seems to me to be about host
configuration rather than helping with VM configuration or virtualizing
resources.

...

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?

Cheers,
Mark.




More information about the libvir-list mailing list