On Tue, Jul 2, 2013 at 3:07 PM, Dan Kenigsberg <danken@xxxxxxxxxx> wrote:
--
Doug Goldstein
Verifying this statement is left as an excercise to theOn 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.
reader of https://bugzilla.redhat.com/show_bug.cgi?id=878481#c0 .
I'm looking at the tip of master branch, both in
>
> > > 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.
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.
That would be cool indeed. It would make it possible to
>
> > > 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
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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list