RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 878481 - define a disconnected <interface>
Summary: define a disconnected <interface>
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 883504
TreeView+ depends on / blocked
 
Reported: 2012-11-20 14:21 UTC by Dan Kenigsberg
Modified: 2015-07-21 17:04 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-21 17:04:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.