[libvirt-users] 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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
On 25/05/12 18:17, Eric Blake wrote: 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).
I made a couple of tests. Image A.qcow2: - 2 Gb file size (the image size is 10Gb) - OS: Windows XP sp2 installed I create the image B.qcow2 with A as backing store through virStorageVolCreateXML(): - 160 Mb file size (image size alway 10Gb) - OS in the same state as before. I do some updates to the OS in image B like installing sp3 and I shut down the VE I create the image C.qcow2 with B as backing store through virStorageVolCreateXML(): - File size 230 Mb - OS: Windows XP sp3 with all the changes made in image B. This is extremely powerful in contexts as cloud VM provisioning or system tests. For what I guessed (didn't look at the code yet) libvirt can already set up a hierarchy in a way that, given a complete disk image, can build several COW images and run a coherent VM merging deltas contained in these files. So shouldn't be hard to do the same procedure with images created from snapshots. As I said in: https://www.redhat.com/archives/libvirt-users/2012-May/msg00105.html I create an image from a snapshot through qemu-img, I obtain a qcow2 file valuable for inspections but not for running a new VE as it doesn't contain the whole disk of the original VM. If I do the same without COW I succeed but I pass from a bunch of seconds to several minutes to complete the task as I basically clone the whole disk. A nice solution could be giving the capability to specify in the volume XML the source as a snapshot name contained in the running domain. The internal logic should be able to generate a new qcow2 file that knows which backing file has been used to generate the disk the snapshot refers to. To be more clear running the image C I create the snapshot S, from S through virStorageVolCreateXML() I create the disk image S.qcow2 which contains deltas from C to the moment S has been taken. I can then use S.qcow2 to spawn a new VE with changes made from C to S (including changes made in B etc obviously). This should allow, for example, to make so that while C is still running I can start other VEs from C disk snapshots; obtaining a dynamic VE branching system. Everything through libvirt API.
participants (2)
-
Eric Blake -
NoxDaFox