| 1 |
"J. Roeleveld" <joost@××××××××.org> writes: |
| 2 |
|
| 3 |
> On Tuesday, January 19, 2016 11:22:02 PM lee wrote: |
| 4 |
>> "J. Roeleveld" <joost@××××××××.org> writes: |
| 5 |
>> > [...] |
| 6 |
>> > If disk-space is considered too expensive, you could even have every VM |
| 7 |
>> > use |
| 8 |
>> > the same base image. And have them store only the differences of the disk. |
| 9 |
>> > eg: |
| 10 |
>> > 1) Create a VM |
| 11 |
>> > 2) Snapshot the disk (with the VM shutdown) |
| 12 |
>> > 3) create a new VM based on the snapshot |
| 13 |
>> > |
| 14 |
>> > Repeat 2 and 3 for as many clones you want. |
| 15 |
>> > |
| 16 |
>> > Most installs don't change that much when dealing with standardized |
| 17 |
>> > desktops. |
| 18 |
>> How does that work? IIUC, when you created a snapshot, any changes you |
| 19 |
>> make to the snapshotted (or how that is called) file system are being |
| 20 |
>> referenced by the snapshot which you can either destroy or abandon. |
| 21 |
>> When you destroy it, the changes you made are being applied to the |
| 22 |
>> file system you snapshotted (because someone decided to use a very |
| 23 |
>> misleading terminology), and when you abandon it, the changes are thrown |
| 24 |
>> away and you end up with the file system as it was before the snapshot |
| 25 |
>> was created. |
| 26 |
>> |
| 27 |
>> In any case, you do not get multiple versions (which only reference the |
| 28 |
>> changes made) of the file system you snapshotted but only one current |
| 29 |
>> version. |
| 30 |
>> |
| 31 |
>> Do you need to use a special file system or something which provides |
| 32 |
>> this kind of multiple copies when you make snapshots? |
| 33 |
> |
| 34 |
> I use LVM for this. |
| 35 |
> |
| 36 |
> Steps are simple: |
| 37 |
> 1) Create a LV (lv_1) |
| 38 |
> 2) Create and install a VM using this LV (lv_1) |
| 39 |
> 3) Stop the VM |
| 40 |
> 4) Create multiple snapshots based on lv_1 (slv_1a, slv_1b, ......) |
| 41 |
> 5) Create multiple VMs using the snapshots (vm1a -> slv_1a, vm1b, |
| 42 |
> slv_1b,.....) |
| 43 |
> |
| 44 |
> Start the VMs |
| 45 |
> |
| 46 |
> This way you can overcommit on the actual diskspace as only changes are taking |
| 47 |
> up diskspace. |
| 48 |
> If you force everyone on the same base-image, the differences should not be too |
| 49 |
> large. |
| 50 |
|
| 51 |
I don't use lvm anymore. It requires you to have unused space in the |
| 52 |
same VG to make a snapshot (which, of course, I didn't have), and when |
| 53 |
you need to move a volume from one machine to another, you're screwed |
| 54 |
because you can't get the volume out of the volume group other than |
| 55 |
moving it to a different media after attaching this media to the VG and |
| 56 |
detaching it after the move. Moving the volume to the new machine is |
| 57 |
likewise a pita. I lost a whole VM when I did that, and I have no idea |
| 58 |
what might have happened to it. I did copy it, and yet it somehow |
| 59 |
disappeared. |
| 60 |
|
| 61 |
> If you also force users to store files on a shared filesystem, it shouldn't be |
| 62 |
> too much of a difficulty to occasionally move everyone to a new base-image when |
| 63 |
> the updates are causing the snapshots to grow too much. |
| 64 |
|
| 65 |
How do you force users to do that? I tried that with some windoze 7 |
| 66 |
VMs, and according to the rules, users are not allowed to save anything |
| 67 |
on their desktops, and nonetheless they can do that. The installed |
| 68 |
applications also create data in the disk space of the VM. Their MUAs |
| 69 |
do that, for example, and you may find users who have accumulated over |
| 70 |
300GB for email storage. Make the disk read-only, and the VM probably |
| 71 |
won't even start. |
Archives