Troubleshooting - Virtual Server Agent for VMware

Table of Contents

General

VMW0058: Error downloading virtual machine config file

Symptom

The backup job fails with the following error:

Error downloading virtual machine config file.

Resolution

  • Check the communication between the vCenter server and the host. If required, restart the management agent on the host. For more information, refer http://kb.vmware.com/kb/1003490.
  • If you have the 4.0 or 4.1 version of vCenter , ensure that the latest updates are installed on the vCenter. For more information, refer to http://kb.vmware.com/kb/1019286.

VMW0010: Error downloading or uploading virtual machine configuration file

Errors can occur during downloads or uploads of VMware virtual machine configuration files.

Symptom

The following errors can occur when transferring configuration files:

  • A backup job fails with one of the following errors:

    Error downloading virtual machine config file.

    Unable to download VMX files.

  • The following error message is displayed when trying to download a .vmx file from a datastore through vCenter:

    Error code: 91:29 - Unable to download the VMX file for virtual machine [...].

Cause

Issues can occur for several reasons:

  • Downloads or uploads can fail because of connectivity issues or high usage in vCenter.
  • The names of one or more virtual machines, datastores, or clusters included in a backup contain the following characters:

    + & @ % = # % * $ # ! \ / : * ? " < > | ; '

  • The management agent on the ESX host might need to be restarted.
  • For vCenter 4.0 or 4.1, updates might need to be installed.
  • Failure when trying to download a .vmx or .nvram file from a datastore through vCenter is an identified VMware vSphere VADP issue. The vCenter client datastore browser connected to vCenter server fails to download .vmx or .nvram files.

    For more information, see Using the vCenter Server 4.x/5.x datastore browser to download or copy a powered-on virtual machine's .vmx and .nvram files fails (1019286).

    There is an identified issue for VMware and Windows 2008 R2 Enterprise; the issue was resolved for other Windows operating systems in versions 4.0 U2 and 4.1.

Resolution

To resolve the issue, check the following items:

VMW0065: Unable to connect to Virtual Machine host

Symptom

Error Code 91:50: Unable to connect to Virtual Machine host [...] as user [...].

Cause

There is a change introduced by Microsoft for certificates.

From the vsbkp.log located on the server where the Virtual Server Agent is installed:

