Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] LVM Re: A really interesting chain of functionality



> From: Mark Woodward [mailto:markw at mohawksoft.com]
> 
> I was thinking, on my drive into work, about your scenario. On the
> surface it sounds like a pretty good use of snapshots, but it is
> actually pretty bad.
> 
> The assumed advantage is that there is some "gold copy" of a VM that
> will be used for [n] snapshot VMs. It is a short term strategy. Since
> there is no resolution process to re-merge changes in the "gold copy"
> into the shapshots after the initial creation, you will inevitably fill
> your snapshots with duplicative data.

Hold on to the assumptions there.  ;-)  (see below)


> Suppose you create a linux vm, and snapshot a number of times to create
> virtual machines. In the lifetime of the VMs updates will be applied for
> bug fixes and security. You will need to apply the updates to each
> snapshot, individually, because there is no correlation of low level
> disk blocks. After a few cycles, you will be losing any real advantage
> of the snap shot.
> 
> A "net boot" image with shared system components configured with dhcpd
> and a mountable home directory is the most efficient and maintainable
> solution for this sort of system. 

In the case of linux machines, duplicates of each other, which don't need
machine-specific customizations to survive shutdowns, I fully agree.  Make /
a NFS mount for that matter.  Then you're *really* avoiding duplicating
data.   ;-)

The datacenter snapshot clones of VM's scenario is a really common use case
for people using snapshots...  Particularly in companies that are
virtualizing the windows desktop, where there is no suitable alternative to
support a network-mount or similar solution on the boot drive, where
machines must join a domain and must survive individually after shutdowns
etc.

In the windows desktop scenario, if you're creating/destroying generic clone
VM's with any regularity, the alternative is *actual* multiple copies of the
same data on disk, for different VM's, plus all the time necessary to
*actually* copy the data.  So any amount of duplicate data (thanks to
windows updates and so forth) that gets created incrementally on the fly
repeatedly in multiple machines is just incidental, and better than the
alternative.

Also, who says there's no process to update the golden image?  You apply
changes to the golden image, and then use the new golden image as the basis
for any new machines.  As soon as all the clones of the old image are able
to be deleted, you're free to delete the old golden image.  If you want, you
could promote the clones and delete the original golden...

Even if it never gets deleted at all, some employee has been at the company
for N years, and their VM is N years old...  The only cost it has is some GB
in the datacenter.  So then you have to ask yourself if it would have
actually been cheaper to have a physical desktop, and weigh the pros/cons,
TCO, etc.  To virtualize or not to virtualize...




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org