Bug 1247541

Summary: [migration] migration will cause nic device broken if "vhost=on" on source and no vhost parameter on destination
Product: Red Hat Enterprise Linux 7 Reporter: Zhengtong <zhengtli>
Component: qemu-kvm-rhevAssignee: jason wang <jasowang>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: ailan, amit.shah, dgilbert, jasowang, juzhang, knoel, michen, qiguo, qzhang, scui, shu, virt-maint, yfu, zhengtli
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-26 06:10:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Zhengtong 2015-07-28 09:31:43 UTC 
Description of problem:

The nic device won't work if do migration while  "vhost=on" for source guest, and no vhost parameter for destination guest. 


Version-Release number of selected component (if applicable):

qemu-kvm-rhev-2.3.0-12.el7


How reproducible:

100%

Steps to Reproduce:
1.boot up guest with cmd as follows on host A:

/usr/libexec/qemu-kvm -name liuzt-RHEL-7.2_LE -machine pseries,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 \
-rtc base=localtime,clock=host,driftfix=slew \
-monitor stdio \
-no-shutdown \
-boot strict=on \
-device usb-ehci,id=usb,bus=pci.0,addr=0x2 \
-device pci-ohci,id=usb1,bus=pci.0,addr=0x1 \
-drive file=/root/test_home/liuzt/vdisk/rhel_le_mig.img,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none \
-device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-serial pty \
-device usb-kbd,id=input0 \
-device usb-mouse,id=input1 \
-device usb-tablet,id=input2 \
-vnc 0:16 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x4 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \
-msg timestamp=on \
-netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c4:e7:83,bus=pci.0,addr=0x6 \
-qmp tcp:0:4444,server,nowait \


and destination incoming guest on host B:

/usr/libexec/qemu-kvm -name liuzt-RHEL-7.2_LE -machine pseries,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 \
... \
-netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
... \
-incoming tcp:0:5980

2.Do migration 
(qemu) migrate -d tcp:10.16.67.19:5980

3.Ping out from guest

Actual results:

Can't ping out , and can't transfer data through target nic device.


Expected results:

nic device works well.

Additional info:
Comment 2 jason wang 2015-07-28 09:41:33 UTC 
Can you try upstream qemu.git to see if it works?

