Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
There's a similar scenario in bug 1004625. We are not sure whether they are same bug. Please help confirm and feel free to close one if they are the same.
(In reply to Qunfang Zhang from comment #3)
> There's a similar scenario in bug 1004625. We are not sure whether they are
> same bug. Please help confirm and feel free to close one if they are the
> same.
The 2 bugs are not the same, but there is some relationship between them.
This particular bug heavily depends on the time of when the interface is deleted. If the interface is deleted after qemu finished initialized the tap/vhost devices, then the problem will not be observed. If the interface is deleted before qemu had a chance to initialize the tap/vhost devices, the problem will be present.
This is due the fact that qemu calls assert() if TUNSETVNETHDRSZ ioctl fails for any reason. This problem is also present in upstream qemu. To solve this, the
error recovery needs to this specific case.
This bug is similar in its behaviour to Bug 1004275. There are certain errors
that qemu considers fatal as there is no really good recoverable scenario when
these errors occur.
Here are the options for the solution as I can see:
1) Change assert/abort into a clear exit solution and continue reporting error.
2) Remove assert/abort and disable or delete the device that fails to initialize
correctly. This may allow qemu to run, but the interface will not function
properly. This will at least make the behaviour consistent between
between initialization state and already running state. It does bring up
some interesting issues thought.
-vlad
Closing.
Since deletion of a tap interface is somewhat malicious and not a standard workflow, we will only fix it in RHEL7 (if necessary).
QE, Please test on RHEL7.
(In reply to Ronen Hod from comment #10)
> Closing.
> Since deletion of a tap interface is somewhat malicious and not a standard
> workflow, we will only fix it in RHEL7 (if necessary).
> QE, Please test on RHEL7.
Tested in rhel7 host, did not hit such issue:
compoments:
# uname -r
3.10.0-118.el7.x86_64
[root@ibm-x3650m4-05 ~]# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-1.5.3-60.el7ev.x86_64
cli:
# /usr/libexec/qemu-kvm -S -name rhel7 -M pc -nodefaults -vga std -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 -drive id=drive_image1,if=none,cache=none,aio=native,file=/home/rhel70326cp1.qcow2_v3 -device virtio-blk-pci,id=image1,drive=drive_image1,bus=pci.0,addr=04 -device virtio-net-pci,mac=16:33:3f:09:12:78,id=vnet0,netdev=hostdev0,bus=pci.0,addr=05 -netdev tap,id=hostdev0,vhost=on,script=/etc/qemu-ifup -m 4G -smp 4,sockets=1,cores=4,threads=1 -cpu SandyBridge -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -vnc :3 -rtc base=localtime,clock=host,driftfix=slew -boot menu=on -enable-kvm -monitor stdio -qmp unix:/tmp/q1,server,nowait -device virtio-balloon-pci,id=b1 -monitor unix:/tmp/monitor-unix,nowait,server
after delete tap, guest and host work well both, so won't file bug against rhel7.
thanks,
(In reply to Qian Guo from comment #11)
> after delete tap, guest and host work well both, so won't file bug against
> rhel7.
Thanks, so although we can probably find a fix to backport, let's leave it CLOSED WONTFIX for now.