Re: To save or not to save

[Alexander Larsson <alexl redhat com>]

On tor, 2012-11-15 at 19:49 +0200, Zeeshan Ali (Khattak) wrote:
> Hi everyone,
>    As you all know currently we save running local VMs when user quits
> Boxes UI. The reason for doing so were:
> 
> 1.  We want to reclaim all the resources (especially RAM, cause CPU
> could be saved by only pausing the VM)
> 2. VM state should not be lost across reboots/shutdowns of host
> 
> However, saving of VM seems to have been a very heavy operation,
> especially on machines with not a lot of RAM (on my machine with only
> 4GB RAM, host more or less freezes completely for a few seconds). The
> reason AFAICT is that most of guest RAM being unused is swapped out so
> saving then involves copying GBs of data per running VM from one part
> of the drive to another.

I think we very much want to save the VM when exiting. Its one of the
core points of boxes behaviour. I.E. we have a very explicit and simple
model wrt when VMs are running and not that everyone can understand.
There is never any "hidden" state that may cause weird performance
issues, etc.

Also, if you have a small amount of ram like you say above then its even
more important that you save the VMs to free ram when you're not using
boxes anywmore.

That said, yes, saving is heavy, and we should look into possibilities
to make it less so. 

One possibility is to use the S3 mode in the guest. When the guest goes
into S3 mode it save ram to the disk itself, and the guest OS has the
knowledge of which pages are actually in use (and not just page caches
or ununsed). As such it only has to dump these pages to disk, which
should be a lot faster.

Another possibility is to use memory ballooning in the guest to flush
out any unused memory and tell qemu to not use it. This causes qemu to
know which memory is not in use, so it could avoid saving it. (Assuming
qemu save code takes this into account).