Using LVM snapshots for KVM virtual machine clones
While I didn't try LVM for KVM storage, I did use it for shadow volume feature of samba and I can tell you one thing: the performance was abysmal.
Each and every snapshot requires an additional write to happen. If you have one base snapshoted volume and 4 snapshots, the amount of writes that goes to the drives is multiplied by 5 when you write to base volume.
As for your specific questions:
- LVM freezes a filesystem while the snapshot takes place (stops writes, flushes cache, does the snapshot, resumes writes)
- as I said, it's very slow
- Yes, corrupted base volume renders all snapshots unusable, what's more, if you run out of space allocated for the snapshot deltas, the snapshot is hosed as well
- yes, you can snapshot a snapshot
Unfortunately, there are only 3 systems I know of that work well with snapshots: NetApp WAFL, ZFS and btrfs. If the system is not critical btrfs could be worth a shot.
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?
Thin-provisioned LVM should be considered a prime option for this scenario, here in 2019.
Thin LV performance is good, and they function like separate volumes so once a snapshot is made you don't have to worry about the care and integrity of the original (it can be damaged, deleted, etc. without affecting the snapshot).
The OP's concern for "the snapshot takes up little actual space" isn't really satisfied by traditional LVM since space must be pre-allocated in a monolithic fashion for each snapshot. But Thin LVs are allocated like sparse files, and actually do take up little space.
The trade-off for thin provisioning is that the available space in the thinpool must be monitored just like a filesystem to avoid filling it up. Linux distros typically have daemons to monitor this and send warnings or take action when a thinpool reaches a near-full state.