Hello Roman, Roman Kagan writes:
> On Tue, Feb 27, 2018 at 12:56:49PM +0100, Richard Palethorpe wrote: >> 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. > > AFAICT "-incoming" is not the only reason for starting QEMU anew. The > block devices will need to be pointed at different nodes in the backing > chains. Moreover the snapshot you're reverting to may have been taken > at a point where the VM had different configuration than it has now. OK, so contrary to what I thought, it looks like there is no QMP command to simply drop the current active layer and repoint the block device to the previous node in the chain. We would have to recreate the block device with the desired backing store and overlays or create a new command. I am not sure that is a showstopper though. > > So the management application will need to do a lot of bookkeeping stuff > anyway, and it'll probably have harder time applying all of the > configuration changes to a live QEMU instance. Well in our use case, configuration changes between snapshots would not be possible. For other use cases the management app will have to restart QEMU when necessary. AFAICT, with or without this patch it is possible for someone to try accepting an incoming migration with an invalid configuration. So I would hope that this is not introducing a new problem? > > Is the cost of killing the old QEMU process and starting a new one big > enough to be worth all the hassle? I doubt I can justify it based on performance, atleast not for our use case, but terminating the QEMU process will interrupt a number of socket connections and such. I am sure this is a technically easier problem to solve than modifying QEMU, but there is one QEMU and many management apps so *maybe* the effort is better spent on QEMU if it avoids more work in the management apps and is not introducing features to QEMU outside of its scope. QEMU already supports reverting to internal snapshots in a live instance, so I don't think I am increasing its scope. > > Thanks, > Roman. -- Thank you, Richard.
