On 09/26/2011 10:17 PM, Bill Bogstad wrote:
On Mon, Sep 26, 2011 at 9:45 PM, Mark Woodward<ma...@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
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
