From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDAUA-0006y2-8r for qemu-devel@nongnu.org; Wed, 15 Jun 2016 09:03:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDAU4-0006Ih-7T for qemu-devel@nongnu.org; Wed, 15 Jun 2016 09:03:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDAU4-0006Ia-22 for qemu-devel@nongnu.org; Wed, 15 Jun 2016 09:03:52 -0400 Date: Wed, 15 Jun 2016 14:03:48 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160615130347.GF2272@work-vm> References: <1465409584-16308-1-git-send-email-haris.phnx@gmail.com> <575882EC.1090906@redhat.com> <575ED37A.10004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <575ED37A.10004@redhat.com> Subject: Re: [Qemu-devel] [Qemu-devel [RFC] [WIP] v2] Keeping the Source side alive incase of network failure (Migration recovery from network failure) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: haris iqbal , QEMU Developers * 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? Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK