summaryrefslogtreecommitdiff
path: root/kvm-all.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2012-10-23 14:54:21 +0200
committerLuiz Capitulino <lcapitulino@redhat.com>2012-10-24 11:27:33 -0200
commit1e9981465f05a0f103d7e09afd975c9c0ff6d132 (patch)
tree614b2fb31ba681b4bde1d2ed2f3a97b9f790227a /kvm-all.c
parent852bef0e0c03e2de9d6441471219cd3bc1bf45b5 (diff)
downloadqemu-1e9981465f05a0f103d7e09afd975c9c0ff6d132.tar.gz
qemu-1e9981465f05a0f103d7e09afd975c9c0ff6d132.tar.bz2
qemu-1e9981465f05a0f103d7e09afd975c9c0ff6d132.zip
qmp: handle stop/cont in INMIGRATE state
Right now, stop followed by an incoming migration will let the virtual machine start. cont before an incoming migration instead will fail. This is bad because the actual behavior is not predictable; it is racy with respect to the start of the incoming migration. That's because incoming migration is blocking, and thus will delay the processing of stop/cont until the end of the migration. In addition, there's nothing that really prevents the user from typing the block device's passwords before incoming migration is done, so returning the DeviceEncrypted error is also helpful in the QMP case. Both things can be fixed by just toggling the autostart variable when stop/cont are called in INMIGRATE state. Note that libvirt is currently working around the race by looping if the MigrationExpected answer is returned. After this patch, the command will return right away without ever raising an error. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Diffstat (limited to 'kvm-all.c')
0 files changed, 0 insertions, 0 deletions