[Qemu-devel] Taking live snapshots of running VMs

[Qemu-devel] Taking live snapshots of running VMs

[Ahmed M. Azab]

Hi All,

Is there a way to take a live memory snapshot of a running VM without
freezing or stopping this VM?

I explored the Qemu code and documentation and I found two ways to
take a snapshot:

1-Using "savevm" Qemu monitor command, which freezes the VM for tens of seconds
2-Using "migrate" and select the destination as a file, which forces
the machine to stop after the snapshot is saved.

In production environments (where delaying the operations of a VM is
very critical), it is always useful to take memory snapshots to do
system analysis or forensics. I think Qemu should provide a way to
take a snapshot based on QOW technque of memory pages (same as the
QCOW disk snapshoting).

If such technique does not exist, I am willing it devlop it myself,
but I wonder if the Qemu community will be interested to add my patch
to future versions.

Ahmed

Re: [Qemu-devel] Taking live snapshots of running VMs

[Mulyadi Santosa]

On Sat, Jul 9, 2011 at 05:24, Ahmed M. Azab <amazab@ncsu.edu> wrote:
> Hi All,
>
> Is there a way to take a live memory snapshot of a running VM without
> freezing or stopping this VM?

something like what Xen does with live migration by using incremental
page migration (or something named like that?)?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] Taking live snapshots of running VMs

[Stefan Hajnoczi]

On Fri, Jul 8, 2011 at 11:24 PM, Ahmed M. Azab <amazab@ncsu.edu> wrote:
> Is there a way to take a live memory snapshot of a running VM without
> freezing or stopping this VM?

You could add a bit of code that forks QEMU.  The kernel does memory
copy-on-write across fork(2).  Make sure not to use file-backed/shared
memory for guest RAM (but that's okay since it is the default).  The
child process could write out the memory image and then terminate - or
it could sit around waiting for you to inspect it with GDB or some
other mechanism.  If you kill the child process then you lose access
to that memory snapshot.

For production I'm not convinced that this feature is useful.  There
is already support for crash dumping and kernel debugging of guest
OSes.  The mechansim various by guest OS, but it works similar to on a
physical machine.  What "system analytics or forensics" exactly are
useful when you only have access to guest *physical* memory?  Seems
like a development feature that you can hack on locally in a few lines
of code but not something for production.

Stefan

Re: [Qemu-devel] Taking live snapshots of running VMs

[Jes Sorensen]

On 07/09/11 00:24, Ahmed M. Azab wrote:
> Hi All,
> 
> Is there a way to take a live memory snapshot of a running VM without
> freezing or stopping this VM?
> 
> I explored the Qemu code and documentation and I found two ways to
> take a snapshot:

What you are talking about is called a 'checkpoint', not a snapshot.
There has been a lot of confusion around the naming, but it really helps
if we try to use the right names.

Checkpoints are for things you want to be able to restart, ie. with
memory, snapshots are just data, ie. disks.

Cheers,
Jes

Re: [Qemu-devel] Taking live snapshots of running VMs

[Kevin Wolf]

Am 09.07.2011 00:24, schrieb Ahmed M. Azab:
> Hi All,
> 
> Is there a way to take a live memory snapshot of a running VM without
> freezing or stopping this VM?
> 
> I explored the Qemu code and documentation and I found two ways to
> take a snapshot:
> 
> 1-Using "savevm" Qemu monitor command, which freezes the VM for tens of seconds
> 2-Using "migrate" and select the destination as a file, which forces
> the machine to stop after the snapshot is saved.
> 
> In production environments (where delaying the operations of a VM is
> very critical), it is always useful to take memory snapshots to do
> system analysis or forensics. I think Qemu should provide a way to
> take a snapshot based on QOW technque of memory pages (same as the
> QCOW disk snapshoting).
> 
> If such technique does not exist, I am willing it devlop it myself,
> but I wonder if the Qemu community will be interested to add my patch
> to future versions.

All the code that deals with memory is already there and used for
migration. I think what you really need is a combination of savevm and
live migration, such that you live migrate the VM state into the qcow2
image and when the migration has completed, you take a disk snapshot and
continue the VM.

It shouldn't be too hard to do this. All of the building blocks are
there, they just need to be combined in the right way. I would be
interested in a patch allowing this.


Having said that, I think there are more variations that we'll want to
support. Basically the dimensions that I see are:

1. Disk-only vs. complete VM state
2. Store VM state internally in qcow2 vs. an external file
3. Use internal vs. external disk snapshots

Ideally, we would allow users to choose freely. For example, internal
disk snapshot with external VM state is a combination that I think could
be very useful.

Kevin