Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Troubleshooting VMware

This section provides guidelines for how to troubleshoot issues that might occur when using VMware.

VM MAC Conflict alarm when restoring cloned VM

Problem:

When restoring a cloned VM with the original VM present, vSphere Client may display the following critical alarm:

VM MAC Conflict

Solution:

The alarm can be ignored.

When the VM is restored, vSphere may detect a transient MAC conflict between the original and cloned VM before a new MAC address is automatically assigned to the clone.

Restoring VMs to original location fails with 'Restore failed to recover all the required VMs'

Problem:

The following messages are displayed in the logs when attempting to restore a VM to its original location:

Handler 'VMwareESX' call failed: Restore failed to recover all the required VMs

Restore failed to recover all the required VMs *** Attachment count: 1 ***

The attachment identifies the VMDK file associated with the VM that failed to restore.

Cause:

If a VM only resides on one datastore, Protector will not consolidate that VMs snapshots when it is restored (thus all its intermediate snapshots are preserved). This can cause a restore failure under certain conditions.

Solution:

Try selecting Clone instead of Original location when specifying the restore location in Protector. This will cause Protector to consolidate the VM's snapshots.

SAN transport message logged for non-SAN datastore

Problem:

The following message is logged when performing an incremental backup of a datastore that is not accessible using SAN Transport Mode:

Disk 'Virtual Hard disk <n> Data.vmdk' snapshot opened with 'san' transport mode

Solution:

This log message may be generated if you are using a virtual machine as the proxy node. For some versions of vCenter and ESXi, the incorrect transfer mode is reported to Protector. Either ignore the log message or use a physical proxy node to prevent the message.

SRM recovery fails with 'Cannot process consistency group [...] expected [...] role target'

Problem:

The following message is displayed by SRM when performing a test or real fail-over or fail-back recovery operation:

Failed to sync data on replica devices.

Cause:

Cannot process consistency group '{<CTG ID>}' with role 'promotedTarget' when expected consistency group with role 'target'

Cause:

SRM checks that replications are in the expected state before performing the recovery operation. This message may be generated if the continuous TrueCopy replication between the production and recovery site has been paused or swapped outside of SRM.

SRM replications must not be paused or swapped outside of SRM.

Solution:

In SRM, perform Discover Devices, then check the Status of the datastores. If the status is Failover complete, check if the corresponding TC replication in Protector is in the paused state and un-pause it if required.

Datastores status should be either Outgoing Replication or Incoming Replication before starting a failover.

vRO Ad Hoc Backup fails with '[...] Tag 'HDID/Protector Ad Hoc' already in use [...]'

Problem:

The following message is logged in vRO when running the 'Ad Hoc Backup' workflow:

(com.hitachivantara.protector.backup/performAdHocBackupOf) Error in (Dynamic Script Module name : performAdHocBackupOf#17)

HdidPluginException[Cannot perform Ad Hoc Backup, Tag 'HDID/Protector Ad Hoc' already in use. Other VM(s) may be backed up because the following objects are tagged: [Name: , Type: VirtualMachine, Id: vm-4398]

Please try again later or contact your system administrator if the failure persists.

Cause:

If you manually assign the 'HDID/Protector Ad Hoc' tag to a VM and subsequently delete that VM, then run the 'Ad Hoc Backup' workflow on any other VM, the operation will fail with the above error.

Solution:

Delete the 'HDID/Protector Ad Hoc' tag from vSphere then recreate it.

The 'Ad Hoc' tag should never be manually assigned. It should only be automatically assigned by Protector vRO workflow scripts.

vRO Ad Hoc Backup fails with 'Cause: VMwareException[Tagging cardinality violation]'

Problem:

The following message is logged in vRO when running the 'Ad Hoc Backup' workflow:

(com.hitachivantara.protector.backup/performAdHocBackupOf) Error in (Dynamic Script Module
        name : performAdHocBackupOf#9) MasterException[failed to associate Tag [name: Protector Ad
        Hoc, Id: urn:vmomi:InventoryServiceTag:...] to VM [vm-...],
 Cause:
        VMwareException[Tagging cardinality violation] ]

Cause:

For the vRO Ad Hoc Backup Workflow to work, it needs to tag the desired VM with the ‘HDID/Protector Ad Hoc’ tag.

The error ‘Tagging cardinality violation’ indicates that the VM already has a tag that belongs to the same tag category as the 'HDID/Protector Ad Hoc' tag. And that this tag category is restricted to “Tags Per Object: One tag”. As such only one tag from the category can be assigned to the desired VM.

Solution:

Move the 'HDID/Protector Ad Hoc' tag into its own category.

If you cannot create a new category, then alter the category tag cardinality such that “Tags Per Object” is “Many tags”. (See screenshot below)

Creating a new Category for vRO tags
GUID-403212AD-5A30-43BF-960E-21F3BA9F36A2-low.png

 

  • Was this article helpful?