1724 a28 10/10 18:02:29 36080 CVMWareInfo::Connect() - Connecting to Url=[https://server.company.com/sdk] User=[domain\userid] 1724 1 10/10 18:02:41 36080 ### CVIWrapper::Connect --- Connection failed with [Connect failed System.Net.WebExceptionSystem.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebReque st request) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at VimApi.VimService.RetrieveServiceContent(ManagedObjectReference _this) at VISDKWrapper.SvcConnection.Connect(String url, String username, String password) at VISDKWrapper.CVIWrapper.Connect(String strUrl, String strUser, String strPwd)] 1724 a28 10/10 18:02:41 36080 CVMWareInfo::Connect() - VISDKCppBridge::Connect failed 1724 a28 10/10 18:02:41 36080 vsbkp::addVMsAsSimpanaClients() - Failed to connect to server [server.company.com domain\userid]

Resolution

Ensure that the proxy is able to communicate with the host and that the user account and password are correct.

Please review the following links:

For VMware please review:

VMW0036: Virtual machine client names are created with '_1' appended to the original client name

Symptom

When viewing virtual machines in the Client Computers list, you may see duplicated client names (for example, client_name and client_name_1).

Cause

If the instance GUID of the virtual machine changes, a duplicate virtual machine client is created with a numeric suffix (for example, client_name_1).

Resolution

For deployments using SnapProtect Service Pack 10 or later:

The QS_SetVMClient script merges backup history for duplicate virtual machine clients, and then deletes the duplicate virtual machine client. All subsequent jobs will be associated with the merged client. The script is available in the Base directory for SnapProtect software.

Perform the following steps to merge duplicate clients. Run the script for each set of duplicate clients.

  1. If you are not logged on to the CommServe computer, run the qlogin command.
  2. At a command prompt, navigate to the software installation path, log in to the CommServe machine, and run the following script:

    qoperation execscript -sn QS_SetVMClient -si @Client1='client_name_1' -si @Client2='client_name'

    If the client name contains spaces, you can run the QScript without explicit parameter names:

    qoperation execscript -sn QS_SetVMClient -si 'client name_1' -si 'client name'

    The duplicate clients are merged using the following criteria:

    • If both clients have a SnapProtect agent installed, the command fails.
    • If one of the clients has a SnapProtect agent installed, backup history is merged into the client with the SnapProtect agent.
    • If one of the clients has a numeric suffix in the client name (such as ‘_1’), backup history is merged into the client without the numeric suffix in its name.
    • If neither client has a SnapProtect agent installed or a numeric suffix in the client name, backup history is merged into the client with the latest backup.
    • If both clients have a numeric suffix in the client name, and do not have a SnapProtect agent installed, backup history is merged into the client with the latest backup.
  3. To log off the CommServe computer, run the qlogout command.
  4. Run an incremental backup and confirm that virtual machines are shown correctly in the Virtual Machine Status tab.

For deployments using SnapProtect Service Pack 9 or earlier:

  1. If you are not logged on to the CommServe computer, run the qlogin command.
  2. At a command prompt, navigate to the software installation path, log in to the CommServe machine, and run the following script:

    qoperation execscript -sn QS_SetVMClient -si @sourceClient='client_name_1' -si @destClient='client_name'

    where client_name is the original client name and client_name_1 is the duplicate.

    This script reassigns all backup history from client_name_1 to client_name. This enables you to view backup history, and to generate Job Summary Reports with the Include Protected VMs option enabled.

  3. To log off the CommServe computer, run the qlogout command.
  4. Remove the duplicate clients:
    1. In the CommCell Console, go to Control Panel | User Preferences.
    2. Click the Client Computer Filter tab.
    3. Select the Show Virtual Server Discovered Clients option.
    4. Delete the duplicate clients from the CommCell Browser.

VMW0037: BIOS UUIDs in vCloud Director are not unique when virtual machines are deployed from catalog templates

Symptoms

When using VMware vCloud Director, multiple virtual machines in vCenter Server have the same BIOS UUID.

This issue is seen when editing the .vmx file of a virtual machine. For example:

uuid.bios = "42 16 33 b9 01 76 de 61-c2 03 aa 2d 73 64 2c e3"

Cause

By default, all instances and virtual machines that are deployed from a given catalog vApp or template in vCloud Director are assigned the same BIOD UUID, because the bios.uuid property is preserved.

Resolution

To work around the issue after the virtual machine is created:

In vCloud Director 1.0:

  1. Remove the uuid.bios entry from the .vmx files of the virtual machine deployed from the specific catalog.
  2. Power on the virtual machines in vCenter Server. When the virtual machines without a BIOS UUID are powered on, a new unique uuid.bios entry is created.

    Alternatively, the virtual machines can be uniquely identified by their vCenter Server UUID. For example:

    vc.uuid = "50 16 fb 85 10 1a 96 f6-77 3a 0e 64 be 96 21 5b"

In vCloud Director 1.5 and vCloud Director 5.1:

You can now configure an option within the vCloud Database to correct this issue. The setting CloneBiosUuidOnVmCopy enables you to configure the following values:

  • 1 (true) - keep the existing BIOS UUID (default value).
  • 0 (false) - generate a new BIOS UUID.

To configure this option, the following SQL statement can be used to change the value:

update config set value = '0' where cat='vcloud' and name='backend.cloneBiosUuidOnVmCopy';

When the change has been configured, restart all cells in vCloud Director.

Additional Information

For more information, see the following articles:

VMW0038: Installer detected the driver already installed and is not able to recycle it.

Symptom

After an upgrade or service pack installation, configuring a Virtual Server Agent can produce the following error message.

Installer detected the driver already installed and is not able to recycle it.

  7968 8044 08/06 02:53:45 Driver Service vstor2-mntapi20-shared already exists

  7968 8044 08/06 02:53:46 Timeout waiting for service to stop(Start)

  7968 8044 08/06 02:53:46 Setup failed to start Vstor2 mntApi 2.0 Driver (shared) service.

Cause

In setups where many installs and uninstalls are performed, the installation might not be able to patch and recycle an installed file level driver. In this situation, rebooting the system is required.

It is also possible that the vstor utility included with the VDDK is not in the correct directory or is not being found.

Resolution

To resolve this issue:

  1. Verify that the vstor2-mntapi20-shared.sys file is in the Windows\System32\drivers\ directory.
  2. Check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\vstor2-mntapi20-shared and verify that the imagepath is set to Windows\System32\drivers\vstor2-mntapi20-shared.sys.
  3. From a command prompt, run the following commands to test whether services are starting and stopping correctly.

    Net stop vstor2-mntapi20-shared
    Net start vstor2-mntapi20-shared

  4. Reboot the system and resume the install.

VMW0026: Backup or restore fails when using SAN or HotAdd mode on non-English localized OS

Symptom

When in SAN or HotAdd mode, backups or restores fail even though the target volumes or LUNs are visible to the Virtual Server iDataAgent.  The VixDiskLib.log file contains entries "Cannot use advanced transport modes ..." and "Cannot create directory ..."

Cause

When in SAN or HotAdd mode, VMware VixDiskLib is not able to access a folder with a name that contains non-ASCII characters.

Resolution

To resolve this issue, create a local administrator account with a name that contains only ASCII characters, and change the logon account for the CommVault Communications Service to this local account. For detailed information about this issue, see Provisioning linked clones when using the French version of Windows 2008 64bit fails with the error: Selected parent VM is not accessible (1037379).

VMW0043: Backup or restore of a virtual machine fails: "[91:30] Unable to open the disk(s) for virtual machine [<VMName>]" or "The host is not licensed for this feature"

Symptom

  1. When using VDDK 5.1 or 5.5, backup or restore of a virtual machine fails.

    The Job Details dialog shows the following error:

    Error Code: [91:30]
    Description: Unable to open the disk(s) for virtual machine [<VMName>]. Please ensure the following: 1) the proxy is able to communicate with the ESX host and resolve the ESX host address 2) the correct transport mode has been selected 3) the disk types configured to the virtual machine are supported.
    Source: <proxy>, Process: vsbkp

    The following message is included in the vixdisklib.log file:

    Not licensed to use this function. Error 16064 at 2357.

  2. In some cases, after upgrading to SnapProtect Version 10, backups fail and the following message is included in the vsbkp.log file:

    15548 1ab0 08/31 20:38:03 289164 CVMDiskInfo::Dispatch_VixDiskLib_Open() - VixDiskLib_Open failed Err=3ec0 The host is not licensed for this feature

Cause

  1. The VDDK 5.1 or 5.5 APIs require that user permissions be applied at the vCenter level, as described in Restore or backup of virtual machines using VDDK API fails with the error: Not licensed to use this function. Error 16064 at 2357 (2063054).
  2. The error message "The host is not licensed for this feature" can be displayed when expired licenses for an older version of vCenter are still resident on a vCenter Server.

Resolution

  1. Assign user permissions for the vCenter entity using the vSphere Client or WebClient.

    For step-by-step instructions, see Add a Custom User with Limited Scope.

  2. To resolve out-of-date license issues, remove the expired licenses from the vCenter Server.

VMW0048: Cannot select and run operations on new virtual machines (Web Console)

Symptom

Immediately after creating a new virtual machine (VM) through VM provisioning on the Web Console, you cannot select the VM or run operations such as Start and Stop on the VM.

Resolution

To reset permissions, log out of the Web Console and then log in again. You can then select and run operations on the newly created virtual machine.

VMW0002: Virtual Machines residing on NFS storage become unresponsive during a snapshot removal operation

For more information, see KB Article VMW0002.

