I have a VM that requires a 8TB drive. Should I use Extents to present a single 8TB drive to the VM or 4 2RB drives and use the OS to create a RAID0 array?
None of the above options. If you loose one disk you loose all data. It would be better to use e.g. 5 disks in a RAID5 in this case. Anyway, although ESXi 5.0 supports larger physical disk sizes now, the limit of 2TB minus 512 Bytes for a virtual disk still exists.
André
The SAN is already a RAID50 array. I'm creating a 8TB LUN. I need to present a single 8TB drive to my application.
So the question stil is: Do i use extents to string 4 VMDKs together and present a single 8TB volume to the OS, or should I present 4 2TB volumes to the OS and create a software RAID9 array?
Ok this is different. Since there is still the limit for a single virtual disk (~2TB) it's up to you whether you present a single large datastore and create 4 virtual disks on it or present 4 smaller datastores with a single virtual disk. In either case you need to create a software RAID0 to get the required volume size. Make sure you leave some disk space on the datastore(s) for snapshots and other files (swap, log, configuration).
Personally I would go with 4 smaller LUNs to be able to load balance the storage traffic if the storage supports it.
André
Depending on other requirements you have, and the type of disk you are using, is raw device mapping an option for you? You are not limited then by the 2TB VMDK size. Is there a possibility of attaching the VM direct to the SAN through an iSCSI initiator provided that is the type of SAN you have. Just putting those out there as options.
-dt
vmdavet is absolutely correct. Sorry I missed this. With ESXi 5.0 you can use RDMs in physical compatibility mode (pass-trough mode) with up to ~64 TB.
André
RDM is not an option as VEEAM will not back them up.
Use 4 x 2 TB VMDK , use GBT partitions and build an 8 TB volume inside the GOS.
Can you do RDM + backup agent in the VM (bypassing snapshot type backups)?
We are moving away from GOS agent backups like BE as fast as we can. They are too slow and unreliable for the volumes of data we need to handle.