Bug 878481

Summary:	define a disconnected <interface>
Product:	Red Hat Enterprise Linux 7	Reporter:	Dan Kenigsberg <danken>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED CANTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	bazulay, berrange, cwei, danken, dyuan, iheim, jdenemar, laine, lpeer, mzhan, rbalakri, ydu
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-21 17:04:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	883504

Description Dan Kenigsberg 2012-11-20 14:21:46 UTC

I have a vm defined with an <interface> connected to a <network>, but I need to take the <network> down. I'd like to disconnect the <interface> from the <network> before that, without interrupting the guest. The underlying qemu process may keep its tap device, but the tap would be plugged out of the bridge, and dangle in thin air.

(03:34:33 PM) danpb: jdenemar: danken I wanted us to have a   <interface type="null">  as a way to indicate a network interface without any ethernet cable plugged in
(03:34:53 PM) danpb: i guess a dangling  TAP device which is set to DOWN, would do the job 
(03:38:52 PM) jdenemar: danken: would you mind summarizing the discussion in an rfe bug? :)
(03:40:44 PM) danpb: we ought to be able to update that on the fly too
(03:40:52 PM) danpb: (via virDomainUpdateDevice)

Without this feature, we would have to resort to defining an auxiliary bridge, and connect it to the tap device, instead of leaving the tap device dangling, while keeping the link state off. It would be great to see this implemented in time for RHEV-3.2.

Comment 1 Dan Kenigsberg 2013-06-06 14:10:26 UTC

RHEV would need this feature for a proper integration with the Linux bridge agent of OpenStack Networking. That agent expects to see an disconnected tap device with a predefined name, and then connect it to one of its bridges.

I believe that this capability would make OpenStack's bridge VIF driver cleaner and more in line with the Nova/Quantum architecture. Would you reconsider your CondNAK?

Comment 2 Daniel Berrangé 2013-06-06 14:17:22 UTC

(In reply to Dan Kenigsberg from comment #1)
> RHEV would need this feature for a proper integration with the Linux bridge
> agent of OpenStack Networking. That agent expects to see an disconnected tap
> device with a predefined name, and then connect it to one of its bridges.

I'm not sure this is really the case. In OpenStack Nova we use normal type=bridge and the bridge name associated with the Quantum network to connect the guest to a dev. Handing off bridging of the tap device to an external entity is something we explicitly removed from Nova recently. I'd not suggest RHEV go down that route. You should always be able to just use  type=bridge or type=direct to connect to any OpenStack Quantum / Nova network topology.

Comment 3 Dan Kenigsberg 2013-06-09 11:52:58 UTC

DanPB, would you help me understand what Nova does when it starts the first VM that is to be connected to a specific network? How does it know which bridge it should connect the VM? Who creates this bridge and its vlan device?

Comment 4 Daniel Berrangé 2013-06-18 16:32:31 UTC

Nova makes an RPC request to quantum when it wants to plug a VIF into a network. Quantum does whatever setup work is required to create the bridge device, and in the data that is returned it will tell Nova what type of network connectivity is required (bridge, ovs, vepa, etc), the name of the associated network device, and also what the preferred name of the TAP device is too. From that info Nova can do all the libvirt configuration:

This code is dealt with in this module:

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py

the 'get_config' method is the relevant one here - all the info is switches on comes from Quantum's RPC methods

Comment 7 Dan Kenigsberg 2013-07-02 20:11:34 UTC

Other use cases for the "dangling tap" may exist, as explained in http://wiki.libvirt.org/page/Guest_won%27t_start_-_warning:_could_not_open_/dev/net/tun_%28%27generic_ethernet%27_interface%29

Comment 9 Jiri Denemark 2014-04-04 21:37:14 UTC

This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.

Comment 17 Laine Stump 2015-07-21 17:04:02 UTC

We've concluded that this feature can't be added in a general enough fashion to be useful in more than a narrow subset of cases (only for standard tap-based devices switching from one bridge to another), and that case can be reasonably handled by defining an isolated network to park the "unconnected" tap devices, so I'm closing this as CANTFIX.

(in the future if qemu is enhanced to allow removing/adding the -device that is connected to an (otherwise undisturbed) -netdev, then we may reconsider).