VMW0003: Error Code 23:10 Error while reading pipeline buffer from MediaAgent

For more information, see KB Article VMW0003.

VMW0006: No Virtual Machines were discovered for this subclient.

For more information, see KB Article VMW0006.

VMW0008: Protected virtual machines do not display in the Backup Job Summary report or in the Job Details Virtual Machine Status tab.

For more information, see KB Article VMW0008.

VMW0009: Increase in Backup Time after Fix for VMware CBT Error for expanded VMDKs (Fixed in Service Pack 9)

For more information, see KB Article VMW0009.

VMW0013: Backup or restore fails when a non-default port is specified for vCenter server

For more information, see KB Article VMW0013.

VMW0020: Logon to vCenter VM File Recovery Plug-In Fails From the CommVault Backups Tab

For more information, see KB Article VMW0020.

Backup

VMW0059: Version 4.0 vStorage option backs up full disk rather than data-only copy

Symptom

The Version 4.0 vStorage option backs up the full disk rather than a data-only copy.

Resolution

To back up a virtual machine as a data-only copy using vStorage option, upgrade the virtual machine to Version 7.0.

If a virtual machine has been cloned or migrated from another ESX Server, ensure that the virtual machine is rebooted prior to running your first backup.

VMW0060: File system metadata collection is not supported for volume [Volume2], VM [VM Name]

Symptom

The disk-level backup of a Windows virtual machine completes with the following error:

File system metadata collection is not supported for volume [Volume2], VM [VM Name]

Cause

The virtual machines may contain disks that are in uninitialized state.

Resolution

Initialize the disks before running a backup, in order to collect metadata enabling file level restores.

VMW0061: vCenter Server becomes unstable during backups

Symptom

When a backup operation is performed on a VMware vCenter client, new events and tasks are added to the vCenter database. If events and tasks cannot be added to the database, the vCenter Server becomes unstable during the backup operation.

Resolution

This is a VMware known issue. To resolve this, follow the instructions given in the VMware KB article or contact VMware Support.

VMW0062: consolidate helper-0 snapshot on vCenter Snapshot Manager

Symptom

The consolidate helper-0 snapshots are created on the vCenter Snapshot Manager and cannot be deleted after the backup job completes. The following error message appears if you try to delete the snapshot from vCenter Snapshot Manager:

Unable to access file <Filename> since it is locked.

Cause

This scenario can arise when the consolidate helper-0 snapshot is not committed to VMDK. This can be a VMware I/O issue.

Resolution

Adjust the virtual environment to resolve high I/O.  Restart the virtual machine to give the quiet time that is required to commit the snapshot.

If you are unable to delete the snapshot, contact VMware Support for assistance.

VMW0063: The Backup Size is larger during the full backup

Symptom

You may get the following message in the vsbkp log during the full backup:

Entire disk is allocated.

The size of the full backup increases when you get this message.

Resolution

Use the CheckChangeTracking utility to reset change tracking. Follow the commands given below:

CheckChangeTracking /host x-vcenter /user branzini /password Brown010 /vm iks-dc1.iks.it /disable
CheckChangeTracking /host x-vcenter /user branzini /password Brown010 /vm iks-dc1.iks.it /enable
CheckChangeTracking /host x-vcenter /user branzini /password Brown010 /vm iks-dc1.iks.it

It may be necessary to run this recycling of change tracking with the virtual machine powered down. It may also be necessary to power cycle the virtual machine after disabling the change tracking and again after enabling it.

VMW0064: Changed block tracking verification failed for disk [%s] on virtual machine [%s]

Symptom

For specific virtual machines in a subclient, an incremental or differential backup automatically converts into a full backup. The following event message is displayed:

Changed block tracking verification failed for disk [%s] on virtual machine [%s]; performing a full backup of the disk. The virtual machine may have been vMotioned since the last backup. If this issue persists it may be necessary to reset changed block tracking on the virtual machine.

Cause

The first backup for the virtual machine becomes a full backup after you migrate the virtual machine to a new datastore.

This is because Changed Block Tracking (CBT) is reset after a storage vMotion operation. For more information, refer to Change Block Tracking is reset after a storage vMotion operation in vSphere 5.x (2048201).

Resolution

All subsequent backups in the backup cycle are performed according to the schedule for the migrated virtual machines.

To reset CBT, see Reset Changed Block Tracking (CBT) for VMware backups.

VMW0067: Change tracking for Virtual Machine [VMservername] has reported an error

Symptom

When Change Block Tracking (CBT) is unavailable, backups revert to Cyclic Redundancy Check (CRC) to determine changed blocks. Since the Virtual Server iDataAgent needs to read the entire virtual machine disk, CRC incremental backups may take almost as long as full backups, even though the amount of data transferred and stored by an incremental backup is limited to the changed blocks within the virtual disk. 

Cause

If a virtual machine is cloned or migrated using cold migration, vmotion, or svmotion methods, CRC may become the default scan mechanism to protect the machine until CBT is reinstated. In each backup cycle, an attempt is made to enable and use CBT.

To check for this condition, review the vsbkp.log file or generate a Job Summary report.

  • For an installation of the Virtual Server Agent using the default installation path, the vsbkp.log file is located in the following folder:

    C:\Program Files\CommVault\Simpana\Log Files

    Look for log entries that indicate CRC is being used, as shown in the following example:

    vsbkp::getCRCFilePaths() - Using CRC from job id [...]
    vsbkp::initCRCTables() - Check sum table has been initialize successfully
    [C:\Program
    Files\CommVault\Simpana\iDataAgent\JobResults\CV_JobResults\iDataAgent\Virt
    ualServerAgent\2\164\vsidaCRC_[...]_(virtualserverguid)_(virtualservervmdkn
    ame.vmdk_VCB4)]
    vsbkp::initCRCTables() - Check sum table has been initialize successfully
    [C:\Program
    Files\CommVault\Simpana\iDataAgent\JobResults\CV_JobResults\iDataAgent\Virt
    ualServerAgent\2\164\vsidaCRC_[...]_(virtualserverguid)_(virtualservervmdkn
    ame.vmdk_VCB4)]
    vsbkp::crcExtentProcessor() - Done...

  • To generate a Job Summary report:
    1. On the CommCell Console, click Reports | Summary.
    2. In the Reports Selection window, highlight Job Summary.
    3. On the General tab, confirm that Backup is selected and Group By is set to Client.
    4. On the Computers tab, choose one of the following:
      • Click the Modify button under Computers to select individual clients or a group of virtual clients.
      • Click the Modify button under Agent Types to select the Virtual Server agent type. You do not have to change the Computers field section when using agent type.
    5. In the Selection tab's Advanced section, ensure that Include Protected VMs is selected.

      The Options and Time Range tabs do not have to be modified from the defaults, but can be depending on your reporting needs.

    6. Click Run.

