VCP 5 - Objective 3.3 – Create and Configure VMFS and NFS Datastores

Identify VMFS and NFS Datastore properties

VMFS Properties

Block Storage
High performance file system format that is optimized for storing virtual machines
Current version is VMFS 5. VMFS 5 is only readable and writable by ESXi 5 hosts, however ESXi 5 hosts can read and write to datastores with the previous VMFS version (3).
Space can be increased while VMs are running on the datastore.
Designed for concurrent access from multiple physical machines and enforces the appropriate access controls on VM files.
When a datastore is formatted with VMFS 5, it uses a GUID partition table, which allows datastores be up to 64TB in size.
VMFS provides specific locking mechanisms (on disk locking) that allow multiple hosts to access the VMs on a shared storage environment.
Contains metadata which includes all mapping information for files on the datastore. This mapping information or metadata is updated each time you perform either a datastore or virtual machine management option such as creating or growing a virtual disk, powering a VM on or off, creating a template, etc.
The locking mechanism prevents multiple hosts from concurrently writing or updating the metadata.
There are two types of locking mechanisms. SCSI reservations (locks the entire LUN from other hosts) which is used with storage devices that do not support hardware acceleration and Atomic Test and SET (ATS) – (locks per disk sector) for those storage devices that do support hardware acceleration.

NFS Properties

File system will be dictated by the NFS Server.
Shared Storage capabilities supported on a NFS volume include vMotion, VMware DRS and VMware HA, ISO images, and snapshots.
Maximum size of the NFS datastore depends on the maximum size supported by the NFS Server. ESXi does not impost any limits on NFS datastore size.
If the NFS server does not offer internationalization support, do not use non-ASCII characters to name your datastores or VMs as you may experience unpredictable failures

Identify VMFS5 capabilities

Config Maximums

Up to 256 VMFS datastores can be attached to a host, with each datastore having a maximum size of 64 TB.
Can have up to 32 extents per datastore

Differences from VMFS 3

Extents can be greater than 2 TB in size
Increased resource limits (file descriptors)
Standardized on a 1 MB block size with support for virtual disk up to 2 TB.
Support of greater than 2 TB when utilizing Physical Mode RDMs
Default use of hardware assisted locking (ATS) on devices that support hardware acceleration.
Ability to reclaim unused space on thin provisioned arrays utilizing VAAI
Online upgrade

Create/Rename/Delete/Unmount a VMFS Datastore

Creating a datastore

Under the storage section of a hosts configuration tab click 'Add Storage'
Select the disk/LUN storage type (either VMFS or NFS) In this case, VMFS.
Select the desired device and file-system version.
Select whether to use all available partitions (erase everything) or use free space. If the disk you are adding is blank, then the entire space is just displayed.
Give the datastore a name and click 'Finish'
After you have completed, if the host is a member of a cluster, a rescan operation will be performed on all hosts in the cluster and the datastore will be added to the others as well

Renaming a VMFS datastore

Pretty simple, right click and rename. This name will be reflected across all hosts that have access to the datastore.

Deleting a VMFS datastore

Just a note, once the datastore is deleted it will be gone from all hosts and the data will be destroyed.
Be sure to remove all VMs from the datastore.
Right click the datastore and select 'Delete'.

Unmounting a VMFS Datastore

Unmounting a datastore does not destroy its data. It simply removes it from the host that you unmounted it on. It will remain visible to all other hosts that have access to it. Before unmounting, be sure not to perform any operations that my cause in I/O on the target datastore, the datastore should be removed from any datastore clusters, storage i/o is disabled and the datastore is not being used for HA heartbeating. Unmounting a datastore that is being used for HA heartbeating MIGHT cause the host to fail and begin to restart VMs. This does not generate an error during the unmount, just a warning. The unmount process is as follows

Right click the datastore and select Unmount
If the datastore is shared, you will have to select which hosts you would like to unmount this datastore from.
Confirm and you're done

Mount/Unmount an NFS Datastore

Mounting an NFS Datastore

In the storage section of the hosts Configuration tab click 'Add Storage'
Select NFS as the storage type.
Enter in the NFS Server Name or IP, the mount point and a desired name for the datastore.
If the volume has been exported as read only, be sure to select Mount NFS Read only.
Confirm and Done!

Unmounting an NFS Datastore

This procedure is exactly the same as the unmount procedure above for VMFS datastores

Extend/Expand VMFS Datastores

You have a couple of options when it comes to gaining more space on your VMFS datastores. You can either add a new extent or grow an existing extent if there is space available. The process is similar.

