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

[Dr. David Alan Gilbert]

* Eric Blake (address@hidden) 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?

Dave

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


--
Dr. David Alan Gilbert / address@hidden / Manchester, UK