qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [RFC PATCH 0/2] Increase usability of external snapshots
@ 2018-02-27 11:56 Richard Palethorpe
  2018-02-27 11:56 ` [Qemu-devel] [RFC PATCH 1/2] migrate: Allow incoming migration without defer Richard Palethorpe
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Richard Palethorpe @ 2018-02-27 11:56 UTC (permalink / raw)
  To: qemu-devel
  Cc: berrange, qemu-block, armbru, dgilbert, eblake, quintela, mreitz,
	Richard Palethorpe

Hello,

Following on from the discussion about creating savevm/loadvm QMP
equivalents. I decided to take the advice given that we should use external
snapshots. However reverting to a snapshot currently requires QEMU to be
restarted with "-incoming". Restarting QEMU requires a fair bit of book
keeping to be done by the management application and may take measurably more
time.

Also to quote the previous discussion:
>>> > Then you could just use the regular migrate QMP commands for loading
>>> > and saving snapshots.  Might need a little extra work on the incoming
>>> > side, since we need to be able to load snapshots, despite QEMU not
>>> > being started with '-incoming defer', but might still be doable ?
>>> > This would theoretically give us progress monitoring, cancellation,
>>> > etc for free.
>>> 
>>> What actually stops this working other than the sanity check in
>>> migrate_incoming ?
>>
>> No idea really - not looked closely at the code implications.
>
> It would be a plus for migration code, right now there are _two_
> implementations, and savevm/loadvm one gets less love.
>
> And we will check "much more" the way to load migration in a
> non-pristine qemu, so ....
>
> Later, Juan.

This patch just changes a few lines which shuts down the currently running VM
and puts the QEMU instance into a state where it can accept an incoming
migration. I haven't tested it yet with more complex scenarios, but it
appears to work fine so far.

I have also started work on a new migration test, which is almost identical to
the existing post-copy test, but migrates to a non-pristine QEMU. It works on
X86, but not yet on PPC64 because the serial output is different. It needs
quite a lot more work, but before I continue, I would like to know first if
this is something people fundamentally object to?

Richard Palethorpe (2):
  migrate: Allow incoming migration without defer
  migrate: Tests for migrating to an already used QEMU

 migration/migration.c  |  12 +++---
 tests/migration-test.c | 113 +++++++++++++++++++++++++++++++++++++------------
 vl.c                   |   2 +
 3 files changed, 92 insertions(+), 35 deletions(-)

-- 
2.16.2

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-03-05 15:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-27 11:56 [Qemu-devel] [RFC PATCH 0/2] Increase usability of external snapshots Richard Palethorpe
2018-02-27 11:56 ` [Qemu-devel] [RFC PATCH 1/2] migrate: Allow incoming migration without defer Richard Palethorpe
2018-03-01 16:59   ` Dr. David Alan Gilbert
2018-03-05 15:33     ` Richard Palethorpe
2018-02-27 11:56 ` [Qemu-devel] [RFC PATCH 2/2] migrate: Tests for migrating to an already used QEMU Richard Palethorpe
2018-03-01 17:32   ` Dr. David Alan Gilbert
2018-02-27 16:07 ` [Qemu-devel] [RFC PATCH 0/2] Increase usability of external snapshots no-reply
2018-03-02 16:15 ` [Qemu-devel] [Qemu-block] " Roman Kagan
2018-03-05 14:38   ` Richard Palethorpe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).