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