Why not have a look at the snapshots section of the LVM-HOWTO?
LVM snapshots are your basic "copy on write" snapshot solution. The snapshot is really nothing more than asking the LVM to give you a "pointer" to the current state of the filesystem and to write changes made after the snapshot to a designated area.
LVM snapshots "live" inside the volume group hosting the volume subject to the snapshot-- not another volume. Your statement "...lots and lots of unallocated freespace not it the partition" makes it sound like your thinking is that the snapshots "live" outside the volume group subject to snapshot, and that's not accurate. Your volume group lives in a hard disk partition, and the volume being subject to snapshot and any shapshots you've taken live in that volume group.
The normal way that LVM snapshots are used is not for long-term storage, but rather to get a consistent "picture" of the filesystem such that a backup can be taken. Once the backup is done, the snapshot is discarded.
When you create an LVM snapshot you designate an amount of space to hold any changes made while the snapshot is active. If more changes are made than you've designated space for the snapshot becomes unusable and must be discarded. You don't want to leave snapshots laying around because (a) they'll fill up and become unusable, and (b) the system's performance is impacted while a snapshot is active-- things get slower.
Edit:
What Microsoft Volume Shadow Copy Services and LVM snapshots do aren't too tremendously different. Microsoft's solution is a bit more comprehensive (as is typically the case with Microsoft-- for better or for worse their tools and products often seek to solve pretty large problems versus focusing on one thing).
VSS is a more comprehensive solution that unifies support for hardware devices that support snapshots and software-based snapshots into a single API. Further, VSS has APIs to allow applications to be made quiescent through the snapshot APIs, whereas LVM snapshots are just concerned with snapshots-- any quiescing applications is your problem (putting databases into "backup" states, etc).
It's perfectly fine to do this. What you do not want is to have the parent of the snapshot (the original, or the source, or whatever you want to call it) to be in use at the same time, because it will cause IO multiplication (Hubert was right about this, it is just easy to prevent by not using the source volume all the time).
If you have one master OS install on an LVM, and you snapshot that four times, you will not have much of an IO penalty, since you are only writing to the individual snapshot volumes. Of course, it is not free, but neither are other forms of snapshotting on other filesystems or virtual disks. There is always a cost somewhere.
One other thing Hubert is right about, is that you have to think about the sizing of your snapshots. You will want to make sure the snapshot volumes are able to keep writing. A full snapshot volume will break stuff badly. A failsafe way to prevent this, is to make the snapshot volume the same size (or bigger) than the source volume. You loose the benefit of using less diskspace this way, though.
You know that qemu images are snapshot capable too?
Best Answer
The idea may be reasonable but dd is the killer for all efforts. You will not get neither speed nor space-saving.
With differential coping at least space-saving may available. Can try lvmsync to do It.
Another option is ZFS (zfsonlinux) where you can do clones from snapshots. But I am not sure about ZVOL perfomance on Linux.