Bug 1007702

Summary:	qmp do not give any error message when run "cont" inside qmp with qemu-kvm using -incoming
Product:	Red Hat Enterprise Linux 7	Reporter:	Jun Li <juli>
Component:	qemu-kvm	Assignee:	Laszlo Ersek <lersek>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	acathrow, hhuang, juzhang, lcapitulino, michen, pbonzini, qzhang, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-30 13:37:20 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 Jun Li 2013-09-13 07:24:32 UTC

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

Comment 4 Luiz Capitulino 2013-09-30 13:37:20 UTC

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>

Comment 5 Paolo Bonzini 2013-10-01 07:49:56 UTC

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.