On 06/15/2016 07:03 AM, Dr. David Alan Gilbert wrote:
> * Eric Blake (ebl...@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
signature.asc
Description: OpenPGP digital signature
