vCLI: Managing Storage

As I want to get deeper into VMware CLI (vCLI) I deciced to make a summary of the vSphere Command-Line Interface Installation and Scripting Guide. Every chapter will be a separate blog post.

This summary is meant for my documentation but feel free to make use of it.

In this blog post: Managing Storage

Examining LUNs

• Listing all logical devices known on this system with detail information
  vicfg-scsidevs –list
• List all logical devices with abbreviated information.
  vicfg-scsidevs –compact-listThe information includes the device ID, device type, size, plugin, and device display name.
• List all device unique identifiers.
  vicfg-scsidevs –uids
  The command lists the primary UID for each device (naa.xxx or other primary name) and any other UIDs for each UID (VML name). You can specify –device to only list information for a specific device.
• List a specific logical device with its detailed information.
  vicfg-scsidevs -l -d mpx.vmhba32:C0:T1:L0
• Print mappings for VMFS volumes to the corresponding partition, path to that partition, VMFS uuid, extent number, and volume names.
  vicfg-scsidevs –vmfs
• Print HBA devices with identifying information.
  vicfg-scsidevs –hbas
  The return value includes the adapter ID, driver ID, adapter UID, PCI, vendor, and model.
• Print a mapping between HBAs and the devices it provides paths to.
  vicfg-scsidevs –hba-device-list

Managing paths with mpath

Listing paths

• List all devices with their corresponding paths, state of the path, adapter type, and other information.
  vicfg-mpath <conn_options> –list-paths
• Display a short listing of all paths.
  vicfg-mpath <conn_options> –list-compact
• List all paths with adapter and device mappings.
  vicfg-mpath <conn_options> –list-map
• List paths and detailed information by specifying the path UID (long path). The path UID is the first item
  in the vicfg-mpath –list display.
  vicfg-mpath <conn_options> –list -P sas.5001c231c79c4a00-sas.1221000001000000naa.5000c5000289c61b
• List paths and detailed information by specifying the path runtime name.
  vicfg-mpath <conn_options> -l -P vmhba32:C0:T0:L0The return information includes the runtime name, device, device display name, adapter, adapter
  identifier, target identifier, plugin, state, transport, and adapter and target transport details.
• List detailed information for the paths for the device specified with –device.
  vicfg-mpath <conn_options> -l -d mpx.vmhba32:C0:T1:L0
  vicfg-mpath <conn_options> –list –device naa.60060…

Changing the State of a Path

• Set the state of a LUN to off
  vicfg-mpath <conn_options> –state off –path vmhba32:C0:T1:L0
• Set the state of a LUN to on
  vicfg-mpath <conn_options> –state active –path vmhba32:C0:T1:L0

Note:
The change -PSPoperation will fail if I/O is active when the path setting is changed. Reissue the command.
You must issue at least one I/O operation before the change take effect.

Managing Path Policies

The following path selection policies are available with the NMP (Native Multipath Policy).

• VMW_PSP_FIXED
  The host will always use the preferred path you have selected when it’s available. If the path ain’t available the policy will try another available path.
• VMW_PSP_FIXED_AP
  Extension to the VMW_PSP_FIXED policy to active-passive and ALUA mode array’s
• VMW_PSP_MRU
  The host will keep using the same path until it’s unavailable. If the current path is unavailable the host will try another path (random). When the first path come back the host will not fail back. It will keep using the same path.
• VMW_PSP_RR
  The host will use round-robin through all available pahts. This policy is used for load balacing.

To change the path policy

• To list the multipathing plugin loaded on the system
  vicfg-mpath <conn-options> –list-plugins
• Set the path policy
  esxcli <conn_options> nmp device setpolicy –device naa.xxx –psp VMW_PSP_RR
• Optional you have to specify the preffered path
  esxcli <conn_options> nmp fixed getpreferred –device naa.xxx
  esxcli <conn_options> nmp fixed setpreffered –device naa.xxx –path vmhba3:C0T2:L3
• To view and manipulate round robin path selection settings
  esxcli <conn_options> nmp roundrobin getconfig –device na.xxx
  esxcli <conn_options> nmp roundrobin setconfig –type “bytes” -B 12345 –device naa.xxx (for bytes)
  esxcli <conn_options> nmp roundrobin setconfig –type=iops –iops 4200 –device naa.xxx (for iops)

Masking Paths with esxcli corestorage claimrule

1. Run esxcli corestorage claimrules list to determine the next available rule ID.
   User rule IDs start at 101
   • Rules 0-100 are reserved for internal use by VMware.
   • Rules 101-65435 are available for general use.
   • Rules 65436-65535 are reserved for internal use by VMware.
