Bug 678951 - long time file copy cause vf lost its ip
Summary: long time file copy cause vf lost its ip
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Alex Williamson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 580954
TreeView+ depends on / blocked
 
Reported: 2011-02-21 04:14 UTC by Chao Yang
Modified: 2013-01-09 23:34 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-23 04:32:46 UTC
Target Upstream Version:
chayang: needinfo-


Attachments (Terms of Use)
guest A device message (23.34 KB, text/plain)
2011-02-21 04:14 UTC, Chao Yang
no flags Details

Description Chao Yang 2011-02-21 04:14:43 UTC
Created attachment 479812 [details]
guest A device message

Description of problem:
There are guest A and guest B, both A and B are boot with vf, then scp large file from A to B, I don't how long time passed, but when I come to office, found guest A lost its ip which cause scp failed.

Version-Release number of selected component (if applicable):
1. qemu-kvm version
# rpm -qa|grep qemu
qemu-kvm-debuginfo-0.12.1.2-2.144.el6.x86_64
qemu-kvm-0.12.1.2-2.144.el6.x86_64
qemu-img-0.12.1.2-2.144.el6.x86_64
gpxe-roms-qemu-0.9.7-6.4.el6.noarch
qemu-kvm-tools-0.12.1.2-2.144.el6.x86_64

2. host kernel version
# uname -r
2.6.32-115.el6.x86_64

3. guest kernel verison
# uname -r
2.6.32-94.el6.x86_64

4. # lspci|grep Eth
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10)
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

How reproducible:
1/1

Steps to Reproduce:
1. boot two guest with following cli, vf1 and vf3 can get ip.
guest A:
# /usr/libexec/qemu-kvm -M rhel6.1.0 -enable-kvm -m 4096 -smp 4 -cpu qemu64,+sse2,+x2apic -name rhel6.1 -uuid `uuidgen` -rtc base=localtime -boot c -drive file=/root/images-rhel6.1/rhel6.1-ide.qcow2,if=none,id=drive-ide0-0-0,media=disk,format=qcow2,cache=none -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0 -net none -usb -device usb-tablet,id=input0 -spice port=8000,disable-ticketing -vga qxl -monitor stdio -balloon none -device pci-assign,host=03:10.1,id=vf1

guest B:
# /usr/libexec/qemu-kvm -M rhel6.1.0 -enable-kvm -m 4096 -smp 4 -cpu qemu64,+sse2,+x2apic -name rhel6.1 -uuid `uuidgen` -rtc base=localtime -boot c -drive file=/root/images-rhel6.1/rhel6.1-ide1.qcow2,if=none,id=drive-ide0-0-0,media=disk,format=qcow2,cache=none -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0 -net none -usb -device usb-tablet,id=input0 -spice port=9000,disable-ticketing -vga qxl -monitor stdio -balloon none -device pci-assign,host=03:10.3,id=vf3

2. scp large file from A to B
  
Actual results:
Guest A lost its ip when scp large file from A to B
Guest A reports:
connection closed by 10.66.73.245
lost connection

Try to ping guest B: 
# ping 10.66.73.245
connect: Network is unreachable.
Expected results:
file copy shouldn't cause ip lost.

Additional info:
If restart guest A network, vf can get ip again.


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