Hide Forgot
Description of problem: Migrate a rhel geust (I test rhel6.3) from src host to des immediately after it boot up. guest will stop at the grub screen and need user manually press "Enter" key to make it boot into the kernel. Otherwise guest will be "waiting" on the screen for a long time (Not sure always or just some minutes. I wait it for a few minutes but the guest still stop here, so I manually press the "Enter" key). Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.231.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot a rhel6.3 guest with "-S" option in the src host. 2. Boot the guest in the des host with "-incoming tcp:0:5800" without "-S" 3. Migrate the guest. Actual results: Guest stops at the grub screen and need a manual "Enter" input. Expected results: Guest should boot into the kernel normally. Additional info:
Created attachment 564344 [details] The screen guest stops
CLI: /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu cpu64-rhel6 -enable-kvm -m 1G -smp 1,sockets=1,cores=1,threads=1 -name rhel6.3-64 -uuid 2baf4e5d-081f-4577-a950-13327d8f7135 -rtc base=localtime,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive file=/opt/rhel6.3-64-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=49-8260-01240e615621,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/boot.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:1a:16,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/tmp/qzhang-test,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -vnc :10 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,addr=0x7 -S -monitor stdio
Hi, I'm trying to understand the workflow. what is the use case in migrating a suspend guest into a running guest ? Did you use rhevm ? libvirt ?
(In reply to comment #4) > Hi, > I'm trying to understand the workflow. > what is the use case in migrating a suspend guest into a running guest ? > Did you use rhevm ? libvirt ? Hi, Orit I just used the qemu command line, did not use the management tools. This case is to add "-S" in the src host and don't append it in the dst host, then implement migration. And the target is to make sure migration in the early boot stage succeeds. This is a regression test case, we had related bug before, for example: https://bugzilla.redhat.com/show_bug.cgi?id=693894
Does it reproduced if you add the -S on the destination too. 1) migrate the guest 2) after migration completed resume the guest (cont command in the monitor)
It's weird that I can not reproduce it even with the exact command line in Comment 0. Continue trying, and will update it here later.
Hi all, Is there a chance this caused by Bug 734426? Key to reproduce this maybe that host time on destination is behind source, but how much amount behind to reproduce this is uncertain.
(In reply to comment #6) > Does it reproduced if you add the -S on the destination too. > 1) migrate the guest > 2) after migration completed resume the guest (cont command in the monitor) Yes, this issue is reproduced when I add the -S on the destination too. And it will be reproduced when the destination host clock is few mins backwards than the source host.
*** This bug has been marked as a duplicate of bug 734426 ***