Hi, up to now, I have had period snapshots taken of my dataset (virtualmahcines) where I store the VMs. I have “recursive” enabled. Yesterday, I tried to create a new dataset from a “virtualmachines” snapshot. To my surprise, the new dataset was a zero bytes dataset (empty with now VMs in it). From various posts I’ve read like here or here, its clearly stated that this works but carries risk because its like imaging a VM when pulling the plug. However, it seems that I’m getting empty snapshots which is a bit concerning. Is shutting down VM, snapshotting and ooting the only way of doing this properly nowadays? Surely those that have productions servers are not going to all this pain, which also involved a downtime? What is the best and most secure way of snapshotting VMs on TN Scale ElectricEel-24.10.2.1?
Immediately after cloning a dataset (or promoting a snapshot) the source and destination are identical; everything stored in the first is reflected as-is in the second.
The derived dataset only starts consuming measurable space as it writes something unique of its own. You’re effectively measuring the small but growing difference between the two.
The settings for a replication task mention what to do with “empty” snapshots. That means a snapshot with no recorded changes — no churn — from its predecessor.
Mmm, I may not have explained properly. I’m trying to “Clone to new dataset” in the below image. The cloned dataset (virtualmachines) is 0 byte in size and doesnàt have the VM volum as a child just like the “virtualmachines” dataset has.
How do you asses that “the clone is 0 byte in size” (this is expected) and “doesn’t have the VM volume as a child”?
From the screenshot, the clone should refer 19 GiB of data—whether this a working VM is another issue.
Because otherwise VMs woudl have a child “vmv101” (the actual VM) sitting under it? And it actually says its has 0 byte allocated to it?
I’m sure I’m missing something …
I stand by my explanation. The new dataset simply hasn’t needed to allocate space of its own. Its initial content is already fully accounted, elsewhere in the pool.
There are many places throughout TrueNAS and ZFS where the reported stats don’t quite match what they would on a simple filesystem. Among those, your example of directly attributed block cloning is comparatively straightforward.
A more challenging example would be approximating free space after a RAIDZ expansion. The precise details are expensive to calculate and hard to express in the limited POSIX vocabulary — let alone in summary UI.
Oh — OK. I think I’m catching on.
It is not surprising that the cloned dataset reports zero bytes.
It is surprising that the recursive clone did not also clone the zvol.
Had the zvol been cloned as well, it too could have reported zero bytes and made sense in terms of its owned allocations. But the cloned zvol should exist and apparently does not.
Sorry; I had focused on the space reporting. If there’s a serious issue here, it’s about whether zvols are picked up during recursive dataset operations. Am I on track now?