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 1456039 - libvirt detach-interface wrongly reports interface as detached
Summary: libvirt detach-interface wrongly reports interface as detached
Keywords:
Status: CLOSED DUPLICATE of bug 993631
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-26 19:51 UTC by Vlastimil Holer
Modified: 2017-05-29 13:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-29 13:33:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
libvirtd output (46.70 KB, text/plain)
2017-05-26 19:51 UTC, Vlastimil Holer 		no flags Details
View All

Description Vlastimil Holer 2017-05-26 19:51:12 UTC 
Created attachment 1282759 [details]
libvirtd output

Description of problem:
We have experienced problems with the libvirt detach-interface reporting the interface as detached, but after inspecting the domain XML again and the virtual machine itself, it wasn't.

# time virsh detach-interface one-39643 bridge --mac 02:00:ac:11:00:59
Interface detached successfully

real    0m4.023s
user    0m0.012s
sys    0m0.007s

# time virsh detach-interface one-39643 bridge --mac 02:00:ac:11:00:59
Interface detached successfully

real    0m4.029s
user    0m0.012s
sys    0m0.010s

# virsh domiflist one-39643
Interface  Type       Source     Model       MAC
-------------------------------------------------------
one-39643-0 bridge     onebr1100  virtio      02:00:ac:11:10:d2
one-39643-1 bridge     onebr1047  virtio      02:00:ac:11:10:68
one-39643-2 bridge     onebr1176  virtio      02:00:ac:11:11:6b
one-39643-3 bridge     onebr1183  virtio      02:00:ac:11:11:79
one-39643-4 bridge     onebr1000  virtio      02:00:ac:11:10:0a
one-39643-5 bridge     onebr912   virtio      02:00:ac:11:00:59

The only (helpful?) thing I have is the output from libvirtd -v.

The guest was running some old unsupported Ubuntu 10 with kernel 2.6.32.

Version-Release number of selected component (if applicable):
kernel 3.10.0-327.36.3.el7.x86_64
libvirt-2.0.0-10.el7_3.5.x86_64
qemu-kvm-1.5.3-126.el7_3.6.x86_64

How reproducible:
Don't know how to get into the situation when the interface can't be detached.

Expected results:
Libvirt action fails to the user.
Comment 2 Jiri Denemark 2017-05-29 13:33:39 UTC 
The problem is in the underlying API which was historically designed and documented as synchronous, but it was never implemented that way. It was always asynchronous. In other words it was supposed to return 0 once the device was successfully detached but in reality the API returned once QEMU confirmed it got the request to remove the device. However, the device detach usually worked so fast it was really removed at the time the API returned success. This behavior is now properly documented in the API documentation with the suggestion to wait for the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event as a confirmation the device was actually removed. Until the event is delivered, successful return of the API indicates no more than a successful request for device removal.

Unfortunately, it's nontrivial for virsh to distinguish whether a device was removed before the API returned and thus it doesn't provide a better message.

*** This bug has been marked as a duplicate of bug 993631 ***
Note You need to log in before you can comment on or make changes to this bug.