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@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
