Bug 1121589 - windows 8.1 always hangs either on changing mac in guest or restarting guest with great macvtap index
Summary: windows 8.1 always hangs either on changing mac in guest or restarting guest ...
Keywords:
Status: CLOSED DUPLICATE of bug 1005016
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Ronen Hod
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-21 09:50 UTC by Chao Yang
Modified: 2014-12-15 00:54 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 09:49:06 UTC


Attachments (Terms of Use)

Description Chao Yang 2014-07-21 09:50:18 UTC
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.

Comment 1 Chao Yang 2014-07-21 09:54:22 UTC
Top shows:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                   

 9638 root      20   0 6514m 2.1g 5788 R 101.3 27.2   5:35.83 qemu-kvm

Comment 3 jason wang 2014-07-22 02:49:27 UTC
Can you reproduce this through libvirt?

Comment 4 Chao Yang 2014-07-22 08:20:35 UTC
(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.

Comment 5 jason wang 2014-07-22 08:39:14 UTC
(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

Comment 6 Chao Yang 2014-07-22 09:08:36 UTC
(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.

Comment 7 Chao Yang 2014-07-22 09:49:06 UTC
Checked bug 1005016, same steps. Closing.

*** This bug has been marked as a duplicate of bug 1005016 ***


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