Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0

[SAURAV LAHIRI]

Thank you Stefan and Jes for providing further inputs.

Details on use case:

The high level use case is that of being able to backup user specified disks of a VM without having to bring down the VM.

That was the reason that I had started of with running the "qemu-img snapshot -c snap1..." on a running vm. So when I have a snapshot i can back this up. Without a frozen and consistent snapshot, backing up the qcow2 disk image would cause serious issues on restore. But after your inputs shelved the plans of creating snapshot on running vm.

So next approach planned did take into account that  I have to shutdown the VM for creating the snapshot. It would appear that, since the internal snapshot creation is an instantaneous process I could bring down the vm, create an internal snapshot, bring up the VM. and this entire thing would take a minimal time.

Once the VM is up I can continue with converting the internal snapshot to an external snapshot and then back up the external snapshot to my backup location. The duration of conversion from internal to external obviously would depend on the size of the original qcow2 disk. But since the VM is up the duration would not concern me much as long as it completes within some practical time limits.


snapshot_blkdev: Regarding this  I do have a couple of questions.

1. If the snapshot cannot be merged then it could mean that there are several snapshot files. One readonly  for each of the previous snapshots and the last one being the active one, which handles all the current writes. Post backup If do have to restore to a particular snapshot then i would probably have to copy all the files in the chain and maintain the entire chain. But would it not affect read performance if several snapshot files are maintained, particularly if the VM is hosting a database like mysql ? Could you please clarify.

2. I have seen that at times the qemu monitor command is not able to connnect to  the monitor socket as libvirt it seems controls the monitor socket. If I shutdown libvirt then commands like socat is able to connect. But since my current environment does use libvirt, shutting down libvirt is not an option. Is there any way around this ?

Appreciate your help.

Regards
sl










--- On Thu, 10/3/11, Jes Sorensen <address@hidden> wrote:

From: Jes Sorensen <address@hidden>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "Stefan Hajnoczi" <address@hidden>
Cc: "SAURAV LAHIRI" <address@hidden>, address@hidden
Date: Thursday, 10 March, 2011, 5:59

On 03/10/11 10:58, Stefan Hajnoczi wrote:
> On Thu, Mar 10, 2011 at 9:32 AM, Jes Sorensen <address@hidden> wrote:
>> On 03/10/11 10:27, Stefan Hajnoczi wrote:
>>> I have CCed Jes who has been working on a live snapshot mechanism.  He
>>> recently added the snapshot_blkdev monitor command that takes a
>>> snapshot of a block device while the VM is running.  A new image file
>>> is created based off the original image file (which will no longer be
>>> modified), all new disk writes go to the new image file.  It is safe
>>> to perform read-only access to the original image file.  There
>>> currently is no support to merge the snapshot changes back into the
>>> original image while the VM is running, but I think that is the next
>>> planned step.
>>
>> Yes, keep in mind that the live snapshot is only for external snapshot
>> files, it doesn't deal with internal snapshots.
>
> Yep, that's why I'm interested in Saurav's use case.  Many use cases
> work with either internal or external snapshot but it depends on the
> details.

Actually I think there's very little reason to keep internal snapshot
support. It doesn't buy us much, but it adds unnecessary complexity.

Cheers,
Jes