Bug 1263573 - Win2008 R2 guest didn't enter into system when migration completed
Win2008 R2 guest didn't enter into system when migration completed
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.2
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Yan Vugenfirer
xianwang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-16 04:39 EDT by jingzhao
Modified: 2017-08-01 21:53 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 04:40:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jingzhao 2015-09-16 04:39:31 EDT
Description of problem:
Win2008 R2 guest didn't enter into system when migration completed

Version-Release number of selected component (if applicable):
Guest win2008 R2
Host kernel:3.10.0-316.el7.x86_64
qemu-kvm-rhev-2.3.0-23.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot win2008 r2 guest with cli in the src host:
/usr/libexec/qemu-kvm \
-M pc \
-cpu IvyBridge \
-nodefaults -rtc base=utc -no-hpet \
-m 2G \
-smp 4,sockets=2,cores=2,threads=1 \
-enable-kvm \
-name rhel7.2 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-monitor stdio \
-qmp tcp:0:6661,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-serial unix:/tmp/serial0,server,nowait \
-vga cirrus \
-vnc :0  \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=1e:55:60:41:0c:37,bus=pci.0,addr=0x3,vectors=10,mq=on \
-chardev socket,id=seabios,path=/tmp/seabios,server,nowait \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-usb \
-device usb-tablet,id=tablet0 \
-object iothread,id=iothread0 \
-drive file=/home/win8r2/win8r2.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,bus=pci.0,id=drive-virtio-disk0,drive=drive-virtio-disk0,bootindex=1,iothread=iothread0 \
-object iothread,id=iothread1 \
-drive file=/home/win8r2/disk,if=none,id=drive-data-disk1,format=raw,cache=none,aio=native,werror=stop,rerror=stop,bps=1024000,bps_rd=0,bps_wr=0,iops=1024000,iops_rd=0,iops_wr=0 \
-device virtio-blk-pci,drive=drive-data-disk1,id=data-disk1,iothread=iothread1,bus=pci.0,addr=0x5 \
-drive file=/home/win8r2/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617601.iso,if=none,media=cdrom,id=drive-ide0,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=0 \
-drive file=/usr/share/virtio-win/virtio-win.iso,if=none,media=cdrom,id=drive-ide1,format=raw \
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide1,id=ide1 \
2.run cli in des host:
/usr/libexec/qemu-kvm \
-M pc \
-cpu IvyBridge \
-nodefaults -rtc base=utc -no-hpet \
-m 2G \
-smp 4,sockets=2,cores=2,threads=1 \
-enable-kvm \
-name rhel7.2 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-monitor stdio \
-qmp tcp:0:6661,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-serial unix:/tmp/serial0,server,nowait \
-vga cirrus \
-vnc :0  \
-netdev tap,id=hostnet0,vhost=on,fds=20:21:22:23 20<>/dev/tap7 21<>/dev/tap7 22<>/dev/tap7 23<>/dev/tap7 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=1e:55:60:41:0c:37,bus=pci.0,addr=0x3,vectors=10,mq=on \
-chardev socket,id=seabios,path=/tmp/seabios,server,nowait \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-usb \
-device usb-tablet,id=tablet0 \
-object iothread,id=iothread0 \
-drive file=/mnt/win8r2/win8r2.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,bus=pci.0,id=drive-virtio-disk0,drive=drive-virtio-disk0,bootindex=1,iothread=iothread0 \
-object iothread,id=iothread1 \
-drive file=/mnt/win8r2/disk,if=none,id=drive-data-disk1,format=raw,cache=none,aio=native,werror=stop,rerror=stop,bps=1024000,bps_rd=0,bps_wr=0,iops=1024000,iops_rd=0,iops_wr=0 \
-device virtio-blk-pci,drive=drive-data-disk1,id=data-disk1,iothread=iothread1,bus=pci.0,addr=0x5 \
-drive file=/home/win8r2/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617601.iso,if=none,media=cdrom,id=drive-ide0,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=0 \
-drive file=/usr/share/virtio-win/virtio-win.iso,if=none,media=cdrom,id=drive-ide1,format=raw \
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide1,id=ide1 \
-incoming  tcp:0:5800
3. Reboot system or "system_reset" in qemu after guest boot up and enter into the system ( in src host)
4. execute "migrate -d tcp:dest ip:5800" in src host
5. Check the system in dest host when migrate completed

Actual results:
Guest didn't enter into the system when input the passwd, also keep the screen of "Preparing the desktop"

Expected results:
Guest can enter into the OS correctly

Additional info:
Comment 1 jingzhao 2015-09-16 05:07:26 EDT
The same issue occurs when migrate with vm boot, especially, the issue occurs when do the migrate operation after display the screen of loading win2008(behind the "Start Windows Normally")
Comment 3 juzhang 2017-06-08 08:09:59 EDT
Hi Qunfang,

Free to update QE contact.