If you do not see any CRC entries, check the vsbkp.log file for the following error:

QueryChangedDiskAreas --- Exception during QueryChangedDiskAreas Error caused by file /vmfs/volumes/VolumeGUID/GUID Instance (VMservername)/GUID Instance .vmdk

If necessary, contact VMware support for issues with the QueryChangedDiskAreas API.

Resolution

To take full advantage of VADP-based incremental backups, correct CBT issues on the problematic virtual machine as quickly as possible.

Ensure that the account used for VSA backups has the appropriate rights to enable change tracking in vCenter.

Review the following VMware links to verify and reset change tracking:

To make CBT available again, the virtual machine must be power cycled by logging in to the virtual machine, accessing the Guest OS, and shutting the machine down. Upon powering on the VMware client, CBT should be reactivated.

VMware states that a stun/unstun cycle is required for CBT to be reactivated on cloned or migrated virtual machines; but a power cycle is the only definitive method to ensure that CBT is reactivated.

VMW0068: Reset Changed Block Tracking (CBT) for VMware backups

Symptom

If CBT is disabled or not functioning properly, the size of incremental backups can be larger than expected. In some cases issues with CBT can cause a full backup to take longer and, when restoring a lazy zero thick provisioned disk, might result in the disk becoming eager zero thick provisioned.

You can verify CBT issues in the CommCell Console by checking the Status Details dialog for a virtual machine backup job. The CBT Status field shows Disabled.

To display the Status Details dialog, right-click a backup job and select View Job Details, then click the Virtual Machine Status tab and double-click a virtual machine entry.

The vsbkp.log file includes information such as the following:

4168 6 08/15 13:37:42 98795 ### QueryChangedDiskAreas --- Exception during QueryChangedDiskAreas Error caused by file /vmfs/volumes/50f432d3-ba380107-2b26-90b11c070562/VM/VM-000003.vmdk

Note: Backups for ESXi 4.x or ESXi 5.x can also increase because of a VMware error as described in Increase in Backup Time after Fix for VMware CBT Error for expanded VMDKs.

Cause

Changed Block Tracking (CBT) is a VMware feature that identifies blocks of data that have changed or are in use. It enables incremental backups to identify changes from the last previous backup, writing only changed or in-use blocks. If CBT is disabled or not functioning properly, an incremental backup might back up a complete virtual machine disk instead of only changed blocks, or revert to a full backup.

Resolution

You can disable CBT to restart change tracking for subsequent backups. This resolution is applicable for ESX hosts 4.0 or later, and for virtual machines at hardware version 7 and later.

Before resetting CBT, ensure that there are no snapshots on the virtual machine.

To reset CBT for a specific virtual machine, you must disable CBT, power cycle the virtual machine, and run a new backup. When the new backup is run, CBT is automatically re-enabled.

You can also reset CBT on multiple virtual machines using a PowerCLI script that resets CBT without requiring that virtual machines be powered down.

See the following articles to find detailed instructions for resetting CBT:

As a result of resetting CBT, the time required for backups increases because the first backup after resetting CBT backs up all blocks for any virtual machines on which CBT was reset. This change can also increase disk storage requirements for backups. The change does not affect scheduled backup cycles or data aging.

Increase in Backup Time after Fix for VMware CBT Error for expanded VMDKs

VMware ESXi 4.x or ESXi 5.x can return incorrect information about virtual machine disk sectors after a virtual machine disk (VMDK) is expanded beyond 128 GB or any doubling of 128 GB, and Changed Block Tracking (CBT) can produce unrecoverable backups. This is a flaw in VMware APIs used by backup software, and can lead to data loss if not addressed immediately. Any virtual machine is at risk if VMDKs have been expanded beyond 128 GB, 256 GB, 512 GB, 1024 GB, or any doubling of 128 GB. For example, the issue can occur after expanding a VMDK from 100 GB to 150 GB, or after expanding a VMDK from 150 GB to 300 GB. Any backup performed since the disk expansion can contain invalid data, including full backups. For more information, including patches for ESXi 5.x, see QueryChangedDiskAreas command returns incorrect sectors after extending virtual machine vmdk file with Change Block Tracking (CBT) enabled (2090639).

Important: The patches provided by VMware prevent this problem from re-occurring, but do not correct VMDKs that were extended prior to the patch.

SnapProtect  Version 11, or Version 10 Service Pack 9 and later, include a fix for this issue to prevent data loss. The SnapProtect software automatically detects expanded disks and resets CBT:

  1. The first backup job resets CBT for all virtual machines with a disk size greater than 128 GB.

    The CBT Status for the affected virtual machines is displayed as Reset.

  2. The software stores the size of each VMDK file in the .vmx file for each virtual machine.
  3. For any backup jobs going forward, the backup job compares the current size of each VMDK file with the size recorded in the .vmx file.
  4. If a disk has been expanded, the software resets CBT and backs up all blocks for the VMDKs attached to the virtual machine.

Note: With this fix, the time and disk space for backups is increased.