Thanks
Comment 3 Zhengtong 2015-07-29 03:44:13 UTC 
(In reply to jason wang from comment #2)
> Can you try upstream qemu.git to see if it works?
> 
> Thanks

Tried with upstream qemu code with  commit below

commit 170f209d7848dc2f14b3f3dccc34a49558680d4d


There is no such problems

ping process always works well through target net device before and after migration.

[root@dhcp71-167 ~]# ping 10.16.67.243
PING 10.16.67.243 (10.16.67.243) 56(84) bytes of data.
64 bytes from 10.16.67.243: icmp_seq=1 ttl=64 time=0.121 ms
64 bytes from 10.16.67.243: icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from 10.16.67.243: icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from 10.16.67.243: icmp_seq=4 ttl=64 time=0.064 ms
64 bytes from 10.16.67.243: icmp_seq=5 ttl=64 time=0.069 ms
64 bytes from 10.16.67.243: icmp_seq=6 ttl=64 time=0.066 ms
64 bytes from 10.16.67.243: icmp_seq=7 ttl=64 time=0.071 ms
Comment 4 Yanan Fu 2015-08-03 08:45:16 UTC 
This issue also exist with X86_64.

version as following:

kernel: 3.10.0-300.el7.x86_64
qemu-kvm: 2.3.0-13.el7.x86_64
Comment 5 Dr. David Alan Gilbert 2015-08-03 09:12:26 UTC 
(In reply to Zhengtong from comment #3)
> (In reply to jason wang from comment #2)
> > Can you try upstream qemu.git to see if it works?
> > 
> > Thanks
> 
> Tried with upstream qemu code with  commit below
> 
> commit 170f209d7848dc2f14b3f3dccc34a49558680d4d

Does it fail on the commit before this - i.e. is it definitely fixed
by something in this commit?

Dave

> 
> There is no such problems
> 
> ping process always works well through target net device before and after
> migration.
> 
> [root@dhcp71-167 ~]# ping 10.16.67.243
> PING 10.16.67.243 (10.16.67.243) 56(84) bytes of data.
> 64 bytes from 10.16.67.243: icmp_seq=1 ttl=64 time=0.121 ms
> 64 bytes from 10.16.67.243: icmp_seq=2 ttl=64 time=0.089 ms
> 64 bytes from 10.16.67.243: icmp_seq=3 ttl=64 time=0.071 ms
> 64 bytes from 10.16.67.243: icmp_seq=4 ttl=64 time=0.064 ms
> 64 bytes from 10.16.67.243: icmp_seq=5 ttl=64 time=0.069 ms
> 64 bytes from 10.16.67.243: icmp_seq=6 ttl=64 time=0.066 ms
> 64 bytes from 10.16.67.243: icmp_seq=7 ttl=64 time=0.071 ms
Comment 6 Zhengtong 2015-08-04 09:29:43 UTC 
(In reply to Dr. David Alan Gilbert from comment #5)
> (In reply to Zhengtong from comment #3)
> > (In reply to jason wang from comment #2)
> > > Can you try upstream qemu.git to see if it works?
> > > 
> > > Thanks
> > 
> > Tried with upstream qemu code with  commit below
> > 
> > commit 170f209d7848dc2f14b3f3dccc34a49558680d4d
> 
> Does it fail on the commit before this - i.e. is it definitely fixed
> by something in this commit?
> 
> Dave
> 
> > 
> > There is no such problems
> > 
> > ping process always works well through target net device before and after
> > migration.
> > 
> > [root@dhcp71-167 ~]# ping 10.16.67.243
> > PING 10.16.67.243 (10.16.67.243) 56(84) bytes of data.
> > 64 bytes from 10.16.67.243: icmp_seq=1 ttl=64 time=0.121 ms
> > 64 bytes from 10.16.67.243: icmp_seq=2 ttl=64 time=0.089 ms
> > 64 bytes from 10.16.67.243: icmp_seq=3 ttl=64 time=0.071 ms
> > 64 bytes from 10.16.67.243: icmp_seq=4 ttl=64 time=0.064 ms
> > 64 bytes from 10.16.67.243: icmp_seq=5 ttl=64 time=0.069 ms
> > 64 bytes from 10.16.67.243: icmp_seq=6 ttl=64 time=0.066 ms
> > 64 bytes from 10.16.67.243: icmp_seq=7 ttl=64 time=0.071 ms

Any version or commit id suggested? I just use the latest code at the time I do the test. and attached the commit id Incidentally.
Comment 7 Dr. David Alan Gilbert 2015-08-05 08:46:27 UTC 
(In reply to Zhengtong from comment #6)
> (In reply to Dr. David Alan Gilbert from comment #5)
> > (In reply to Zhengtong from comment #3)
> > > (In reply to jason wang from comment #2)
> > > > Can you try upstream qemu.git to see if it works?
> > > > 
> > > > Thanks
> > > 
> > > Tried with upstream qemu code with  commit below
> > > 
> > > commit 170f209d7848dc2f14b3f3dccc34a49558680d4d
> > 
> > Does it fail on the commit before this - i.e. is it definitely fixed
> > by something in this commit?
> > 
> > Dave
> > 
> > > 
> > > There is no such problems
> > > 
> > > ping process always works well through target net device before and after
> > > migration.
> > > 
> > > [root@dhcp71-167 ~]# ping 10.16.67.243
> > > PING 10.16.67.243 (10.16.67.243) 56(84) bytes of data.
> > > 64 bytes from 10.16.67.243: icmp_seq=1 ttl=64 time=0.121 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=2 ttl=64 time=0.089 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=3 ttl=64 time=0.071 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=4 ttl=64 time=0.064 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=5 ttl=64 time=0.069 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=6 ttl=64 time=0.066 ms
> > > 64 bytes from 10.16.67.243: icmp_seq=7 ttl=64 time=0.071 ms
> 
> Any version or commit id suggested? I just use the latest code at the time I
> do the test. and attached the commit id Incidentally.

Ah OK, if that was just the latest version you tried, then I don't have any more suggestions to try at the moment.
Comment 11 Zhengtong 2015-08-10 06:27:39 UTC 
Hi Jason,

Good news, The problem resolved with the packages you supplied.

details:

1. Reproduced this problems with migrating on single host with 
qemu-kvm-rhev-2.3.0-13.el7

2. Swithed the qemu-kvm-rhev version to 
qemu-kvm-rhev-2.3.0-15.el7bz1248312 ,  the problems disappeared.
Comment 12 jason wang 2015-08-12 02:24:33 UTC 
*** Bug 1252355 has been marked as a duplicate of this bug. ***
Comment 13 juzhang 2015-08-12 02:29:52 UTC 
Since bz1252355 is marked duplicated of this bz. Adding regression keywords for this bz.