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.
Description of problem:
Create 5000 macvtap devices on eth0. Enlarge NO. of open files to 4000 by ulimit -n 4000, then try to launch a pre-installed windows 8.1 guest with macvtap device as backend. For example:
"
-netdev tap,id=hostnet0,vhost=on,fd=3007 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=ee:67:2e:0e:06:aa,bus=pci.0 3007<>/dev/tap3007
"
When trying to change guest mac address to the one specified in cli, guest hangs.
Even successfully changed its mac, and could reach to external network, it hangs on restarting guest.
Version-Release number of selected component (if applicable):
2.6.32-491.el6.x86_64
qemu-kvm-0.12.1.2-2.430.el6.x86_64
How reproducible:
100%
Steps to Reproduce:
1.
2.
3.
Actual results:
Guest
Expected results:
This doesn't happen when testing macvtap index is smaller like 8.
Additional info:
CLI:
/usr/libexec/qemu-kvm -S -machine rhel6.6.0,dump-guest-core=off -cpu SandyBridge,hv_relaxed -enable-kvm -m 2048 -realtime mlock=off -smp 6,sockets=6,cores=1,threads=1 -monitor stdio -rtc base=localtime,clock=host,driftfix=slew -boot order=c,menu=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=win8.1.raw,if=none,id=drive-virtio0-0-0-0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,drive=drive-virtio0-0-0-0,id=virt0-0-0-0,scsi=off -device usb-tablet,id=input0 -vga cirrus -vnc :2 -msg timestamp=on -netdev tap,id=hostnet0,vhost=on,fd=3007 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=ee:67:2e:0e:06:aa,bus=pci.0 3007<>/dev/tap3007 -device virtio-balloon-pci,id=balloon
Any additional info you need, please set needinfo on me.
(In reply to jason wang from comment #3)
> Can you reproduce this through libvirt?
Hi jason,
I am not sure how to pass libvirt 'fd=', but I guess this number is unpredictable and not sure if libvirt will pick numbers greater than like 3000. Additional, I retested again without specifying fd but let qemu-kvm open it by itself, then this issue is not reproducible. Hope this helps.
(In reply to Chao Yang from comment #4)
> (In reply to jason wang from comment #3)
> > Can you reproduce this through libvirt?
>
>
> Hi jason,
>
> I am not sure how to pass libvirt 'fd=', but I guess this number is
> unpredictable and not sure if libvirt will pick numbers greater than like
> 3000. Additional, I retested again without specifying fd but let qemu-kvm
> open it by itself, then this issue is not reproducible. Hope this helps.
Then you mean it has something related to the fd number instead of the number of macvtaps?
Then it could be related to the 1024 file descriptors limitation with select(). Upstream switch to g_poll(). Could you pls retry with fd=X (X<1024)? If yes, please duplicate this with bz1005016.
Thanks
(In reply to jason wang from comment #5)
> (In reply to Chao Yang from comment #4)
> > (In reply to jason wang from comment #3)
> > > Can you reproduce this through libvirt?
> >
> >
> > Hi jason,
> >
> > I am not sure how to pass libvirt 'fd=', but I guess this number is
> > unpredictable and not sure if libvirt will pick numbers greater than like
> > 3000. Additional, I retested again without specifying fd but let qemu-kvm
> > open it by itself, then this issue is not reproducible. Hope this helps.
>
> Then you mean it has something related to the fd number instead of the
> number of macvtaps?
>
> Then it could be related to the 1024 file descriptors limitation with
> select(). Upstream switch to g_poll(). Could you pls retry with fd=X
> (X<1024)? If yes, please duplicate this with bz1005016.
>
> Thanks
I made a mistake. I should append 'fd=' to qemu-kvm in comment 4 to test macvtap.
Retested again, still reproducible with large fd index. I have changed max of open files to 6000 manually before test.
About libvirt, haven't found a way to pass fd to qemu-kvm yet.