For older service packs for SnapProtect Version 10 and for SnapProtect Versions 9 or 8, you can use the CheckChangeTracking tool to reset CBT on specific affected virtual machines. For more information, see KB article VMW0009. The tool automatically re-enables CBT for the next backup job, which will back up all blocks for VMDKs even if an incremental backup is requested. CBT is also enabled for future incremental backups.

If you apply VMware patch ESXi600-201511001 to the VMware ESXi 6.0, 6.0 Update 1, or 6.0 Update1a hosts, SnapProtect detects the new ESXi build version and reverts back to using CBT. The next incremental backup will accurately protect any blocks that have changed since the last successful backup.

VMW0025: Failed Could not backup vCloud data for VM

Symptom

Backup job status can show "Completed with Errors," even though virtual machines in vCenter and vCloud are actually backed up.

The Virtual Machine Status tab in the job details shows:

Failed Could not backup vCloud data for VM

Job summary reports also display

[%VM%] Failed Could not backup vCloud data for VM

Cause

If a VMware instance is configured to access both vCenter and a vCloud director, backup jobs fail to collect vCloud information for virtual machines in the vCenter.

Resolution

To prevent this message from being generated, configure separate virtual clients for vCloud and vSphere in the CommCell.

VMW0039: You do not have access rights to this file

Symptom

When performing a backup in SAN mode, the following error is shown in the vsbkp.log and VixDisk.log:

You do not have access rights to this file

Cause

Windows 2008 R2 provided access for SAN mode transport when disks were offline; but in Windows 2012 disks must be online to be accessed. If the SAN policy for disks is Offline, disks are not accessible unless they are set to Online on the proxy.

Resolution

To enable backups using SAN transport on Windows 2012 servers, use one of the following approaches:

  • Set the disk to Online on the proxy.
  • Change the SAN policy to onlineall and set the SAN disk to read-only except for restores. You can use the diskpart utility to clear the read-only flag.

VMW0046: Metadata collection fails when backing up Windows 2012 R2 using Windows 2012 R2 proxy

Symptom

When backing up a Windows 2012 R2 virtual machine on a Windows 2012 R2  proxy, the backup completes without errors; but the following entry appears in the vsbkp.log file:

Guest size of VM [vm_name] is not available after LVM processing.

As a result, you cannot browse the files for the virtual machine.

Cause

Metadata collection for the virtual machine fails if the backup job is run with granular recovery enabled, but without quiescing the guest file system and applications.

Resolution

  1. From the CommCell Browser, go to Client Computers | virtualization_client | VMware | backup_set.
  2. Right-click the subclient and select Properties.
  3. Click the Backup Options tab.
  4. Select the Quiesce Guest File System and Applications option.
  5. Click OK.
  6. Re-run the backup.

VMW0052: Backup snapshot completes successfully but snapshot and disk files are not cleaned up

Symptom

When performing a backup of a virtual machine, the backup takes a long time to complete, but does complete successfully. After the backup, the snapshot and virtual machine disks remain on the datastore. 

The following message appears in the vsbkp.log file:

Exception while waiting for task task_ID - The operation has timed out

Cause

If a virtual machine is being backed up when a Storage vMotion request is made to migrate the virtual machine to another datastore, or if a Storage vMotion is in progress when a backup request arrives, the backup is delayed. When both tasks are completed, the snapshot and virtual machine disks remain on the original datastore.

This issue can occur when using vCenter Server 5.1, vCenter Server 5.1 Update 1, or vCenter Server 5.5 versions earlier than 5.5 Update 2, with virtual machines residing on datastores that are part of a Storage Distributed Resource Scheduler (SDRS) cluster. More detailed information about the issue is available at An orphaned VMDK is created when a system or user generated vSphere Storage vMotion task is performed during virtual machine backup (2055943).

The issue is resolved in vCenter Server 5.5 Update 2 and higher.

Resolution

Use the bDisableVMotionDuringBackup setting to disable Storage vMotion during backups:

  1. From the CommCell Browser, go to Client Computers > virtualization_client.
  2. Right-click the client and select Properties.
  3. On the General tab of the Client Computer Properties dialog, click Advanced.
  4. On the Advanced Client Properties dialog, click the Additional Settings tab.
  5. Click Add.
  6. Add the following entry:
    • Name: bDisableVMotionDuringBackup
    • Category: Virtual Server
    • Type: Boolean
    • Value: true (to disable Storage vMotion during backups)
  7. Click OK to save the additional setting.
  8. Click OK twice more to save the advanced client properties and the client properties.

When bDisableVMotionDuringBackup is set to true, Storage vMotion is disabled while a backup is in progress. The Storage vMotion request can be resubmitted when the backup completes or if the backup job is killed.

If a migration is already in progress, a backup request goes to a pending state until the Storage vMotion operation completes. For a backup job that includes multiple VMs, a VM that is being migrated is skipped and the other VMs are processed first. 

This additional setting does not disable host vMotion.

VMW0004: Error Code 91:30 Unable to open the disk(s) for Virtual Machine.

For more information, see KB Article VMW0004.

VMW0005: VixDiskLibVim.dll not loaded during initialization.

For more information, see KB Article VMW0005.

VMW0012: Secondary SCSI disk assigned to VM becomes inaccessible after a backup

For more information, see KB Article VMW0012.

VMW0015: Backups with VMware VixDiskLib 6.0 fail with host certificate error

For more information, see KB Article VMW0015.

VMW0018: Backup in SAN transport mode fails for virtual machine with virtual RDMs: Timeout waiting for VixDiskLibThread operation, possible VDDK Deadlock encountered

For more information, see KB Article VMW0018.

VMW0023: A client with name [client_name] already exists but was previously configured with the host name [fully_qualified_hostname] at CVD Port [0].

For more information, see KB Article VMW0023.

VMW0024: Backup fails with VDDK 6.0 when proxy has IPv6 enabled

For more information, see KB Article VMW0024.

Restore

VMW0069: There are no items to show in this view

Symptom

Browse operation yields a message stating "There are no items to show in this view."

Cause

