Bug 1263573
| Summary: | Win2008 R2 guest didn't enter into system when migration completed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jingzhao <jinzhao> |
| Component: | qemu-kvm-rhev | Assignee: | Yvugenfi <yvugenfi> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | xianwang <xianwang> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.2 | CC: | chayang, juzhang, knoel, michen, qzhang, virt-maint, xfu, xianwang, ybendito, yvugenfi |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 08:40:34 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
jingzhao
2015-09-16 08:39:31 UTC
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") Hi Qunfang, Free to update QE contact. Best Regards, Junyi 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? 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 (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 (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 (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. (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. (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? (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. 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 \
Closing based on comment #12 |