Hide Forgot
Description of problem: When do "cont" inside qmp with qemu-kvm using -incoming, qmp do not give any error message. But inside rhel6 host qmp will give some error message. Please see "Additional info". Version-Release number of selected component (if applicable): qemu-kvm-1.5.3-2.el7.x86_64 3.10.0-18.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.run qemu-kvm using -incoming. # /usr/libexec/qemu-kvm -monitor stdio -incoming tcp:0:5800 -qmp tcp:0:4445,server,nowait 2.run "cont" inside qmp. {"execute":"cont"} Actual results: {"return": {}} Expected results: When run {"execute":"cont"} inside qmp, qmp will give some warning or error message like in RHEL6 host. Additional info: I also do this inside RHEL6.5 host, it gives some error message. {"execute":"cont"} {"error": {"class": "MigrationExpected", "desc": "An incoming migration is expected before this command can be executed", "data": {}}} Version-Release number of selected component: 2.6.32-418.el6.x86_64 qemu-kvm-0.12.1.2-2.402.el6.x86_64
We consciously dropped this error and changed the semantics of the cont command not to fail. We're not supposed to change command's behavior this way, this is really an exception which we don't believe will cause any breakages. If this does break anything, please re-open and set to high priority. Here's the full commit log for an explanation and for future reference: commit 1e9981465f05a0f103d7e09afd975c9c0ff6d132 Author: Paolo Bonzini <pbonzini> Date: Tue Oct 23 14:54:21 2012 +0200 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> Signed-off-by: Luiz Capitulino <lcapitulino>
I'll add a note on the reason _why_ we changed it. In RHEL6, the monitor is not accessible during incoming migration. Thus, the MigrationExpected error will only happen before migration is started. Once migration is started, the RHEL6 monitor will block for the whole duration of migration; the "cont" command will be processed at the end of migration and start the VM. In RHEL7, the monitor remains accessible during incoming migration. However, it is possible that a management application is relying on "cont" starting the VM if it is issued after migration has started (management can figure that out from the "query-migrate" monitor command). Thus, we needed anyway to implement emulation of the RHEL6 behavior. At this point, we had the necessary code to drop altogether the mostly useless "MigrationExpected" error.