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

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hello,
I attempted to create snapshots outside the original qcow2 disk, a feature that is available with 0.14.0, but facing an unexpected behaviour as described below. Any help is greatly appreciated.

I am using qemu version 0.14

# qemu --version
QEMU emulator version 0.14.0, Copyright (c) 2003-2008 Fabrice Bellard


# qemu-img --version
qemu-img version 0.14.0, Copyright (c) 2004-2008 Fabrice Bellard
usage: qemu-img command [command options]
QEMU disk image utility


Following steps were executed to copy a snapshot outside the original qcow2 but looks like there is an issue.

1. VM(vm1) brought up with a qcow2 image(/home/user1/lucid-vm2). This is a lucid 10.04 VM.

2. Next snapshot created for the qcow2
   #qemu-img snapshot -c snap1 /home/user1/lucid-vm2

3. Lets see if the snapshot got created.
    # qemu-img snapshot -l /home/user1/lucid-vm2 
    Snapshot list:
    ID        TAG                 VM SIZE                DATE       VM CLOCK
    1         snap1                     0 2011-03-09 23:17:53   00:00:00.000


4. Next inside the running VM(vm2) a new file is created. Since the snapshot was
    created before creating this file. The snapshot should not have this file.
   #touch samplefile

5. Now the snapshot snap1 is copied outside the original qcow2 image.
   qemu-img convert -f qcow2 -O qcow2 -s snap1 /home/user1/lucid-vm2 /home/user1/lucid-vm2-snap1

6. Next shutdown VM(vm1) and bring it up the snapshot image /home/user1/lucid-vm2-snap1. 
   Since the snapshot was created before creating the file named "samplefile" it is to
   be expected that the file should not be there in the snapshot image. But the file does appear  in the snapshot image
   #ls samplefile
   samplefile
   

Regards
sl




      

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]

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

[Stefan Hajnoczi]

On Wed, Mar 9, 2011 at 6:06 PM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
> Following steps were executed to copy a snapshot outside the original qcow2 but looks like there is an issue.
>
> 1. VM(vm1) brought up with a qcow2 image(/home/user1/lucid-vm2). This is a lucid 10.04 VM.
>
> 2. Next snapshot created for the qcow2
>    #qemu-img snapshot -c snap1 /home/user1/lucid-vm2

It is not safe to run qemu-img while the VM is using the image file.

Stefan

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

Thank you very much Stefan, Based on your suggestion I tried out the following two scenarios.

Scenario 1:
1) I executed following with the vm in shutdown state.
"#qemu-img snapshot -c snap1 /home/user1/lucid-vm2" 

2) Brought the VM Up.

3) Inside the vm create a file.
#touch samplefile

4) Shutdown the vm and copy the snapshot outside the original qcow2

#qemu-img convert -f qcow2 -O qcow2 -s snap1 /home/user1/lucid-vm2 /home/lucid-vm2-snap1

Result : When I bring up the vm do not see the samplefile which is the expected behaviour.

Scenario 2:

1) I executed following with the vm in shutdown state.

"#qemu-img snapshot -c snap1 /home/user1/lucid-vm2" 


2) Bring up the VM.

3) Inside the vm create a file.

#touch samplefile


4) VM is NOT Shutdown and copy the snapshot outside the original qcow2



#qemu-img convert -f qcow2 -O qcow2 -s snap1 /home/user1/lucid-vm2 /home/lucid-vm2-snap1



Result : When I bring up the vm do not see the samplefile which is the expected behaviour.



Is Scenario 2 safe where in the copying the snapshot outside the original qcow2 is being executed with the VM running. This is because if this is safe then this could be an approach as it would not require a long downtime for the VM. 

Regards
sl

--- On Wed, 9/3/11, Stefan Hajnoczi <stefanha@gmail.com> wrote:

From: Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com>
Cc: qemu-devel@nongnu.org
Date: Wednesday, 9 March, 2011, 15:53

On Wed, Mar 9, 2011 at 6:06 PM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
> Following steps were executed to copy a snapshot outside the original qcow2 but looks like there is an issue.
>
> 1. VM(vm1) brought up with a qcow2 image(/home/user1/lucid-vm2). This is a lucid 10.04 VM.
>
> 2. Next snapshot created for the qcow2
>    #qemu-img snapshot -c snap1 /home/user1/lucid-vm2

It is not safe to run qemu-img while the VM is using the image file.

Stefan



      

[-- Attachment #2: Type: text/html, Size: 2621 bytes --]

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

[Stefan Hajnoczi]

On Thu, Mar 10, 2011 at 1:51 AM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
> Scenario 1:
> 1) I executed following with the vm in shutdown state.
> "#qemu-img snapshot -c snap1 /home/user1/lucid-vm2"

