[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Merging blocks from an overlay file containing vmstat

From: Jakob Bohm
Subject: Re: [Qemu-discuss] Merging blocks from an overlay file containing vmstate to a backing file
Date: Thu, 20 Nov 2014 16:50:43 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 20/11/2014 06:36, 정복득 wrote:
> Hi,
> I have a question about block commit and internal vm snapshot.
> I am using an overlay file to run a virtual machine.
> I took a snapshot with the 'vmsave' qemu monitor command, then commited 
> blocks in the overlay file into the backing file after playing with my 
> virtual machine a while and then shutting down it.
> Because every block in the overlay file merged to the backing file, I deleted 
> the overlay file.
> After I started virtual machine with the backing file later on, I checked the 
> snapshot with 'info snapshots' at qemu monitor but couldn't see any snapshots 
> at all. Meanwhile, block commit seemed successful as I could see files that I 
> added while the VM was using the overlay file.
> Internal snapshots with vmstate in an overlay file are not merged to the 
> backing file?
> What should I do if I want to preserve internal snapshots into the backing 
> file?
> Is there a way that I can take a external snapshot? I am not using libvirt or 
> virsh.

vmsave memory snapshots can only be stored in qcow2 files.

If you somehow set up one qcow2 file to use another qcow2 file as
its backing store, I don't think there is any command to transfer
snapshots (disk or memory) from the overlay qcow2 to the backing
qcow2 and stillappear as snapshots in the backing qcow2.

When creating an internal snapshot in an existing qcow2 backing
file, there is some vagueness in the documentation as to where the
saved memory is stored in the qcow2 file structure: In the frozen
snapshot or in the internal overlay.

If the vmsave memory/register image is stored in the part of the
qcow2 file which represents the disk contents at snapshot time,
it would be an interesting issue to look at the ability to commit
this part to a qcow2 backing store when committing the block
changes in a non-running snapshot to that same qcow2 backing

However in your case it sounds like you committed the "running"
disk blocks to the backing store, essentially removing the
snapshot (and making any references to disk contents in the
vmsave memory snapshot invalid anyway).


Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]