On Tue, Jul 2, 2013 at 3:07 PM, Dan Kenigsberg <[email protected]> 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
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
