[libvirt-users] Spawn new domains from a snapshot.

[NoxDaFox]

On 25/05/12 18:17, Eric Blake wrote:
> 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.
Is there any link where I can follow the discussion about this topic?
>
>> 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?
Disk snapshot, the full resume would be a cool feature as well but I 
think that the time spent to realize it may be too much atm compared to 
the  business cases that could benefit from it.
>> -  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)?
As I said disk state. The case is what I wrote before: "Lots of cpu 
cycles saved once new image versions must be deployed (typical case a 
windows update to propagate in the nodes network)."
Imagine how painful is to maintain in a cloud system OS and software 
updates.
>
>> 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.
Indeed is read only, to be clear: I don't need anything magical atm, 
just a "domain lifecycle branching" from disk images.
Glossary is quite confusing but for what I understood #2 snapshot disk 
image should be the "backing file", here comes the problem: as I'm using 
copy on write snapshot #2 image is not the real backing file, without 
cow would be really easy.

What my system is capable to do atm is: with or without cow, take a 
snapshot and automatically convert it into a qcow2 disk image through 
qemu-img snapshot conversion; the resulting disk is used for analysis 
purposes but would be nice to use it also for this kind of scenario.
Everything is already possible if I don't use cow, but you can easily 
guess in this case how performance suffers.

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