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

After configuring a clustered VMDK a user needs 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 ESXi 8.0.0
VMware vSphere ESXi 7.0.0
VMware vSphere ESXi 6.5
VMware vSphere ESXi 6.0
VMware vSphere ESXi 5.5
VMware vSphere ESXi 6.7

Resolution

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/SQL01.vmdk)
  2. Shut down all VMs, having access to the clustered VMDK to be extended. 
  3. Login to an ESXi host (SSH) with an 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. The unit type is not case-sensitive. vmkfstools interprets either k or K to mean kilobytes. If you do not specify the unit type, vmkfstools defaults to kilobytes. The newSize parameter defines the entire new size, not just the increment you add to the disk.
Example: vmkfstools --extendvirtualdisk 2048G /vmfs/volumes/shareddatastore/SQL1.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. VMware recommends using the vMotion operation or solutions listed in the Impact section of this KB article 
  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

Impact/Risks:

Online extension of a clustered disk is not supported

Note: Make sure to check this KB article regularly to get an update on the online extension procedure once available. 

Offline extension of a clustered (shared) VMDK is supported but require 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.

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

Powered by Wolken Software