The MediaAgent selected in the Browse Options dialog box may be installed on a Unix computer. Unix-based MediaAgents are not supported for direct restores.

Resolution

To resolve this issue, select a Windows-based MediaAgent.

VMW0071: File-level restores complete with errors (SymLink file)

Symptom

When performing a file-level restore that includes a symbolic link file, the restore completes with errors.

Cause

File-level restores are not supported for symbolic link files when using the Enable Granular Recovery option for backups of Linux VMs. .

Resolution

Use the Live File Recovery method to restore a symbolic link file. See Live File Recovery for more details.

To enable Live File Recovery even when the Enable Granular Recovery option is selected, you can configure the nEnforceLivebrowse additional setting on the Virtual Server Agent (VSA) proxy.

VMW0072: Restore fails (SAN transport mode with proxy on Windows Server 2008)

Symptom

A restore fails when using SAN transport mode with a proxy on Windows Server 2008.

Resolution

Clear the read-only mode by performing the following steps:

  1. Open a command prompt.
  2. Run diskpart.
  3. List and select the SAN shared disks.
  4. Type attribute disk clear readonly.

For example:

C:\Users\Administrator> diskpart

Microsoft DiskPart version 6.0.6002 Copyright (C) 1999-2007 Microsoft Corporation. On computer: COMPUTERNAME

DISKPART> list disk

Disk ### Status Size Free Dyn Gpt -------- ---------- ------- ------- --- --- Disk 0 Online 64 GB 0 B Disk 1 Offline 78 GB 2048 KB <--- The share disk is usually reported as Offline

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> detail disk

ROCKET IMAGEFILE SCSI Disk Device Disk ID: 02872505 Type : iSCSI Bus : 0 Target : 0 LUN ID : 0 Read-only : Yes <--- Make sure of read-only mode Boot Disk : No Pagefile Disk : No Hibernation File Disk : No Crashdump Disk : No

There are no volumes.

DISKPART> attribute disk clear readonly

Disk attributes cleared successfully.

VMW0073: File-level restores introduce a different file size and checksum

Symptom

If a file-level restore is performed from a backup that used VCB mounter, the restored files may have a different size and a checksum.

Resolution

  1. From the Backup Set Properties dialog box, switch the backup mode to vStorage.
  2. Re-run the backup.
  3. Restore the files again.

VMW0074: SAN mode restores slow down and display “clear lazy zero” or "Allocate blocks"

Symptom

When attempting restoration of a VMware virtual machine from disk backup in SAN environments, the restore job slows down with the events in VMware client GUI displaying “clear lazy zero” or "Allocate blocks".  For restores that specify thin or auto disk provisioning, this results in the performance of restores with SAN transport mode being slower than those using NBD transport mode.

Cause

Blocks for thick provisioned disks are allocated when the disks are created; blocks for thin provisioned disks are allocated as needed during the restore (using calls to disk manager APIs). If thin provisioning is chosen for the restore, the restore operation takes longer, regardless of the original disk provisioning format. The performance impact is less if NBD transport mode is used, and if a disk is recovered directly to the ESX host rather than through the vCenter.  Using thick lazy zero disk formatting places an additional load on the host, requiring the host to zero blocks before writing to disk and slowing the restore process.

Resolution

To resolve this issue, perform one of the following:

  • Restore using NBD, which may be faster depending on the network connection between the host and proxy.
  • Select SAN transport and force the disk type to Thick Eager Zero. This causes a thick eager zero disk to be created on restore. All blocks are zeroed before restoring data, the writing of restored data is quicker, and the need for negotiation between the host and proxy is eliminated.
  • Restore directly to an ESX server instead of vCenter.

VMW0075: While restoring VM as template, registering template VM fails

Symptom

When attempting restoration of a VMware virtual machine as a template virtual machine, registering the template virtual machine fails.

Resolution

Manually register the template virtual machine if the host is present under the folder.

VMW0076: Recovering data associated with deleted clients and storage policies

Symptom

In a disaster recovery scenario, use the following procedure to recover data associated with the following entities:

  • Deleted storage policy
  • Deleted client, agent, backup set or instance

Before You Begin

This procedure can be performed when the following are available:

  • You have a Disaster Recovery Backup that contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup that was performed before deleting the storage policy.
  • Media containing the data you wish to recover is available and not overwritten.
  • If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
    • IP Address Change license
    • CommCell Migration license

    See License Administration for more details.

  • A standby computer, which is used temporarily to build a CommServe.

Resolution

