[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-devel [RFC] [WIP] v2] Keeping the Source side ali

From: Eric Blake
Subject: Re: [Qemu-devel] [Qemu-devel [RFC] [WIP] v2] Keeping the Source side alive incase of network failure (Migration recovery from network failure)
Date: Mon, 13 Jun 2016 09:38:34 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]