From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cX3HO-0005Ui-MB for qemu-devel@nongnu.org; Fri, 27 Jan 2017 04:57:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cX3HK-0005IZ-T7 for qemu-devel@nongnu.org; Fri, 27 Jan 2017 04:57:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53280) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cX3HK-0005IJ-No for qemu-devel@nongnu.org; Fri, 27 Jan 2017 04:57:10 -0500 Date: Fri, 27 Jan 2017 09:57:02 +0000 From: "Daniel P. Berrange" Message-ID: <20170127095702.GD26553@redhat.com> Reply-To: "Daniel P. Berrange" References: <1485422212-31546-1-git-send-email-ashijeetacharya@gmail.com> <20170127093742.GB26553@redhat.com> <20170127094613.GA3323@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170127094613.GA3323@work-vm> Subject: Re: [Qemu-devel] [PATCH] migrate: Migration aborts abruptly for machine "none" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Ashijeet Acharya , thuth@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org On Fri, Jan 27, 2017 at 09:46:13AM +0000, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > On Thu, Jan 26, 2017 at 02:46:52PM +0530, Ashijeet Acharya wrote: > > > Migration of a "none" machine with no RAM crashes abruptly as > > > bitmap_new() fails and thus aborts. Instead, place a check for > > > last_ram_offset() being '0' at the start of ram_save_setup() and > > > error out with a meaningful error message. > > > > > > Signed-off-by: Ashijeet Acharya > > > --- > > > migration/ram.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/migration/ram.c b/migration/ram.c > > > index ef8fadf..bf05d69 100644 > > > --- a/migration/ram.c > > > +++ b/migration/ram.c > > > @@ -1947,6 +1947,11 @@ static int ram_save_setup(QEMUFile *f, void *opaque) > > > { > > > RAMBlock *block; > > > > > > + if (last_ram_offset() == 0) { > > > + error_report("Failed to migrate: No RAM available!"); > > > + return -1; > > > + } > > > + > > > > If we're merely going to block migration, as opposed to making it work, > > then IMHO we should use migration blockers registered at machine setup > > for this task. > > > > We have a new cli arg added to QEMU to tell it to abort startup if the > > machine configuration is not migratable. That only works if using > > migration blockers - this check you've added is too late to be detected > > at startup. > > Hmm, yes you're right, that would be better. > Although it does lead to an interesting situation where starting with a 'none' > and constructing it component at a time would get rejected by --only-migratable > even though the final construction is fine. Even in that case I would expect the ram to be specified upfront e.g. $qemu -machine none -m 500 thus avoiding addition of the migration blocker Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|