Before we start, yes i know the setup is not optimal, but we're working on a plan to setup everything from scratch. I inherited this from a part time student that doesn't work here anymore. This is a question on a potential solution.
We have a pretty urgent fault that needs to be fixed before the rebuilding of our NAS though.
The setup: 2x servers, 1x Windows server 2012r2 (referred to as Vmhost) and 1x FreeBSD (referred to as Nas) with 8x 300GB disks in Raidz2. The nas exposes 2 luns to vmhost with iscsi.
Vmhost is running a couple of VMs (duh) that is stored on these iscsi disks.
The problem: There is 1 VM that has snapshots (or checkpoints) in hyper-v that are 2 years old (don't ask why), which has resulted in that the snapshot file is just as big as the actual disk file (vhdx disk).
We are running of space on our nas and that makes our VMs slow or unresponsive.
One thing i do not understand (but is probably very easily explainable) is that Windows reports that the iscsi disk have almost 4TB of data on it, while i don't have more than 300*6 (+2 parity) GB of HDD installed. Is this just good compression on ZFS's part?
Proposed solution: Move the vm's disk to some other disk and correct the mapping in vm config, then just press "delete checkpoint" in hyper-v and let hyper-v merge the snapshot to the disk and then move it back to the iscsi disk.
Question on is is: If the vhdx disk is 1tb and the snapshot file is 1tb, is a 3tb disk enough as a merge disk? And will it actually unlock 1tb? (the vhdx's size is fixed) or will it not do much (since it obviously is not reporting correct size)?
Bigger question: Since the sizes does not really make sense any direction, what numbers can i trust? I have way over 4tb data in total on 1800gb of space if i go by numbers. Is zfs so smart that is can see that some data in the snapshot might the same as on the disk and not use extra space?