Here you are snapshotting the current disk image and storing the
snapshot away as "snap1".

> 2) Brought the VM Up.
>
> 3) Inside the vm create a file.
> #touch samplefile

Now you modified the current disk image but "snap1" remains unchanged.

> 4) Shutdown the vm and copy the snapshot outside the original qcow2
>
> #qemu-img convert -f qcow2 -O qcow2 -s snap1 /home/user1/lucid-vm2 /home/lucid-vm2-snap1
>
> Result : When I bring up the vm do not see the samplefile which is the expected behaviour.

Are you bringing up the VM with lucid-vm2 (which should have
samplefile) or lucid-vm2-snap1 (which should not have samplefile)?

> Scenario 2:
> 1) I executed following with the vm in shutdown state.
> "#qemu-img snapshot -c snap1 /home/user1/lucid-vm2"
>
> 2) Bring up the VM.
>
> 3) Inside the vm create a file.
> #touch samplefile
>
> 4) VM is NOT Shutdown and copy the snapshot outside the original qcow2
>
> #qemu-img convert -f qcow2 -O qcow2 -s snap1 /home/user1/lucid-vm2 /home/lucid-vm2-snap1
>
> Result : When I bring up the vm do not see the samplefile which is the expected behaviour.
>
>
> Is Scenario 2 safe where in the copying the snapshot outside the original qcow2 is being executed with the VM running. This is because if this is safe then this could be an approach as it would not require a long downtime for the VM.

There is no guarantee that qemu-img will work on an image file that is
open by a running VM.

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.

If you can describe your snapshot use case at a higher level that
might be useful.

Stefan

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

[Jes Sorensen]

On 03/10/11 10:27, Stefan Hajnoczi wrote:
>> Is Scenario 2 safe where in the copying the snapshot outside the original qcow2 is being executed with the VM running. This is because if this is safe then this could be an approach as it would not require a long downtime for the VM.
> 
> There is no guarantee that qemu-img will work on an image file that is
> open by a running VM.

I think the guarantee here is that you're guaranteed it will go horribly
wrong if you try to do so.....

> 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.

Cheers,
Jes

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

[Stefan Hajnoczi]

On Thu, Mar 10, 2011 at 9:32 AM, Jes Sorensen <Jes.Sorensen@redhat.com> 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.

Stefan

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

[Jes Sorensen]

On 03/10/11 10:58, Stefan Hajnoczi wrote:
> On Thu, Mar 10, 2011 at 9:32 AM, Jes Sorensen <Jes.Sorensen@redhat.com> 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

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]

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 <Jes.Sorensen@redhat.com> wrote:

From: Jes Sorensen <Jes.Sorensen@redhat.com>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "Stefan Hajnoczi" <stefanha@gmail.com>
Cc: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com>, qemu-devel@nongnu.org
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 <Jes.Sorensen@redhat.com> 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




      

