Re: [Qemu-devel] [Qemu-devel [RFC] [WIP] v2] Keeping the Source side alive incase of network failure (Migration recovery from network failure)

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On 06/13/2016 12:38 AM, haris iqbal wrote:

>>>  ##
>>>  { 'enum': 'RunState',
>>>    'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
>>>              'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
>>>              'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
>>> -            'guest-panicked' ] }
>>> +            'guest-panicked', 'postmigrate-recovery' ] }
>>
>> Adding new enums can cause existing clients like libvirt to do weird
>> things if they aren't expecting the new state. Are we sure we want to do
>> it?
> I think so. If we do not have a new state, then one would not know
> that the VM is in recovery.
> 
>> Is it a state that cannot be entered by default, but only in
>> response to a client request that proves the client is new enough to
>> expect the new state?
> 
> I did not quite understand what you are trying to say.
> 

A client that is not expecting the new 'postmigrate-recovery' state may
mishandle a VM that is in that state.  So I'm suggesting that we may
want to special case this state, and make it possible to enter the state
only if the client has done something first to inform qemu that it
understands what it means for a VM to be in that state.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]