Re: [libvirt] configuring a disconnected <interface>
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.
> 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.
> 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
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|