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