@Tywin said it well in
#117. Guides don't really cut it. If you can read my existing post on the topic and you can say "well duh that makes complete sense", then you might be able to pull it off with minimal risk and I am certainly willing to give you my blessing to try, with the caveat that you're an adult and responsible for your own actions and a reminder that my blessing means nothing, heh. That post is general advice about obstacles to virtualization written for people who are experienced with virtualization. At first glance it is easy to say "oh just another VM" but a proper FreeNAS deployment has some significant divergence from being just a typical VM.
and a negative guide of what not to do (Specific "stupid virtualization tricks", pitfalls, etc) would be useful.
That would be the first message in this thread.
Look, the fundamental problem here is that there isn't really a safe way to teach magic to users. Early on, I spent some time trying to work with Cyberjock on virtualizing with some less-than-ideal hardware. It failed, or rather, it worked for a little bit, then failed, but the thing that was a saving factor was paranoia. We identified that the system wasn't stable and he was willing to accept and understand that and STOPPED TRYING. He then proceeded to do his thing by doing a deep dive into the topic and figuring out what he needed to do in order to make a workable system, and I believe he now has a virtualized FreeNAS system that he is happy with, on better hardware. Awesome. His willingness to sink his teeth into a topic and then not let go until he's beaten it is the sort of quality you need to have success.
But it is risky. As an example, I downed a virtualized filer here to do a network card swap and when it came back up, it had renumbered PCI ... silently invalidating the PCI passthru configuration. I got a very, very chilly feeling for a few moments when the FreeNAS VM refused to come up. Unexpected side effects are a sysadmin's nightmare. They can be benign, but they can also be way bad.
In the Hardocp forum and other forums, quite a few people seem to be running it in VM without issue. By the picture posted of their hardware, the hardware used,etc - these are most likely sophisticated users. They know how to do it properly, much like, jgreco and others, while I do not.
So there's a few possibilities there. Not all are happy.
1) It is completely possible that these people have followed my virtualization recipe, which Tywin already pointed you to.
2) It is completely possible that they've done something hacky, like using RDM. The experience we've had here in the forums is that this can go wrong very quickly, and then users don't know how to recover. So:
2A) Maybe things go wrong and they know how to recover. Great.
2B) Maybe things go wrong and they're owning the failure and loss. Sad but I respect that.
2C) Maybe nothing goes wrong. That's not what we've seen here but it may be related to clue level. Great.
3) It is completely possible that they're using FreeNAS as a VM serving data off an ESXi datastore, which comes with lots of possibly unexpected caveats but is expected to generally work.
3A) If the datastore is nonredundant, then a problem with the datastore (disk loss) is likely to hang the FreeNAS VM. Not great behaviour for a filer.
3B) The obvious configuration of making a single data disk is a bad idea; ZFS has no place to recover bitrot from. Two virtual data disks mirrored on a redundant datastore is ideal and I bless it with my stamp of approval. Of course, you're using a LOT of disk to provide that pool, but the VM is going to pick up the reliability characteristics of the underlying datastores and enhance them with bitrot detection too.
3C) The bad configuration is to configure a bunch of nonredundant datastores and then make a bunch of virtual data disks on them and run ZFS in RAIDZ on top. This will seem to work great but suffers 3A) and seems to have some other issues as well if recovering from failures.
Definitions of "properly" vary widely and there's no single correct route. These are not all the possibilities, even.