EVault vSphere Agent Version 7.12.1231 Release Notes, August 22, 2013 ______________________________________________________________________ ====================================================================== CONTENTS 1 OVERVIEW 1.1 Release History 1.2 Supported Platforms/VMware Infrastructure 1.3 Supported Systems for File and Folder Recovery 2 NEW FEATURES 3 INSTALLATION NOTES 3.1 Installation Requirements 3.2 Conditional Requirements 3.3 Licensing Requirements 3.4 Install/Upgrade 4 FIXES and KNOWN ISSUES 4.1 Fixes 4.2 Known Issues 5 PRODUCT SUPPORT 5.1 Technical Support 5.2 Product Updates 5.3 Documentation ______________________________________________________________________ ====================================================================== 1 OVERVIEW This document contains release notes for EVault vSphere Agent 7.12. This Agent provides recovery protection for VMware vSphere environments without requiring the ESX Service Console. A single vSphere Agent can support a vCenter Server with as many as 1000 VMs; you do not have to install the Agent or other software on each VM you want to back up. You can back up your VMs to a secure, remote vault. The Agent supports granular file restores. This allows you to select and restore specific files and folders from a VM, rather than restoring an entire VM or individual virtual disks (VMDKs). The Agent is pre-installed in a VM and provided in OVA format. vSphere Agent 7.12 is for use in combination with: - EVault Software Windows CentralControl version 7.22 or later - EVault Software Web CentralControl version 7.21 or later For VM and VMDK restores, you can use Director version 6.22 or later. To ensure successful backups and restores in N:1 replicated environments, the Director must be version 6.31 or later (or version 6.22 with a hotfix obtained from EVault Support). For granular file and folder restores, Director 7.00 or later is required. Files and folders can be restored from safesets that were created using vSphere Agent version 6.90 or later and version 6.x vaults, but only after both the Agent and Director are upgraded to version 7.00 or later. ----------------------------------------------------------------------- 1.1 Release History Version 7.12.1231, August 22, 2013, sixth release Version 7.11.1209, June 27, 2013, fifth release Version 7.10.1164, December 5, 2012, fourth release Version 7.02.1119, October 16, 2012, third release Version 7.01.1117, September 24, 2012, second release Version 7.00.1107, August 8, 2012, first release ----------------------------------------------------------------------- 1.2 Supported Platforms/VMware Infrastructure vSphere ESX and ESXi hosts: - ESXi 5.1 (up to 5.1a) - ESXi 5.0 (up to update 1) - ESXi 4.1 (up to update 3) - ESX 4.1 (up to update 2) vSphere vCenter Servers: - vCenter Server 5.1 update 1b - vCenter Server 5.1 update 1b Linux Appliance - vCenter Server 5.0 (up to update 2) - vCenter Server 4.1 (up to update 3) ----------------------------------------------------------------------- 1.3 Supported Systems for File and Folder Recovery For file and folder recovery, the vSphere Agent currently supports the following operating systems and file systems. Windows: - NTFS - FAT - FAT32 - Dynamic disks Note: GPT partitions are not supported for file and folder recovery. Linux: - ext3 - ext4 _______________________________________________________________________ ======================================================================= 2 NEW FEATURES 2.1 New Feature in Version 7.11 - A solution for securing shared VMDKs during granular file and folder recovery is now available. This solution requires some manual steps. For more information, please contact Support. ---------------------------------------------------------------------- 2.2 New Features in Version 7.10 vSphere Agent now supports vSphere version 5.1, including the following features: - vCenter Single Sign-On server. vSphere Agent can authenticate with a vCenter Single Sign-On server configured with multiple Active Directory domains. - Hardware version 9. vSphere Agent can back up and restore VMs that are running hardware version 9. - vCenter Server Appliance. vSphere Agent can back up and restore VMs in a vCenter that is managed by the vCenter Server Appliance. - vSphere 5.1 vMotion. vSphere Agent can back up VMs that have been migrated to another host. ---------------------------------------------------------------------- 2.3 New Features in Version 7.00 vSphere Agent now supports granular file and folder recovery. This allows you to restore specific files and folders from a VM backup, rather than restoring an entire VM or VMDK. For example, you can restore individual files from a My Documents folder (or even the entire My Documents folder) instead of restoring the entire VM or VMDK where the folder resides. For granular file and folder recovery, vSphere Agent version 7.00 or later and EVault Software Director version 7.00 or later are required. If you use a Director version earlier than 7.00, you cannot restore specific files or folders. Files and folders can be restored from safesets that were created using vSphere Agent version 6.90 or later and version 6.x vaults, but only after both the Agent and Director are upgraded to version 7.00 or later. To restore VMs and VMDKs, you can use Director version 6.22 or later. To ensure successful backups and restores in N:1 replicated environments, the Director must be version 6.31 or later (or version 6.22 with a hotfix obtained from EVault Support). Note: Users do not have to enter credentials to access files on a VMDK that has been shared. You can limit the amount of time that a VMDK is shared using an Idle time option. However, if you have security concerns, do not perform file and folder restores; restore entire VMs or VMDKs instead. Note: The vSphere Agent backs up VMs with VMDKs as large as 2032 GB. 2032 GB is the maximum VMDK size recommended by VMware to allow sufficient overhead for snapshots, and snapshots are required for vSphere Agent backups. If a backup job includes a VM with a VMDK that is larger than 2032 GB, the VM is skipped during the backup. _______________________________________________________________________ ======================================================================= 3 INSTALLATION NOTES 3.1 Installation Requirements Hardware -------- See the VMware website for supported and recommended hardware platforms. Ensure that the vCenter has sufficient resources, including CPU and memory, for the vSphere Agent and all VMs in your vCenter. Ensure that the vCenter configuration follows VMware recommendations and best practices. Software -------- Using Microsoft SQL Server Express for the vCenter Server database or the internal database used by vCenter virtual appliance is not recommended. ----------------------------------------------------------------------- 3.2 Conditional Requirements A user ID with full Administrator rights is required for backups and restores. VMware plug-in versions earlier than 6.90 cannot exist in the same environment as the vSphere Agent. For file and folder restores on Linux platforms, you must install the Samba client in order to mount shared virtual disks (VMDKs). Samba is an installable option with some Linux distributions. You can also visit www.samba.org to download the open-source software. Note: Backups of physical Raw Disk Mappings (RDMs) are not supported with vSphere Agent. VMware does not allow snapshots of physical RDMs, and snapshots are required for vSphere Agent backups. To back up a physical RDM, you must install an Agent in the VM with the physical RDM. Virtual RDMs are protected, and are restored as VMDKs on supported datastores. ----------------------------------------------------------------------- 3.3 Licensing Requirements In Director versions 6.22 and later, the vSphere Agent claims at least three licenses from the Director. A Server Agent license and a VMware plug-in license is required for each vSphere Agent. A VMware Cluster license (called “ESXFarm”) is required for each hypervisor host in the environment. For example, in a vCenter with 15 VM hypervisors (ESX/ESXi hosts), the vSphere Agent claims 15 Cluster licenses, one ESX license and one Server Agent license. ----------------------------------------------------------------------- 3.4 Install/Upgrade 3.4.1 Install The vSphere Agent is pre-installed in a VM, and provided in Open Virtualization Appliance (OVA) format. You must deploy the OVA file in the vCenter where you want to back up VMs. The OVA file name is: vSphereAgent-7-12-1231.ova To obtain the OVA file, contact your licensed service provider or visit http://www.evault.com/. The vSphere Agent is installed on a Linux VM, and deployed with the following RPMs: agent-combined-7.12-1231.i386.rpm compat-libstdc++-33-3.2.3-63.i386.rpm createrepo-0.9.6-3.fc9.noarch.rpm e2fsprogs-1.41.13-0.i386.rpm e2fsprogs-libs-1.41.13-0.i386.rpm EVLT-vmware-appliance-agent-7.12-1231.i386.rpm fontconfig-2.5.0-2.fc9.i386.rpm freetype-2.3.5-7.fc9.i386.rpm iscsi-initiator-utils-6.2.0.870-1.0.fc9.i386.rpm jre-6u26-linux-i586.rpm ksh-20080202-2.fc9.i386.rpm libICE-1.0.4-3.fc9.i386.rpm libSM-1.1.0-1.fc9.i386.rpm libtdb-3.5.5-2.fc9.i386.rpm libX11-1.1.4-1.fc9.i386.rpm libXau-1.0.3-5.fc9.i386.rpm libxcb-1.1-5.fc9.i386.rpm libXdmcp-1.0.2-5.fc9.i386.rpm libXext-1.0.4-1.fc9.i386.rpm libXft-2.1.12-5.fc9.i386.rpm libxml2-python-2.7.3-1.fc9.i386.rpm libXmu-1.0.4-1.fc9.i386.rpm libXp-1.0.0-11.fc9.i386.rpm libXrender-0.9.4-3.fc9.i386.rpm libXt-1.0.4-5.fc9.i386.rpm ntfs-3g-2010.8.8-2.fc9.i386.rpm openmotif-2.3.3-1.fc9.i386.rpm pancetera-tools-2-223.i386.rpm pancetera-unite-2-6223.i386.rpm pyOpenSSL-0.11-0.fc9.i386.rpm rsync-3.0.4-0.fc9.i386.rpm samba-3.5.5-2.fc9.i386.rpm samba-client-3.5.5-2.fc9.i386.rpm samba-common-3.5.5-2.fc9.i386.rpm samba-winbind-3.5.5-2.fc9.i386.rpm vmware-appliance-7.12-1231.i386.rpm vmware-appliance-buagent-7.12-1231.i386.rpm vmware-appliance-languages-7.12-1231.i386.rpm vmware-appliance-thirdparty-12-1231.i386.rpm vmware-appliance-vsphere-plugin-7.12-1231.i386.rpm vmware-appliance-vv-7.12-1231.i386.rpm vmware-appliance-vvagent-7.12-1231.i386.rpm vmware-recovery-appliance-7.12-1231.i386.rpm xorg-x11-filesystem-7.3-1.fc9.noarch.rpm For deployment and configuration information, see the vSphere Agent User Guide. To restore files and folders from VMDKs that are Windows dynamic disks, you must install a separate Dynamic Disk Tool that is provided with the vSphere Agent. The Dynamic Disk Tool is the preferred way to access files and folders on shared VM backups. To install the Dynamic Disk tool, run this executable file: DynamicDiskTool-1-01-0336.exe For more information about the Dynamic Disk Tool, see the vSphere Agent User Guide and Dynamic Disk Tool release notes. ---------------------------------------------------------------------- 3.4.2 Upgrade With Internet access, you can upgrade a vSphere Agent by entering the "system upgrade" command in the Agent CLI. If direct Internet access is not available, you can download RPMs from your service provider, create a CIFS share, and upgrade the vSphere Agent locally using the "system upgrade manual" command. For more information, see the vSphere Agent User Guide. RPMs are available from your service provider in a .zip file named: vSphereAgent-7-12-1231-RPMs.zip When you upgrade a vSphere Agent, some or all of the RPMs are updated. Settings such as vCenter registration and Web CentralControl credentials are preserved. IMPORTANT: vSphere Agent 7.12 includes a fix for an issue with backing up VMDKs that are larger than 1 TB minus 1 KB. If you upgrade a vSphere Agent from version 7.00 or earlier to version 7.11, and then perform a backup, the Agent detects VMs with VMDKs larger than 1 TB minus 1 KB, and ensures that they are backed up correctly. For more information, see Section 4.1.5 of these release notes. If you upgrade Agent 6.91 for VMware to vSphere Agent 7.12, the tmpfs setting for the Agent VM is increased. This increase enables the Agent to support as many as 1000 VMs managed by a vCenter Server. Previous versions of the Agent supported as many as 250 VMs in a vCenter. _______________________________________________________________________ ======================================================================= 4 FIXES and KNOWN ISSUES 4.1 Fixes 4.1.1 Fixes in 7.12 release Previously, backups sometimes failed due to snapshot creation errors. vSphere Agent 7.12 reduces the risk of these errors. (25143, 25124, 25030, 24949, 24534) Backups failed sporadically with an error message about opening a file for input. In some cases, the vSphere Agent had too many files open concurrently; in other cases, it exceeded the limit on open NFC sessions for the vSphere version. vSphere Agent 7.12 increases the open file limit and improves NFC session handling, which reduces the risk of failed backups. (25003) In some environments, when vSphere Agent 7.10 was registered to a vSphere vCenter 5.1 server, the vCenter service restarted periodically. This caused users to lose connection to the vCenter. vSphere Agent 7.12 reduces the risk of the vCenter service restarting in vCenter 5.1. (24236) ---------------------------------------------------------------------- 4.1.2 Fixes in 7.11 release If a vCenter crashed during a backup with multiple VMs, the backup appeared to complete successfully. However, data that was backed up before the crash could not be restored. Data can now be restored from VMs that are backed up before a vCenter crash. (24590) Previously, a VM could not be backed up if it was inside a vApp. You can now back up VMs that are inside vApps. (21316) Note: A VM cannot be backed up if it is inside a vApp that is nested inside another vApp. If default ports were changed on the vCenter and ESX/ESXi servers, the vSphere Agent appeared to register to the vCenter but backups failed because the vSphere Agent could not find VMs in the vCenter. You can now specify alternate communication and data ports by running the "vcenter register" command. (24061) Note: If you specify alternate ports on a vSphere Agent 7.10 that includes a hotfix for alternate ports, and then upgrade to vSphere Agent 7.11, you do not need to specify the alternate ports again. Alternate ports are preserved when you upgrade the vSphere Agent. ---------------------------------------------------------------------- 4.1.3 Fixes in 7.10 release If you restore a VM to a datastore that is shared by the ESXi host where the vSphere Agent is running and the host where you are restoring the VM, data is now written directly from the vSphere Agent's ESXi host to the destination datastore. Previously, data was sent from the vSphere Agent's ESXi host to the destination host before it was written to the shared datastore. (23646) ---------------------------------------------------------------------- 4.1.4 Fixes in 7.02 release If a Satellite vault was unavailable and the vSphere Agent tried to register to a Base vault, synchronization succeeded but the following error appeared when you tried to restore data: "An unexpected error occurred during information loading". This problem no longer occurs. (23653) ---------------------------------------------------------------------- 4.1.5 Fixes in 7.01 release An issue with backing up VMDKs larger than 1 TB minus 1 KB (1,073,741,823 KB) has been fixed. In Agent for VMware 6.9x, backups of VMs with VMDKs larger than 1 TB minus 1 KB appeared to complete successfully, but data corruption occurred in VMDKs larger than 1 TB minus 1 KB. As a workaround, vSphere Agent 7.00 skipped a VM in a backup if it included a VMDK larger than 1 TB minus 1 KB. To ensure that VMDKs larger than 1 TB minus 1 KB are backed up correctly, upgrade to vSphere Agent version 7.01 or later and run existing backup jobs. NOTE: VMs that were backed up using an Agent version earlier than 7.01 and contain VMDKs larger than 1 TB minus 1 KB should not be restored. After an upgrade, vSphere Agent version 7.01 or later seeds backups for VMs with VMDKs larger than 1 TB minus 1 KB that were skipped during backups with vSphere Agent 7.00. (23610/23385/23373) Previously, the vSphere Agent could only support as many as 250 VMs managed by a vCenter Server. The Agent can now support as many as 1000 VMs in a vCenter because the tmpfs setting for the Agent VM has been increased. (23344) Restores to original location no longer disconnect and become inactive without completing. (23486) Previously, new vCenters sometimes failed to communicate with new vSphere Agents that were reregistered with the vault. This no longer occurs. (22750) ---------------------------------------------------------------------- 4.1.6 Fixes in 7.0.0 release After failover to a Passive vault, restore from another computer failed. Backups ran successfully to the new Active vault (previously Passive). However, attempts to create new jobs did not use the alternate vault information. (23392/22798) When you tried to restore a VM to a host that does not support a virtual device in the VM, the VM could not be registered to the host. VMs with unsupported devices are now restored without the unsupported devices. (23265) On localized languages other than English, VMDKs were sometimes deleted when a VM or VMDK restore was nearing completion. (22958) For old, large backups, recoveries sometimes failed, and the Agent indicated that there was nothing to restore. (22734) In some cases, the Agent created an empty support bundle. (22651) Very large backups with very large catalogs sometimes failed due to space constraints. To ensure sufficient room for catalog and delta files, the vSphere Agent VM partition that contains Agent files is significantly larger in version 7.0 than in previous versions. (22480) In previous versions, successful recoveries sometimes appeared to place the Agent in a stopped state. (22432/22004) In previous versions, backups sometimes failed, indicating "Thread synchronization error" and "Unable to create semaphore" in the log. (22362) In rare cases, a snapshot became locked. This caused the next backup to fail. (22312) In previous versions, a VMDK restore of a single VMDK required the same amount of space as the entire original VM. It failed if there was less space than on the original, whether or not the single VMDK was smaller than the available space. (22265) In previous versions, when a VM contained a physical RDM disk in a multi-VMDK configuration, the backup skipped the physical RDM, but restored partially. Upon restore, all of the non-physical RDM VMDKs were restored correctly. However, as there was a missing VMDK, generation of the .vmx file failed. (22260) ----------------------------------------------------------------------- 4.2 Known Issues 4.2.1 Backup Issues If a vCenter goes offline (e.g., due to maintenance), the vSphere Agent could lose connection to the vCenter. After the vCenter comes online again, the Agent could take several minutes to reestablish connection to the vCenter. During this short period of time, scheduled backups could fail. To ensure that scheduled backups do not fail, reboot the vSphere Agent after a vCenter goes offline. (24703) In vCenter 4.1, you cannot back up VMs with physical RDMs that are connected to IDE nodes. This problem does not occur for VMs with physical RDMs that are connected to SCSi nodes. (23308) Backups of large, highly fragmented VMs can sometimes fail due to segmentation faults. (22816) When you back up a VM that contains an independent disk or physical RDM, an error message appears in the backup log for each independent disk and physical RDM. Because independent disks and physical RDMs cannot be backed up, the VM backup is incomplete. You cannot restore the entire VM from the backup. However, you can restore VMDKs that are not independent disks or physical RDMs, and files and folders from these VMDKs. (23046) If you run a backup, then rename the item you backed up and back it up right away, that backup might fail. The discovery process could be as long as 20 minutes before the backup can be run again. (21936) When attempting to back up a job to an alternate vault location (mount point on the vSphere Agent), that backup job will wait for other backup jobs to complete. (21876) CBT cannot be set or enabled for suspended VMs. If CBT is already set (enabled), CBT will be used, even if the VM is suspended. VMs that are powered ON or OFF do not have this issue. (21846) The Safeset Properties Original Size value shown for a vSphere job is displaying the size of the VM as though it is thick provisioned even when the VM is thin provisioned. (21604) References to Quick File Scanning (QFS) sometimes appear in the logs. These messages can be ignored because QFS is disabled globally by the vSphere Agent. (22989) vSphere Agents are not prevented or protected from performing concurrent backups of the same VM from the same vSphere Agent or another vSphere Agent. Avoid running concurrent backups of the same VM or job from the same vSphere Agent or another vSphere Agent. This can cause unfavorable CBT results and put delta backups out of sync. (21659) ---------------------------------------------------------------------- 4.2.2 Restore Issues If you restore a VMDK larger than 1 TB minus 1 KB from a safeset that was created using Version 6.91 or 6.90 Agent for VMware, data corruption might occur. WORKAROUND: To ensure that VMDKs larger than 1 TB minus 1 KB are successfully backed up, run the backup jobs using vSphere Agent version 7.01 or later. (23385/23373) If there is insufficient space for restoring a VM or VMDK on the original or alternate datastore, the restore appears to continue but the data is not restored. WORKAROUND: Restore VMs and VMDKs to datastores with sufficient space. (23379) If a new file is created just before a VM is backed up (e.g., one minute before the backup), the file might be corrupted when the VM is restored. (23208) If the original datastore of a VM is no longer present, the restore log indicates it is restoring to original location but restores to an alternate datastore. (22233) In a restore, each VM and VMDK is restored to a separate folder on a datastore: one for each VMX file, and one for each VMDK file. The first folder created has the specified name. "_X" is appended to the name for each subsequent folder, where X is a sequential number starting at 1. (23561/21952) Thick Provisioned Eager Zeroed hard disks are restored as Thick Provisioned Lazy Zeroed. (21432) When you restore VMs that resided in custom folders, they are sometimes restored to the main level instead of their original custom folders. (21241) ---------------------------------------------------------------------- 4.2.3 File and Folder Restore Issues When you share a VMDK from a VM backup that contains a large basic disk, the resulting UNC path is not always complete. WORKAROUND: Paste the UNC path into the Dynamic Disk Tool. You can then access all data from the VM. (23397) If you terminate a share when performing a file and folder restore, leftover directories remain in /opt/share. WORKAROUND: Reboot the vSphere Agent to remove the leftover directories. (23118) To prevent problems with file and folder restores, the minimum bandwidth usage value for the Agent is now 1500 kilobits per second. If bandwidth throttling is set for the Agent, the total bandwidth available is divided by the number of file and folder restores you are running. Reduced bandwidth can cause delays in opening the Dynamic Disk Tool and mounting VMDKs, and could cause the Dynamic Disk Tool to crash. (23057) If you terminate a share when doing a file and folder restore and then try to perform another file and folder restore, an incorrect UNC path with no files appears. After terminating a share, you must restart the vSphere Agent before you can perform another file and folder restore. (23053) On Linux platforms, file and folder restores are supported on LVM2 volumes that do not span multiple virtual disks. File and folder restores do not work with LVM2 volumes that span multiple virtual disks. (23196) Email notifications are not provided for file and folder restores. (22842) Some versions of Linux do not have correct default settings for interpreting special characters over a mounted shared drive. When mounting a share on Linux, files and folders with non-ASCII characters might be inaccessible or have different names. WORKAROUND: Specify the character encoding when mounting a share. For example, when mounting a VRA with utf8 encoding, include "iocharset=utf8" in the mount command. (23214) ---------------------------------------------------------------------- 4.2.4 Snapshot Issues Sometimes snapshot files are left behind, consuming space on the logical disk. (22557) If a snapshot from a previous backup fails, the subsequent backup does not perform a snapshot and will fail. Recommendation: Do not manually remove the orphaned snapshot. WORKAROUND: Reboot the vSphere Agent. Upon reboot, the Agent will remove the orphaned snapshot. (21632) The Agent cannot enable CBT for a VM with a snapshot. WORKAROUND: Remove the snapshot so that CBT can be enabled. (21739) ---------------------------------------------------------------------- 4.2.5 Communication Issues If replication between vaults is configured using host names instead of IP addresses, and the vSphere Agent cannot resolve host names, the Agent cannot register or back up to a Base or Passive vault. The log does not indicate that the problem is related to host name resolution. WORKAROUND: Configure replication using vault IP addresses instead of host names, or ensure that the vSphere Agent can resolve host names using DNS or static entries. If you replace a vSphere Agent's virtual network card or assign a different MAC address, the Agent does not recognize the virtual network card after a reboot. WORKAROUND: In the Agent Setup interface, select Network Reset. The Agent then recognizes the new virtual network card and assigns an IP Address or can be configured to use static IP. (24053) The vSphere Agent can fail to connect to Windows CentralControl if system default proxy settings set in Internet Explorer prevent Windows CentralControl from communicating with the vSphere Agent and obtaining the SSL certificate. WORKAROUND: On the computer where Windows CentralControl is running, disable proxy settings in Internet Explorer. (23231) When performing a reregistration to the vault, information on the vCenter tab in Agent Configuration is removed. When the vCenter tab is empty, the synch operation fails to complete. WORKAROUND: Populate the vCenter tab in order for Synchronize to recover the delta information. (22028) ---------------------------------------------------------------------- 4.2.6 Naming Issues If you create folders under the "VM and Templates" view (blue folders), you can create multiple VMs with the same name. You can see all of these VMs through CentralControl. However, when you try to back up VMs with the same name, the only backup that succeeds is the one for the VM in the root folder. The other backups fail because the vSphere Agent cannot find the VMs. WORKAROUND: Rename VMs so that each has a unique name. (21900) When the vSphere Agent host name is longer than 20 characters, backups fail with "Validation failed: failed to validate computer". The vSphere Agent host name must be restricted to a maximum 20 characters. (22388) VM names with special characters may display differently in the backup structure versus the restore structure. Upon restore, the log might indicate that the VM has been renamed, and also that the created datastore folder name is incorrect. However, in VMware, the name of the restored VM appears correctly. (22281) In vCenter 5, the following characters cannot be used and are not supported for VM names: # & @ { } (21974/21415) If you have a VM named VM*, and you create a filter using the asterisk as in VM*, the filter does not back up all VMs starting with VM as expected, but backs up only the one VM whose name is VM*. (21418) When you try to change the vSphere Agent host name, the following warning sometimes appears: "This node is a group master. Changing the hostname may break the group communication." You can ignore this warning and continue to change the Agent host name. Changing the Agent host name does not result in any problems. (23289) When you create a support bundle, the destination directory cannot include spaces. (24105) _______________________________________________________________________ ======================================================================= 5 PRODUCT SUPPORT 5.1 Technical Support Contact information for your provider is available through the Help menu. ----------------------------------------------------------------------- 5.2 Product Updates Product updates are available from your provider. ----------------------------------------------------------------------- 5.3 Documentation The available documentation for the vSphere Agent is: vSphere Agent User Guide vSphere Agent Quick Start Guide vSphereAgent.txt (this document) DynamicDiskTool.txt (release notes for the Dynamic Disk Tool) All documentation is available from your provider. ________________________________________________________________________ ========================================================================