Preventive Service Planning
Abstract
This document details the Known Issues & Limitations for IBM® Spectrum Protect for Virtual Environments: Data Protection for VMware V8.1.
Content
This document is divided in to linked sections for ease of navigation. Use the links below to jump to the section of the document that you require.
Content
- Data Protection for VMware vSphere & GUI issues and limitations
- Data Mover issues and limitations
- Mount Proxy
- Self-service File Restore Issues and Limitations
- VVol related Issues and Limitations
- Application Protection Issues and Limitations
- Recovery Agent Issues and Limitations
- Installation Issues and Limitations
Note: Known issues and limitations for file restore operations that are run from the IBM Spectrum Protect file restore interface are documented in the following technote: File Restore Known Issues and Limitations.
Data Protection for VMware vSphere & GUI Issues and Limitations
Version of IBM Spectrum Protect Backup Server is displayed incorrectly (internal reference #199908)
Problem: In the vCenter IBM Spectrum Protect configuration area on the Backup Servers tab, there is a table of associated backup servers and their versions. If a IBM Spectrum Protect backup server is at level 8.1.10 or 8.1.11, then it will show up as level 8.1.0 or 8.1.1 respectively.
Workaround: None.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.8. Solved with V8.1.12.
Datacenter Association gives incorrect error message (internal reference #195416)
Problem: In the Data Protection for VMware plug-in, there is an option to add a datacenter. When a data center is added to the non-primary backup server and there is no data mover associated with that backup server, then the datacenter wizard will return with an error message:
"GVM50002E AN error occurred: Log out and login again. If the problem persists, contact your administrator for assistance"
Once closing this error panel, the newly associated data center will show up in the table correctly. The error is incorrect and the association has been made correctly with the backup server.
Workaround: No workaround is needed, since no error actually occurred. Just close the error dialog and proceed with configuration.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.10. Solved with V8.1.11.
Double Byte languages will not correctly show error message log (internal reference #195595)
Problem: The panel to display log files in the vSphere plug-in will show the logs with garbled text in double byte languages, such as Chinese, Japanese and Korean.
Workaround: The user can download the error logs from the same panel or logon to the machine that contains the logs and view them from there.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.10.
Data Center node names greater than 63 characters will cause the backups not to show as restore points. (internal reference #171038)
Problem: Data Center Node names greater than 63 characters will cause the backups not to show as restore points in the IBM Spectrum Protect User Interface for VMware (VeGui). The documented maximum node name length is 64 characters.
The Data Mover node name is not affected by this limitation and can therefore be 64 characters in length. This can also demonstrated on the command line by setting the Data Center node as the Nodename in the option file and running:
dsmc q vm * -optfile=dsm.opt
The list of backups should include all of the data mover backups that have a proxy association with the Data Center node.
Workaround: Insure that your Data Center node names are not greater then 63 characters.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.4. Solved with V8.1.7.
Error table does not show register and grant proxy node tasks (internal reference #171009)
Problem: Adding a remote data mover is a two part process. First the new data mover node is registered and given proxy access. Second, the remote data mover host is configured (create option files, create services and start services). The first part must succeed in order to proceed to the second part.
If an error occurs in the second part, the plug-in will display a table of tasks showing the status for each one. This table ommits the registration of the node and the grant proxy tasks performed in part one.
This notice is to remind a user that encounters an error that a node was registered on the IBM Spectrum Protect server.
Workaround: You can use the remove data mover button from the data movers panel which unregisters the IBM Spectrum Protect node. Resolve the issue which caused the error and re-run the add data mover request from the plug-in using the same node name.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.6. Solved with V8.1.7.
vCenter 6.7 HTML Logout Causes GVM 5002E "Data Service clientId" Error (internal reference #167809)
Problem: When a user logs out of a 6.7 HTML vSphere client while on an IBM Spectrum Protect plug-in page, they will get a GVM 5002E error when they log back in. The error message will state:
Data Service invoked a HttpSession without clientId, but a clientId is required. Log out and in again, if the problem persists, contact your administrator for assistance.
This issue is only on a 6.7 vCenter in vSphere HTML mode. Flash mode does not display this behavior. Logging in and out again will not fix the issue.
Workaround: This is a VMware issue that has the following Knowledge Based article associated with it: https://kb.vmware.com/s/article/55899. Despite the workaround listed in the above article, internal testing has confirmed that opening a new browser window or even restarting the browser is insufficient. The user needs to clear the cache on the browser or open a 'private browsing window' that will not reference the cache.
Affected platforms: Linux and Windows.
Limitation: Since V8.1.6. Vendor issue.
Missing restore status in vSphere web client (internal reference #152436)
Problem: When starting a restore from the IBM Spectrum Protect vSphere web client, if an error occurs very early in the restore process there may be no indication in the web client Tasks table. This can happen, for example, if an Instant Access restore is attempted using a read only datastore. To view the error in cases like this, look in the following log file:
C:\Program Files (x86)\Common Files\Tivoli\TDPVMware\VMwarePlugin\logs\vmcli
Workaround: None.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Solved with v8.1.7, see APAR IT23491.
IBM Spectrum Protect vSphere Client plug-in does not appear in vSphere 5.5 (internal reference #148664)
Problem: Version 8.1.2 of the IBM Spectrum Protect vSphere Client plug-in does not support vSphere 5.5. Please use plug-in version 8.1.0 or earlier with vSphere 5.5.
Workaround: None.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Solved with v8.1.4, see APAR IT21990.
The folder objects in vSphere Web Client do not have a Configure Tab in vSphere 6.5.0 (internal reference #134755)
Problem: The configure tab for folder objects in the vSphere Web client is not appearing in the VMware vSphere web client for vSphere release 6.5. Therefore, the IBM Spectrum Protect vSphere Client plug-in configuration information normally shown on this tab is not available. This problem is expected to be resolved in a future vSphere release.
Workaround: To view the IBM Spectrum Protect configuration information for a folder, use the vSphere object navigator to select a folder, then launch the "IBM Spectrum Protect > Configure Data Protection" action. View the configuration information in the action dialog, then select Cancel to exit without saving any changes.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.2. Solved with v8.1.4.
Configuration Wizard lower than v8.1.2 has misleading error message when using STRICT admin ID (internal reference #147733)
Problem: When running the Data Protection for VMware Config Wizard at a level before version 8.1.2, and using an admin ID with option SESSIONSECURITY set to STRICT on an IBM Spectrum Protect server at level 8.1.2 or higher, it may fail with error:
GVM1136E The administrative API encountered an internal error while processing the request
Workaround: The workaround is to set admin ID with option SESSIONSECURITY set to TRANSITIONAL
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Solved with v8.1.4.
The VM name is truncated and the number of VMs is not counting correctly in the Schedule history table. (internal reference #146445)
Problem: VM name is limited to a maximum of 64 characters. The problem will occur if a VM name is longer than 64 characters. Then VM name is truncated and the number of VMs is not counting correctly in the Schedule history table if a VM name is longer than 64 characters.
Problem Verification: (only if necessary!) The problem will occur if a VM name is longer than 64 characters.
Workaround: The workaround is to limit the VM names to be shorter than 65 characters.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.2. Solved with v8.1.4, see IT21993.
vCenter services need to be restarted for the vSphere Client (HTML5 and Flex UI) after installing the GUI plug-in.(internal reference #135720, VMware reference PR-1871806)
Problem: After installing the GUI plug-in, the user cannot see the IBM Spectrum Protect plug-in in the HTML5 version of the VMware vSphere Client (HTML5 and FLEX UI).
Workaround:
-
for vShere 6.5: Restart the vCenter service for the HTML5 client by issuing the following commands:
service-control --stop vsphere-ui service-control --stop vsphere-client service-control --start vsphere-u service-control --start vsphere-client -
for vSphere 6.0: see VMware KB how to restart services:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109881
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109887
Affected platforms: Linux and Windows.
Limitation: Since 8.1.2. Vendor issue.
The Getting Started page doesn't display correct text for links and tabs at the first login after installing the HTML5 plug-in. (internal reference #144218)
Problem: After installing the GUI plug-in, the user may see non-readable text in the IBM Spectrum Protect plug-in in the HTML5 version of the VMware vSphere Client, such as "getting.start".
Workaround: Logout and login again to the HTML5 client via your web browser.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.2. Vendor issue.
Configuration Wizard failed to complete successfully on Linux (internal reference #135989)
Problem: After an upgrade, the configuration wizard or initial login screen has an error called “Proxy Rejected”. This situation can occur in some upgrades if the same node names are used as a previous install. The specific error is as follows and is present on the initial login screen or in the configuration wizard completion screen:
GVM0022E The VMCLI inquire configuration command failed, the following messages describe the error.
ANS1532E (RC5722) Proxy Rejected: Proxy authority has not been granted to this node.
FMM16014I The return code is 2.
Workaround 1: Re-run the configuration wizard using a different node name than the one used in the previous installation.
Workaround 2: The same node name can be used by manually granting the proxy via a IBM Spectrum Protect command. This method requires access to the IBM Spectrum Protect server user and password. Issue the following commands:
- From the command line, navigate to the /opt/tivoli/tsm/client/ban/bin directory.
- Start the dsmadmc command line application by issuing:
./dsmadmc id=serverId password=serverPassword - With the names of your previous VMCLI node and data center nodes, run the following command:
grant proxynode target=VCenterNode agent=DatacenterNode” and “grant proxy target=VCenterNode agent=VMCLInode
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Works as designed.
Invalid schedule name when creating a scan schedule using Data Protection for VMware vSphere GUI leads to error message ANR2600E (internal reference #130076)
Problem: Defining a Scan schedule using the Data Protection for VMware vSphere GUI, the schedule creation may fail to report the following error messages:
GVM0125E: An error occurred while making the Web server request. If this error persists, check the network connection with the Web server and verify that the Web server is running.
ANR2600E DEFINE SCHEDULE: Invalid schedule name - TEST-VCENTER01. MGMT.TESTENVIRONMENT_VMCLI_SCAN.
Problem Verification: None
Workaround: The following commands will rename the vmcli so that it would be possible to update the schedule using the Data Protection for vSphere GUI. Run the following commands using the Server Administrative Command Line (dsmadmc):
- define the „vmcliNode_SCAN“ Scan schedule:
- for Windows:
define sched polDom vmcliNode_SCAN desc='TSM4VE scan schedule' action=command starttime=00:00:00 dayofweek=sat per=2 perunits=weeks objects='C:\Program Files (x86)\Common Files\Tivoli\TDPVMware\VMwarePlugin\scripts\vmcli.cmd -f start_guest_scan -dcscan ALL_DC -o data_mover_node' define sched polDom vmcliNode_SCAN desc='TSM4VE scan schedule' action=command starttime=00:00:00 dayofweek=sat per=2 perunits=weeks objects='C:\Program Files (x86)\Common Files\Tivoli\TDPVMware\VMwarePlugin\scripts\vmcli.cmd -f start_guest_scan -dcscan „Local DC,SVC,XIV“ -o data_mover_node' - for Linux:
define sched polDom vmcliNode_SCAN desc='TSM4VE scan schedule' action=command starttime=00:00:00 dayofweek=sat per=2 perunits=weeks objects='/opt/tivoli/tsm/tdpvmware/common/scripts/vmcli' -f start_guest_scan -dcscan ALL_DC -o data_mover_node' define sched polDom vmcliNode_SCAN desc='TSM4VE scan schedule' action=command starttime=00:00:00 dayofweek=sat per=2 perunits=weeks objects='/opt/tivoli/tsm/tdpvmware/common/scripts/vmcli -f start_guest_scan -dcscan „Local DC,SVC,XIV“ -o data_mover_node'
- for Windows:
- define the association between the „vmcliNode_SCAN“ schedule and vmcliNode:
define association polDom vmcliNode_SCAN vmcliNode
Affected platforms: Linux and Windows.
Limitation: Since 7.1 and 8.1 releases. Permanent restriction, see APAR IT17304.
Running second time 'run configuration wizard', new prefix of node name is not applied (internal reference #131802)
Problem: The IBM Spectrum Protect Data Protection for VMware GUI configuration wizard provides a field to set a prefix string for naming all nodes that will be created by the wizard. In some cases when the wizard is used multiple times, the prefix name does not get used, instead the prefix is treated as blank so the suggested node names do not include the prefix characters
Problem Verification: The proposed node names in the wizard panels do not include the prefix characters.
Workaround: Restart the configuration wizard and re-enter the prefix name.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Solved with v8.1.2 see IT18415.
VE GUI online help pages are displayed in English when browser locale is CHS or CHT on some specific platforms (internal reference #131406)
Problem: Launching Data Protection for VMware Admin UI using IE/Edge browser on Windows 8.1/10/2012/2016 in Simplified Chinese or Traditional Chinese locales will cause the online help to load in English instead of the expected Chinese language.
Workaround: Use another browser like Chrome or Firefox on Windows 8.1/10/2012/2016 if you want to use Simplified or Traditional Chinese online help.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Vendor issue.
Upgrade vCenter Server Appliance to 6.5 will not preserve connection configuration information in the Web Client Extension (internal reference #136323)
Problem: After upgrading VCSA 6.0 to 6.5, the extension's connection information is not saved.
Workaround: The user can re-enter the connection information after the upgrade on IBM Spectrum Protect -> Manage -> Connections.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Vendor issue.
Restore of the encrypted virtual machines in vSphere 6.5 environment will output an error and continue to restore the virtual machine but does not preserved its configuration (internal reference #136499)
Problem: During restore operation of a virtual machine, which was backup using vSphere 6.5 virtual machine encryption, occur an error message but the restore operation continue.
The restore does not preserve the virtual machine configuration. The virtual machine will not be encrypted any more after the restore and the virtual machine storage policy will assign to "Datastore Default" instead of its original storage policy.
Workaround: None.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Permanent restriction.
In vCenter 6.0.2 a VM Restore may trigger a VM MAC Conflict Alarm (internal reference #132823)
Problem: In vCenter version 6.0.2 and later, a restore operation of a virtual machine may trigger a VM MAC address conflict alarm if the original VM was not deleted.
This alarm behavior is by design. If there is a conflict, VMware will change the VM MAC address of the newly restored VM.
Workaround: Users can disable the VM MAC address conflict alarm in vCenter if they do not want to receive this alarm.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Works as designed.
IBM Data Protection GUI dialog can become inaccessible from the browser window (internal reference #73199)
Problem: When you use the IBM Data Protection GUI (an extension within the VMware vSphere Web Client), a dialog (such as the Restore VM dialog) can be moved by the user out of the VMware vSphere Web Client viewing area. As a result, the dialog can become inaccessible to the user.
Workaround: If a dialog becomes inaccessible, log out of the VMware vSphere Web Client. Then, login again.
Affected platforms: Linux and Windows.
Limitation: Since 8.1.0. Permanent restriction.
Data Protection for VMware vSphere GUI attempts to back up invalid VMs (internal reference #146643)
Problem: A VM must be in the 'connected' state to be accessed for backup by the Data Protection for VMware vSphere GUI. A VM that is not in the 'connected' state cannot be accessed for backup and is considered an invalid VM. When an invalid VM exists in the VMware vCenter, the Data Protection for VMware vSphere GUI attempts to back up this invalid VM anyway, even when the invalid VM is not selected. Pending any unforeseeable issues with the VMs selected for backup, the Data Protection for VMware vSphere GUI completes the backup operation but the following error message is returned:
ANS2721E (RC4400) The virtual machine backup operation completed. However, one or more virtual machine backups failed.
Workaround: Check the console output and error logs for information about why the connection state was invalid. For example, an error message similar to the following is returned in the dsmerror.log file:
ANS2713E The virtual machine 'vmonion-rest' is in an invalid connection state 'inaccessible'. As a result, it cannot be backed up.
In this scenario, the invalid VM 'vmonion-rest' was not originally selected; however, the Data Protection for VMware vSphere GUI attempted to back it up anyway.
Existing VMCLI node registers as a Data Mover Node (internal reference #146647)
Problem: After successfully installing and configuring the Data Protection for VMware vSphere GUI, the GUI is uninstalled and unregistered from the vCenter. Then, the Data Protection for VMware vSphere GUI is installed and configured again on the same system. During this second configuration, an existing
Tivoli Storage Manager node is used for either the data center node or the data mover node. After configuration completes, the table in the Configuration Status page incorrectly shows an old (or legacy) VMCLI node as a data mover node.
This scenario is a known issue and is working as designed. The table in the Configuration Status page shows the topology for all nodes associated with the Data Protection for VMware vSphere GUI configuration. If there are old (or legacy) VMCLI nodes attached to the vCenter, these VMCLI nodes are shown as data mover nodes in the new configuration.
Workaround: None.
Data Protection for VMware vSphere GUI and VMCLI show failed VMs with large VMDKs (internal reference #146648)
Problem: After successfully installing and configuring the Data Protection for VMware vSphere GUI, two or more VMs are selected for backup. One of the VMs has a VMDK that exceeds 2 TB. The backup operation succeeds for one VM but fails for the VM that has a VMDK that exceeds 2 TB. However, the failed VM displays in the list of backed up VMs.
This scenario is a known issue and is working as designed. Although the failed VM displays in the list of backed up VMs, the failed VM does not display with a restore point. Therefore, the failed VM should cause no additional issues or confusion.
Workaround: None.
Data Protection for VMware vSphere GUI help page is inconsistent with the server locale (internal reference #146651)
Problem: When the Data Protection for VMware vSphere GUI help page is accessed through the "Learn more" link for the first time, the help displays in the language specified by the locale setting of the processor that runs the Data Protection for VMware vSphere GUI, not the language specified by the locale of the VMware vSphere Client. In this situation, after the Data Protection for VMware vSphere GUI help page displays, click at least two links within the help, then close the help. The next time the help is started from the "Learn more" link, it displays in the language specified by the locale setting of the VMware vSphere Client.
This is a known issue caused by inconsistent locale settings among the processor that runs the Data Protection for VMware vSphere GUI and the VMware vSphere Client. The Data Protection for VMware vSphere GUI does not support running in an environment that contains inconsistent locale settings among the processor that runs the Data Protection for VMware vSphere GUI, the VMware vSphere Client, and the Tivoli Storage Manager server.
Workaround: Specify the same locale settings among the processor that runs the Data Protection for VMware vSphere GUI, the VMware vSphere Client, and the Tivoli Storage Manager server.
Data Protection for VMware vSphere GUI Application Configuration Status report might contain inaccurate guest operating system information (internal reference #146652)
Problem: In the Application Configuration Status report, the full name shown in the Guest Operating System column is based on objects that are managed by VMware vSphere. The Application Configuration Status report cannot validate the full name that is managed by VMware vSphere. As a result, the full name might be inaccurate.
This is a known issue caused by VMware users that must enter a guest operating system full name for a new operating system release when the predefined full name text is not yet available.
Workaround: Specify or select the correct full name when configuring the guest operating system.
Determining which datacenter to select in the "Instant Access/Instant Restore Status" dialog (internal reference #146653)
Problem: In the "Instant Access/Instant Restore Status" dialog of the Data Protection for VMware vSphere GUI, when using the "Select a datacenter" drop-down list, the information provided in the dialog does not clarify which datacenter to select. Determining which datacenter to select might be particularly confusing when the same data mover node is used for the VM's original datacenter and the datacenter where the VM was restored.
Workaround: This scenario is a known problem and is working as designed. To solve this problem, select the VM's original datacenter and not the datacenter where the VM was restored.
Scan schedule defined using the Data Protection for vSphere GUI on a Linux system cannot run without prompting the user for the VMCLI node password (internal reference #146659)
Problem: This situation occurs when the following two conditions exist:
The Data Protection for vSphere GUI and Tivoli Storage Manager backup-archive client are installed on the same Linux system. The backup-archive client scheduler uses the VMCLI node. When the VMCLI password is updated, the backup-archive client password is invalidated. Likewise, when the backup-archive client password is updated, the VMCLI password is invalidated. As a result, the user is continually prompted for a new password, and cannot set up a working scheduler.
This is a known problem that is caused by the inability of the Data Protection for vSphere GUI and the backup-archive client scheduler to use the same VMCLI node when both applications are installed on the same Linux system.
Workaround: To enable the Data Protection for vSphere GUI and the backup-archive client scheduler to use the same VMCLI node when both applications are installed on the same Linux system, create a stanza for SERVERNAME TSMCLIWRAPPER in the dsm.sys file with the following settings:
SERVERNAME TSMCLIWRAPPER
TCPSERVERADDRESS <same TSM server as VMCLI node>
PASSWORDACCESS generate
MANAGEDSERVICES webclient schedule
NODENAME <VMCLI node name>
The stanza must specify SERVERNAME TSMCLIWRAPPER to be successful.
Caution: When the passworddir option is used to specify an alternate directory location for TSM.PWD, this workaround is unsuccessful. TSM.PWD must be in the default location for this workaround to be successful.
Date displays incorrectly in Data Protection for VMware vSphere GUI (internal reference #73084)
Problem: The Data Protection for VMware vSphere GUI Mount Status pane displays the Start Date and Snapshot Date incorrectly when the following conditions exist:
-The language environment is set to Japanese, Korean, Simplified Chinese, or Traditional Chinese.
-The date and time format of the system is set to a format that contains the abbreviated name of the month (MMM) or the AM/PM designator (tt).
Workaround: Complete the following tasks to resolve this issue: Set the TIMEformat option in the Tivoli Storage Manager backup-archive client dsm.opt file on the data mover system. Set the date and time format in the 'Region and Language' settings as follows:
- Short date: Any date format that uses the month as a number. Do not use the abbreviated name of the month (MMM).
- Long date: Not affected. Any format is good.
- Short time: Any time format that does not use the AM/PM designator (tt).
- Long time: Any time format that does not use the AM/PM designator (tt).
Set the value of the TIMEformat option to 1. For example: timeformat 1
Data Protection for VMware vSphere GUI configuration wizard might display data mover node with incorrect datacenter node (internal reference #152806)
Problem: In this scenario, datacenters with similar names are added to the Managed Datacenters list in the GUI Domain page of the configuration wizard or configuration notebook. However, in the Data Mover Nodes page, one of the created data mover nodes is shown as mapped to the wrong datacenter node. As a result, it appears that the data mover node was not created for the wanted datacenter node. This is a known issue.
Workaround: To resolve this issue, complete the following tasks:
- In the Data Mover Nodes page, select the data mover node and click Edit Node Name in the toolbar.
- Add an ampersand (&) at the beginning of the data mover node name.
Data Mover
Data Mover Common Issues and Limitations
Backup of VM with disk size not multiple of 1MB may hang (internal reference #181115)
Problem: Backing up a disk with size not multiple of 1MB may hang during VDDK disk Open call. The issue is due to a VMware VDDK defect described in https://kb.vmware.com/kb/66936.
Workaround: Increase the disk size to a multiple of 1MB.
Affected platforms: Linux and Windows.
During a scheduled VE backup operation, messages ANS9365E is logged in the dsmerror log indicating that a VDDK read operation failed due to an out of memory condition. (internal reference # 173659)
Problem: During a scheduled VE backup operation, there are occasionally messages logged in the dsmerror.log indicating that a VDDK read operation failed due to an out of memory condition. The message logged is:
01/05/2019 14:58:32 ANS9365E VMware vStorage API error for virtual machine 'testVM1'.
IBM Spectrum Protect function name : VixDiskLib_Read
IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (3142)
API return code : 2
API error message : Memory allocation failed. Out of memory.
The out of memory condition is coming from the VMware vStorage VixDiskLib_Read API, and only occurs when the NBD transport is being used for the VM being backed up; This will not be seen when transport HOTADD or SAN are used.
When this return code is returned from a VixDiskLib_Read call, IBM Spectrum Protect will retry the read for up to 2 minutes. In most cases, the read will succeed after 1 or 2 retries, as indicated by the message:
01/05/2019 14:58:42 ANS0361I DIAG: vmRetryVirtualDiskRead(): vddk read successful, total retries=2.
Workaround: This problem is typically intermittent, and retrying the VixDiskLib_Read will normally succeed. If this is the case, then no action is necessary. However, it is possible to eliminate this condition, or at least reduce the frequency of its occurrence, by reducing the amount of parallelism being used by the backup process. This can be done by making one or more of the following changes:
1. Reduce the value of the VMLIMITPERHOST. This can be done by reducing the value by 1 until the ANS9365E message is no longer seen.
2. Reduce the value of the VMMAXPARALLEL. This can be done by reducing the value by 1 until the ANS9365E message is no longer seen.
3. This problem is only seen when NBD transport is being used. If backups are not succeeding or if the the read retries are causing long backup windows (or performance issues), use the HOTADD or SAN transport instead of NBD(SSL). If HOTADD or SAN is the primary transport, then determine why the effected VMs are using NBD, and if possible, correct any conditions that are preventing advanced transports from being used.
Affected platforms: Linux and Windows.
Possibility of inaccuracy in automated data mover assignment (internal reference #168920)
Problem: VMs that are recently added to the inventory in a folder or data center that is being protected by a tagged based schedule are automatically associated with data movers running this schedule. It is possible that the data mover automatically chosen is not currently active or otherwise unconfigured. This will lead to the VM not being protected.
Workaround: Edit the schedule associate with the VM and ensure the full rebalance check box is selected and click save
Affected platforms: Linux and Windows.
When option TIMEFORMAT 5 is used with the option PITTIME, the time value will be rejected on input even if the time value is valid.(internal reference #157671)
Problem: The format assigned to TIMEFORMAT 5 "AM/PM HH::MM::SS" is not accepted with option PITTIME. The traditional Chinese locale and language packs automatically sets the TIMEFORMAT option to 5.
Problem Verification: Set the TIMEFORMAT option to 5 in the options file, at command line, in a scheduled backup, or in a CSV file for restoring virtual machines and set the PITDATE and PITTIME values. The error message will be ANS1036S or ANS2277E.
Workaround: Set the TIMEFORMAT option to 1, 2, 3, or 4 in the and change any PITTIME input to the corresponding TIMEFORMAT.
Affected platforms: Linux and Windows.
LAN-free backup of a virtual machine that does not succeed due to lack storage space returns an incorrect error code of -72 instead of 29. (internal reference #147639)
Problem: When backing up a virtual machine using LAN-free and the backup stops due to lack of storage space on the server the wrong error code will be displayed. The correct error code for this situation is 29, but the backup operation will return -72 in logs and on the extended summary table. Both messages corresponding to each error code, 1329S for 29 and 1235E for -72 will be displayed and logged.
Problem Verification: If the backup operation was conducted over LAN-free and did not succeed with error code -72, the backup operation will also have logged the message 1329S, which is logged when the server indicates an out of storage space situation.
Workaround: No workaround, the backup will succeed when there is sufficient storage space in the assigned storage pool on the server.
Affected platforms: Linux and Windows.
Virtual machine backup fails with the incorrect return codes 33 or 34 and with messages 0323E or 0324E respectively. (internal reference A #14777)
Problem: Backups of one or more VMware virtual machines fail with the incorrect error codes 33 or 34 and with messages 0323E or 0324E respectively. The backup operation has encountered a virtual machine with a pRDM in which the underlying storage for the disk has become disconnected from the network accessible by the ESX host. Backup of a virtual machine with a network disconnected pRDM disk is not possible.
Problem Verification: The pRDMs of the affected virtual machines will not be accessible from within the guest or from the ESX host.
Workaround: Fix the network, storage, or security issue preventing access to the pRDM of the virtual machine. Alternatively, remove the pRDM from the virtual machine's configuration until the connection issue to the pRDM can be resolved.
Affected platforms: Linux and Windows.
The data mover may end abruptly during backup of VMware virtual machines when one or more sessions have been in media wait for 2.5 or more hours. (internal reference B #14777)
Problem: During backups of a VMware virtual machine with the value of options VMMAXPARALLEL (default is 4) or VMMAXBACKUPSESSIONS (always equal or greater than the value of VMMAXPARALLEL) is greater than one to a file pool or VTL on the server there may be a limited number of mount points available. The remaining sessions are put in to media wait until a mount point is available from the server. If one or more sessions is in media wait continually for 2.5 hours or more all backups by the client may end abruptly. The administrator client may be used to query for which sessions are currently in media wait.
Problem Verification: Check the server logs and use session queries to see if any sessions are kept in the media wait state for extended periods of time.
Workaround: There are several available workaround.
1) Increase the available mount points on the server by adding additional volumes, removing unneeded data from full volumes, and adjusting the maxnummp value of a node.
2) Decrease the value of the options VMMAXPARALLEL and VMMAXBACKUPSESSIONS until sessions do not stay in an extended media wait state.
Affected platforms: Linux and Windows.
A VMware virtual machine restore operation may hang if 26 or more virtual disks are being restored simultaneously in some conditions. (internal reference #140766)
Problem: In some circumstances a VMware virtual machine restore operation may hang if certain conditions are met. If the VMware virtual machine to be restored has at least 26 virtual hard disks to be restored, the options VMMAXRESTOREPARALLELDISKS and VMMAXRESTORESESSIONS are set to 26 or higher, the version of the vCenter is 6.5, the option VMVSTORTRANSPORT includes transport type nbd, and nbd is selected for the transport type at runtime, the operation may hang.
See also https://kb.vmware.com/s/article/52813
Problem Verification: Setup the options for the data mover and environment as described above in the problem description and attempt to perform a backup and then restore. If the restore hangs, then the above problem scenario has been re-created.
Workaround: Set the option VMMAXRESTOREPARALLELDISKS to 25 or lower.
Affected platforms: Linux and Windows.
Forcing disks provisioned as thick eager to be thin during a virtual machine restore can result in the disks remaining thick eager. (internal reference #140377)
Problem: Attempting to convert disks provisioned "Thick Eager zeroed" to be provisioned "Thin" during a virtual machine restore can result in the disk remaining provisioned "Thick Eager zeroed". This can occur when restoring from the GUI or command line. The restore of the virtual machine is successful but the disks remain provisioned as "Thick Eager zeroed".
Workaround: There are 2 workaround's for this issue.
- Setting the option VMVSTORTRANSPORT to NBDSSL:NBD:HOTADD or specifying one of these transport types NBDSSL, NBD or HOTADD will force the restore to not use the SAN transport. This will result in being able to force the thick eager disks to thin. The option can either be set in the option file or during a dsmc command.
- VMware has a KB that describes a manual method to convert disks from one provisioning type to another https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2014832
Affected platforms: Linux and Windows.
Updating and Expiring a Node Password can result in rejected session (internal reference #147153)
Problem: If a nodes's password is updated and later expires before it is ever used, the next time the node attempts to connect to the server the session will be rejected. A subsequent attempt to connect to the server will not be rejected.
Problem Verification: The rejected connection attempt will return
ANS1026E (RC136) The session is rejected: There was a communications protocol error.
Workaround: To work around the rejected connection, retry the connection.
Affected platforms: Linux and Windows.
Limitation: Solved with v8.1.4.
VM backup with application protection of VMs hosting vCenter or vCenter related infrastructure applications fails with ANS2330E during first attempt. (internal reference #147798)
Problem: VM backup with application protection of VMs hosting vCenter or vCenter related infrastructure (Platform Services Controller server, databases used by vCenter, etc) may fail with ANS2330E during first attempt due to VMware APIs are unresponsive during snapshot operation.
Workaround:
- Disable application protection for such vms and use in-guest client to backup necessary application data.
- Use application protection with persistent VSS snapshots (done automatically during second attempt of vm backup).
Affected platforms: Linux and Windows.
IBM Spectrum Protect 8.1.2 will ship with VMware's VDDK 6.0.3 API which lacks SAN transport support when using VMware's NEW VMFS-6 datastore. VDDK 6.0.x does not support back up of VMs residing on VMFS-6 datastores using SAN transport mode. (internal reference #142822)
Problem: Attempts to backup VMware virtual machine(s) on VMFS-6 datastore(s) from a physical data mover using the SAN transport will result in an error messasge and the backup will fail. The backup will fail with a VMware API error You do not have access rights to this file".
IBM Spectrum Protect function name : VixDiskLib_Open
IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (1885)
API return code : 13
API error message : You do not have access rights to this file
Workaround: When backing up virtual machine(s) that reside on a VMFS-6 datastore from a physical data mover the SAN transport mode should be disabled with the VMVSTORTRANSPORT option. Virtual data movers are not effected because they do not have SAN transport support.
For example: VMVSTORTRANSPORT "NBDSSL:NBD"
Affected platforms: Linux and Windows.
Limitation: Solved with v8.1.4.
Client could freeze during VM backup when reach node's mount point limit (internal reference #124122)
Problem: While backing up VMware virtual machines to the IBM Spectrum Protect Server the client may freeze indefinitely when there are insufficient mount points available from the server. This freeze will not occur if backing up to a container storage pool on the IBM Spectrum Protect Server. Given sufficient time of approximately 1-2 hours, the client will eventually fail the backup and issue message ANS9373E about a backup that is not progressing. Backups without sufficient mount points will cause performance degradation from the IBM Spectrum Protect Client.
Problem Verification: This problem can be identified by examining the IBM Spectrum Protect Client error log. If VMware virtual machine backups cause the message ANS9373E about backups not progressing and ANS0326E about insufficient mount points then this issue is the likely culprit. In some cases, the client may freeze and will not close without user intervention.
Workaround: Backups to a container storage pool on the IBM Spectrum Protect Server will prevent the error. Alternatively, increasing the number of available mount points will prevent this issue.
Each node used for backing up VMware virtual machines should be assigned max mount points approximately equal to the value of the client option VMMAXPARALLEL or VMMAXBACKUPSESSIONS, whichever is higher. Adjust higher as needed if the problem persists.
Affected platforms: Linux and Windows.
Limitation: Solved with v8.1.2, see APAR IT18408.
Sometimes VM backup dsmc output shows a duplicate Disk Sent message (internal reference #130805)
Problem: During a backup of VMware virtual machines a message is issued for each virtual disk that will be backed up and then a second a message to indicate when the data for that disk has finished being sent to the IBM Spectrum Protect Server. Occasionally, the message indicating that the disk processing has finished will be repeated twice and possibly more.
There is no error in the backup process, the message is displayed incorrectly.
Problem Verification: The virtual disk sent message will be displayed multiple times for the same disk.
Workaround: None.
Affected platforms: Linux and Windows.
Limitation: Solved with v8.1.2, see APAR IT18412.
VM restored directly to ESXi 6.0 host does not display in VMware vSphere 6 Client inventory (internal reference #154482)
Problem: In this scenario, a VM was restored directly to an ESXi 6.0 host. The ESXi 6.0 host was specified with either of the following methods:
1. The vmchost parameter on the backup-archive client command-line:
dsmc restore vm <vmname> -vmchost=<ESXi 6.0 hostname>
2. The vmchost option in the backup-archive client options file (dsm.opt):
VMCHost <ESXi 6.0 hostname>
The restore operation completed successfully. However, the restored VM does not display in the VMware vSphere 6.0 Client inventory. This is a known VMware issue. (PR# 1363606)
Affected platforms: Linux and Windows.
In-guest domain credentials must be enclosed in quotation marks (internal reference #154493)
Problem: When setting domain credentials on a Linux system for an in-guest virtual machine application, you must enclose the domain credentials in quotation marks ("). For example:
dsmc set password -type=vmguest VMGUEST-Part-of-domain "domainname\Administrator" Admin-password
OR
dsmc set password -type=vmguest VMGUEST-Name "Admin-Id" Admin-password
Failure to do so can cause the backup operation to fail. Error messages ANS9398E, ANS1228E, ANS9493E, and ANS4174E typically display when encountering this issue.
Affected platforms: Linux and Windows.
Clocks must be in sync to prevent failure of security token request (internal reference #154496)
Problem: The clocks on the data mover and the ESXi host must be in sync within 10 minutes to satisfy the requirements of the Platform Services Controller single-signon (SSO). An informational message is generated that is similar to the following example:
ANS2309I Single Sign On login to the vSphere Server failed in function
visdkGetSecurityToken - Issue.
"The time now Tue Feb 24 11:14:29 UTC 2015 does not fall in the request lifetime interval extended with clock tolerance of 600000 ms: [ Tue Feb 24 14:11:41 UTC 2015; Tue Feb 24
14:41:41 UTC 2015). This might be due to a clock skew problem."
Detail: [no detail]
A credential login is now attempted.
Workaround: When installing the vCenter Server, synchronize the ESXi clock with a Network Time Protocol (NTP) server. Note that the amount of time that the clocks can be out of sync is configured in the vSphere Web Client.
Affected platforms: Linux and Windows.
IFFULL instead of IFINCR backup after increasing one vmdk size on ESXi 5.5 and lower (internal reference #162907)
Problem: Due to issues with VMware Change Block Tracking (CBT) after increasing vm disk size running on vSphere 5.5 or lower, a CBT reset is performed and full backup is taken.
Subsequent backups work as usual.
Workaround: None.
Affected platforms: Linux and Windows.
Remote Platform Services Controller (PSC) unavailable for Single Sign On (SSO) (internal reference #154499)
Problem: In this scenario, the data mover cannot communicate with the PSC for SSO. An informational message is generated that is similar to the following example:
ANS2309I Single Sign On login to the vSphere Server failed in function
visdkTestSSOEndpoint - .
hostname/sts/STSService
"No connection could be made because the target machine actively refused it."
Detail: connect failed in tcp_connect()<
A credential login is now attempted.
Workaround: Open a command prompt on the data mover and ping the PSC to make sure communication is active and that a firewall is not interfering. By default, the PSC uses port 80 (http) and port 443 (https). You can customize the port settings in the PSC installer.
Affected platforms: Linux and Windows.
Issues with virtual machines hosted on an ESXi host upgraded to vSphere 6.0 (internal reference #154500)
Problem: In this scenario, the virtual machine is on an ESXi host that was upgraded from vSphere 5.x to vSphere 6.0. After the upgrade, the following issues occur:
- Change Block Tracking (CBT) does not work. As a result, Data Protection for VMware 7.1.2 forces a full VM backup.
- Virtual machine quiescing fails. As a result, the snapshot and the backup fail.
Messaging is generated that is similar to the following example:
2015-03-23T22:22:45.267Z| vcpu-0| I120: DISKLIB-CTK : Could not open change tracking file "/vmfs/volumes/51c4ef65-ee5af035-6d95-00145e575bc2/win2008r2x64 -
small/win2008r2x64 - small_1-000002-ctk.vmdk": Change tracking invalid or disk in use.
2015-03-23T22:22:45.269Z| vcpu-0| I120: DISKLIB-CTK : Re-initializing change tracking.
2015-03-23T22:22:45.269Z| vcpu-0| I120: DISKLIB-CTK : Auto blocksize for size
10485760 is 128.
2015-03-23T22:22:45.269Z| vcpu-0| I120: OBJLIB-FILEBE : Error creating file
'/vmfs/volumes/51c4ef65-ee5af035-6d95-00145e575bc2/win2008r2x64 -
small/win2008r2x64 - small_1-000002-ctk.vmdk': 3 (The file already exists).
2015-03-23T22:22:45.271Z| vcpu-0| I120: DISKLIB-CBT : Initializing ESX kernel change tracking for fid 2756465.
2015-03-23T22:22:45.271Z| vcpu-0| I120: DISKLIB-CBT : Creating cbt node 2a0f71-cbt failed with error Cannot allocate memory (0xbad0014, Out of memory).
2015-03-23T22:22:45.271Z| vcpu-0| W110: DISKLIB-LIB : Could not attach vmkernel change tracker: ESXi tracking filter failed (0x143c). Disk will be opened, but change tracking information will be invalidated.
Workaround: Make sure that the ESXi host memory use does not exceed 75%.
Affected platforms: Linux and Windows.
Backing up too many disks in parallel against the same ESX host or datastore may result in backup failures. (internal reference #130237)
Problem: Backing up too many disks in parallel against the same ESX host or datastore may result in backup failures. You may see the following console messages:
ANS1228E Sending of object 'esxlincli11' failed.
ANS5283E The operation was unsuccessful.
ANS4174E Full VM backup of VMware Virtual machine 'vmname' failed with RC=-1 mode=Incremental Forever - Full, target node name='TSMESX01-DM', data mover node name='TSMESX01-DM'
You may see the following error for each failed disk in the error log:
10/05/2016 10:18:19 ANS9365E VMware vStorage API error for virtual machine 'vmname'.
IBM Spectrum Protect function name : VixDiskLib_Open
IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (1851)
API return code : 13
API error message : You do not have access rights to this file
In addition, if you are using nbd transport for the backup you may also see multiple instances of the following error:
10/05/2016 10:18:19 ANS9365E VMware vStorage API error for virtual machine 'unavailable'.
IBM Spectrum Protect function name : VixDiskLib_Read
IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (3067)
API return code : 2
API error message : Memory allocation failed. Out of memory.
Problem Verification:
- Check your dsmerror.log file for the error messages described above.
- Check the host and datastore that each disk resides on. The disks that failed should have had many other disks that were backing up against the same host or datastore.
- Check your dsm.opt file for the VMLIMITPERHOST and VMLIMITPERDATASTORE options. This problem can occur when these values are not set, or are set too high.
Workaround: In your dsm.opt file, set values for VMLIMITPERHOST and VMLIMITPERDATASTORE if not already set, or lower them if they already exist.
Affected platforms: Linux and Windows.
Virtual machines, added or moved to a container already assigned a multiple data mover schedule that is nested underneath a single data mover schedule, are either not backed up or are backed up unexpectedly (internal reference #131465)
Problem: This limitation occurs because virtual machines that are recently added or moved to a multiple data mover schedule do not have an associated data mover and therefore inadvertently inherited the data mover associated with the single data mover schedule. Two unintentional results can occur due to this limitation:
1. Even though a default data mover has been defined for the multiple data mover schedule, the recently added virtual machines do not get backed up.
2. The virtual machines are backed up by an unexpected data mover, when they should have either been backed up by a default data mover, if one was defined, or not at all, if no default data mover was defined. *
* This outcome can occur in the case where the data mover associated with the single data mover schedule is also associated with the multiple data mover schedule but is not defined as the default.
Problem Verification: To determine if this situation applies to you, look for the following:
- A multiple data mover schedule nested underneath a single data mover schedule. If you do not use nested schedules this limitation does not apply.
- A warning message is displayed in the IBM Spectrum Protect Manage tab in the vSphere Web Client, for those virtual machines or their parent containers that are affected:
The data mover <data mover name> is not associated with the schedule <schedule name>. Virtual machines that inherit this data mover will not be backed up.
- Inheritance from the container assigned the single data mover schedule is indicated in the data mover field in the IBM Spectrum Protect Manage tab, for those virtual machines or their parent containers that are affected.
- New virtual machines that are not being protected will show 'At Risk' status on the IBM Spectrum Product Monitor tab.
Workaround: This limitation has a number of workarounds:
1. Perform a full rebalance on the multiple data mover schedule each time you add or move additional virtual machines in it.
2. Directly assign a data mover to each additional virtual machine you add or move in the multiple data mover schedule.
3. Manually assign a data mover tag to the same container that the multiple data mover schedule tag is assigned to. The data mover represented by this tag will act as the default data mover for any virtual machines in this schedule that do not have a data mover assigned to them.
- Determine what data mover you want to assign as the default data mover. This data mover must be associated with the schedule. You can find the list of data movers for the schedule by visiting the Manage Schedules page, clicking on the schedule, and viewing the schedule details pane.
- Using either the Tags portlet in the Summary page in vSphere Web Client, or PowerCLI, assign the data mover tag to the same container that the schedule tag is attached to.
Note 1: Each time you perform a full data mover rebalance of the schedule from the Manage Schedule page, you must manually reattach this data mover tag.
Note 2: The data mover tag you set on the container will be the default data mover tag for this container. This setting will override any default data mover you have specified in your data mover options files. As a best practice, ensure that the same data mover is used in both places.
Affected platforms: Linux and Windows.
Limitation: Solved with v8.1.2.
Disks identified with test flag VMRESTORE_FORCE_THIN marked as thick eager zeroed after VM is restored on NFS based datastores. (internal reference #108542)
Problem: Disks identified with test flag VMRESTORE_FORCE_THIN marked as thick eager zeroed after VM is restored on NFS based datastores.
This issue occurs during a VMware restore with snapshot due to a VMware bug identified in the following VMware Knowledge Base article: http://kb.vmware.com/kb/2137818
The disk is marked as thick eager zeroed when the snapshot is removed after the VM is restored. The disk is created thin and is only marked as thick eager zeroed at the end of the restore operation. This issue does not impact performance or storage.
Workaround: None.
Affected platforms: Linux and Windows.
Unable to get SAN transport when performing backup or restore VM operations on disks that are a multiple of 2 TB in size. (internal reference #105397)
Problem: When attempting to perform a SAN backup or restore VM operation on a virtual machine that has virtual disks that are greater than 2 TB, NBDSSL or NBD transport may be selected instead of SAN. This problem may occur if the virtual disk is a multiple of 2 TB in size (2 TB, 4 TB, 6 TB, etc). See the following VMware KB article for detailed information: http://kb.vmware.com/kb/2135503
Workaround: To workaround this issue until VMware provides a fix, specify the VMVSTORTRANSPORT option to NBD or NBDSSL in dsm.opt (Windows) or dsm.sys (Linux).
Affected platforms: Linux and Windows.
Transport mode does not failover (internal reference #145451)
Problem: In this scenario, the vmvstortransport option is specified during a backup VM and restore VM operation. The specified transport mode becomes unavailable during processing and the operation fails. The IBM Spectrum Protect Backup-Archive client does not failover to another transport mode when the specified transport mode becomes unavailable during an operation. When this occurs, the dsmerror.log contains a reference to "VixDiskLib_Write" or "VixDiskLib_Read".
Workaround: None.
Affected platforms: Linux and Windows.
VMware Change Block Tracking (CBT) support for content-aware backups (internal reference #145453)
Problem: IBM Spectrum Protect full VM backup will use VMware Change Block Tracking (CBT) support if available to enable content-aware (used-block only) backups. VMware CBT requires ESX 4.0 or later host (with virtual hardware 7). IBM Spectrum Protect will turn on CBT on the first IBM Spectrum Protect backup of the virtual machine.
IBM Spectrum Protect full VM backup does support virtual machines that do not support CBT. In this case, both used and unused areas of the disk will be backed up and an informational message will be logged to the dsmerror.log. The command line 'dsmc show vm all' will display the CBT status. See also Overview of Change Block Tracking
Workaround: None.
Affected platforms: Linux and Windows.
RDM Physical Compatibility Mode and Independent disks (internal reference #145455)
Problem: Backups are not supported for virtual machines that have either independent disks (either persistent or non-persistent), or that have raw device mapping (RDM) disks configured in physical compatibility mode. RDM disk configured in virtual compatibility mode are supported. In previous releases, attempting to back up a virtual machine that included one of these disks would fail.
Two options have been added to allow the virtual mskiprd skioachine backup to succeed, but skip the backup of these disks. Also on restore, these disks will not be restored. The options are "VMPROCESSVMWITHPRDM=NO/YES" and "VMPROCESSVMWITHINDEPENDENTDISK=NO/YES". The default for these options is "NO", meaning the virtual machine will fail to backup.
Workaround: If both types of disks are included in the virtual machine, then both options must be specified and set to "YES" for the backup to succeed.
Affected platforms: Linux and Windows.
Client-side deduplication performance and return code=254 (internal reference #145456)
Problem: VMware off-host full VM backups with client-side deduplication enabled fails with return code=254. Error message:
ANS7899E The client referenced a deduplicated extent that does not exist on the IBM Spectrum Protect server.
This error can occur when a IBM Spectrum Protect server expiration or similar process is either in the process of removing a deduplicated extent or has an extent locked during the backup. A subsequent backup should succeed.
Workaround: When running heavy backup loads on the IBM Spectrum Protect server, if a VM backup fails multiple times with RC=254 or an increase backup run time is noticed when client-side deduplication is enabled, disable client-side deduplication for the VMware backup proxy node. This issue does not occur when using server-side deduplication.
Affected platforms: Linux and Windows.
Incorrect level of the VMware Tools (internal reference #145466)
Problem: When a IBM Storage Protect backup VM command fails consistently with the following error in the dsmerror.log, an incorrect level of the VMware Tools might have been installed inside the guest OS:
ANS9365E VMware vStorage API error.
OR
ANS9365E VMware vStorage API error for virtual machine '<vmname>'.
IBM Spectrum Protect function name : CreateSnapshot_USCORETask
IBM Spectrum Protect file : ..\..\common\vm\vmvisdk.cpp (6704)
API return code : 2249
API error message : An error occurred while saving the snapshot: Failed to quiesce the virtual machine.
OR
ANS9365E VMware vStorage API error for virtual machine '<vmname>'.
IBM Spectrum Protect function name : CreateSnapshot_USCORETask
IBM Spectrum Protect file : ..\..\common\vm\vmvisdk.cpp (6704)
API return code : 2249
API error message : An error occurred while saving the snapshot: Failed to quiesce the virtual machine.
Workaround: It might be necessary to uninstall and re-install the latest version of VMware Tools on the guest OS virtual machine.
If the problem persist, refer to the following VMware Knowledge Base (KB) article for detailed information and solution: "Cannot create a quiesced snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine ".
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1018194
Affected platforms: Linux and Windows.
Long running snapshot delete (internal reference #145542)
Problem: A IBM Spectrum Protect backup VM command can fail if the delete snapshot of a failed prior run requires a longer timeout value than one set by the VMware vCenter. The following error might be logged in dsmerror.log as a result of this timeout value that is exceeded by the vStorage API:
ANS9365E VMware vStorage API error, API error message: "server refused connection", API return code:14009
Workaround: The snapshot delete will continue to be processed. The next backup attempt should succeed.
Affected platforms: Linux and Windows.
Change Block Tracking (CBT) needs reset (internal reference #145546)
Problem: When a IBM Spectrum Protect Backup VM fails with one of the following warning messages in the dsmerror.log:
ANS9365E VMware vStorage API error.
TSM function name : visdkQueryChangedDiskAreas
TSM file : vmvisdk.cpp (3592)
API return code : 12
API error message : SOAP 1.1 fault: "":ServerFaultCode[no subcode]"A specified parameter was not correct. deviceKey"
ANS9365E VMware vStorage API error.
TSM function name : visdkPrintSOAPError
TSM file : vmvisdk.cpp (885)
API return code : 12
API error message : SOAP 1.1 fault: "":ServerFaultCode[no subcode]"Error caused by file /vmfs/volumes/4ade85fd-81f49624-57f5-000e0cdd0d21/winxp-32/winxp-32.vmdk"
It might be necessary to reset the VMware Change Block Tracking (CBT) for the virtual machine. This error can occur if the ESX server is shut down or rebooted without first entering maintenance mode. It can also occur when a backup is attempted through both the ESX Server and vCenter at the same time for the same VM. Change Block Tracking is needed by IBM Spectrum Protect to back up content-aware (used-block only areas of the disk). If CBT is in this failed state, IBM Spectrum Protect will continue with the backup, and will back up the used and unused areas of the disk. See also CBT KB Overview of Change Block Tracking.
Workaround: Run a single IBM Spectrum Protect backup with the test flag vmbackup_cbt_reset. Example:
dsmc backup vm 'myvm' -testflag=vmbackup_cbt_reset.
This test flag will require a snapshot and snapshot delete to turn off CBT and a second snapshot to turn on CBT. Therefore, the test flag should not be set permanently as it could impact backup performance.
Affected platforms: Linux and Windows.
"Clear lazy zero" is repeated in VMware vCenter task during VM Restore (internal reference #145548)
Problem: When performing a virtual machine restore with disk type set to 'eager zero' using vSphere 4.1 or higher and when using SAN transport, the message "Clear lazy zero" is repeated in the "recent tasks" section of the VMware vSphere console, and the performance of the restore drops. VMware, instead of zeroing a VMDK as it is created, instead sets the lazy zero bit on each block in the VMDK so that it can be cleared at a later time. To avoid the performance issue, perform a restore to the ESX server instead of a vCenter.
Workaround: None.
Affected platforms: Linux and Windows.
Slow restore using SAN transport (internal reference #145550)
Problem: Although VM backups using SAN as transport is very fast, VM restores using SAN is usually the slowest of all transports. This problem is more prevalent when thin disks are used, and VMware recommends using NBDSSL for restores when thin disks are involved.
See the following VMware KB article for more detailed information (Best practices when using SAN transport for backup and restore): http://kb.vmware.com/kb/1035096
Workaround: None.
Affected platforms: Linux and Windows.
Thin-provisioned disk (internal reference #145552)
Problem: There is a know problem in VMware vSphere 4 where a snapshot disk does not show the correct thin- or thick-provisioned trait based on the actual disk's property. As a result, when a backup of a virtual machine with a thin-provisioned disk set in the disk properties is performed, IBM Spectrum Protect is unable to save the thin-provisioned disk attribute. Since this attribute is not saved, IBM Spectrum Protect is unable to restore the disk as thin-provisioned, but instead will restore the disk using the thick-provisioned disk attribute. See the following VMware KB article for detailed information: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020137
VMware vSphere 5 provides the ability to get the thin or thick trait, so this will be saved on backup, and the disk will be created with the saved attribute on restore.
There is also a known issue with the VMware VDDK where thin disks being restored to a local datastore might incorrectly try to use the SAN transport. To restore thin disks in this situation, and also preserve the thin attribute, the "VMVSTORTRANSPORT nbdssl:nbd" (or any acceptable values excluding "san") should be used. Since "san" is not in the list of transports to use, it will not be incorrectly chosen when restoring thin disks to a local datastore.
Workaround: None.
Affected platforms: Linux and Windows.
VMware datastore space issues for backups (internal reference #145566)
Problem: When backing up a VM, a snapshot of the VM is taken and usually stored in the same datastore as the virtual hard disk that is being backed up. If there is not enough space in the datastore for this snapshot, an error will occur.
If the VM is not running, the error message that is returned will be like the following message:
'API error message : File testVM/testVM.vmx is larger than the maximum size supported by datastore[DataStore1_LUN1_500GB]'.
However if the VM is running, the error returned might not be as obvious and similar to the following message:
'API error message : Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.'
Be aware of the space needed on the VMware datastore for the snapshot files when backing up VMs with large virtual disks. See the following VMware KB article for more detailed information:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012384
Workaround: Use the vmdatastorethreshold option to set the threshold percentage of space usage for each VMware datastore of a virtual machine. See Client options reference: Vmdatastorethreshold.
Affected platforms: Linux and Windows.
Data mover cannot back up itself (internal reference #145568)
Problem: In this scenario, the data mover that runs the backup operation attempts to back up its own disks. This scenario is not supported. As a result, the backup operation fails. A data mover must be backed up by a different data mover.
Workaround: Verify that the data mover that runs the backup operation does not attempt to back up its own disks
Affected platforms: Linux and Windows.
Backing up Windows 2008 and Windows 2008 R2 virtual machines containing dynamic disks (internal reference #145570)
Problem: Backing up Windows 2008 and Windows 2008 R2 virtual machines that contain dynamic disks can result in the dynamic disks being detached from Windows at the end of the backup. The dynamic disks are still intact and can be reconnected to Windows.
This problem occurs because application-consistent quiescing is performed when the snapshot is taken during the backup process. For application-consistent quiescing to be available on Windows 2008 and Windows 2008 R2, one of the conditions that Windows requires is that the virtual machine must not use dynamic disks. This is because VMware uses a hardware provider to perform the VSS snapshot, and shadow copies created by hardware providers of volumes that reside on dynamic disks have a specific requirement that they cannot be imported onto the same system. See the following Microsoft VSS topic for more detailed information: http://msdn.microsoft.com/en-us/library/aa384594%28v=vs.85%29.aspx
Workaround: It might be possible to prevent this message by modifying how part of the virtual machine is quiesced. It is possible to configure the virtual machine so that application data is not quiesced, while still allowing the file system to be quiesced. The implication to this is that application data might not be flushed to disk before the snapshot is taken. File system data will still be flushed, and the I/O held while the snapshot is being taken.
Affected platforms: Linux and Windows.
Restoring virtual machines backed up with IBM Spectrum Protect 8.1.x from low level clients is not supported (internal reference #145571)
Problem: Virtual machines backed up using the 8.1 level of the IBM Spectrum Protect Data Protection for VMware Data Mover cannot be restored from low level clients. This includes prior levels of the IBM Spectrum Protect backup-archive client, as well as prior levels of the IBM Spectrum Protect for Virtual Environments clients.
Workaround: None.
Affected platforms: Linux and Windows.
Backing up a virtual machine that has a IBM Spectrum Protect for Virtual Environments volume mounted (internal reference #145574)
Problem: If the virtual machine being backed up is running IBM Spectrum Protect for Virtual Environments, and has a IBM Spectrum Protect for Virtual Environment volume mounted, the backup of that virtual machine might fail with the message:
Cannot create a quiesced snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.
Workaround: To allow the backup of this virtual machine to continue, unmount the volume from IBM Spectrum Protect for Virtual Environments and retry the operation.
Affected platforms: Linux and Windows.
During virtual machine backup or restore problem with Data Protection for VMware data mover, error message "You do not have access rights to this file" in the dsmerror.log file. (internal reference #145433)
Problem: The Tivoli Storage Manager for Virtual Environments: Data Protection for VMware data mover uses the VMware vStorage API for Data Protection (VDAP) to backup and restore virtual machines in a vCenter Server environment. During virtual machine backup or restore problem with Data Protection for VMware data mover, the VMware vStorage API for Data Protection (VDAP) returns error messages in the dsmerror.log file. Often the error message will be reported to the console if the client is running in the command-line mode. In these messages, note the name of the Tivoli Storage Manager Backup/Archive Client function and the error message text. You will need these values when you read the "Resolving the problem" sections of this document. For more details see Common error message returned by VMware vStorage API for Data Protection (VDAP) and reported in the Tivoli Storage Manager for Virtual Environments: Data Protection for VMware data mover.
Workaround: None.
Affected platforms: Linux and Windows.
"You do not have access rights to this file" or similar error during vm backup/restore with GPO configured user. (internal reference #162908)
Problem: If a user is configured using GPO backup/restore vm may fail with "You do not have access rights to this file" or similar permissions error.
This is due to VMware VDDK expects user to be an administrator: https://kb.vmware.com/kb/52441
Workaround: None.
Affected platforms: Linux and Windows.
Powering on a restored Linux Guest VM with EFI boot enabled might fail. (internal reference #145435)
Problem: Powering on a restored Linux Guest VM with EFI boot enabled might fail. Manual steps are required in order to configure the guest VM to properly boot from the restored Linux EFI boot disk.
Workaround: The following steps describe the procedure to successfully boot from a restored Linux EFI guest VM:
- Remove the boot VMDK from the VM.
WARNING: DO NOT DELETE THE VMDK FILE. - Add the boot VMDK back to the VM and enable the boot in to EFI setup console.
- Boot the machine and use console EFI Setup to reconfigure the boot options, adding the boot VMDK back.
- Use the console EFI Setup to change the boot order.
- Boot the machine.
Message "NBD_ERR_NETWORK_CONNECT (internal reference #145436)
Problem: When using NBD transport, the following error in the dsmerror.log may indicate that a VMware limit of ESX host connections has been exceeded. User action is to reduce the vmmaxparallel and vmlimitperhost options to limit the number of IBM Spectrum Protect connections to the ESX host.
ANS9365E VMware vStorage API error.
TSM function name : VixDiskLib_Open
TSM file : vmvddksdk.cpp (1748)
API return code : 14009
API error message : NBD_ERR_NETWORK_CONNECT
Further VMware documentation can be found here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022543
Workaround: None.
Affected platforms: Linux and Windows.
Restore operations using a HotAdd mode might not clean up target VMDKs from the data mover vmx file. (internal reference #145442)
Problem: If a HotAdd mode is used, during restore operations, target VMDKs might not clean up from the Data Mover vmx file.
Workaround: In order to clear this problem, turn off the Data Mover VM, edit the vmx file to remove the redundant vmdks.
Affected platforms: Linux and Windows.
Unique VM names (internal reference #145450)
Problem: VMware vCenter allows for two or more virtual machines to have the same display name. IBM Spectrum Protect requires that all virtual machine names in a vCenter server configuration be unique.
Workaround: To prevent errors during processing, ensure that all virtual machines have a unique display name.
Affected platforms: Linux and Windows.
Avoid uses of / (slash), \ (backslash) or % (percent) in named elements (virtual machine names, datacenter names, folder names, and so on) (internal reference #145576)
Problem: VMware allows the use of (/, \, %) but VMware internally stores each of these characters as an escape sequence. A slash is escaped as %2F or %2f, a backslash is escaped as %5C or %5c, and a percent is escaped as %25.
If one is using these special characters, then the escape sequence must be used to reference them in the IBM Spectrum Protect client.
For example: OurDatacenter\LevelOne becomes OurDatacenter%5cLevelOne
Workaround: None.
Affected platforms: Linux and Windows.
Virtual machine names containing commas, semi-colon characters, or other special characters (internal reference #145567)
Problem: The following characters have special meaning to Tivoli Storage Manager, and therefore virtual machine names containing these characters cannot be backed up using the FULL VM backup commands.
These special characters are: " ' : ; * ? , < > / \ |
(double quote, single quote, colon, semi-colon, asterisk, question mark, comma, less than, greater than, forward slash, backslash, vertical bar)
Workaround: None.
Affected platforms: Linux and Windows.
English/7bit ASCII virtual machine names (internal reference #145562)
Problem: There are some limitations of the VMware vStorage APIs and in IBM Spectrum Protect processing virtual machines with non-English/7bit ASCII characters in the name. Tivoli Storage Manager support for VMWare backup and restore is limited to English virtual machine names. Names using other languages is not supported at this time.
Workaround: None.
Affected platforms: Linux and Windows.
The diagnostic message ANS0361I may be displayed at the end of a VM backup when using a IBM Spectrum Protect server older then 8.1.2. (internal reference #146408)
Problem: Backing up a virtual machine using the VE GUI on Linux may display ANS0361I at the conclusion. The message has been observed when backing up to a IBM Spectrum Protect server that is older then 8.1.2.
Workaround: The backup completes successfully, therefore there is no need for a workaround.
Affected platforms: Linux.
A very long delay may be experieced while performing operations to the IBM Spectrum Protect Server, before the operation fails with GSKKM_ERR_DATABASE_OPEN (internal reference # 148640)
Problem: The problem is specific to the following scenario on Unix. A user is attempting to configure client/server communication with Secure Socket layers. The version of the IBM Spectrum Protect server is not relevant in this case, but they are using the 8.1.2 IBM Spectrum Protect Client/API. The user manually imports the server certificate (dsmcert.kdb) as a root user, they do this by either running the GSKIT command-line utility program, gsk8capicmd, to import the certificate, or they use the new dsmcert tool. The user then switches to another non-root user on the system, they then attempt to perform IBM Spectrum Protect Client operations. In this scenario, the user will experience a very long delay, anywhere between 5 to 20 minutes, before the client fails with a GSKKM_ERR_DATABASE_OPEN error.
Problem Verification: The operation may appear to be hung, as it could take up to 20 minutes, before failing. The failures may be different depending on the operation being attempted, but a GSKKM_ERR_DATABASE_OPEN error will be logged on dsmerror.log/dsierror.log.
Workaround: The workaround is to manually change the permission on the certificate (dsmcert.kdb) so that both root and non-root users have read access to the certificate files. "chmod go+r dsmcert.*"
Affected platforms: Linux.
DP for VMware Configuration Fails On Linux If Use Existing Data Mover (internal reference #148757)
Problem: The DP for VMware configuration wizard will fail the 'Run Inquire Configuration' step at the end of the configuration. This happens on new installations of DP for VMware in Linux when the user elects to use an existing data mover. This does not affect installing over a previous DP for VMware installation.
Problem Verification: On the last step for the configuration wizard, the 'Run Inquire Configuration" step will show 'Failed'. Clicking on the 'Failed' link will show error ANS0282E, The password file is not available.
Workaround: Uninstall DP for VMware, delete files /etc/adsm/TSM.*, and reinstall DPfor VMware without using pre-existing nodes.
Affected platforms: Linux.
TSM Linux vStorage Server - SAN transport prerequisites (internal reference #146614)
Problem: SAN transport for full virtual machine backup and recovery from a physical Linux TSM vStorage backup server is only supported with the following configuration:
- Datastore must reside on storage hardware that fully supports the vStorage APIs for Array
Integration (VAAI), specifically the VAAI Atomic Test and Set (ATS) feature which is also known as Hardware Accelerated Locking.
If the environment does not meet these prerequisite versions, normal operations on a host server such as power on/off of a virtual machine, snapshot creation, etc. could cause the backup from the vStorage backup server to fail. This problem is not seen when using a Windows vStorage backup server or a Linux vStorage backup server running in a guest VM since the hotadd transport is not effected. When running on a physical vStorage backup server, the problem can be avoided by setting one of the following options:
vmvstortransport "nbdssl:nbd"
vmvstortransport "nbdssl"
vmvstortransport "nbd"
If the storage hardware VAAI ATS feature is not being used the Tivoli Storage Manager Backup-Archive client processing on the Linux TSM vStorage backup server may fail with the following message:
ANS9365E VMware vStorage API error.
TSM function name : vddksdkRead
TSM file : vmvddksdk.cpp (2382)
API return code : 16000
API error message : One of the parameters supplied is invalid
ANS0361I DIAG: ANS1111I VmProcessExtent(): vddksdkRead() rc=-1, startSector=4480000, numSectorsToRead=512
ANS1228E Sending of object 'suse10vm04' failed
ANS5283E The operation was unsuccessful.
This problem is the result of SCSI reservation conflicts. As such, SCSI reservation conflict errors will be reported in the /var/log/messages file on the Linux vStorage backup server.
The TSM BA Linux proxy requires full VAAI support. See VMware KB for description of vStorage for Array Integration (VAAI) support required for TSM BA Linux proxy SAN transport: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976
Workaround: None.
Affected platforms: Linux.
Segmentation fault on some Linux distributions when set LD_LIBRARY_PATH in the shell window or globally (internal reference #121689)
Problem: Setting LD_LIBRARY_PATH=/opt/tivoli/tsm/client/ba/bin in a shell window or globally can make system calls, such as su, have a segmentation fault on some Linux distributions. This is due to version mismatches between the local system libraries and those included in /opt/tivoli/tsm/client/ba/bin directory.
Workaround: Do not set LD_LIBRARY_PATH in the shell window or globally. Instead do the following:
1. Create the following aliases for dsmc and dsmj
alias dsmc='LD_LIBRARY_PATH=/opt/tivoli/tsm/client/ba/bin dsmc'
alias dsmj='LD_LIBRARY_PATH=/opt/tivoli/tsm/client/ba/bin dsmj'
2. Add:
'export LD_LIBRARY_PATH=/opt/tivoli/tsm/client/ba/bin' line to the top of /etc/init.d/dsmcad
and restart dsmcad, for example:
service dsmcad restart
Mount Proxy
Mount Proxy Common Issues and Limitations
-
Instant access and instant restore operations fail when using NFS data stores (internal reference #152739)
Problem: In this scenario, an instant access or instant restore operation specifies an NFS data store as the target data store or as the temporary data store. When an NFS data store is specified, the instant access or instant restore operation fails with the following error messages:-
Operations:
- Instant access
- Instant restore with NFS data store specified as the target data store
Task Details pane in vSphere GUI:ERROR ANS2411E Instant Restore/Access of virtual machine '<virtual machine name>' failed with rc= 4389 ERROR ANS9404E (RC4389) Error creating the specified Virtual machine. See log files for more information.Progress History pane in vSphere GUI:
VM '<virtual machine name>': Creating a virtual machine on the ESX host... VM '<virtual machine name>': ** Unsuccessful **VMware vSphere Client:
A general system error occurred: Error creating disk Function not implementeddsmerror.log file on data mover:
ANS2411E Instant Restore/Access of virtual machine '<virtual machine name>' failed with rc = 4389 12/13/2013 12:48:09 ANS4904E Instant access of VMware Virtual Machine '<virtual machine name>' failed. target node name='<target_node_name>', data mover node name='<data_mover_node_name>'Instant restore with NFS data store specified as the temporary data store
-
Operation:
- Instant restore with NFS data store specified as the temporary data store
Task Details pane in vSphere GUI:ERROR ANS2411E Instant Restore/Access of virtual machine '<virtual machine name>' failed with rc = 6534 ERROR ANS2419E (RC6534) The datastore does not have enough free space for the instant restore operation.Progress History pane in vSphere GUI:
VM '<virtual machine name>': Creating a virtual machine on the ESX host... VM '<virtual machine name>': ** Unsuccessful **VMware vSphere Client: No error message displays.
-
This is a known limitation. VMware does not support iSCSI or vMotion operations with NFS data stores as described in the following VMware Knowledge Base Article:
"Unable to add a physical mode disk mapping (RDM) to a virtual machine stored on an NFS datastore (1001856)" https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1001856
As a result, Data Protection for VMware does not support instant access or instant restore operations when using NFS data stores.
Workaround: Do not specify an NFS volume as a temporary data store or as a target data store. Specify only supported volumes as a temporary data store or as a target data store.
Mount Proxy Windows Issues and Limitations
-
Running parallel Instant Access with VM with a high number of disks might fail (internal reference # 146815)
Problem: When starting multiple instant access operations in parallel, a VM might fail to boot. The operation might fail as it is not able to open additional iSCSI sessions.
Problem Verification: In the recovery agent log a message like:dwSetConnectionSessPointer: Login request Failed. Could not allocate a Session resource.appears in this case. The mount proxy is reporting ANR0519E in its error log file.
Workaround: If instant access is performed for VMs with a high number of disks, run one instant access operation after each other. Perform cleanup of the previous instant access, before starting a new one.
-
Clean up of instant access might fail (internal reference #147528)
Problem: When multiple instant access operations are running in parallel, the clean up of an individual instant access operation might fail. The mount proxy may not be able to remove the iSCSI targets correctly.
Problem Verification: The mount proxy is reporting in its error log file:ANS2469E Unable to remove the iSCSI targetWorkaround: Retry the operation.
Mount Proxy Linux Issues and Limitations
No Mount Proxy Linux specific Issues and Limitations. See section : Mount Proxy Common Issues and Limitations
Self-service File Restore Issues and Limitations
Known issues and limitations for file restore operations that are run from the IBM Spectrum Protect file restore interface are documented in the following technote: File Restore Known Issues and Limitations.
VVol related Issues and Limitations
-
Unable to associate data movers with multiple schedule groups that have similar schedule names in the IBM Spectrum Protect->Configure->Schedules tab (internal reference #147710)
Problem: When there are schedules with names that are alphabetically close to each other and they don't belong to the same schedule group, all the schedules in a group are not identified as a group. When this happens, the value for "Schedules In Same Group" column in the ISP->Configure->Schedules is incorrect. The list is used to associate with the data mover, therefore, the data mover will not be assigned to all the schedules in the group. When the list is setup correctly, the assigning a data mover action is required only once and all the schedules in that group are associated with the specified data mover. For example, there is the following one schedule group with four schedules:ScheduleName ScheduleGroup SchedulesInSameGroup 01MIN everyhour2 16MIN, 31MIN, 46MIN 16MIN everyhour2 01MIN, 31MIN, 46MIN 31MIN everyhour2 01MIN, 16MIN, 46MIN 46MIN everyhour2 01MIN, 16MIN, 31MINWhen the 2nd schedule group is defined with the following schedules below, the third column information is not generated. This is because of the sorted list of schedules retrieved from the server. The list of schedules is not grouped together based on the schedule group name. When the data mover is chosen to be associated to a particular schedule in a schedule group, all the schedules in the group do not get associated with the specified data mover because the list of 'ScheduleInSameGroup' is not setup correctly.
ScheduleName ScheduleGroup SchedulesInSameGroup 00MIN everyhour1 01MIN everyhour2 15MIN everyhour1 16MIN everyhour2 30MIN everyhour1 31MIN everyhour2 45MIN everyhour1 46MIN everyhour2Workaround: Add a prefix to the schedule names so that they can be sorted and grouped together correctly. For example, if the prefix hourly1 is added to every schedule in the schedule group everyhour1 and hourly2 is added to every schedule in the schedule group everyhour2, the third column information is generated successfully:
ScheduleName ScheduleGroup SchedulesInSameGroup hourly1_00MIN everyhour1 hourly1_15MIN, hourly1_30MIN, hourly1_45MIN hourly1_15MIN everyhour1 hourly1_00MIN, hourly1_30MIN, hourly1_45MIN hourly1_30MIN everyhour1 hourly1_00MIN, hourly1_15MIN, hourly1_45MIN hourly1_45MIN everyhour1 hourly1_00MIN, hourly1_15MIN, hourly1_30MIN hourly2_01MIN everyhour2 hourly2_16MIN, hourly2_31MIN, hourly2_46MIN hourly2_16MIN everyhour2 hourly2_01MIN, hourly2_31MIN, hourly2_46MIN hourly2_31MIN everyhour2 hourly2_01MIN, hourly2_16MIN, hourly2_46MIN hourly2_46MIN everyhour2 hourly2_01MIN, hourly2_16MIN, hourly2_31MINLimitation: Solved with v8.1.4
-
Schedule VM backups failed with ANS9365E for VMs reside on NetApp VVol datastore (internal reference #146337)
Problem: Backup of VM that contains disks on both vVol and non-vVol datastores may fail with ANS4174E due to read errors and vCenter communication errors. The dsmerror.log will contain the following errors:<date time> ANS9365E VMware vStorage API error for virtual machine 'boxboro9_CVT_SQL2014_VVOL'. IBM Spectrum Protect function name : VixDiskLib_Open IBM Spectrum Protect file : vmvddksdk.cpp (1885) API return code : 13 API error message : You do not have access rights to this file <date time> ANS9365E VMware vStorage API error for virtual machine 'unavailable'. IBM Spectrum Protect function name : VixDiskLib_Read IBM Spectrum Protect file : vmvddksdk.cpp (3101) API return code : 16000 API error message : One of the parameters supplied is invalid <date time> ANS0361I DIAG: vmbackvddk.cpp (9220): VmReadVDDK(): Read failed: vddksdkRead() rc=0, startSector=4229760, numSectorsToRead=768This issue occurs due to VMware bug identified in the following VMware Knowledge Base article: https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2149271
Workaround:
1) Use vmvstortransport nbd for VMs that contain disks on both vVol and non vVol datastores.
2) Do not configure VMs to contain disks on both vVol and non-vVol datastores.
-
IBM Spectrum Protect for VMware: Virtual Volumes features (hardware snapshot) are not supported for VM that has been storage vMotioned out of VVol datastore (internal reference #134301)
Problem: If a VM located on VVol datastore contains TSM local snapshots created by TSM, when the VM storage vMotioned out of the original VVol datastore, TSM no longer supports any functions related to VVol local snapshot currently relocated to NON VVol datastore even though some functions may appear to work. Those backups should be removed from TSM server manually.
VMware Snapshot Manager may allows the VM to revert those snapshots located in NON VVol datastore but the VM may suffer dataStore I/O performance while up and running. Therefore, TSM does not recommend to use those local snapshot for TSM Revert VM operation nor File Restore operation after VM is relocated to NON VVol datastore.
In case for any reason that the VM needs to Storage vMotion out of VVol Datastore temporary for maintenance, try to storage vMotion to a NON VVol Datastore that is also located to the same back end Storage Sub System if possible for performance reason. Just storage vMotion back when VVol datastore is back to operational.
Example: After the VM is storage vMotioned to VMFS datastore, query backups will show all local backups and restore function still works.Protect>q vm Joanne-VM2 -ina Query Virtual Machine for Full VM backup # Backup Date Mgmt Class Size Type A/I Location Virtual Machine --- ------------------- ---------- ----------- ------ --- -------- --------------- 1 06/13/2017 14:50:58 DDMGMT 49.00 GB IFINCR I SERVER Joanne-VM2 2 06/13/2017 20:00:28 DDMGMT 49.00 GB IFINCR A SERVER Joanne-VM2 3 06/14/2017 18:41:35 VVOLMGMT4 49.00 GB SNAPSHOT I LOCAL Joanne-VM2 4 06/14/2017 18:44:00 VVOLMGMT4 49.00 GB SNAPSHOT I LOCAL Joanne-VM2 5 06/14/2017 20:36:19 VVOLMGMT4 49.00 GB SNAPSHOT I LOCAL Joanne-VM2 6 06/14/2017 20:39:53 VVOLMGMT4 49.00 GB SNAPSHOT A LOCAL Joanne-VM2 Protect> res vm Joanne-VM2 -vmbackuplocation=local Restore function invoked. Restore VM command started. Total number of virtual machines to process: 1 Restore of Virtual Machine 'Joanne-VM2' started Starting full restore of VMware virtual machine 'Joanne-VM2', mode='Snapshot Revert', targ et node name='JT2_VVOL_DATACENTER', data mover node name='JT2_VVOL_DATACENTER_DM' Restoring from a persisted snapshot. Restore processing finished. Successful full restore of VMware virtual machine 'Joanne-VM2', mode='Snapshot Revert', ta rget node name='JT2_VVOL_DATACENTER', data mover node name='JT2_VVOL_DATACENTER_DM'Workaround: Use "dsmc delete backup vm -objtype=vm -ina -pick" to remove all local backups stored on TSM server. The local snapshots will also be removed.
-
DP for VMware vSphere Web Client: Virtual machine "Backup History" with Backup Type "Snapshot" display Error Code 7308 (internal reference #146161)
Problem: If a VM is not on VVol datastore and the VM is scheduled for backup with vmbackuplocation=both, the local backup will fail with the error code 7308 but the server backup will succeed. The failed backup will not be reflected in the number of VM Failed column on the Monitor page of the vSphere Web Client. The bottom table will show the local backup Failed with Error Code 7308 and the server backup Succeeded. The VM task view for this schedule does not show that the schedule has an error. The dsmerror.log will contain the following errors:<date time> ANS4174E Full VM backup of VMware Virtual Machine '5_NONVVOL_LOCAL_ONLY' failed with RC=7308 mode=Snapshot, target node name='CVTVVOL_VC65_VVOLDATACENTER', data mover node name='CVTVVOL_VC65_VVOLDATACENTER_DM' <date time> ANS2708E One or more disks of the virtual machine '' are not in a virtual volumes datastore. Local backup is not allowed. If the VMBACKUPLOCATION option value BOTH was specified, the backup to the server will continue.Workaround: Since the local backup is not applicable for this VM, you can do one of the 2 options below:
1) Update the schedule to do server backup only (vmbackuplocation=server)
2) Assign a local exclude tag for this VM
-
In vSphere 6.5 environment backups on virtual machines that have virtual disk on VMware Virtual Volumes (VVol) can fail (internal reference #137246)
Problem: Backups of virtual machines that reside on an iSCSI VVol datastore can fail when the SAN transport is incorrectly selected
Problem Verification: The backup will fail and the dsmerror.log will contain the following two error messages:02/08/2017 12:57:16 ANS9365E VMware vStorage API error for virtual machine 'TEST_VVOL_VM'. IBM Spectrum Protect function name : VixDiskLib_Open IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (1868) API return code : 13 API error message : You do not have access rights to this file 02/08/2017 12:57:16 ANS9365E VMware vStorage API error for virtual machine 'TEST_VVOL_VM'. IBM Spectrum Protect function name : VixDiskLib_Open IBM Spectrum Protect file : ..\..\common\vm\vmvddksdk.cpp (1868) API return code : 13 API error message : You do not have access rights to this fileWorkaround: It is necessary to force the Virtual Disk Development Kit APIs to use a supported transport for VVol. NBD, NBDSSL or HOTADD are acceptable. The client option VMVSTORTRANSPORT can be used.
For example in dsm.opt file: VMVSTORTRANSPORT=“NBDSSL:NBD“
-
Intermittent backup failure of VMs on VVol datastores. (internal reference #108537)
Problem: A backup VM operation using the scheduler service fails with the following error messages: ANS4174E, ANS1228E, ANS5283E
However, the same VMs can be backed up successfully by starting the operation manually (dsmc backup vm), or by starting the scheduled backup manually using dsmc sched.
The failure occurs when all of the following conditions exist:
- The VMs are on VVol datastores.
- A different userid account is used for the scheduler service. For example, a Local Administrator account versus the Active Directory Administrator account.
Workaround: This is a known issue. To avoid this issue, make sure that the same account is used for all backup operations. If the problem still exists, change the temp working directory in the dsmvddk.opt file by setting the tmpDirectory option. Create this temp working directory using the same account that will be used for performing backups.
Application Protection Issues and Limitations
-
Restore of Microsoft Exchange Server database from VM backup with application protection succeeds but is prevented from removing disk.(internal reference #199650)
Problem: Restore of Microsoft Exchange Server database from VM backup with application protection succeeds but is prevented from removing any disk on the system including the iSCSI disk if disk performance counters enabled and a tool like task manager or resource manager running.
Workaround: Close task manager or other tool that has open handles to drives for its performance counters.
-
IBM Spectrum Protect Snapshot on Windows restore Microsoft SQL Database from VM backup failed with "the object is in use by another process" error. (internal reference #171209)
Problem: Restore Microsoft SQL Database from VM backup failed and report error message "the object is in use by another process" error in dsmerror.log file of backup-archive folder. Problem occurs only when Data Protection for VMware is V8.1.6 or V8.1.4 (backup-archive client 8.1.6 or 8.1.4 too), but Data Protection for SQL or IBM Spectrum Protect Snapshot (with Data Protection for SQL license) is previous release (less than V8.1.4). If Data Protection for VMware and IBM Spectrum Protect Snapshot has the same release version, restore works fine.
Workaround: Make SQL Database offline and restore Microsoft SQL Database will succeed.
-
Restoring a Microsoft SQL database from a virtual machine backup is not supported when the named SQL server instance has the same name as the default instance (internal reference #156941)
Problem: When you are restoring a Microsoft SQL database from a virtual machine backup, the named SQL server instance must be different from the name of the default SQL server instance. If they are the same, the restore operation fails. The default SQL instance name is identified by the network name of the computer. A named instance is identified by the network name of the computer plus the instance name, for example, 'computerName\InstanceName'. Therefore, if the named instance has the value “computerName\computerName”, the restore operation fails.
Workaround: Upgrade IBM Spectrum Protect: Data Protection for SQL Server to version 8.1.4.
-
Virtual machine backup with application protection, client side deduplication and compression fails with 718 version of TSM server (internal reference #156523)
Problem: Virtual machine backup with application protection, client side deduplication and compression fails with the following errors:ANS1228E Sending of object '<vm_name>' failed. ANS1017E Session rejected: TCP/IP connection failure.Data mover log dsmerror.log contains multiple session restart messages: Attempting to restart session for VM <vm_name>. Will try every 15 seconds for 60 minutes.
The issue occurs under the following conditions:
- Data mover is connected to 718 version of TSM server.
- Client side compression and deduplication is enabled.
Problem Verification: problem does not occur if parallel backup functionality is disabled. If parallel backup functionality is enabled, the problem is less likely to occur when VMMAXBACKUPSEssions, VMMAXPArrallel option values match the number of CPUs on data mover.
Workaround:
1. Disable parallel backup functionality by adding TESTFLAG VMBACKUP_OVERLAPPED_IO_DISABLE to data mover options file.
2. Adjust parallel backup options. Set VMMAXBACKUPSEssions, VMMAXPArrallel option values to the number of CPUs on data mover.
-
Application protection (VMVSS) backups appear to be restorable without the IBM Spectrum Protect for Virtual Environments package installed, when in fact they are not. (internal reference #146176)
Problem: If your VM is configured for application protection (i.e. the VEBACKUPNODE option is set), it will display VMVSS backups available on the IBM Spectrum Protect server. However, if you try to restore those backups without the IBM Spectrum Protect for Virtual Environments package installed, the restore will fail with the following warnings:Warning: RC: 1204 ACN5363W IBM Spectrum Protect Recovery Agent is either at an earlier level or not found. The VM backup data query or restore is not issued. ACN5365W Restoring from the VM backup is disabled. Restore actions are usually disabled because of license issues or code incompatibility issues.Workaround: To restore VMVSS backups, you must first install IBM Spectrum Protect for Virtual Environments.
-
Cannot mount DB after application protection restore with replay of current and restored logs (internal reference #128296, #141548)
Problem: Failure to mount DB after restore. Exchange DB restore completes successfully, but it’s not possible to mount the DB. This is due to failure to revert volume to the snapshot taken at backup time.
Under some conditions application protection code may use VSS system provider to create an application consistent shadow copy before VM backup. VSS system provider uses copy-on-write method to create shadow copy. This means that all changes made after shadow copy creation time are written to a special area - shadow storage. Usually Windows keeps shadow storage with the volume. For example, volume F: shadow storage is located on volume F:. It is possible to move shadow storage between volumes. In such cases, when shadow storage location has been altered, DB restore may fail. Such failure happens because shadow copy, created at backup time using VSS system provider, is not available at restore time. Shadow copy is used at restore time to revert restored volume to application consistent state. If it’s not available data after restore will be in inconsistent state.
One more explanation why VSS shadow storage is not available is that the volume with shadow storage was excluded at backup time.
Workaround 1: Before VM backup, add shadow copy storage association for each volume available on guest VM using the following command:
vssadmin add shadowstorage /for=E: /on=E: /maxsize=unbounded
Note: 'vssadmin add shadowstorage' command might fail if virtual machine has VSS snapshots. In such case, delete VSS snapshots using the same application that created them. If you have a VSS backup of Exchange database with LOCAL backup destination created by Data Protection for Exchange, use Data Protection for Exchange application to delete this backup. Unidentified VSS snapshots can be deleted using Windows Diskshadow command 'delete shadows'
Workaround 2: Manually revert snapshots to achieve application consistency of database files:
- Mount all disks in VM backup using Recovery Agent
- Start Windows DiskShadow command in interactive mode. Issue "list shadows all" command
- Find "ShadowCopyID.txt" file in the root of each mounted drive. This file contains VSS shadow copy GUID to be used in volume revert operation.
- Find the GUID of the volume where the DB files are.
- Issue DiskShadow revert command: 'revert [GUID]' where GUID is the snapshot GUID from ShadowCopyID.txt file.
-
Inconsistent Status for Application Protection Backups (internal reference #130305)
Problem: The IBM Spectrum Protect Monitor tab in the vSphere client shows a list of virtual machines (VMs) and their backup status with an option to view the entire history of a particular VM in the Backup History table below the main status table.If a backup occurs when a VM is powered off while also having IBM Spectrum Protect Application Protection enabled, the main status table shows that the VM's backup was successful when it was actually not successful.
Since the VM was powered off at the time of the backup and an Application Protection Backup was not successful, a retry with non Application Protection was attempted and was successful. This results in the status being reported as success in the At Risk Table because a backup does exist for the VM, but that status is unsuccessful in the Backup History table because the Application Protection backup attempt was not successful.
Problem Verification: To determine if this problem has occurred, check to see whether the VM has been configured to have Application Protection enabled. If Application Protection is enabled and the VM was also powered off at the time of the backup, the main status table will show that there was a "Last Successful Backup" for the VM. However, the VM's Backup History Table will show that the backup has failed.
Workaround: VMs need to be powered on for a successful Application Protection backup to occur.
-
VM backup with application protection shows after snapshot quiesce error one extra snapshot attempt. (internal reference #130975)
Problem: During VM backup with application protection, if errors occur quiescing the snapshot, there could be an extraneous retry attempt.
For example:ANS4066I Snapshot operation attempt 2 of 3 for the guest virtual machine 'tsmcetwin106' failed using "VMware Tools" snapshot. Reattempting snapshot with "VMware Tools" snapshot. Creating "VMware Tools" snapshot for virtual machine 'tsmcetwin106' Starting Full VM backup of VMware Virtual Machine 'tsmcetwin106' mode: 'Incremental Forever - Incremental' target node name: 'LINH_DM' data mover node name: 'LINH_DM' application protection type: 'VMware' application(s) protected: 'n/a' ... ANS4073W Snapshot operation attempt 2 of 3 for the guest virtual machine 'tsmcetwin106' failed using "VMware Tools" snapshot. Reattempting snapshot with "VMware Tools with file system quiescing and application quiescing (VSS) disabled" snapshot.Problem Verification: an additional snapshot attempt is there
Workaround: To work-around the problem, you can decrease the number of attempts by 1.
Limitation: Solved with v8.1.2, see APAR IT18413.
-
Concurrent backup or restore of the same VM guest is not supported (internal reference #152740)
Problem: In this scenario, a VM guest backup or restore operation is running. Before processing completes, a second backup or restore operation of the same VM guest is started. This type of concurrent backup or restore of the same VM guest is not supported. If you attempt to run multiple concurrent operations of the same VM guest, the second operation fails. In addition, the first operation might also fail. This is a known limitation.
Workaround: Run only one operation of a VM guest at a time. For example, if you are backing up a given VM guest, do not attempt to run another backup or restore operation of that same VM guest. Likewise, if you are restoring a given VM guest, do not attempt to run another backup or restore operation of that same VM guest.
-
VM backup with application protection VSS unfreese failure due to 10 seconds flush and hold timeout (internal reference #124111)
Problem: VMware guest backups with application protection for Microsoft Exchange or Microsoft SQL servers may fail with:ANS2330E Failed to unfreeze the VSS writers because the snapshot time exceeded the 10 second timeout limitationThis behavior may have different root causes and is described in APARs IT15552 or IT15991 (additionally VMware KB https://kb.vmware.com/kb/2150648 )
Workaround: When this occurs, proceed with one of the following:
- stop VM backup with data protection on and continue backup VM without data protection or install data protection product inside the VM.
- apply the workaround from IT15991 ( https://kb.vmware.com/kb/2150648 )
-
Backup of a VM with application protection fails when one (or more) Microsoft Exchange Server 2013 databases are dismounted (internal reference #154505)
Problem: In this scenario, a virtual machine with application protection enabled was backed up with Data Protection for VMware. However, the virtual machine contained one (or more) Microsoft Exchange Server 2013 databases that were dismounted. As a result, the backup operation fails with the following warning message:ANS9432W IBM Tivoli Storage Manager application protection failed to truncate application logs on virtual machine 'VM-name'Workaround: Mount the Exchange Server 2013 database, then run the backup operating again.
-
Unsupported restore tasks when the Microsoft Exchange Server database changes after virtual machine backup (internal reference #154506)
Problem: An Exchange Server database restore or user mailbox restore from the backed up virtual machine are not supported when either of the following issues occur after the virtual machine is backed up:
- The database is relocated to a different volume.
- The database path changes.
Workaround: None.
Recovery Agent Issues and Limitations
Microsoft Bitlocker encryption not supported (internal reference #200411)
Problem: File-level restore for BitLocker-encrypted drives on Windows virtual machines is not possible.
This limitation applies to file-level restore in all versions of VMware and Microsoft Hyper-V environments.
Workaround: n/a
Affected platforms: Windows
Limitation: Since V8.1.0. Peramant restriction, see APAR IT36049.
Recovery Agent may exit during unmount operation on Windows 2016 (internal reference #131800)
Problem: On Windows 2016 Server, the Recovery Agent GUI may exit during the unmount operation. The unmount operation does complete successfully event though the GUI exits.
Workaround: The Recovery Agent GUI must be restarted.
Affected platforms: Windows
Limitation: Since V8.1.0. Solved with v8.1.2, see APAR IT18933.
Mount of RAID volume requires significant temporary storage space (internal reference #146608)
Problem: When the Recovery Agent mounts a volume on a Windows system, it stores volume-related metadata as write cache in a temporary directory under C:\ProgramData\Tivoli\TSM\RecoveryAgent\mount.
This temporary directory requires nominal storage space. However, when the Recovery Agent mounts a RAID volume on a Windows system, this temporary directory requires greater storage space. For example, if you have a RAID volume on four 5 GB disks, the temporary directory requires 5 GB of storage space.
This space requirement is a known issue that is related to RAID volumes.
Workaround: If you plan to mount a RAID volume on a Windows system, you can resolve this issue with either of the following methods:
- Increase available space on the system drive so that sufficient storage space is available in C:\ProgramData \Tivoli\TSM\RecoveryAgent\mount to accommodate the RAID volume-related metadata.
- Configure the Recovery Agent to store temporary volume-related metadata on a different drive with sufficient space. Click Settings in the Recovery Agent GUI, then specify a different drive in the Folder for temporary files field.
Affected platforms: Windows
Limitation: Since V8.1.0.
Direct mount and restore functions unavailable after installing the Recovery Agent device driver in silent mode (internal reference #146611)
Problem: In this scenario, the Recovery Agent device driver ("Mountdriver" 32-bit; "mountdriver" 64-bit) was installed in silent mode. However, the Recovery Agent cannot mount directly or restore data.
Workaround: To resolve this issue, register the Recovery Agent device driver and restart the system by completing the following steps:
- Open a command prompt in administrator mode.
- Issue the following command from the Recovery Agent "mount" folder:
install.exe C:\\Windows\\system32\\drivers\\fbvv.inf fbvv >> installFBVV.log 2>&1 - Restart the system.
Affected platforms: Linux and Windows
Limitation: Since V8.1.0.
Installation Issues and Limitations
Data Protection for VMware Linux Install in 8.1.10 Installs All Options (internal reference #195984)
Problem: When running an install of Data Protection for VMware in 8.1.10, the installer allows for 3 options: Documentation, Data Protection for VMware Data mover and Data Protection for VMware GUI. Even if a subset of these are selected all components are installed. All components will work correctly, it is just not possible to only install a subset of the components.
Workaround: The problem is only seen when running the install in console mode (-i console). Run the install in silent mode or using the install configuration wizard GUI mode to avoid the problem.
- To install only Data mover using the silent install from the root of the installation folder, run the following commands:
cd CD/Linux/DataProtectionForVMware ./install-Linux.bin -i silent -DLICENSE_ACCEPTED=true -DCHOSEN_INSTALL_SET=Custom -DCHOSEN_INSTALL_FEATURE_LIST=TDPVMwareDM - To install using the Install configuration wizard GUI use the following commands:
cd CD/Linux/DataProtectionForVMware ./install-Linux.bin -i swing
Complete installation information including uninstalling of components that are not needed from prior install, see Installing the Data Protection for VMware components by using the installation wizard.
Affected platforms: Linux
Limitation: Since V8.1.10. Solved with v8.1.11
IBM Data Protection for VMware plug-in Not Upgraded in Different Domain (internal reference #184832)
Problem: An upgrade of IBM Spectrum Protect Data Protection for VMware results in the plug-in not being updated. The plug-in will show itself as being the previous level, despite a successful upgrade. The symptom of this issue is the IBM Spectrum Protect -> Configure -> Connections in the vSphere Client shows a version unsupported message with the GUI host being a higher level than the plug-in.
This can occur when the vCenter can not 'ping' the IBM Data Protection GUI host because they are in different domains. The upgrade installer uses the GUI Host machine name and registers it, which can not be contacted by the vCenter.
Workaround: The solution is to re-register the plug-in using the correct fully qualified GUI host name or IP address. To do this, login to the GUI host configuration wizard in 'configuration mode'. On the vCenter Settings page, check "Update registration" Enter in the GUI host address or IP address that can be reached by the vCenter. Click "Next" on all pages and "Finish" at the end. Once the plug-in is successfully registered with the correct address. Log back in to the vCenter to verify it has been updated.
Affected platforms: Linux and Windows
Limitation: Since V8.1.6. Solved with v8.1.8.
The metadata for some of the files deployed with Data Protection for VMware is not up to date(internal reference #185331)
Problem: This issue is informational only and does not affect the operation of Data Protection for VMware in any way. Some of the deployed files are:
- not digitally signed by IBM
- missing 'IBM Corporation' from the company information property
- missing a 2019 Copyright statement
- not versioned
Workaround: Ignore the missing information.
Affected platforms: Windows
Limitation: Since V8.1.8.
Invalid license message not shown (internal reference # 171765)
Problem: A licensed install of IBM Spectrum Protect Data Protection for VMware can be upgraded using the FTP download without incident. However if the FTP installer is used a new install, which is not supported, the install will be successful. However once the product is used in a backup operation, errors will appear in the logs. The issue is that the source of the error, having no license, is not clear. The message a user will see instead is:
ANS0322E (RC6583) no text available for this return code
Problem Verification: If the user sees the following message after a FTP install:
ANS0322E (RC6583) no text available for this return code, then this issue has been seen
Workaround: There is no workaround, since this is a valid error. The lack of description for the error is the issue. The user should only do a fresh install with the DVD version of IBM Spectrum Protect Data Protection for VMware, since that is the path that installs a license. The FTP package is meant solely for upgrades to existing licensed installations.
Affected platforms: Linux and Windows
Limitation: Since V8.1.6. Solved with v8.1.7.
Un-installation does not remove all files and directories (internal reference #139990)
Problem: With each installation of IBM Spectrum Protect for Virtual Environments a directory is created in C:\Windows\Downloaded Installations\. The names of the directory are arbitrary GUIDs like {F5999A64-42AF-4DDF-AB56-F3445714C4AB}. Each directory contains files, like 1033.MST and IBM Spectrum Protect for Virtual Environments Data Protection for VMware.msi where the msi file is around 100 MB. After uninstall, these directories and files are left around in the system. Performing multiple installs and uninstalls of the product will eventually take up a large amount of space on the system.
Workaround: Go to C:\Windows\Downloaded Installations\ and delete the directories where IBM Spectrum Protect for Virtual Environments Data Protection for VMware.msi or IBM Tivoli Storage Manager for Virtual Environments Data Protection for VMware.msi is present.
Affected platforms: Windows
Limitation: Since V8.1.0. Solved with v8.1.2.
Un-selecting during GUI upgrade or not specify plug-in and Web Extension during silent upgrade will not un-register either (internal reference #121811)
Problem: When doing a upgrade of Data Protection for VMware if the user has the GUI plug-in and/or Web Extension registered and deselects either during the GUI upgrade or does not specify them in the command line of the silent install, the unregister will fail and a popup warning message will be displayed informing the user to manually unregister them. The GUI plug-in and/or Web Extension will remain registered after upgrade
Workaround: The user can manually remove the GUI plug-in and/or Web Extension.
From and elevated command window change directory to: C:\Program Files (x86)\Common Files\Tivoli\TDPVMware\VMwarePlugin
Run the following command to remove the plug-in:
C:\IBM\tivoli\tsm\tdpvmware\webserver\jre\jre\bin\java -jar unreg.jar VCENTER_HOSTNAME VCENTER_USERNAME VCENTER_PASSWORD HOST_NAME
Run the following command to remove the web extension:
C:\IBM\tivoli\tsm\tdpvmware\webserver\jre\jre\bin\java -jar unreg.jar -wc_ext VCENTER_HOSTNAME VCENTER_USERNAME VCENTER_PASSWORD HOST_NAME
Affected platforms: Windows
Limitation: Since V8.1.0.
Modify option (in maintenance mode) does not modify the selected feature on Windows 64-bit systems (internal reference #146627)
Problem: In this scenario, after you completed the initial installation of a Data Protection for VMware feature (such as the Data Protection for VMware Enablement File or Data Mover), you restart the installation process and select Modify to modify an installed feature. However, after you select the feature and click Next, the installation program displays the "InstallShield Wizard Complete" page. It does not display the installation process for the selected feature. This is a known problem.
Workaround: To modify an installed feature, first clear the check box for this feature, then select the check box for this feature again. Click Next to proceed with the modification.
Affected platforms: Windows
Limitation: Since V8.1.0.
Upgrading a vCenter Server from 5.5 to 6.0 may result in incomplete IBM Tivoli Storage Manager task messages in the vCenter Client Task Panel (internal reference #154502)
It is unclear if an error occurred during the upgrade process or not but in one instance incomplete messages were observed. The messages look like the following:
XXX com.ibm.tsm.tasks.backup_vm_scheduled.label not found XXX
XXX com.ibm.tsm.tasks.backup_vm.label not found XXX
XXX com.ibm.tsm.tasks.restore_vm.label not found XXX
The issue can be corrected by logging in to the vCenter Managed Object Browser and removing the old IBM Tivoli Storage Manager extensions. The extensions will be added back during the next backup or restore.
1. Go to (vCenterServer)/mob/?moid=ExtensionManager
2. You should see the following extensions: "com.ibm.tsm.tasks"
3. In the "Methods" section select the method "UnregisterExtension"
4. Enter the extension names "com.ibm.tsm.tasks" and press "Enter".
Workaround: None.
Affected platforms: Linux and Windows
Limitation: Since V8.1.0. Solved with 8.1.10.
Linux: (Un)installing from PuTTY in console/silent modes fails (internal reference #163165)
Problem: While using PuTTY, InstallAnywhere fails to switch to console and silent modes during VE install and uninstall.
This happens because InstallAnywhere cannot handle or bypass an X11 connection, if the connection is no longer established or never existed.
Received message:
PuTTYNG X11 proxy: unable to connect to forwarded X server: Network error: Connection refused
=======================================================
Installer User Interface Mode Not Supported
Unable to load and to prepare the installer in console or silent mode.
=======================================================
Workaround: Install an X Server running on Microsoft Windows (example: Xming) and start it.
Set "Enable X11 forwarding" from "PuTTY Configuration"->"Connection"->"SSH"->"X11".
To verify if the connection is established:
- Log on to the Linux machine with PuTTY.
- Execute "xclock" command or a similar command.
If a window showing the time appears, the connection is established.
Affected platforms: Linux
Limitation: Since V8.1.4.
Related Information
Was this topic helpful?
Document Information
Modified date:
21 March 2022
UID
swg21993762