[libvirt] configuring a disconnected <interface>

Fri Aug 23 03:53:31 UTC 2013

On Tue, Jul 2, 2013 at 3:07 PM, Dan Kenigsberg <danken at redhat.com> wrote:

> 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.
>
>
>
Did anything come of <interface type='none'> or allowing <source> to be
missing? While going through the vmx parser (VMWare), I noticed a good
quantity of vmx files provided to me by different people have 2 ethernet
devices defined. Both defined as bridged devices and both with their own
unique MAC address however the 2nd one will not have an associated
network/bridge device. libvirt will generate the following:

    <interface type='bridge'>
      <mac address='00:0c:29:3b:64:f4'/>
      <source bridge=''/>
    </interface>

But that just doesn't seem correct and I was trying to figure out what a
more correct syntax would be.

-- 
Doug Goldstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130822/e2e4f9bd/attachment-0001.htm>