[-- Attachment #2: Type: text/html, Size: 4575 bytes --]

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

[Stefan Hajnoczi]

On Thu, Mar 10, 2011 at 7:57 PM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
> 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.

Excellent, that sounds exactly like Jes is addressing so future
QEMU/KVM releases will hopefully have the live snapshot/merge
capability.

> 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.

If the VM is not running you can use the qemu-img commit command to
merge the snapshot back down into the base image.  After that you only
have one image file again and can restart the VM.  Hopefully the
deltas are small enough that this process is quick.

In the future a live merge command will take care of this and avoid
the downtime.

> 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 ?

New versions of libvirt have a virsh "qemu-monitor-command" command
you can use to send a QEMU monitor command.

Stefan

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

[Jes Sorensen]

On 03/10/11 22:04, Stefan Hajnoczi wrote:
> On Thu, Mar 10, 2011 at 7:57 PM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
>> 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.
> 
> Excellent, that sounds exactly like Jes is addressing so future
> QEMU/KVM releases will hopefully have the live snapshot/merge
> capability.
> 
>> 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.
> 
> If the VM is not running you can use the qemu-img commit command to
> merge the snapshot back down into the base image.  After that you only
> have one image file again and can restart the VM.  Hopefully the
> deltas are small enough that this process is quick.
> 
> In the future a live merge command will take care of this and avoid
> the downtime.

Yep, qemu-img convert should be able to copy it into a single image so
you can delete the chain.

Cheers,
Jes

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

Thank you Stefan, Jes. So it appears that snapshot_blkdev is the way to go for vm disk backup with running vms.

In regard to merging changes, assuming that we go snapshot_blkdev rightaway.
Stefan's suggestion: "qemu-img commit"
Jes's suggestion: "qemu-img convert"

Does qemu-img convert apply to running VM's. In that case it would appear to be the more practical approach(since vm shutdown would not be required).


Also incase If i have interpreted "qemu-img convert" incorrectly and does require a VM shutdown. Then when is expected time when the "live merge" will be available.


Thanks and Regards
Saurav Lahiri

--- On Fri, 11/3/11, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:

From: Jes Sorensen <Jes.Sorensen@redhat.com>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "Stefan Hajnoczi" <stefanha@gmail.com>
Cc: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com>, qemu-devel@nongnu.org
Date: Friday, 11 March, 2011, 2:31

On 03/10/11 22:04, Stefan Hajnoczi wrote:
> On Thu, Mar 10, 2011 at 7:57 PM, SAURAV LAHIRI <saurav_lahiri@yahoo.com> wrote:
>> 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.
> 
> Excellent, that sounds exactly like Jes is addressing so future
> QEMU/KVM releases will hopefully have the live snapshot/merge
> capability.
> 
>> 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.
> 
> If the VM is not running you can use the qemu-img commit command to
> merge the snapshot back down into the base image.  After that you only
> have one image file again and can restart the VM.  Hopefully the
> deltas are small enough that this process is quick.
> 
> In the future a live merge command will take care of this and avoid
> the downtime.

Yep, qemu-img convert should be able to copy it into a single image so
you can delete the chain.

Cheers,
Jes




      

[-- Attachment #2: Type: text/html, Size: 3089 bytes --]

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

[Jes Sorensen]

On 03/11/11 10:39, SAURAV LAHIRI wrote:
> Thank you Stefan, Jes. So it appears that snapshot_blkdev is the way
> to go for vm disk backup with running vms.
> 
> In regard to merging changes, assuming that we go snapshot_blkdev
> rightaway. Stefan's suggestion: "qemu-img commit" Jes's suggestion:
> "qemu-img convert"
> 
> Does qemu-img convert apply to running VM's. In that case it would
> appear to be the more practical approach(since vm shutdown would not
> be required).
> 
> Also incase If i have interpreted "qemu-img convert" incorrectly and
> does require a VM shutdown. Then when is expected time when the "live
> merge" will be available.

I believe commit only applies to images with internal files. If you use
convert then it doesn't modify the actual images, so lets say you have a
chain like this:

original->snapshotA->snapshotB

original and snapshotA are read-only when snapshotB is running.
Therefore you should be able to use convert to simply copy snapshotA
into a new image file snapshotX and save that for your backup. If you
later restore, you have a single image file you can boot from.

What you cannot do is to create the new snapshotX file and switch to it
as the backing file for snapshotB while you are up and running.

Cheers,
Jes

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

[Stefan Hajnoczi]

On Fri, Mar 11, 2011 at 9:50 AM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/11/11 10:39, SAURAV LAHIRI wrote:
>> Thank you Stefan, Jes. So it appears that snapshot_blkdev is the way
>> to go for vm disk backup with running vms.
>>
>> In regard to merging changes, assuming that we go snapshot_blkdev
>> rightaway. Stefan's suggestion: "qemu-img commit" Jes's suggestion:
>> "qemu-img convert"
>>
>> Does qemu-img convert apply to running VM's. In that case it would
>> appear to be the more practical approach(since vm shutdown would not
>> be required).
>>
>> Also incase If i have interpreted "qemu-img convert" incorrectly and
>> does require a VM shutdown. Then when is expected time when the "live
>> merge" will be available.
>
> I believe commit only applies to images with internal files. If you use

Nope, qemu-img commit only applies to images with backing files (aka
external snapshots).

> convert then it doesn't modify the actual images, so lets say you have a
> chain like this:
>
> original->snapshotA->snapshotB
>
> original and snapshotA are read-only when snapshotB is running.
> Therefore you should be able to use convert to simply copy snapshotA
> into a new image file snapshotX and save that for your backup. If you
> later restore, you have a single image file you can boot from.
>
> What you cannot do is to create the new snapshotX file and switch to it
> as the backing file for snapshotB while you are up and running.

qemu-img commit merges the deltas from a qcow2 (or qed or other
copy-on-write image format) into the backing file.  If you have the
following:

qemu-img create -f qcow2 -o backing_file=master.img,backing_fmt=raw
instance.qcow2

Then the following command will merge the delta from instance.qcow2
back into master.img:

qemu-img commit instance.qcow2

My suggestion was to shut down the VM and run qemu-img commit so that
you can move back to the original disk image file which has now been
updated with the deltas.  You no longer need the file with the deltas.

So qemu-img commit lets you merge down the chain of snapshots, whereas
qemu-img convert lets you copy a full disk image into a new image
file.

To be clear, qemu-img should not be used on an image file that is
currently open by a running VM.

Stefan

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

Thank you Stefan that does clarify on how to correctly use "qemu-img commit "

Regards
sl

--- On Fri, 11/3/11, Stefan Hajnoczi <stefanha@gmail.com> wrote:

From: Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com>
Cc: "Jes Sorensen" <Jes.Sorensen@redhat.com>, qemu-devel@nongnu.org
Date: Friday, 11 March, 2011, 7:55

On Fri, Mar 11, 2011 at 9:50 AM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/11/11 10:39, SAURAV LAHIRI wrote:
>> Thank you Stefan, Jes. So it appears that snapshot_blkdev is the way
>> to go for vm disk backup with running vms.
>>
>> In regard to merging changes, assuming that we go snapshot_blkdev
>> rightaway. Stefan's suggestion: "qemu-img commit" Jes's suggestion:
>> "qemu-img convert"
>>
>> Does qemu-img convert apply to running VM's. In that case it would
>> appear to be the more practical approach(since vm shutdown would not
>> be required).
>>
>> Also incase If i have interpreted "qemu-img convert" incorrectly and
>> does require a VM shutdown. Then when is expected time when the "live
>> merge" will be available.
>
> I believe commit only applies to images with internal files. If you use

Nope, qemu-img commit only applies to images with backing files (aka
external snapshots).

> convert then it doesn't modify the actual images, so lets say you have a
> chain like this:
>
> original->snapshotA->snapshotB
>
> original and snapshotA are read-only when snapshotB is running.
> Therefore you should be able to use convert to simply copy snapshotA
> into a new image file snapshotX and save that for your backup. If you
> later restore, you have a single image file you can boot from.
>
> What you cannot do is to create the new snapshotX file and switch to it
> as the backing file for snapshotB while you are up and running.

qemu-img commit merges the deltas from a qcow2 (or qed or other
copy-on-write image format) into the backing file.  If you have the
following:

qemu-img create -f qcow2 -o backing_file=master.img,backing_fmt=raw
instance.qcow2

Then the following command will merge the delta from instance.qcow2
back into master.img:

qemu-img commit instance.qcow2

My suggestion was to shut down the VM and run qemu-img commit so that
you can move back to the original disk image file which has now been
updated with the deltas.  You no longer need the file with the deltas.

So qemu-img commit lets you merge down the chain of snapshots, whereas
qemu-img convert lets you copy a full disk image into a new image
file.

To be clear, qemu-img should not be used on an image file that is
currently open by a running VM.

Stefan




      

[-- Attachment #2: Type: text/html, Size: 3478 bytes --]

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

[SAURAV LAHIRI]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

Thank you very much Stefan and Jes for brining about clarity to the issue of snapshots in qemu.  One last question which we would be interested in is when is the back merge of snapshots for running vms expected to be released.

Regards
sl

--- On Fri, 11/3/11, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:

From: Jes Sorensen <Jes.Sorensen@redhat.com>
Subject: Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0
To: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>, qemu-devel@nongnu.org
Date: Friday, 11 March, 2011, 5:50

On 03/11/11 10:39, SAURAV LAHIRI wrote:
> Thank you Stefan, Jes. So it appears that snapshot_blkdev is the way
> to go for vm disk backup with running vms.
> 
> In regard to merging changes, assuming that we go snapshot_blkdev
> rightaway. Stefan's suggestion: "qemu-img commit" Jes's suggestion:
> "qemu-img convert"
> 
> Does qemu-img convert apply to running VM's. In that case it would
> appear to be the more practical approach(since vm shutdown would not
> be required).
> 
> Also incase If i have interpreted "qemu-img convert" incorrectly and
> does require a VM shutdown. Then when is expected time when the "live
> merge" will be available.

I believe commit only applies to images with internal files. If you use
convert then it doesn't modify the actual images, so lets say you have a
chain like this:

original->snapshotA->snapshotB

original and snapshotA are read-only when snapshotB is running.
Therefore you should be able to use convert to simply copy snapshotA
into a new image file snapshotX and save that for your backup. If you
later restore, you have a single image file you can boot from.

What you cannot do is to create the new snapshotX file and switch to it
as the backing file for snapshotB while you are up and running.

Cheers,
Jes




      

[-- Attachment #2: Type: text/html, Size: 2348 bytes --]