Extension of a Clustered (shared) VMDK
search cancel

Extension of a Clustered (shared) VMDK

book

Article ID: 342629

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

NB Online extension of a clustered disk is not supported

 
After configuring a clustered VMDK, it is required to extend the size of the clustered (shared) disk.

Note: One of the common examples of using a clustered VMDK is Windows Server Failover Cluster (WSFC)
with a disk resource shared across multiple VMs (starting with vSphere 7.x)

Environment

VMware vSphere ESX 9.x
VMware vSphere ESXi 8.x
VMware vSphere ESXi 7.x

Resolution

As with any VMDK manipulation, a working backup MUST be confirmed before any work is started.


To extend a clustered VMDK, follow the steps below:

  1. Obtain the path to the clustered VMDK to be extended (for example, /vmfs/volumes/shareddatastore/VM-NAME/VM-NAME.vmdk)

  2. Shut down all VMs, having access to the clustered VMDK to be extended.
     
  3. Login to an ESXi host (SSH) with access to the datastore where the clustered VMDK is stored.

  4. Expand a clustered VMDK with the following command:
vmkfstools  -X|--extendvirtualdisk newSize[bBsSkKmMgGtT]

Specify the newSize parameter adding an appropriate Unit Suffix.
 
Unit Suffix:
It is not case-sensitive. vmkfstools interprets either k or K to mean kilobytes.
If you do not specify the unit suffix, vmkfstools defaults to kilobytes.
 
newSize:
The newSize parameter defines the entire new size, not just the increment you add to the disk.
Example below extends the existing vmdk to new total size of 2048 GB :
vmkfstools --extendvirtualdisk 2048G /vmfs/volumes/shareddatastore/VM-NAME/VM-NAME.vmdk -d eagerzeroedthick

Note: As zeros are being written this will take a while.
  1. Refresh the configuration file of VMs with the access to the extended clustered disks. See "Additional Information" below.

  2. Verify that the new disk size is correctly reflected on all VMs using "Edit Settings" section in the UI. If there are any discrepancies, remove the VMDK from that VM and readd it (“Add an existing disk”), making sure to use the same SCSI controller and ID.

  3. Boot the first VM and grow the Guest filesystem. Use the Guest OS respective guidelines

  4. Boot remaining VMs and confirm the functionality of the cluster.
Note: if you extend the clustered VMDK by using vSphere UI, you have no control over all the options to extend the disk. As a result, the EagerZeroedThick VMDK automatically becomes LazyZeroedThick. You would need to convert the disk to be EZT using the vmkfstools. For more details, see Attempts to extend the size of an EagerZeroedThick VMDK from the vSphere Client might result in a LazyZeroedThick VMDK (343322)



Additional Information

Offline extension of a clustered (shared) VMDK is supported but requires reloading configuration files (*.vmx) for all VMs having an access to the disk(s) that has been extended You can reload the configuration files by:

  • Using the vMotion operation for all VMs having an access to the clustered disk. Select to change host only while executing the vMotion Wizard. Validated for WSFC.
  • Using command line options outlined in Reloading a vmx file without removing the virtual machine from inventory (343248).
  • Removing and re-adding VMs with an access to the extended clustered disk from the vCenter Inventory. Note that operations generates a new VM Inventory ID (vmid), which might have an impact on the automation and operation of the VM. VMware does not recommend using this option.


Note: After extending a clustered VMDK from vSphere, make sure to follow the guest OS specific procedure and recommendations to extend the size of the disk in the Guest OS.


Powered by Wolken Software