Version 6.0.1 now supports VMDK storage with DRS (Distributed Resource Scheduler) and vMotion, via the VMwareDisks and VMNSdg resources. (See Symantec High Availability Console for VMware)
The virtual disks for VM’s in a VMware environment supporting DRS and vMotion are not on a “shared bus” and therefore cannot be presented to all nodes in the cluster at once. Instead, the ESX server manages which VM can access the virtual disks. Changing which node “sees” the disk is accomplished via the VMwareDisks agent. If Volume Manager is used to manage the disks and volumes in a Volume Manger diskgroup, the VMNSdg resource is used instead of the standard VMDg resource, and standard MountV resources are used to mount the volumes.
When the VMwareDisks resource is configured, two bits of information are needed (See page 46 in the Bundled Agents document referenced below):
- ESXDetails: The IP address and login information for the list of ESX servers where the VM can reside, and
- DiskPaths: the list of paths to the virtual disks, which includes the name of the datastore (referred to as either “data store” or “datastore” in docs), the path on the datastore to the virtual disk, and the SCSI virtual device name. These values can be found from the vSphere interface by right-click on the VM in the left column, then pick the virtual disk in the edit dialog window.
Be sure to verify that you have the correct username and password for the ESX server, the VMwareDisks resource will simply return a “status unknown” if it isn’t correct, because the agent will not be able to log into the ESX server. Also, the password must be encrypted first before plugging it into the ESXDetails attribute in the VMwareDisks resource. Encryption is accomplished via executing a “vcsencrypt -agent” command in a Command Prompt window — the command will then prompt twice for the password, and return the encrypted password.
One of the features of the VMwareDisks resource is that it can handle dynamically changing the datastore for a given virtual disk (this is mentioned in the docs somewhere, but sorry I couldn’t find the reference for this article). The agent seems to find an ESX fingerprint for the virtual disk, and adds that to the VCS configuration. Examining the DiskPaths attribute after dynamically changing the datastore for a virtual disk will reveal that a long number has magically been added to the attribute for that virtual disk. No interaction on the part of the VCS administrator is needed to handle the datastore change – it’s all done “under the covers.”
See Symantec High Availability Solutions Guide for VMware, the Symantec High Availability Solutions Guide for Custom Application in VMware Environment, the Symantec High Availability Console Installation and Upgrade Guide, and Veritas Cluster Server Bundled Agents Reference Guide which can be found at https://sort.symantec.com/documents/doc_details/sfha/6.0.1/Windows/ProductGuides/ or go to sort.symantec.com, hover over “Downloads” and pick Documents, then select Veritas Storage Foundation and High Availabililty in the left selection box, and Windows in the middle selection box, and finally the “Product Guides” link for the appropriate version under the Windows column.
One Response