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.