Hide Forgot
+++ This bug was initially created as a clone of Bug #630830 +++ Description of problem: The bug is same as bug #630830. When copying files from 2 windows VM, network becomes unavailable. Guest windows IP address becomes 169.254.x.x, which is auto-assigned by windows machine. Background information: I'm trying to run windows VM in openstack, then seems like the issue can be easily reproduced this problem in my environment with latest virt_win-0.1-74.iso. Below is related version information. Guest machine: windows 2008 R2 Service Pack 1 Guest Redhat VirtIO Ethernet Adapter version: - Driver date: 6/19/2013 - Driver version: 61.65.104.6500 Note that my initial virt_win.iso is version 0.1-65, then I update driver to 0.1-74 although system prompt it is latest one already. Host machine: Ubuntu 12.04.3 LTS Kernel: 3.8.0-29-generic QEMU-KVM version: QEMU emulator version 1.0 (qemu-kvm-1.0) Openstack: Havana. Note that this problem is easily reproduced if you copy files cross 2 VMs on 2 seperate physical bare-metal server. If within same bare-metal server, you can run multiple file copy operations, then it can be reproduced.
Can you paste qemu-kvm commandline here ? Can it be reproduced on virtio-win-65 ? Which netkvm type are you using ,bridging ,or openvswitch ?
QE tried the bug with this driver-virtio-win-1.6.6-1.el6.noarch.rpm Detail steps I, 1.Let one guest win2k8-R2 running on rhel6.5 (qemu-kvm-rhev-415) host with the driver installed. 1.1Execute netperf testing on it,and after finishing script the netkvm was still available. 2.Let another guest win2k8-R2 running on rhel7.0 (qemu-kvm-rhev-1.5.3-19.el7.x86_64) host with the driver installed 2.1Execute netperf testing on it and after finishing script the netkvm was still available. Related scripts,please see attachments. II， 1.Execute netperf testing on both guest. 2.Run multiple Copying operation from each other at the same time. As a results,all actions were smoothly,the netkvm of them were still available.Any issues please let me know,thanks. Thanks Min
Created attachment 833082 [details] scripts
(In reply to Mike Cao from comment #1) > Can you paste qemu-kvm commandline here ? qemu-kvm commandline: /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -name instance-00000005 -uuid a109b19d-bfc3-4eb0-95b3-dd39709b231f -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2013.2,serial=483f1ef9-2a06-e311-0000-00000000002f,uuid=a109b19d-bfc3-4eb0-95b3-dd39709b231f -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000005.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -drive file=/opt/stack/data/nova/instances/a109b19d-bfc3-4eb0-95b3-dd39709b231f/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=19,id=hostnet0,vhost=on,vhostfd=20 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:4e:d9:e9,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/a109b19d-bfc3-4eb0-95b3-dd39709b231f/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k en-us -vga cirrus -incoming fd:17 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > Can it be reproduced on virtio-win-65 ? Yes, it is reproduced on virtio-win-65. I try to update to 74, but per Yan's reply, seems like my update operation is not signed. So I'll update driver and have a try. > Which netkvm type are you using ,bridging ,or openvswitch ? I'm using linux bridging. BTW, my host OS is ubuntu 12.04.3 LTS. Do I need install driver-virtio-win in the ubuntu server?
(In reply to dengmin from comment #2) > QE tried the bug with this driver-virtio-win-1.6.6-1.el6.noarch.rpm > Detail steps > I, > 1.Let one guest win2k8-R2 running on rhel6.5 (qemu-kvm-rhev-415) host with > the driver installed. > 1.1Execute netperf testing on it,and after finishing script the netkvm > was still available. > 2.Let another guest win2k8-R2 running on rhel7.0 > (qemu-kvm-rhev-1.5.3-19.el7.x86_64) host with the driver installed > 2.1Execute netperf testing on it and after finishing script the netkvm > was still available. > Related scripts,please see attachments. > II， > 1.Execute netperf testing on both guest. > 2.Run multiple Copying operation from each other at the same time. > As a results,all actions were smoothly,the netkvm of them were still > available.Any issues please let me know,thanks. > > Thanks > Min Pls try build 74 as well. Yan,Could you view the tests on comment #2 ,any more tests need QE to run ? Thanks, Mike
(In reply to Leslie from comment #4) > (In reply to Mike Cao from comment #1) > > Can you paste qemu-kvm commandline here ? > > qemu-kvm commandline: /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 2048 -smp > 1,sockets=1,cores=1,threads=1 -name instance-00000005 -uuid > a109b19d-bfc3-4eb0-95b3-dd39709b231f -smbios type=1,manufacturer=OpenStack > Foundation,product=OpenStack > Nova,version=2013.2,serial=483f1ef9-2a06-e311-0000-00000000002f, > uuid=a109b19d-bfc3-4eb0-95b3-dd39709b231f -nodefconfig -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000005.monitor, > server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -drive > file=/opt/stack/data/nova/instances/a109b19d-bfc3-4eb0-95b3-dd39709b231f/ > disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0, > bootindex=1 -netdev tap,fd=19,id=hostnet0,vhost=on,vhostfd=20 -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:4e:d9:e9,bus=pci.0, > addr=0x3 -chardev > file,id=charserial0,path=/opt/stack/data/nova/instances/a109b19d-bfc3-4eb0- > 95b3-dd39709b231f/console.log -device > isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 > -device isa-serial,chardev=charserial1,id=serial1 -usb -device > usb-tablet,id=input0 -vnc 127.0.0.1:0 -k en-us -vga cirrus -incoming fd:17 > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > > > Can it be reproduced on virtio-win-65 ? > > Yes, it is reproduced on virtio-win-65. I try to update to 74, but per Yan's > reply, seems like my update operation is not signed. So I'll update driver > and have a try. Note that as you are testing windows server 2008 x64 ，you should install netkvm driver from \virtio-win-65.iso\Vista folder .
Hi Mike, Looks OK. Leslie - Can you provide your test scripts or netperf command line? Thanks, Yan.
Hi Yan, Actually I didn't use any test scripts or netperf command line. I just copy one big file (1G) from one samba server to one windows guest machine, then the windows guest machine acting as samba client will suffer the network problem. Best Regards Leslie
(In reply to Mike Cao from comment #5) > (In reply to dengmin from comment #2) > > QE tried the bug with this driver-virtio-win-1.6.6-1.el6.noarch.rpm > > Detail steps > > I, > > 1.Let one guest win2k8-R2 running on rhel6.5 (qemu-kvm-rhev-415) host with > > the driver installed. > > 1.1Execute netperf testing on it,and after finishing script the netkvm > > was still available. > > 2.Let another guest win2k8-R2 running on rhel7.0 > > (qemu-kvm-rhev-1.5.3-19.el7.x86_64) host with the driver installed > > 2.1Execute netperf testing on it and after finishing script the netkvm > > was still available. > > Related scripts,please see attachments. > > II， > > 1.Execute netperf testing on both guest. > > 2.Run multiple Copying operation from each other at the same time. > > As a results,all actions were smoothly,the netkvm of them were still > > available.Any issues please let me know,thanks. > > > > Thanks > > Min > > Pls try build 74 as well. > > Yan,Could you view the tests on comment #2 ,any more tests need QE to run ? > > Thanks, > Mike I re-tested the guest with driver build 74 with the same steps to comment 2 but could not reproduce the issue. Additional,1.QE use the file more than 3G. 2.Let netperf testing running about 14 hours.The network was still available.Even user can copy big files while netperf was running,as a result,netkvm was still available. 3.According to comment 3,I copied about 17.5G file from windows server to the guest.Still cannot reproduce the issue. Any issues,please let me know.Thanks
Can you describe network configuration on the host? Is it Linux bridge, Open vSwitch, something else? Best regards, Yan.
(In reply to Yan Vugenfirer from comment #10) > Can you describe network configuration on the host? Is it Linux bridge, Open > vSwitch, something else? > > Best regards, > Yan. See comment #4 ,the reporter claims he is using Linux Bridge. As he also claims that he is tesing under Ubuntu host,Can we let him try upstream qemu-kvm instead to see whether it is ubuntu qemu-kvm bug ? Thanks, Mike
(In reply to Mike Cao from comment #11) > (In reply to Yan Vugenfirer from comment #10) > > Can you describe network configuration on the host? Is it Linux bridge, Open > > vSwitch, something else? > > > > Best regards, > > Yan. > > See comment #4 ,the reporter claims he is using Linux Bridge. > As he also claims that he is tesing under Ubuntu host,Can we let him try > upstream qemu-kvm instead to see whether it is ubuntu qemu-kvm bug ? > Looks like good idea. > Thanks, > Mike
Dear Leslie, Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto