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

[Mark Woodward]

On 09/26/2011 10:17 PM, Bill Bogstad wrote:
> On Mon, Sep 26, 2011 at 9:45 PM, Mark Woodward<markw at mohawksoft.com>  wrote:
>> On 09/26/2011 07:17 PM, Edward Ned Harvey wrote:
>>> So, this all serves to rather emphasize my point, which is to say...
>>> (LVM) Create snapshot, mount it, monitor it with nagios or whatever,
>>> lvextend it, lvextend the filesystem, resize2fs, unmount and release
>>> snapshot...
>>> versus
>>> (ZFS, Netapp, Volume Shadow Services, etc.)  Do nothing, and don't worry
>>> about it.  It's all automatic and dynamic and just works.
>> I don't think this is right. Running nagios on a snapshot would do nothing.
>> A snapshot is protected from change.
> This is neither true in the logical nor physical sense with LVM.   It
> was never true in a physical sense, in that the storage for the
> snapshot is slowly used up due to copy-on-write as applications write
> to the original copy of the filesystem.   It's not true in the logical
> sense because LVM snapshots have actually been read/write for quite a
> while.  A common usage pattern for this appears to be when you want
> multiple copies of essentially the same virtual machine image.
> You start with a single gold copy and then create writable snapshots
> for each virtual machine.

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.

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. Sure, a combination of strategies 
makes sense, but you have to make sure that you can update your "gold 
copy" of the VM and re-snap your VMs without having to reconfigure each 
time.

Using dhcp you can use the virtual mac address of a VM to dictate which 
settings it gets at boot time and work from there. Then link that mac 
address to a set of directories like etc and/or home. That way you have 
your gold copy and you have the advantage of reducing duplicative data.
> Bill Bogstad