MBS Agent Agent for VMware ESX Server Version 6.70.2044b Release Notes
1 Agent for VMware ESX Server Version 6.70.2044b Release Notes, February 11th, 2010 1 OVERVIEW This document contains release notes for the Agent for VMware ESX Server. This Agent provides disaster recovery protection for VMware ESX environments. The Agent for VMware ESX Server runs on the ESX Server Console. You can manage it with Web Agent Console 6.70 or Windows Agent Console 6.70. The Agent kit consists of three programs (VV, VVAgent, and buagent), plus the VMware Plug-In (vmwareplugin.so). VVAgent and buagent are Agent (daemon) components. VV is a command-line program used to perform such tasks as backups, restores, and synchs. 1.1 Release History Version 6.70.2044, January 4th, 2010 Version 6.70.2044a, January 22nd, 2010 Version 6.70.2044b, February 11th, 2010 1.2 Supported Platforms - ESX Server Console 3.0, updates 1 through 4 - ESX Server Console 3.5, updates 1 through 4 - ESX Server Console 4.0, including update 1 2 FEATURES The Agent for VMware ESX Server has been designed to allow you to perform a "hot" backup of a VMware virtual machine. The Agent now supports VMotion. You can perform VM backups without reseeding when you use VMotion to migrate VMs from one ESX server to another. This applies even if a VM is VMotioned during a backup operation, or if VMotion fails. You can centrally manage your Agents with Web Agent Console or Windows Agent Console. You can select one or more virtual machines for backups and restores. You can use wildcards in name filters for backups, but the Agent does not support multiple wildcard selections on the same line. For example, "a*,b*" will include a VM named "alpha,beta" rather than two VMs named "alpha" and "beta". When you manage a Job through Web Agent Console, the current VM name displays.
2 You can restore a VM to its original location, or an alternate datastore. During the process, you can optionally register the VM. VMs with multiple disks on multiple datastores will consolidate to a single datastore. You can restore a VM as its component files to an alternate directory on disk, and then register them manually. This allows you to recover individual VM disk files and attach them to other VMs. The component files will be restored to directories whose names include the names of the datastores where the files originally resided. You can restore VMs backed up from one ESX Server to another ESX Server with the "Restore from another Computer" workflow. Backup Job logs now report the status of individual VMs. This allows you to quickly identify machines that require attention. Also, each log provides a list of VMs that were not accessible to the Job (because they were on local storage of a different ESX server from where the Agent was running). You can now protect ESXi servers in mixed ESX/ESXi environments. This applies even if there is only one ESX server in a large ESX/ESXi cluster. Also, you can now back up and restore VM templates. Thin-provisioned virtual disks are now supported. They are backed up as regular disks. Bandwidth Throttling: You can either let the Agent use all available bandwidth for backup Jobs, or "throttle back" to restrict the usage. In other words, you can limit the number of Mbps (megabits per second) used. You can also schedule (turn on and off) Bandwidth Throttling by the time of day, and day of the week. Performance improvements with reduced backup and recovery time. The Agent can take advantage of a multi-processor system. It can also use multi-threading. Logical Vault Replication (LVR) Support: The Agent supports Vaults configured for LVR, and automatically determines the correct Vault and backup data if the logical Vault has changed. For example, if the active Vault has failed, and the passive one has become the active one, the Agent will synchronize and switch over to the new one. The log file will show this activity. Delta file recreation support: The Agent can recreate a missing delta file using additional Vault information from the backup. This does not work on a corrupted delta file. In that case, you must manually delete the file before you run the synchronize command. If the delta information has only been partially recovered, some data may reseed during the backup. Additional information will appear in the log if a delta file has been recreated. Force reseed through CLI: Delta recreation allows you to rebuild a delta (DTA) file through Job synchronization. You can use the /forcereseed option to force a reseed in case of a delta recreation failure during the rebuilding of a delta file. Longer path name support: Agents for VMware ESX Server that are connected to version 6.x Vaults support path names as long as 4096 characters. Older versions only supported 511 characters. The supported lengths will appear in the log files. Regardless of backward compatibility, older Agents will not be able to restore from file or folder backup Jobs that contain the longer path names.
3 Cross-catalog searching: You can search through all available catalogs when you restore files (without needing to switch Restore Wizard screens). You can select one safeset, or a range of safesets. Longer Job names: Job names can now be up to 30 characters in length. 3 INSTALLATION NOTES 3.1 Installation Requirements Hardware You must install the Agent for VMware ESX Server on an ESX Server Console version 3.0, 3.5, or 4. Software * Vault version 5.53 or above * Web Agent Console version 6.70 or Windows Agent Console version 6.70 * Network - a TCP/IP stack (to communicate with Agent systems) You can back up machines running on any ESX server in the vcenter, as long as its storage is accessible from the host running the Agent (i.e., storage is on a SAN). You cannot back up VMs that are only in local storage of other ESX servers. 3.2 Conditional Requirements vcenter 2.5 or 4.0 to support VMotion 3.3 Installing/Uninstalling/Upgrading Upgrades from versions 5.61 and 5.62 of this application are supported. ******************************************************** UPGRADING YOUR ESX SERVER: ******************************************************** For best results, DO NOT USE the CD or DVD upgrade for VMware ESX because this will erase your entire ESX installation disk, including your Agent installation and all associated files. This will force your backups to reseed. Instead, use the esxupgrade.sh script from VMware KB article #1009440 (http://kb.vmware.com/kb/1009440). The Agent upgrade should work properly when you use this script. 4 FIXES and KNOWN ISSUES 4.1 Fixes in This Release
4 In previous versions, when the Agent for VMware ESX Server 6.70 needed to communicate with the vcenter, certain configurations failed. This caused an inability to browse for virtual machines during Job creation. Agent communication with the vcenter has been modified to resolve the problem. Note that Web Agent Console and Windows Agent Console do not distinguish between the 6.70.2044 (GA) release and its hot fixes. To determine precisely what has been installed, obtain the md5sum value from the libvi3.so file, and compare it to the following values: GA 6.70: 92aa2f793693d0363b2859fd84967272 6.70 HOT FIX A: c55e7cd19136f16ecf4811038ae9fa86 6.70 HOT FIX B: 36bc831b228f15ccfd78e20f0acb611b To obtain the md5sum value, issue the following commands (assuming that the Agent is installed in /usr/local/buagent, which is the default): cd /usr/local/buagent md5sum libvi3.so (17338) The Agent installer no longer permits you to enter invalid directory paths. All paths must be entered as absolute paths. If you have mistakenly installed an Agent using a relative path, you can correct this by editing the "agentdir" line in /etc/init.d/vvagent: agentdir=<relative-path> Specify the absolute path where the Agent has been installed: agentdir=<absolute-path> (17322) When you restore VMs to alternate locations, you can no longer select overwriting/renaming options. (17270) Inaccessible VMs are now "grayed out" in Web Agent Console, and you cannot select them. (17150)
5 In previous versions, backups would sometimes fail with an "Unexpected transition from fid(0xf) to fid(0x5)" error. This has been corrected. (16944) When you use the "Restore from another Computer" workflow, the Job may fail to restore because of missing VMware credentials. The error message does not clearly identify the cause: PLGN-E-05735 UNKNOWN ERROR in initrestore() Through Windows Agent Console, you can edit the Job to add the necessary credentials. You can then run the restore Job normally from that point. Previously, you were not able to modify the Job through Web Agent Console in order to add these credentials. This made it impossible to use the "Restore from another Computer" workflow. You can now use this workflow because it prompts you for the appropriate VMware credentials. (16756) In previous versions, permission errors sometimes appeared in the log if you restored from a VM backup that was done live on ESX 3.0. This behavior has been corrected. (16380) VMs that you select through wildcards and explicitly include in a backup Job will only be backed up once. (15200) In previous versions, the process of uninstalling the Agent sometimes left ESX firewall ports open. This behavior has been corrected. (13013) In previous versions, there was no option to exclude specific VMs from backup Jobs. An option for excluding is now available. (12250) 4.2 Known Issues Sequences of VM backups and restores using the "Restore VMs to an alternate datastore" option may cause an error (e.g., "File <unspecified> not found") when the restored
6 VM is started. WORKAROUND: Remove or rename Agent-created memory snapshots before you run the next backup after a restore operation. (17521) Email notification regarding the success/failure of Jobs has been disabled for this release. (17498, 17459) If you back up a VM whose name contains a semicolon (;), the Restore Wizard in Windows Agent Console will only display the characters that follow the semicolon. (17460) In some cases, VMX files may not be backed up if the Agent is not running on the ESX that hosts the VM. WORKAROUND: Manually edit the VMX file before you restore. (17292) Independent disks can only be backed up when the VM is powered off. (17233) Deferred VMs may not be documented appropriately in logs. A deferred VM may be marked as Incomplete, and an error message (instead of a warning) may display. (17215) When you create a VM from a thin disk, backup and restore Jobs can succeed. Restoring, however, converts thin disks to thick disks. This increases the used space to the (maximum) configured size. (17095) If you use Web Agent Console to explicitly include a VM that has been implicitly selected through a wildcard, the VM will display in the selection list. If you then select the same VM for "Exclude", the VM will be removed from the selection list. However, because the VM has been implicitly selected, it will still be backed up. This is the expected behavior of the Web Agent Console because you are reversing an explicit selection. To exclude the VM, click "Exclude" again. (17049) If you use VMotion to migrate a VM from ESX server 'A' to 'B', and you subsequently create a new Job (or modify
7 a Job on ESX server 'B') to include this VM, it will result in a reseed of the migrated VM. The Agent does not support backups of RDM (Raw Device Mapping) logical or physical disks. Any snapshots of a VM, except those created by the Agent, will be included in the Agent's backup of a VM as part of the VM's data files. If one of the Agent's snapshots is deleted while the backup is running, the backup will fail. Errors will be reported for the VM if a non-agent snapshot is removed during backup. The Agent does not back up removable storage devices (such as floppy disks and CD-ROMs) on virtual machines. These files are inside the VMs, so you can back them up using additional local-file backup Jobs. VMs created on later versions of ESX may not run on earlier versions of ESX due to VMware hardware version differences. We recommend restoring to the same version of ESX, or a more recent version. REGISTERING A VM MANUALLY The Agent will normally register a restored VM for you automatically. If registration fails (e.g., according to the log; or the files of the VM have been restored, but the VM does not appear in the GUI; or you have restored the VM to an alternate location, in which case the Agent will not register the VM for you), you can register the VM yourself. Using the VMware vsphere client (or the Infrastructure client): 1. Browse the datastores to locate the VMX file of the restored VM. (You must have restored the VM to an accessible datastore.) 2. Right-click on the VMX file, and then select "Add to inventory". Log in to an ESX server that has the command-line tools installed. The ESX server on which the Agent is installed should be suitable. The vmware-cmd command must be available. Use this command to verify its presence:
8 vmware-cmd -l If you see "Command not found", the vmware-cmd is not available, and needs to be installed. Otherwise, it will list all of the registered VMX files. To register the VM, issue the vmware-cmd command through the VMware command-line interface: vmware-cmd -s register /vmfs/volumes/datastore-name/restored-path/vm-name.vmx The path is the full name of the VMX file. You might need to register a VM to a different ESX host, or an ESX host that does not have access to the restored VMX file. If so, see the following documentation for detailed information about the syntax of vmware-cmd, or use the GUI. VMware documentation for the command-line interface: http://www.vmware.com/pdf/vsphere4/r40/vsp_40_vcli.pdf (Chapter 5) http://www.vmware.com/support/esx21/doc/vmware-cmd.html