On Fri, Jan 27, 2017 at 03:22:38PM +0530, Ashijeet Acharya wrote: > Okay > > On Friday, 27 January 2017, Daniel P. Berrange <berra...@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 <ashijeetacha...@gmail.com > > <javascript:;>> > > > --- > > > 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 > > > Are you referring to the new "--only-migratable" option I added along with > John last week? > > migration blockers - this check you've added is too late to be detected > > at startup. > > > I think that the machine is not completely 'non-migratable' because if I > boot qemu with "-m 1G" (say) the migration actually completes successfully.
Of course - you would only add the migration blocker when ram size is 0 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/ :|