Re: [libvirt] configuring a disconnected <interface>

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/linuxbri... 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.