Creating and Configuring VMFS and NFS Datastores. Flashcards
Supported NFS Versions
vSphere 6 makes NFS 4.1 available for the first time; however, only vSphere 6 hosts support it. In addition, because NFS 4.1 is not compatible with NFS 3, you will not be able to use both versions on the same storage array. This means that if you want to use NFS 4.1 on an NFS storage array, you should upgrade all the hosts that will connect to the array to vSphere 6.
Configuring NFS Storage for vmdk Formatting.
You can make an NFS share on an NFS server available to your host by mounting it to the host. You can liken mounting an NFS share to creating a mapped drive.
You need the address of the share and the name. In essence, that is exactly what you need to mount an NFS datastore.
Case sensitive. Figure 9-2. Step 6.
Configuring Storage Multipathing (SAN).
Generally speaking, you do not have to change the default multipathing settings that your host uses for a specific storage device, because the host software is very good at making the right choice.
Configuring Storage Multipathing (SAN): Fixed.
In this case, the preferred path is used whenever available.
If the preferred path should fail, another path is used until the preferred path is restored, at which point the data moves back onto the preferred path.
The disadvantage of this solution is that a flapping connection could cause the paths to “play ping-pong” with each other, a condition known as thrashing.
Configuring Storage Multipathing (SAN): Most Recently Used.
This is the default used with a SAN that is set to Active/Passive. With this policy, a path is chosen and continues to be used so long as it does not fail.
If it fails, another path is used, and it continues to be used so long as it does not fail, even if the previous path becomes available again.
Configuring Storage Multipathing (SAN): Round Robin.
This is the only path selection policy that uses more than one path during a data transfer session.
Data is divided into multiple paths, and the paths are alternated to send data.
Even though data is sent on only one path at a time, this increases the size of “the pipe” and therefore allows more data transfer in the same period of time.
If you decide to use Round Robin, the settings should be coordinated and tested between you and the storage administrator.
Disabling a Path to a VMFS Datastore.
What if you wanted to make changes to the underlying components in that path, such as the switches or cables that connect the host to the datastore?
You should make sure that there is another path available, but, as a precaution, the system will not allow you to disable a path if it is the only path to the datastore.
Determining VMFS Requirements.
As mentioned previously, your datastores are logical containers that are analogous to the file systems within them.
In other words, datastores hide the specifics of a storage device and provide a uniform model for storing VMs.
As you know, you can also use them for storing ISO images, VM templates, and even floppy images.
You may want to create different datastores for different types of VMs.
This approach will be especially helpful if the underlying disk for the datastores also differs in performance, which is highly likely.
In that regard, you can group datastores into folders based on what types of VMs they contain.
This makes it possible possible to assign permissions and alarms at the folder level, thereby reducing administrative effort.
In addition, it is now possible to create storage profiles to make sure that your VMs are connecting to the appropriate datastore.
In fact, you can create only VMFS-5 datastores in vSphere 6.
You can upgrade VMFS-3 to VMFS-5, but you cannot create new VMFS-3 datastores.
VMFS-5 Capabilities. Partial. **
- Support for greater than 2 TB storage devices for each VMFS extent. This increases the flexibility for you and the storage administrator when creating and using LUNs. You can create and use up to 64 TB extents.
- Standard 1 MB file system block size with support of 62 TB virtual disks (with Version 10 or later VMs). Previous versions required a larger block size to store larger files. This meant that the administrator would have to choose between more efficient file storage or the capability to store larger files. Now you can have both at the same time.
- Support of greater than 2 TB disk size for RDMs in physical compatibility mode. You can use physical compatibility RDMs up to 64 TB in size.
- Online, in-place upgrade capability. You can upgrade VMFS-3 datastores to VMFS-5 without any disruption to your hosts or VMs.
Configuring and Managing VMFS Extents.
Generally speaking, to create a VMFS datastore, you mount a logical volume (the datastore) to one or more logical unit numbers (LUNs) that are local or on a storage area network (SAN).
After the LUN is mounted to the VMFS datastore, it’s also referred to as an extent.
Therefore, a datastore mounted to only one LUN still has one extent.
Rename Datastore.
In general, you should name your datastores based on their purpose.
In most cases, their purpose should be to store a particular type of VM, an ISO file library, templates, and so on.
As you know, organizational goals and directions change over time, thereby redefining the purposes of your datastores.
When this happens, you should consider changing their names. To change the name of your datastore, follow the steps outlined in Activity 9-5.
Delete Datastore.
If you decide that you no longer need a VMFS datastore, you can choose to delete it.
You should be aware that deleting a VMFS datastore is a “permanent” action that deletes all the metadata on the LUNs in the SAN.
In other words, there is no “going back” in any normal sense.
Because of this, you should make absolutely sure that there is no data on the datastore that you will need.
You can use Storage vMotion to migrate a VM’s files, or you can cold migrate VM files to other datastores before deleting the datastore if you need to keep them.
You should also move or back up any ISO files that you may need later.
Unmount Datastore.
In earlier versions of vSphere, this was not possible with a VMFS datastore.
With vSphere 5.0 and later, it is possible, but a lot of conditions must be met before it is possible.
The following is a list of 5 conditions that you must address before unmounting a VMFS datastore:
- No registered VMs can reside in the datastore.
- The datastore cannot be part of a datastore cluster.
- The datastore cannot be managed by Storage DRS.
- Storage I/O Control must be disabled.
- The datastore cannot be used for vSphere HA Heartbeat.
Extending VMFS Datastores:
Extending a datastore means adding another LUN to it. (Create extent).
In legacy versions of VMware software (prior to vSphere 4), this was the only option with regard to growing a datastore.
Now you also have the option to expand the datastore (discussed next), but the option to extend might be the right choice depending on the situation.
If your storage administrator is using only relatively small LUNs (500 GB and less), extending might be your best alternative.
