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: 1742 bytes --]

On 06/15/2016 07:03 AM, Dr. David Alan Gilbert wrote:
> * Eric Blake (eblake@redhat.com) wrote:
>> 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.
> 
> Do you mean another migration capability?
> 

Sure, that would be an introspectible way - if left off, the state
cannot be reached, but if the client turns the capability on, then the
state is useful.

-- 
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 --]