making snapshots with raw devices? and some general snapshot thoughts

making snapshots with raw devices? and some general snapshot thoughts

[Tomasz Chmielewski]

Is it possible to make snapshots when using raw devices (i.e. disk, 
partition, LVM volume) as guest's disk image?

According to documentation[1] (and some tests I made) it is only 
possible with qcow2 images. Which makes it very inflexible:

- one is forced to use a potentially slower file access
- one can't use the benefits of i.e. iSCSI disk access, SAN etc.


Also, according to the documentation, "VM snapshots are snapshots of the 
complete virtual machine including CPU state, RAM, device state and the 
content of all the writable disks".

Which leads to another observation: in some situations what one really 
needs is to "pause" execution of guest from within the host (i.e. 
because you want to shutdown or reboot the host due to a kernel or 
hardware upgrade).
After all changes on host are done, "guest" should be resumed without 
even knowing it was paused (most likely it will loose network connections).

This is how it's done with Xen or other virtualization solutions - they 
only save RAM, CPU, device state to a separate file; they don't save the 
content of all disks, because it's normally not needed for "pausing" guests.

Is it possible to do it with KVM?



[1] http://bellard.org/qemu/qemu-doc.html#SEC18


-- 
Tomasz Chmielewski
http://wpkg.org

Re: making snapshots with raw devices? and some general snapshot thoughts

[Javier Guerra]

On Wed, Feb 25, 2009 at 8:20 AM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> Is it possible to make snapshots when using raw devices (i.e. disk,
> partition, LVM volume) as guest's disk image?
>
> According to documentation[1] (and some tests I made) it is only possible
> with qcow2 images. Which makes it very inflexible:
>
> - one is forced to use a potentially slower file access
> - one can't use the benefits of i.e. iSCSI disk access, SAN etc.

what about using 'good' block devices, and add one small, mostly empty
qcow2? could it be used to store the snapshot for all?  of course it
would degrade performance while it's active, but should revert after
'commiting' it to the 'real' block device(s)



-- 
Javier

Re: making snapshots with raw devices? and some general snapshot thoughts

[Tomasz Chmielewski]

Javier Guerra schrieb:
> On Wed, Feb 25, 2009 at 8:20 AM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
>> Is it possible to make snapshots when using raw devices (i.e. disk,
>> partition, LVM volume) as guest's disk image?
>>
>> According to documentation[1] (and some tests I made) it is only possible
>> with qcow2 images. Which makes it very inflexible:
>>
>> - one is forced to use a potentially slower file access
>> - one can't use the benefits of i.e. iSCSI disk access, SAN etc.
> 
> what about using 'good' block devices, and add one small, mostly empty
> qcow2? could it be used to store the snapshot for all?  of course it
> would degrade performance while it's active, but should revert after
> 'commiting' it to the 'real' block device(s)

It doesn't work for me - I get:

qm> savevm 1
Error while creating snapshot on 'virtio0'

Where "virtio0" is my "real" block device. I guess it still wants to 
write a snapshot there, as outlined in the documentation:

    "The VM state info is stored in the first qcow2 non removable and
     writable block device. The disk image snapshots are stored in every
     disk image."

Or, am I making a mistake here?

Besides:
- guest will see this second device - not needed
- still, we save the state of disks, but we don't need it for tasks like 
"pausing guest, upgrading kernel on host, rebooting host, resuming guest"


-- 
Tomasz Chmielewski
http://wpkg.org

Re: making snapshots with raw devices? and some general snapshot thoughts

[Javier Guerra]

On Wed, Feb 25, 2009 at 9:31 AM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
>   "The VM state info is stored in the first qcow2 non removable and
>    writable block device. The disk image snapshots are stored in every
>    disk image."
>
> Or, am I making a mistake here?

ah, i misremembered that.


-- 
Javier

Re: making snapshots with raw devices? and some general snapshot thoughts

[Anthony Liguori]

Tomasz Chmielewski wrote:
> Is it possible to make snapshots when using raw devices (i.e. disk, 
> partition, LVM volume) as guest's disk image?
>
> According to documentation[1] (and some tests I made) it is only 
> possible with qcow2 images. Which makes it very inflexible:
>
> - one is forced to use a potentially slower file access
> - one can't use the benefits of i.e. iSCSI disk access, SAN etc.
>
>
> Also, according to the documentation, "VM snapshots are snapshots of 
> the complete virtual machine including CPU state, RAM, device state 
> and the content of all the writable disks".
>
> Which leads to another observation: in some situations what one really 
> needs is to "pause" execution of guest from within the host (i.e. 
> because you want to shutdown or reboot the host due to a kernel or 
> hardware upgrade).
> After all changes on host are done, "guest" should be resumed without 
> even knowing it was paused (most likely it will loose network 
> connections).
>
> This is how it's done with Xen or other virtualization solutions - 
> they only save RAM, CPU, device state to a separate file; they don't 
> save the content of all disks, because it's normally not needed for 
> "pausing" guests.
>
> Is it possible to do it with KVM?

In monitor:

(qemu) stop
(qemu) migrate exec:dd of=state.img

reboot machine

qemu -incoming exec:dd if=state.img -other -options

Regards,

Anthony Liguori
>
>
> [1] http://bellard.org/qemu/qemu-doc.html#SEC18
>
>

Re: making snapshots with raw devices? and some general snapshot thoughts

[Tomasz Chmielewski]

Anthony Liguori schrieb:

>> Is it possible to do it with KVM?
> 
> In monitor:

Works great - thanks!

Small corrections below.


> (qemu) stop
> (qemu) migrate exec:dd of=state.img

Gives me:

qm> migrate exec:dd of=state.img
migrate: extraneous characters at the end of line

Should be:
qm> migrate "exec:dd of=state.img"

> reboot machine
> 
> qemu -incoming exec:dd if=state.img -other -options

Should be:

qemu -incoming "exec:dd if=state.img" -other -options


-- 
Tomasz Chmielewski
http://wpkg.org