From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujFX-00020w-8u for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:48:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZujFR-0006Fh-AZ for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:48:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujFR-0006FN-6G for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:48:17 -0500 Date: Fri, 6 Nov 2015 15:48:11 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151106154810.GC4267@work-vm> References: <1446747083-18205-1-git-send-email-dgilbert@redhat.com> <20151106034846.GC29481@in.ibm.com> <20151106090952.GA2459@work-vm> <20151106122222.GF2459@work-vm> <20151106134341.GG2459@work-vm> <20151106153314.GA14232@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151106153314.GA14232@in.ibm.com> Subject: Re: [Qemu-devel] [PATCH v9 00/56] Postcopy implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, liang.z.li@intel.com, "qemu-devel@nongnu.org" , luis@cs.umu.se, Bharata B Rao , "amit.shah@redhat.com" , Paolo Bonzini , David Gibson * Bharata B Rao (bharata@linux.vnet.ibm.com) wrote: > > Where we have iterable, but non-postcopiable devices (e.g. htab > > or block migration), complete them before forming the 'package' > > but with the CPUs stopped. This stops them filling up the package. > > That helps and the migration suceeds now when I switch to postcopy > immediately after starting the migration. Excellent. > However after postcopy migration, when I attempt to start an incoming > instance again to migrate the guest back, I see this failure: > > qemu-system-ppc64: cannot set up guest memory 'ppc_spapr.ram': Cannot allocate memory > > The same doesn't happen with normal migration. Huh that's fun; that's the original source guest that's running out of RAM? It's original QEMU should be gone by that point. > > I will see if I can debug this more tomorrow. Thanks. Dave > > Regards, > Bharata. > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK