libvirt users - May 2012 - Spawn new domains from a snapshot.

Hello everybody,

I would like to be able to spawn several domains from a given snapshot.

Here's a possible scenario:
-  I start from disk image A.qcow2.
-  I made some changes to A and I take different snapshots: 1 - 2 - 3
-  While A is still running I would like to run domains B and C from snapshot 2
I don't want to revert a domain, I want to create new ones. The
original should be still running but it may be stopped if necessary.

The idea I had was to create a qcow2 image through qemu-img (let's
call it Z.qcow2), as I'm using copy on write for performances then I'd
need to commit the changes contained in Z to A always using qemu-img.
Is there any other better way? I would love to do it through libvirt,
maybe specifying in the config file the backing store path of the
whole disk and then giving as a source file the one containing deltas.

This could be a good idea for realizing a cloud based system as a
incredible amount of time would be saved though it.
Imagine moving only qcow2 file containing deltas through the network
and then give the base image to each node so that it can use it for
start it's own domain.
As well would be possible to store the heavy base image in a single
node saving storage space.
Lots of cpu cycles saved once new image versions must be deployed
(typical case a windows update to propagate in the nodes network).

NoxDaFox

On 05/25/2012 07:48 AM, NoxDaFox wrote:
> Hello everybody,
> 
> I would like to be able to spawn several domains from a given snapshot.
So would I.  It's not yet possible from libvirt, but we are getting
closer as we discuss ideas of how to do it.
> 
> Here's a possible scenario:
> -  I start from disk image A.qcow2.
> -  I made some changes to A and I take different snapshots: 1 - 2 - 3
Disk snapshots, or full system checkpoint snapshots with VM state?
> -  While A is still running I would like to run domains B and C from
snapshot 2
Do you want B and C starting from A's memory state (hard) or just from
A's disk state (easier)?
> I don't want to revert a domain, I want to create new ones. The
> original should be still running but it may be stopped if necessary.
> 
> The idea I had was to create a qcow2 image through qemu-img (let's
> call it Z.qcow2), as I'm using copy on write for performances then
I'd
> need to commit the changes contained in Z to A always using qemu-img.
> Is there any other better way? I would love to do it through libvirt,
> maybe specifying in the config file the backing store path of the
> whole disk and then giving as a source file the one containing deltas.
It sounds like you want the following qcow2 hierarchy:

A.base  <-  1.snap  <-  2.snap  <- 3.snap
                                \- B.snap

As long as 2.snap is read-only for both A and B, then 3.snap (used by A)
and B.snap (used by B) can safely diverge in contents.
> 
> This could be a good idea for realizing a cloud based system as a
> incredible amount of time would be saved though it.
> Imagine moving only qcow2 file containing deltas through the network
> and then give the base image to each node so that it can use it for
> start it's own domain.
Yes, thin provisioning via common base images is already part of VDSM
management of clouds.
> As well would be possible to store the heavy base image in a single
> node saving storage space.
> Lots of cpu cycles saved once new image versions must be deployed
> (typical case a windows update to propagate in the nodes network).
-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20120525/8f85fdc5/attachment.sig>