Também usamos nossos NetApps como armazenamento de bloco simples para VMware e o fazemos há mais de dois anos sem problemas (exceto o uso do iSCSI). (Pessoalmente, não estou muito feliz com isso, pois parece que nossos NetApps são superqualificados para isso.)
Eu não tenho os comandos exatos que usamos para criar o vol e LUN, mas é assim que eles se parecem agora:
vmstorage4a> vol status vol1
Volume State Status Options
vol1 online raid_dp, flex nosnap=on, nosnapdir=on,
64-bit no_atime_update=on,
fractional_reserve=0
Containing aggregate: 'aggr0'
vmstorage4a> lun show -v
/vol/vol1/vms5a-0 8t (8796093022208) (r/w, online, mapped)
Serial#: -d9-P?B811NB
Share: none
Space Reservation: enabled
Multiprotocol Type: vmware
Maps: vm=0
Occupied Size: 3.4t (3793203814400)
Creation Time: Fri Jun 8 22:39:10 EDT 2012
Cluster Shared Volume Information: 0x0
vmstorage4a> df -h vol1
Filesystem total used avail capacity Mounted on
/vol/vol1/ 8500GB 8225GB 274GB 97% /vol/vol1/
snap reserve 0TB 0TB 0TB ---% /vol/vol1/..
Isso é basicamente o que você tem, exceto que também temos no_atime_update = on. No meu entender, isso impede que o registro de data e hora do último acesso no LUN seja atualizado toda vez que o LUN for acessado, reduzindo assim a E / S de gravação desnecessária.
Se você tiver um LUN por volume, certifique-se de que guarantee = volume não esteja desativado (em status vol). Se for, seu LUN pode crescer mais que o volume. Eu tive isso acontecer e foi uma pena.