On Tuesday, January 19, 2016 11:22:02 PM lee wrote: > "J. Roeleveld" <jo...@antarean.org> writes: > > [...] > > If disk-space is considered too expensive, you could even have every VM > > use > > the same base image. And have them store only the differences of the disk. > > eg: > > 1) Create a VM > > 2) Snapshot the disk (with the VM shutdown) > > 3) create a new VM based on the snapshot > > > > Repeat 2 and 3 for as many clones you want. > > > > Most installs don't change that much when dealing with standardized > > desktops. > How does that work? IIUC, when you created a snapshot, any changes you > make to the snapshotted (or how that is called) file system are being > referenced by the snapshot which you can either destroy or abandon. > When you destroy it, the changes you made are being applied to the > file system you snapshotted (because someone decided to use a very > misleading terminology), and when you abandon it, the changes are thrown > away and you end up with the file system as it was before the snapshot > was created. > > In any case, you do not get multiple versions (which only reference the > changes made) of the file system you snapshotted but only one current > version. > > Do you need to use a special file system or something which provides > this kind of multiple copies when you make snapshots?
I use LVM for this. Steps are simple: 1) Create a LV (lv_1) 2) Create and install a VM using this LV (lv_1) 3) Stop the VM 4) Create multiple snapshots based on lv_1 (slv_1a, slv_1b, ......) 5) Create multiple VMs using the snapshots (vm1a -> slv_1a, vm1b, slv_1b,.....) Start the VMs This way you can overcommit on the actual diskspace as only changes are taking up diskspace. If you force everyone on the same base-image, the differences should not be too large. If you also force users to store files on a shared filesystem, it shouldn't be too much of a difficulty to occasionally move everyone to a new base-image when the updates are causing the snapshots to grow too much. -- Joost
