Oui, il faut en effet faire plusieurs VMDK de 2TB chacuns sur un VMFS de la taille voulue (32TB par exemple). Ensuite, tu les assembles dans un VG LVM, aucune difficulté particulière. Cela est du coup facile d'ajouter ou retirer des VMDK dans un VG via vgextend ou pvmove.
Avant tout, au final, ce qui est important sur ce type de serveur avec beaucoup de stockage, c'est le temps de recovery des filesystems en cas de crash de l'OS ou de l'hyperviseur (si pas en FT). Pour cela, XFS va énormément t'aider, il est alors facile d'optimiser les temps de recovery en dimensionnant correctement la RAM de la VM (compter 1GB + 1GB de RAM par tranche de 10TB de stockage). De mémoire, avec le bon dimensionnement, il faut compter 10 minutes par tranche de 10TB, là ou par exemple il faut compter 2h pour 1TB en ext3 !
Le RDM logical ou physical est possible. Mais par experience, alors que nous avions dans un premier temps privilégié cette méthode sur plusieurs serveurs (Linux et Windows), nous avons depuis au fur et à mesure tout rebasculé sur du vmdk, bien plus simple à gérer au quotidien sans des contraintes parfois pénibles pour aucun avantage au final (LVM sur Linux ou partitions fractionnées sur Windows font le job sans soucis). Egalement, le physical RDM ne permet pas le storage vmotion, ce qui est pénalisant lors du remplacement de ta baie de stockage.
Les seuls RDM que nous conservons au final sont ceux pour les systèmes de fichiers cluster type GFS, car le positionnement sur du vmfs génère des erreurs SCSI. Mais franchement, si on pouvait s'en passer, nous n'hésiterions pas (ca bloque entre autre le VMotion, pas de snapshot possible, etc).
Pour finir, ayant pourtant à gérer plusieurs gros cluster VMWare de la version 4.0 à 5.1, des centaines de VM, plusieurs centaines de TB, nous n'avons jamais eu de corruption sur du vmfs.
J'espère que ces éléments pourront t'aider.