Recovering Deleted Data
  1. Locate the latest Disaster Recovery Backup that contains the information on the entity (storage policy, client, agent, backup set or instance) you are trying to restore.
    • Check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
    • If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
    • If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
      • If you regularly run and have copies of the Data on Media and Aging Forecast report, you can check them to see if the appropriate media is available.
      • If you do not have an appropriate report, and know the media that contains the DR Backup, catalog the media using Media Explorer. Once the cataloging process is completed, details of the data available in the media are displayed.
  2. On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
  3. Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See CommServe Disaster Recovery Tool for step-by-step instructions.)
  4. Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
  5. If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
  6. Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.

    When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.

  7. Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.

    This brings back the entity in the CommServe database and the entity is visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)

  8. You can now browse and restore the data from the appropriate entity.

    As a precaution, mark media (tape media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.

VMW0077: Floppy and CD drive of a virtual machine connect to a different datastore after an out-of-place restore

Symptom

You are performing an out-of-place restore of a virtual machine and you specify a different datastore during the restore. After the restore completes, the floppy and CD drive of the virtual machine still connect to the original datastore.

Resolution

  1. Log in to the vCenter using vSphere client.
  2. Edit settings of the virtual machine.
  3. Specify the new datastore for the floppy and CD drive in the Virtual Machine Properties dialog box.

VMW0078: Volume name not found in the restore source path

Symptom

While restoring files and folders from a virtual machine, the restore fails with the following error:

Volume name not found in the restore source path <source_path>, this is a volume restore.

Cause

This error appears when you have selected all files and folders in a virtual machine for the restore.

A file-level restore of the entire contents of a VM is not supported.

Resolution

If you want to restore the entire contents of a VM, perform a full VM restore.

VMW0022: Virtual Machine is restored successfully but not added to the correct resource pool

Symptom

The virtual machine is not added to the correct resource pool after the restore.

Cause

This error appears in the following scenarios:

  • You have performed the backup of the virtual machine using an ESX Server, but the ESX Server is managed by a vCenter.
  • You are restoring the virtual machine to an ESX Server, but the ESX Server is managed by a vCenter.

Resolution

If the ESX Server is managed by a vCenter, do not configure the instance for the ESX server. Configure an instance for the vCenter, then perform the backup.

Similarly, before performing the restore, ensure that the instance is configured for the vCenter and not for the ESX server.

VMW0079: Restoring disks to an existing virtual machine

Symptom

When restoring a dynamic disk to an existing virtual machine (target virtual machine), the dynamic disk is restored as a foreign disk.

Resolution

After the restore completes, perform the following steps on the target virtual machine:

  1. Open the Computer Management Console on the virtual machine.
  2. Click Disk Management in the left pane.

    All the disks are displayed in the right pane.

  3. Right click the foreign disk and click Import Foreign Disk...

Drive Letters are not assigned automatically

When you restore a disk to a Windows 2003 virtual machine, the drive letters are not assigned automatically to the partitions on the disk. After the restore completes, assign the drive letters manually.

If you restore a disk to its original location on the Windows 2003 virtual machine, the drive letters are assigned automatically.

Volumes are not mounted automatically

When you restore disks of a Linux virtual machine, the volumes are not mounted automatically. After the restore completes, mount the volumes manually.

VMW0080: The LAN connection is not retained after the restore of a virtual machine

Symptom

When you restore a full virtual machine, the LAN connection is not retained.

Cause

The LAN configuration of the virtual machine has changed before the restore.

Resolution

Configure the ReRegisterVMAfterRestore additional setting on the proxy computer where the Virtual Server Agent is installed and set the value to 1. All virtual machines restored using the proxy computer will get registered twice, and the LAN connection will be restored successfully.

VMW0040: Failed to start the virtual machine

Symptom

When a virtual machine has been replicated in vSphere and backed up, and a full VM restore is performed from the backup, the following status message might be displayed in vCenter:

Failed to start the virtual machine.

Cause

If the Power ON Virtual Machine After Restore option is selected when performing a full VM restore, VMware attempts to power on the restored VM before disabling replication.

Resolution

Clear the Power ON Virtual Machine After Restore option when initiating the restore. VMware automatically disables replication when the restore is completed, and you can power on the virtual machine manually.

VMW0041: Cannot restore files from a Windows 2012 virtual machine using deduplication

Symptom

When restoring from a backup of a Windows 2012 virtual machine that has deduplication enabled, a file-level restore completes successfully but only creates stub files.

Cause

Windows 2012 provides its own native deduplication capability. If a Windows 2012 VM has native deduplication enabled, file-level restores from backups are not supported because the backed up files are only stored as stubs.

Resolution

Use one of the following methods to restore files:

  • When using a Virtual Server Agent proxy on Windows 2012 or later with Windows deduplication enabled, use Live File Recovery to restore files that have been dehydrated by Windows deduplication. A MediaAgent running Windows 2012 or later, with the Virtual Server Agent installed and with the Windows deduplication role enabled, must be used as the VSA proxy when restoring the dehydrated files.
  • To retrieve files from a backup for a Windows 2012 VM using deduplication, use the Virtual Machine files option on the Restore Options dialog to restore the virtual machine disk that contains the files.
  • Install a local file system agent on the Windows 2012 VM to enable file-level backups. As a result, the data is backed up in a rehydrated state so that you can restore file-level data from that backup.

VMW0050: In-place CBT restore to vCloud fails: "Cannot import VM <VMName> (<VMmoref>) since it is already managed by vCloud."

Symptom

If CBT restores are enabled, an in-place restore of the full virtual machine (VM) that is managed by vCloud is successful; but a failure is indicated when trying to import the VM into vApp.

The restore is shown as successful in the Job Details dialog in the CommCell Console; but the following error message appears in logs:

Cannot import VM <VMName> (<VMmoref>) since it is already managed by vCloud.

The virtual machine is not powered on automatically.

Cause

During a full restore that does not use CBT, the virtual machine is removed from vCloud, then the restored VM Is recreated and imported into the vCloud.

During a CBT full restore, the original VM is not removed, and only changed blocks for the virtual machine data are restored. Because the original VM is already present in vCloud, the attempt to import the restored VM fails.

Resolution

After the virtual machine is restored, you can power on the VM manually and ignore the logged errors.

To prevent this error for CBT restores, you can uncheck the vCloud option on the Restore Options for All Selected Items dialog. (The vCloud option only appears if vCloud credentials are provided in the VMware instance properties.)

VMW0051: Live recovery for virtual machines fails with error [72:106]: "There are too many virtual machines exported."

Symptom

When you use the Restore Virtual Machine using vMotion option to recover a virtual machine, the restore fails with the following error message:

Error Code: [72:106]
Description: There are too many virtual machines exported.
Please wait for some virtual machines to be migrated or unregistered; or perform a traditional full virtual machine restore.

Cause

This issue occurs when the export limit for the 3DFS cache is exceeded. This can occur when previous restore jobs do not complete successfully and unmount the datastores for virtual machines being recovered.

Resolution

To resolve this issue, clear the 3DFS cache by performing the following steps:

  1. Log in to the machine hosting the 3DFS service (the File Recovery Enabler for Linux).
  2. Enter the following command to stop the 3DFS service:

    killall –SIGINT 3dnfsd

    The killall command sends SIGINT to the 3dnfsd process. The 3dnfsd process captures this signal and exits gracefully.

  3. Enter the following commands to clear the cache:

    cd  /opt/3dfs 
    mv 3dfs 3dfs.old
    rm –rf 3dfs.old &

VMW0053: After upgrade, CBT restore fails with error "CBT file ... is not present." or VSA discovery fails

Issues with client IDs can occur after upgrading clients created in SnapProtect Version 9.0 or upgraded from 9.0 to  SnapProtect Version 10.0.

Symptom

  1. When performing a restore of a virtual machine with the Changed Block Tracking (CBT) option enabled, the restore cannot use CBT and reverts to a classic restore.

    The vsrst.log file shows the following messages:

    CBT file ... is not present. Can't continue in CBT Mode. Reversing to normal mode

    CBT restore is not possible, falling back to the old way

  2. Discovery can fail if a fault tolerance guest virtual machine (VM) is discovered, even when the virtual machine is not defined as content on the subclient for a backup job.

Cause

By default, clients created in SnapProtect Version 9.0 or upgraded from 9.0 to  SnapProtect Version 10.0 use BIOS UUIDs. Virtualization clients created in SnapProtect Version 10.0 use instance UUIDs.

  1. By default, upgraded clients continue to use BIOS UUIDs; but CBT restores use instance UUIDs to identify changed blocks from the last backup. Because the UUIDs do not match, the restore reverts to a classic restore.
  2. If BIOS UUIDs are used, the BIOS UUIDs must be unique across all clients. For backup operations, discovery fails if there are duplicate UUIDs.

Resolution

SnapProtect Version 10.0 virtualization clients use instance UUIDs. After an upgrade, you can create a virtualization client for the vCenter, ensure that all virtual machines are covered by a subclient, and run full backups. Going forward, all backup and restore operations for the virtualization client will use instance UUIDs, and you will not encounter issues with BIOS UUIDs.

To resolve BIOS UUID issues for jobs from older clients created in SnapProtect Version 9.0, you can run the following stored procedure on the CommServe database (for Windows x64 systems only). The script enables or disables the use of VM Instance UUIDs to identify a virtual machine.

qoperation execscript -sn SetUseInstanceGUID -si "client_name" -si "instance_name" -si [0/1]

The script resets the Instance property UseInstanceGUID to the value supplied. All parameters are required; the last parameter can be 0 (Unset) or 1 (Set). When the property is set to 0, the client behaves in 9.0 style, using BIOS UUIDs to identify virtual machines.

To resolve BIOS UUID issues, set client instances to use instance UUIDs:

  1. To verify the property change, run the following query before and after running the script.
    1. To find the instance ID:

      USE CommServ

      select distinct App.instance,App.clientId,C.name,I.name from APP_Client C,APP_InstanceName I,App_Application App where C.name = '<ClientName>'
      and I.name = '<InstanceName>' and App.clientId = C.id and App.instance = I.id

      The first column in the results from the above query gives the instance ID.

    2. To fetch the value of the property:

      select * from APP_INSTANCEPROP where componentNameId = @instanceId AND attrName = 'Use VM Instance GUID' and modified=0

  2. Log in to the CommServe host using qlogin.
  3. Run the script for any clients and instances that should use the VM instance UUID instead of the BIOS UUID.

    qoperation execscript -sn SetUseInstanceGUID -si "client_name" -si "instance_name" -si 1

    For multiple instances, you can run the script separately for each instance, or you can run the following script to set all instances to use the VM instance UUID instead of the BIOS UUID:

    qoperation execscript -sn SetUseInstanceGUID -si "ALL" -si "ALL" -si 1

  4. Run the following query to verify that the Instance Property in App_InstanceProp is changed to the value given in the third parameter.

    USE CommServ

    select distinct App.instance,App.clientId,C.name,I.name from APP_Client C,APP_InstanceName I,App_Application App where C.name = '<ClientName>'
    and I.name = '<InstanceName>' and App.clientId = C.id and App.instance = I.id

    The first backup job after executing the script will run as a full backup.

  5. Run a full backup job.
  6. Perform an in-place restore to verify that the restore uses CBT.

Additional Resources

Restore with Changed Block Tracking (CBT)

VMW0054: Disk letter is not shown when browsing data for backup that used disk filtering

Symptom

After performing a backup with disk filtering, a browse operation shows some disks with letter labels and other disks with volume labels.

The vsbkp.log file may display messages such as the following:

The disk is dynamic disk. Parse and add LDM Partitions for this disk.
...
Named the volume as <letter>:.
...
Volume <letter>: does not have all disks required
...
The disk is not dynamic disk. Parse and add DOS Partitions for this disk.
...
Named the volume as Volume<n>.
...
Dumping volume information for [Volume<n>]

Cause

If a backup filters the disk that contains the operating system, the backup cannot load the registry hive and map volumes to drive letters on basic disks. Instead, volumes are named using sequential numbers.

For dynamic disks, the backup can get drive letters from the Logical Disk Manager (LDM) database without requiring the registry.

Resolution

If you need to preserve disk letters for basic disks, include the operating system disk in your backup.

VMW0057: NFS datastores not unmounted after live recovery for virtual machines

Symptom

After you use the Live Recovery for Virtual Machines feature, NFS datastores might not be unmounted after the live recovery operation is completed.

Resolution

In most cases, NFS datastores are unmounted properly when the vCenter is at Version 5 Update 2 or higher.

VMW0011: Error Code: [19:1950] Unable to mount the media as a datastore. Please check the communication between the 3dfs server and the ESX host.

For more information, see KB Article VMW0011.

VMW0016: Browse for Live Mount or Live Recovery fails because of lack of space in Job Results folder

For more information, see KB Article VMW0016.

VMW0017: Live Browse fails to open VM disks from vCenter or ESX server

For more information, see KB Article VMW0017.

VMW0019: Restore operation keeps running and datastore is not released: Did not find mount context for shareId

For more information, see KB Article VMW0019.

VMW0021: An error occurred while taking a snapshot: The filename is too long.

For more information, see KB Article VMW0021.