Like you, I find myself managing large LUNs (1TB each) presented as RDMs only for the purpose of virtual file servers. The sole reason for being RDMs is that there is no real benefit of putting them onto VMFS due to the 2TB limit (excluding the use of Extents which I won’t go into). If you imagine my scenario if I did use VMFS, I would have 2 file servers each with a 1TB virtual disk hosted on a 2TB VMFS volume and attempts to do anything such as snapshotting or indeed volume growing of the 1TB virtual disks is almost impossible, unless of course extents are introduced. One way to bypass the volume sizing limit without an extent would be to create another virtual disk on a different VMFS volume and then diskpart them together at the OS layer!

How you manage the provision of storage varies between use cases although I find it hard to justify adding the VMFS layer if the use case (high capacity demands) can only offer 1 or 2 virtual disks from it.

Andrew

We went with View for two reasons:

1) View is advantageous from a licensing perspective to us. We didn’t want to mix our desktop VM’s onto our server VM cluster. It was much less costly to purchase View licensing for 30 VM’s and have two ESX hosts than to pay for two full ESX host license.

2) We expected that Pano would fit some of our business needs but not all. We plan on deploying other end-point devices and possibly experimenting with View for offline laptops use.

I agree, though, View is by no means a requirement. It worked in our particular case.

But why you wanna use View ?
Think the PanoDAS service together with the Panomgrsrv makes the connection to the Pano device not the view stuff.

ITP