I'm afraid it doesn't quite work as you described. Even with NFS the individual VMs are still contained within VMDK files. Their files are not directly visible on the NFS file system. What NFS does bring you though is;
-Automated Thin provisioning. That is, a VM will only consume the amount of space it actually requires. With FC or ISCSI the VMDK files are usually pre provisioned so the VM will consume it's maximum disk space right from the start.
-Visible deduplication savings, with NFS you can see, from Virtual Center, the space you have regained from NetApps deduplication. This means you can immediately use that space and deploy additional VMs
-Snapshots, with NFS you can restore individual VMs from snaps shots without copying the VM, just using the metadata of the file
For their disk files the VMs access the NetApp using the VMware layer only. If however you wanted some shared space, say a NFS volume for your Linux VMs or a CIFS share for your Windows VMs then yes you certainly could set up a separate VLAN if you wanted to separate the VM traffic from the VMware traffic.
I understand that the VM itself has to come from a VMDK, but I don't understand why I can't just mount parts of the filesystem at boot over NFS. For example, /usr or /home as we would do on a non-virtualizard server. Am I missing something?
I have read about thin provisioning, though it does seem a shame that thin provisioning isn't maintained when cloning through VMWare.
You can certainly do that. The VM would boot off of the NFS datastore mounted to the VMware hosts then the VM could connect to a shared NFS folder for user data. The user data would be a different NFS volume and would likely be on a separate VLAN. Very standard setup and easy to do with a NetApp. Dedupe is going to help you on both volumes as user data will likely have a high amount of redundancy as well.
I've thought of a follow up question. Is it possible to implement security using ONTAP with NFS on a per-network-port basis?
e.g. could we say that connections on network port 1 can only see volume a, b and c and connections on network port 2 can only see volumes d, e and f? If the answer is yes, how robust is this security?
All the connections I'm referring to would be NFS.
The 2nd, is leveraing the "MultiStore" capabilities, which create completely separate virtual NetApp controllers within a single physical controller (like VMs within a physical server). The security with "MultiStore" is extremely high, and is used, for example, by our large service provider customers to create storage as a service for completely different/separate customers.
Networking is not my strong area so hopefully some one else will pitch in. This certainly can be done and in fact done is a couple of different ways. You can restrict a NFS share by subnet and even down to per host access. You also can leverage a capability of the NetApp device called Multistore. With Multistore, imagine VMware was running on the storage device and on ESX you had VMs. Each VM was a NetApp device. Now it isn't of course VMware but the concept is the same. You can create virtual NetApp controllers, assign them storage and network ports and manage them as completely different storage arrays. Handy for what you are asking or if you wanted the NetApp device to belong to multiple Windows Domains.
As for how secure is it? I am not sure how to answer that technically but we have customers in all levels of government using this technology. Again hopefully someone network security savy will step in.
You can get more info in TR-3462 in the NetApp library.