"J. Roeleveld" <jo...@antarean.org> writes: > 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.
I don't use lvm anymore. It requires you to have unused space in the same VG to make a snapshot (which, of course, I didn't have), and when you need to move a volume from one machine to another, you're screwed because you can't get the volume out of the volume group other than moving it to a different media after attaching this media to the VG and detaching it after the move. Moving the volume to the new machine is likewise a pita. I lost a whole VM when I did that, and I have no idea what might have happened to it. I did copy it, and yet it somehow disappeared. > 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. How do you force users to do that? I tried that with some windoze 7 VMs, and according to the rules, users are not allowed to save anything on their desktops, and nonetheless they can do that. The installed applications also create data in the disk space of the VM. Their MUAs do that, for example, and you may find users who have accumulated over 300GB for email storage. Make the disk read-only, and the VM probably won't even start.