Click on the datastore, then click properties.
Click 'Increase' and then select your option to either add a new extent or grow and existing one.
From here on the process is similar to that of creating a new datastore, where you select to either destroy current data or use available free space, set a capacity and click 'Finish'

Upgrade a VMFS3 Datastore to VMFS5

Datastores that are in VMFS 2 or VMFS 3 can be upgraded to VMFS 5. If however you are in VMFS 2 you must perform the upgrade to VMFS 3 first (thus, since ESXi 5 cannot access VMFS 2 you will need to keep a legacy 4.1 host around to do this), then upgrade to VMFS 5 This can be a non disruptive upgrade that is performed while VMs are running on the storage and all files will be preserved. That being said, there are some situations where a complete reformat of your datastores would be preferred (if you weren't using a 1 MB block size). This is also a one-way process where you can't go back to a previous VMFS format.

After upgrading you will now have (if you reformat) a standard 1 MB block size (before it could be 1, 2, 4, or 8) and a new smaller 8K subblock size (down from 64K). Also, VMFS 5 uses a new partition format called GPT rather than MBR. The GPT conversion for in place upgrades does not occur until you expand the datastore.

Inplace upgrade process involves

Verify that the host has at least 2MB of free blocks and 1 free file descriptor
Select the VMFS datastore from the Storage section of the Hosts Configuration Tab.
Click 'Upgrade to VMFS5.' – Done!

IMO it's probably best to completely reformat all of your LUNs with the VMFS 5 filesystem rather than doing an inplace upgrade. This will ensure you get the standard 1 MB block size and also ensure you are supported with all of the new vSphere 5 storage features.

Place a VMFS Datastore in Maintenance Mode

Placing a VMFS Datastore in maintenance mode will evacuate all VMs on the datastore by Storage vMotioning them to other datastores. In order too place a datastore in maintenance mode the following prerequisites must be met

Storage DRS needs to be enabled on the datastore cluster that contains the datastore.
No CD ROM/ISO images can be stored on the datastore
There must be at least two datastores in the cluster.

The actual process of doing this is quite easy. Simply select 'Enter SDRS Maintenance mode' from the Datastore inventory view on the datastore you wish to bring into maintenance mode. A list of placement recommendations will be generated and you can uncheck those which you wish not to apply.

Select the Preferred Path for a VMFS Datastore

The ability to select the preferred path exists only when using the Fixed Path Policy. In order to set this, simply open the Manage Paths dialog box from within the Datastore view. Right Click on your desired path and select 'Preferred' An asterisk will now appear on the path showing that it is the preferred path.

Disable a path to a VMFS Datastore

Disabling a VMFS path will temporarily disable a path to a datastore for maintenance or other reasons. The process is similar in fashion to that of setting a preferred path except selecting 'Disabled' instead of preferred. You can disable a path no matter which PSP you are using.

Determine use case for multiple VMFS/NFS Datastores

I can think of many reasons why you would want to use multiple VMFS/NFS Datastores; a few listed below

Separate spindles – having different spindles to help provide better performance. Having multiple VMs, especially I/O intensive VMs sitting on one big datastore may cause latency and performance issues.
Separate RAID groups. – for certain applications, such as SQL server you may want to configure a different RAID configuration of the disks that the logs sit on and that the actual databases sit on.
Redundancy. – If you are doing any sort of replication you would certainly want your replicated VMs to sit on different disks than your production VMs in the case that you have failure on your production storage.
Tiered Storage – You may have a use case to have storage formatted in different arrays laid out as Tier 1, Tier 2, etc.

Determine appropriate Path Selection Policy for a given VMFS Datastore

Most Recently Used

The host will select the path that it used most recently.
When this path becomes unavailable, it will select an alternate path.
When the initial path comes back online, nothing will happen, it will continue to use the alternate path.
Default policy for most active/passive arrays.

Fixed

The host will use the designated preferred path if configured, other wise it will select the first available working path.
If the path becomes unavailable, the host will select an alternate path
When the preferred path comes back online, the host will revert to that path. (note: this only works if you set the preferred path. If you allow the host to select it's own preferred path it will continue to use the alternate and not revert to the original).
Default policy for most active/active arrays.

Round Robin

Uses an automatic path selection algorithm rotating through all active paths when connecting to an active/passive array, and all paths when connected to an active/active array.
Provides more load balancing across paths.
Default for a number of different arrays.

When, how and why to use each policy really depends on the array and the vendors recommendations. Always consult the product documentation of your SAN to determine if they have any recommendations on which policy to use.