Best Regards,
Junyi
Comment 4 ybendito 2017-07-25 09:54:01 EDT
I see the source vm runs with tap network interface and destination with macvtap. Does the same procedure of migration from source tap to source destination work?
Comment 5 ybendito 2017-07-25 10:04:24 EDT
Also: in case teh migration from tap setup to macvtap setup is in intention, please provide exact steps how you configure the system before running VMs to have  macvtap working
Comment 6 xianwang 2017-07-27 03:29:10 EDT
(In reply to ybendito from comment #5)
> Also: in case teh migration from tap setup to macvtap setup is in intention,
> please provide exact steps how you configure the system before running VMs
> to have  macvtap working

Hi, zhaojing, could you help to reply this comment? thanks
Comment 7 jingzhao 2017-07-27 04:26:05 EDT
(In reply to xianwang from comment #6)
> (In reply to ybendito from comment #5)
> > Also: in case teh migration from tap setup to macvtap setup is in intention,
> > please provide exact steps how you configure the system before running VMs
> > to have  macvtap working
> 
> Hi, zhaojing, could you help to reply this comment? thanks

create macvtap, please check following steps

# ip link add link eno1 name brg_macvtap type macvtap mode bridge
# ip link set brg_macvtap up
# ip link show

....
69: brg_macvtap@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 500
link/ether c2:54:bb:58:b9:d2 brd ff:ff:ff:ff:ff:ff

qemu command line:

-netdev tap,id=hostnet0,vhost=on,fd=9 
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=c2:54:bb:58:b9:d2 9<>/dev/tap69

Thanks
Jing
Comment 8 xianwang 2017-07-27 05:14:52 EDT
(In reply to ybendito from comment #4)
> I see the source vm runs with tap network interface and destination with
> macvtap. Does the same procedure of migration from source tap to source
> destination work?

generally speaking, source end and destination end should have similar interface with tap, we don't allow migration to happen if the command line is not matched, migration developer suggest the qemu cli of two sides keep matched. so, I am not sure whether this scenario is valid.
Comment 9 Yan Vugenfirer 2017-07-27 05:17:23 EDT
(In reply to xianwang from comment #8)
> (In reply to ybendito from comment #4)
> > I see the source vm runs with tap network interface and destination with
> > macvtap. Does the same procedure of migration from source tap to source
> > destination work?
> 
> generally speaking, source end and destination end should have similar
> interface with tap, we don't allow migration to happen if the command line
> is not matched, migration developer suggest the qemu cli of two sides keep
> matched. so, I am not sure whether this scenario is valid.

Can you please retest?
I think we should have two scenarios: tap to tap and macvtap to macvtap.
Comment 10 xianwang 2017-07-27 22:16:01 EDT
(In reply to Yan Vugenfirer from comment #9)
> (In reply to xianwang from comment #8)
> > (In reply to ybendito from comment #4)
> > > I see the source vm runs with tap network interface and destination with
> > > macvtap. Does the same procedure of migration from source tap to source
> > > destination work?
> > 
> > generally speaking, source end and destination end should have similar
> > interface with tap, we don't allow migration to happen if the command line
> > is not matched, migration developer suggest the qemu cli of two sides keep
> > matched. so, I am not sure whether this scenario is valid.
> 
> Can you please retest?
> I think we should have two scenarios: tap to tap and macvtap to macvtap.

OK, since this bug is reported two years ago, so, I think it worth to retest this scenario on the RHEL7.4 host with newest qemu-kvm-rhev and kernel version, how do you think?
Comment 11 Yan Vugenfirer 2017-07-30 04:23:32 EDT
(In reply to xianwang from comment #10)
> (In reply to Yan Vugenfirer from comment #9)
> > (In reply to xianwang from comment #8)
> > > (In reply to ybendito from comment #4)
> > > > I see the source vm runs with tap network interface and destination with
> > > > macvtap. Does the same procedure of migration from source tap to source
> > > > destination work?
> > > 
> > > generally speaking, source end and destination end should have similar
> > > interface with tap, we don't allow migration to happen if the command line
> > > is not matched, migration developer suggest the qemu cli of two sides keep
> > > matched. so, I am not sure whether this scenario is valid.
> > 
> > Can you please retest?
> > I think we should have two scenarios: tap to tap and macvtap to macvtap.
> 
> OK, since this bug is reported two years ago, so, I think it worth to retest
> this scenario on the RHEL7.4 host with newest qemu-kvm-rhev and kernel
> version, how do you think?

I agree.
Comment 12 xianwang 2017-08-01 02:49:26 EDT
I have tested three scenarios on newest version as follows, the result are all pass:
Host:
3.10.0-693.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7.x86_64

Guest:
win2008-r2-64-virtio.qcow2

1)scenario I:
tap<-->tap: migration completed and vm works well.

qemu cli (both src and dst):    
    -netdev tap,id=hostnet0,vhost=on,queues=4,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on \

2)scenario II:
tap<-->macvtap: migration completed and vm works well.

qemu cli (src):
    -netdev tap,id=hostnet0,vhost=on,queues=4,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on \

qemu cli (dst):
    -netdev tap,id=hostnet0,vhost=on,fds=9:10:11:12 \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on 9<>/dev/tap9 10<>/dev/tap9 11<>/dev/tap9 12<>/dev/tap9 \

3) macvtap<-->macvtap: migration completed and vm works well.

qemu cli (src):
    -netdev tap,id=hostnet0,vhost=on,fds=23:24:25:26 \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on 23<>/dev/tap23 24<>/dev/tap23 25<>/dev/tap23 26<>/dev/tap23 \

qemu cli (dst):
    -netdev tap,id=hostnet0,vhost=on,fds=9:10:11:12 \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on 9<>/dev/tap9 10<>/dev/tap9 11<>/dev/tap9 12<>/dev/tap9 \
Comment 13 Yan Vugenfirer 2017-08-01 04:40:34 EDT
Closing based on comment #12

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