Hi!
You are confusing a couple of things.
You can mount snapshots in FreeNAS. But only snapshots of mountable things, e.g. datasets/filesystems. You cannot mount ZVOLs. That's why you cannot mount snapshots of ZVOLs, either. ZVOLs are byte-by-byte images of "hard disks" in your use case. Or iSCSI LUNs exported to VMware. Or database table space. All of which cannot be mounted but need to be accessed by the right application. So in your case you need to connect them to a VM running the matching guest operationg system to make sense of the data inside.
In terms of create a clone from snapshot and comparing this to a zfs send/receive -- the clone's are linked to the snapshot correct? That means you can't delete the snapshot without deleting the clone?
Yes. Thanks for refreshing my memory. You can create a r/w clone from an r/o snapshot. And then you can make that cloned ZVOL appear as a second (third, fourth, ...) hard disk in your VM via the "Devices" menu. Need to shutdown the VM first.
Does the zfs send/received command unlink the "clone" from the parent snapshot?
A
zfs send
creates a bytestream of the snapshot's contents. A
zfs receive
creates a completely new ZVOL with the contents sent to it. You could just redirect the contents of a
zfs send
to a file to store it for later, copy over a slow and flaky connection to the other side of the world, then do a
zfs receive
over there locally ... stuff like that.
If you rollback to a specific snapshot (say not the most recent but a snapshot that was 3 or "x" snapshots prior to the most recent -- do you have to manually delete the more recent snapshots or does FreeNAS take care of deleting these for you? Also what if you've done a zfs send/receive to a remote archive -- I'm betting it's probably best to manually delete the intermediate snapshots as well.
If you rollback to snapshot X, all snapshots younger than X are lost, if I am not mistaken. That would make sense, at least. A
copy made by the means of
zfs send/receive
is not affected by anything you do to the snapshot. That's why I prefer creating copies this way, better safe than sorry.
HTH,
Patrick