2. Decide which rule ID to use.
   The rules are used sequential. So make sure you use the correct rule ID or another claimrule will be used.
3. Add the MASK_PATH plugin to the claim rule with the ID you decided to use.
   esxcli <conn_options> corestorage claimrule add –plugin MASK_PATH –rule <ruleID>
   –type <type> -A <adapter>
4. Verify that the claim rule was added correctly.
   esxcli <conn_options> corestorage claimrule list
5. Load the path claiming rules.
   esxcli <conn_options> corestorage claimrule load
6. Release the device from the current plugin so that it can be claimed by another rule. For example, you
   might run the following command for each path:
   esxcli <conn_options> corestorage claiming unclaim -t location -A vmhba0 -C 0 -T 0 -L 149
7. Run the path claiming rules, which include the newly added rules.
8. esxcli <conn_options> corestorage claimrule run

To unmask the path

1. Delete the MASK_PATH claim rule.
   esxcli <conn_options> corestorage claimrule delete -r <rule#>
2. Verify that the claim rule was deleted correctly.
   esxcli <conn_options> corestorage claimrule list
3. Reload the path claiming rules from the configuration file into the VMkernel.
   esxcli <conn_options> corestorage claimrule load
4. Run esxcli corestorage claiming unclaim for each path to the masked device, for example:
   esxcli <conn_options> corestorage claiming unclaim -t location -A vmhba0 -C 0 -T 0 -L 149
5. Run the path claiming rules.
   esxcli <conn_options> corestorage claimrule run

Managing NFS/NAS DAtastores

• List all known NAS file systems.
  vicfg-nas <conn_options> -l
• Add a new NAS file system to the ESX/ESXi host.
  vicfg-nas <conn_options –add –nasserver dir42.eng.vmware.com -s /<mount_dir> nfsstore-dir42
• Add a second NAS file system with read‐only access.
  vicfg-nas <conn_options> -a -y –n esx42nas2 -s /home FileServerHome2
• Delete one of the NAS file systems.
  vicfg-nas <conn_options> -d FileServerHome1

Migrating Virtual Machines with svmotion

• Running svmotion in interactive mode (you will be prompted for the information)
  svmotion <conn_options> –interactive

• Running svmotion in noninteracitve mode
  svmotion [standard vCLI options] –datacenter=<datacenter_name>
  –vm <VM config datastore path>:<new datastore>
  [–disks <virtual disk datastore path>:<new datastore>,
  <virtual disk datastore path>:<new datastore>]

  By default the –vm option will migrate the completed Virtual Machine to the new location (config files and vmdks)
  The –disks option will migrate only that vmdk.

Managing Duplicate VMFS Datastores with vicfg-volume

Each VMFS datastore created in a LUN has a unique UUID that is stored in the file system superblock. When
the LUN is replicated or a snapshot made, the resulting LUN copy is identical, byte‐for‐byte, to the original
LUN. As a result, if the original LUN contains a VMFS datastore with UUID X, the LUN copy appears to
contain an identical VMFS datastore, or a VMFS datastore copy, with the same UUID X.
ESX/ESXi hosts can determine whether a LUN contains the VMFS datastore copy, and either mount the
datastore copy with its original UUID or change the UUID to resignature the datastore.
When a LUN contains a VMFS datastore copy, you can mount the datastore with the existing signature or
assign a new signature.

To mount a datastore

1. List all volumes that have been detected as snapshots or replicas.
   vicfg-volume <conn_options> –list
2. Run vicfg-volume –persistent-mount with the VMFS‐UUID or label as an argument to mount a
   volume.
   vicfg-volume <conn_options> –persistent-mount <VMFS-UUID|label>

To umount a datastore

1. vicfg-volume <conn_options> –unmount <VMFS-UUID|label>

Resignature  a VMFS copy

• Datastore resignaturing is irreversible.
• The LUN copy that contains the VMFS datastore that you resignature is no longer treated as a LUN copy.
• A spanned datastore can be resignatured only if all its extents are online.
• The resignaturing process is crash and fault tolerant. If the process is interrupted, you can resume it later.
• You can mount the new VMFS datastore without a risk of its UUID conflicting with UUIDs of any other
  datastore, such as an ancestor or child in a hierarchy of LUN snapshots.

1. Make sure the copy is not mounted.
2. Run vicfg-volume with the resignature option.
   vicfg-volume <conn_options> –resignature <VMFS-UUID|label>
   The command returns to the prompt or signals an error.
3. It’spossible that vmx, vmdk, vmsd or vmsn file has a reference to the original signature. You will have to change these.

Rescanning Storage Adapters

• vicfg-rescan <conn_options> vmhba1