| 1 |
"J. Roeleveld" <joost@××××××××.org> writes: |
| 2 |
|
| 3 |
|
| 4 |
> [...] |
| 5 |
> If disk-space is considered too expensive, you could even have every VM use |
| 6 |
> the same base image. And have them store only the differences of the disk. |
| 7 |
> eg: |
| 8 |
> 1) Create a VM |
| 9 |
> 2) Snapshot the disk (with the VM shutdown) |
| 10 |
> 3) create a new VM based on the snapshot |
| 11 |
> |
| 12 |
> Repeat 2 and 3 for as many clones you want. |
| 13 |
> |
| 14 |
> Most installs don't change that much when dealing with standardized desktops. |
| 15 |
|
| 16 |
How does that work? IIUC, when you created a snapshot, any changes you |
| 17 |
make to the snapshotted (or how that is called) file system are being |
| 18 |
referenced by the snapshot which you can either destroy or abandon. |
| 19 |
When you destroy it, the changes you made are being applied to the |
| 20 |
file system you snapshotted (because someone decided to use a very |
| 21 |
misleading terminology), and when you abandon it, the changes are thrown |
| 22 |
away and you end up with the file system as it was before the snapshot |
| 23 |
was created. |
| 24 |
|
| 25 |
In any case, you do not get multiple versions (which only reference the |
| 26 |
changes made) of the file system you snapshotted but only one current |
| 27 |
version. |
| 28 |
|
| 29 |
Do you need to use a special file system or something which provides |
| 30 |
this kind of multiple copies when you make snapshots? |
Archives