<div dir="ltr"><div class="gmail_extra">On Tue, Jul 2, 2013 at 3:07 PM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote:<br>

> On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote:<br>
> > On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote:<br>
> > > On Thu, Jun 20, 2013 at 02:42:31PM +0300, Dan Kenigsberg wrote:<br>
> > > > Hi List,<br>
> > > ><br>
> > > > Like most of us, I've bought my actual computer with an Ethernet<br>
> > > > interface card, that I can connect to a wall jack at will. It's quite<br>
> > > > easy to disconnect the Ethernet cable from the wall, as well.<br>
> > > ><br>
> > > > I would like to expose this behavior to virtual computers, too. Via<br>
> > > > libvirt, of course. That's useful, since an admin may need to disconnect<br>
> > > > a running VM from a network temporarily, without resorting to<br>
> > > > hot-unplugging its nic.<br>
> > ><br>
> > > In the bug you filed requested this feature, you said that you want<br>
> > > this so that you can make oVirt configure bridging behind libvirts<br>
> > > back with Quantum.<br>
> ><br>
> > This is not exact. Bug 878481 - define a disconnected <interface><br>
> > was opened with the VM-connected-to-no-bridge in mind.<br>
> ><br>
> > Since libvirt is lacking this feature, oVirt has introduced an ugly<br>
> > hack: a dummy bridge, to which a disconnected VM is moved to. The<br>
> > interface fo this VM had to be set with <link state=off> to avoid<br>
> > inter-VM communication.<br>
> ><br>
> > Only then came the Quantum use case.<br>
><br>
> Sigh. In the BZ, your justification only mentioned that this is<br>
> required for integration with Quantum, never that it was required<br>
> separately.<br>
<br>
</div></div>Verifying this statement is left as an excercise to the<br>
reader of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=878481#c0" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=878481#c0</a> .<br>
<div><div class="h5"><br>
><br>
> > > As explained in the bug, this is a really bad way<br>
> > > todo this & should not be required - OpenStack Nova demonstrates you<br>
> > > can do the right thing wrt Quantum using exisiting libvirt config.<br>
> ><br>
> > I'm not sure that this is THE right thing. At the momement, both<br>
> > quantum's linuxbridge plugin and nova's LinuxBridgeInterfaceDriver have<br>
> > an ensure_vlan_bridge() method.<br>
> ><br>
> ><br>
> > I'm no OpenStack expert, but I think that the nicest separation between<br>
> > nova's and quantum's domains is the tap device (obviously only for<br>
> > networks which use tap devices). Quantum should create the Linux bridge<br>
> > and its underlying connectivity (or even worse for ovs with security<br>
> > groups...), and Nova should connect a newly-created VM to it. Otherwise,<br>
> > Nova would have to reimplement just about any extension that is<br>
> > introduced to Quantum.<br>
><br>
> While there are many, many ways to configure a physical network,<br>
> there are a small, finite number of ways that you can connect a<br>
> virtual machine to a physical network. Thus while there can be<br>
> many different quantum plugins, Nova only needs to know about a<br>
> handful of VM configuration rules.<br>
><br>
> > In particular, I worry about the mapping of a network to a physical<br>
> > device. Quantum's linuxbridge does it according to a preconfigured<br>
> > cfg.CONF.LINUX_BRIDGE.physical_interface_mappings. Does Nova's vif<br>
> > driver support something like this? From where does it collect this<br>
> > information?<br>
> ><br>
> > Anyway, would you suggest oVirt to implement its own<br>
> > ensure_vlan_bridge()? Or use the vif driver code? Or that of linuxbridge<br>
> > quantum plugin?<br>
><br>
> I'm not sure you're looking at current codebase. As of Grizzly the<br>
> quantum specific VIF plugin (and all other existing VIF plugins)<br>
> are deprecated in favour of LibvirtGenericVIFDriver. This defines<br>
> (currently) 4 different types of VIF configuration, linux bridge,<br>
> openvswitch, 802.qbg and 802.qbh. Each of these VIF types has a<br>
> set of metadata associated with it describing the configuration<br>
> requirements, which is used to configure the VM interface appropriately.<br>
> This clean separation isolates Nova from any knowledge of Quantum,<br>
> and vica-verca.<br>
<br>
</div></div>I'm looking at the tip of master branch, both in<br>
<a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L342" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L342</a><br>
and<br>
<a href="https://github.com/openstack/quantum/blob/master/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py#L679" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py#L679</a><br>

<br>
My spefcific painpoint is that the vif driver calls<br>
linux_net.LinuxBridgeInterfaceDriver.ensure_vlan_bridge() with no<br>
regards of the configuration of the quantum agent.<br>
<br>
True, a specific configuration parameter of a specific agent of a<br>
quantum plugin is not of the business of Nova. But this suggests that<br>
connecting a bridge to an external NIC is not its business, either.<br>
<div class="im"><br>
<br>
><br>
> > > So I'm not inclined to support this disconnected mode.<br>
> ><br>
> > Disconnected mode exists in actuality. It has valid use cases in the<br>
> > virtual world as well. I would like to discuss the domxml schema for<br>
> > representing it, and then, hopefully find the menpower to implement it<br>
> > outside the core libvirt team. So please, reconsider.<br>
><br>
> The XML schema is easy enough - it is just a new  <interface type=none>.<br>
> Ideally we would want some kind of support in QEMU for this, concept<br>
> so that we don't have to have a hidden dangling tap device<br>
<br>
</div>That would be cool indeed. It would make it possible to<br>
virDomainUpdateDevice() from a tap-based connectivity to non-tap one.<br>
<br>
Until we have something like that in qemu, would it be reasonable to<br>
implement <interface type=none> via a dangling tap? Wouldn't it be fine<br>
to limit changing type=none to type=network only to bridge-based<br>
networks?<br>
<br>
Regards,<br>
Dan.<br>
<div class=""><div class="h5"><br><br></div></div></blockquote><div><br></div><div style>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:</div>
<div style><br></div><div>    <interface type='bridge'></div><div>      <mac address='00:0c:29:3b:64:f4'/></div><div>      <source bridge=''/></div><div style>    </interface></div>
<div style><br></div><div style>But that just doesn't seem correct and I was trying to figure out what a more correct syntax would be. </div></div><br>-- <br>Doug Goldstein
</div></div>