On Thursday, January 21, 2016 11:17:05 PM lee wrote: > "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.
Keeping unassigned space available for growth and snapshots is common practice for me. I always have unassigned space which can be assigned quickly. And when wanting the option to move VMs, put the "disks" on SANs. If you want to do it on the cheap, you need to do a lot more manually. > > 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. Not difficult, as long as you do NOT make everyone local admin and limit permissions. Do not give them write-permissions everywhere and put a limited quota on their profiles. And for email, do not allow the MUAs to store all the email locally, enforce a central mailserver. I'm sorry, but you are expecting people on this list to provide you with all the answers which a simple google search should be able to answer. And which is also covered in basic sys-admin documentation and courses. -- Joost
