* 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?
Dave
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
