Hide Forgot
---Problem Description--- Windows7 guest fails to shutdown after migration ---uname output--- Linux hostname.in.ibm.com 2.6.32-118.el6.x86_64 #1 SMP Tue Feb 22 11:15:55 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Machine Type = HS22 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Windows7 guest fails to shutdown after migration ---KVM Component Data--- Userspace tool common name: qemu-kvm The userspace tool has the following bit modes: 64 Userspace rpm: qemu-kvm-0.12.1.2-2.148.el6.x86_64 Kernel version: Linux phx2.in.ibm.com 2.6.32-118.el6.x86_64 #1 SMP Tue Feb 22 11:15:55 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Qemu version: qemu-kvm-tools-0.12.1.2-2.148.el6.x86_64 Guest OS: Windows7 (32 and 64bit) Guest OS Image storage type: nfs file Host Machine Type: HS22 Target Machine Type (for migration): same format as Host Machine Type Test Type: manual Qemu Command Line: /usr/libexec/qemu-kvm -enable-kvm -m 7862 -smp 8,sockets=8,cores=1,threads=1 -name win-64 -monitor stdio -drive file=win7-64.raw,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,script=/root/qemu-ifup,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:9a:2f:bf,bus=pci.0,addr=0x3 -usb -device usb-tablet,id=input0 -vnc :2 Target Qemu Command Line: /usr/libexec/qemu-kvm -enable-kvm -m 7862 -smp 8,sockets=8,cores=1,threads=1 -name win-64 -monitor stdio -drive file=win7-64.raw,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,script=/root/qemu-ifup,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:9a:2f:bf,bus=pci.0,addr=0x3 -usb -device usb-tablet,id=input0 -vnc :5 -boot cd -incoming tcp:0:4444 Step to recreate: 1. Start the VM on B with the exact same parameters as the VM on A, in migration-listen mode: B: <qemu-command-line> -incoming tcp:0:4444 2. Start the migration on the source host: A: migrate -d tcp:B:4444 3. Check the status A: (qemu) info migrate =Comment: #2================================================= 1.Server architecture(s) (please list all effected) (x86/POWER6/Z/etc.): x86 2.Server type (9117-MMA/HS20/s390/etc.): IBM HS22 Blade server 3.General component (desktop/kernel/base OS/dev tools/etc.): qemu-kvm 4.Other components involved (ixgbe/java/emulex/etc.): NA 5.Does the server have the latest GA firmware? yes 6.Has the problem been shown to occur on more than one system? yes 7.Is a tested patch available? no If yes to the above, has it been approved upstream? 8.What is the latest official Red Hat build on which this bug has been seen? RHEL 6.1 Alpha
Tried on qemu-kvm-0.12.1.2-2.151.el6.x86_64 1.start win7(both 32bit and 64 bit) with -cpu 4 -m 4G Actual Results: after migration ,guest can shutdown , Can NOT reproduce ,will try on a big machine tmr
Seems to work on upstream. Does 'shutdown' refer to the shutdown button, or system_powerdown via the monitor? The steps to reproduce are silent on the matter.
Tried on qemu-kvm-0.12.1.2-2.152.el6.x86_64 command same as described in comment #0 Actual Results: One time guest can not shutdown after migration,because the clock of 2 hosts not sync'ed. After sync 2 hosts clock by using #ntpdate -b XXX then can not reproduce
Hi,Avi According to comment5,would you please tell me this is not bug or ?
another question,user must sync time by themselves?or our management(such as virt-manger) can take care sync related thing?thanks.
I don't get it. What is the relationship between guest shutdown and the host clock? It may be some timer that fails to fire though. If it doesn't reproduce with synced clocks, reliably, I recommend closing the bug.
The sync of the src/dst hosts is a nice to have but not required. If they are our of sync the management that spawns qemu needs to supply the right rtc offset for the destination guest. I wonder why the live migration protocol does not override this w/ rtc state being passed. I'll move this issue to 6.2 since it is not a blocker and can be handled by mgmt in the common case.
Timing dependent guest operations only work if time is synchronized across migration source and destination.