[libvirt] configuring a disconnected <interface>

[Dan Kenigsberg]

On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote:
> On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote:
> > On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote:
> > > On Thu, Jun 20, 2013 at 02:42:31PM +0300, Dan Kenigsberg wrote:
> > > > Hi List,
> > > > 
> > > > Like most of us, I've bought my actual computer with an Ethernet
> > > > interface card, that I can connect to a wall jack at will. It's quite
> > > > easy to disconnect the Ethernet cable from the wall, as well.
> > > > 
> > > > I would like to expose this behavior to virtual computers, too. Via
> > > > libvirt, of course. That's useful, since an admin may need to disconnect
> > > > a running VM from a network temporarily, without resorting to
> > > > hot-unplugging its nic.
> > > 
> > > In the bug you filed requested this feature, you said that you want
> > > this so that you can make oVirt configure bridging behind libvirts
> > > back with Quantum.
> > 
> > This is not exact. Bug 878481 - define a disconnected <interface>
> > was opened with the VM-connected-to-no-bridge in mind.
> > 
> > Since libvirt is lacking this feature, oVirt has introduced an ugly
> > hack: a dummy bridge, to which a disconnected VM is moved to. The
> > interface fo this VM had to be set with <link state=off> to avoid
> > inter-VM communication.
> > 
> > Only then came the Quantum use case.
> 
> Sigh. In the BZ, your justification only mentioned that this is
> required for integration with Quantum, never that it was required
> separately.

Verifying this statement is left as an excercise to the
reader of https://bugzilla.redhat.com/show_bug.cgi?id=878481#c0 .

> 
> > > As explained in the bug, this is a really bad way
> > > todo this & should not be required - OpenStack Nova demonstrates you
> > > can do the right thing wrt Quantum using exisiting libvirt config.
> > 
> > I'm not sure that this is THE right thing. At the momement, both
> > quantum's linuxbridge plugin and nova's LinuxBridgeInterfaceDriver have
> > an ensure_vlan_bridge() method.
> >
> > 
> > I'm no OpenStack expert, but I think that the nicest separation between
> > nova's and quantum's domains is the tap device (obviously only for
> > networks which use tap devices). Quantum should create the Linux bridge
> > and its underlying connectivity (or even worse for ovs with security
> > groups...), and Nova should connect a newly-created VM to it. Otherwise,
> > Nova would have to reimplement just about any extension that is
> > introduced to Quantum.
> 
> While there are many, many ways to configure a physical network,
> there are a small, finite number of ways that you can connect a
> virtual machine to a physical network. Thus while there can be
> many different quantum plugins, Nova only needs to know about a
> handful of VM configuration rules.
> 
> > In particular, I worry about the mapping of a network to a physical
> > device. Quantum's linuxbridge does it according to a preconfigured
> > cfg.CONF.LINUX_BRIDGE.physical_interface_mappings. Does Nova's vif
> > driver support something like this? From where does it collect this
> > information?
> > 
> > Anyway, would you suggest oVirt to implement its own
> > ensure_vlan_bridge()? Or use the vif driver code? Or that of linuxbridge
> > quantum plugin?
> 
> I'm not sure you're looking at current codebase. As of Grizzly the
> quantum specific VIF plugin (and all other existing VIF plugins)
> are deprecated in favour of LibvirtGenericVIFDriver. This defines
> (currently) 4 different types of VIF configuration, linux bridge,
> openvswitch, 802.qbg and 802.qbh. Each of these VIF types has a
> set of metadata associated with it describing the configuration
> requirements, which is used to configure the VM interface appropriately.
> This clean separation isolates Nova from any knowledge of Quantum,
> and vica-verca.

I'm looking at the tip of master branch, both in
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L342
and
https://github.com/openstack/quantum/blob/master/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py#L679

My spefcific painpoint is that the vif driver calls
linux_net.LinuxBridgeInterfaceDriver.ensure_vlan_bridge() with no
regards of the configuration of the quantum agent.

True, a specific configuration parameter of a specific agent of a
quantum plugin is not of the business of Nova. But this suggests that
connecting a bridge to an external NIC is not its business, either.


> 
> > > So I'm not inclined to support this disconnected mode.
> > 
> > Disconnected mode exists in actuality. It has valid use cases in the
> > virtual world as well. I would like to discuss the domxml schema for
> > representing it, and then, hopefully find the menpower to implement it
> > outside the core libvirt team. So please, reconsider.
> 
> The XML schema is easy enough - it is just a new  <interface type=none>.
> Ideally we would want some kind of support in QEMU for this, concept
> so that we don't have to have a hidden dangling tap device

That would be cool indeed. It would make it possible to
virDomainUpdateDevice() from a tap-based connectivity to non-tap one.

Until we have something like that in qemu, would it be reasonable to
implement <interface type=none> via a dangling tap? Wouldn't it be fine
to limit changing type=none to type=network only to bridge-based
networks?

Regards,
Dan.