AVAYA R6.2.1 Release Notes Issue 1.3 INTRODUCTION This document introduces the Release 6.2.1 and describes known issues and the issues resolved in this release. SOFTWARE RELEASE VERSIONS Release Date File Name Avaya Aura System Platform R1.0 August 2009 vsp-1.0.0.0.12.iso Avaya Aura System Platform R1.1 November 2009 vsp-1.1.0.0.10.iso February 2010 vsp-1.1.1.0.2.iso R1.1.1 R1.1.1.4.2 February 2010 vsp-patch- 1.1.1.4.2.noarch.rpm R1.1.1.7.2 April 2010 vsp-patch- 1.1.1.7.2.noarch.rpm R1.1.1.9.2 June 2010 vsp-patch- 1.1.1.9.2.noarch.rpm R1.1.1.93.2 August 2010 vsp-patch- 1.1.1.93.2.noarch.rpm R1.1.1.94.2 November 2010 vsp-patch- 1.1.1.94.2.noarch.rpm R1.1.1.97.2 February 2011 vsp-patch- 1.1.1.97.2.noarch.rpm R1.1.1.98.2 December 2011 vsp-patch- 1.1.1.98.2.noarch.rpm Avaya Aura System Platform R6.0 - June 2010 vsp-6.0.0.0.11.iso 700500262 Avaya Aura System Platform Patch R6.0.0.1.11 August 2010 vsp-patch- 6.0.0.1.11.nonarch.rpm Avaya Aura System Platform S8300D Pre- Upgrade Patch R6.0.0.2.11 February 2011 vsp-patch- 6.0.0.2.11.noarch.rpm Avaya Aura System Platform Pre-Upgrade May 2011 vsp-patch- Patch R6.0.0.3.11 R6.0.1-700500858 August 2010 6.0.0.3.11.noarch.rpm vsp-6.0.1.0.5.iso 1
Release Date File Name Avaya Aura System Platform S8300D Pre- Upgrade Patch R6.0.1.2.5 February 2011 vsp-patch- 6.0.1.2.5.noarch.rpm Avaya Aura System Platform Pre-Upgrade Patch R6.0.1.3.5 May 2011 vsp-patch- 6.0.1.3.5.noarch.rpm November 2010 vsp-6.0.2.0.5.iso R6.0.2-700501130 Patch R6.0.2.1.5 November 2010 vsp-patch- 6.0.2.1.5.noarch.rpm R6.0.2.3.5 February 2011 vsp-patch- 6.0.2.3.5.noarch.rpm Avaya Aura System Platform S8300D Pre- Upgrade Patch R6.0.2.5.5 April 2011 vsp-patch- 6.0.2.5.5.noarch.rpm Avaya Aura System Platform Pre-Upgrade Patch R6.0.2.6.5 May 2011 vsp-patch- 6.0.2.6.5.noarch.rpm February 2011 vsp-6.0.3.0.3.iso R6.0.3 R6.0.3.1.3 April 2011 vsp-patch- 6.0.3.1.3.noarch.rpm R6.0.3.3.3 August 2011 vsp-patch- 6.0.3.3.3.noarch.rpm R6.0.3.4.3 September 2011 vsp-patch- 6.0.3.4.3.noarch.rpm R6.0.3.6.3 December 2011 vsp-patch- 6.0.3.6.3.noarch.rpm R6.0.3.7.3 April 2012 vsp-patch- 6.0.3.7.3.noarch.rpm R6.0.3.9.3 June 2012 vsp-patch- 6.0.3.9.3.noarch.rpm Avaya Aura System Platform R6.2 March 2012 vsp-6.2.0.0.27.iso R6.2.0.2.27 April 2012 vsp-patch- 6.2.0.2.27.noarch.rpm July 2012 vsp-6.2.1.0.9.iso R6.2.1.0.9 (700504042) R6.2.1.3.9 vsp-patch- 6.2.1.3.9.noarch.rpm 2
Upgrades Upgrades to R6.2.1 are supported from 6.2.0.0.27 + patch 6.2.0.2.27 or R6.0.3.0.3 + patch (6.0.3.4.3 is the minimum patch from which upgrade to R6.2 is supported), but Avaya recommends you use the latest approved patch for your template. If no patch is specified for your template, then you can upgrade directly from R6.2 to R6.2.1 without applying a pre-upgrade patch. Please refer to the template documentation for the correct patch to apply to your system: https://support.avaya.com/css/p8/documents/100135000. Resolved Issues and Updates 1. System Platform installed on a supported server with battery backed RAID write cache will generate an alarm when the charge on its RAID battery is below a certain threshold. It will generate a minor alarm when the maximum battery charge level is getting low but is still capable of keeping the cache in write-back mode. It will generate a major alarm when the battery is no longer capable of maintaining the cache in write-back and the cache has changed to write-thru mode. 2. System Platform installed on supported server with redundant power supplies will generate an alarm when one of the power supplies fails. 3. Important kernel security and bug fix updates: RHSA-2011:1163-1 RHSA-2011:1212-1 RHSA-2011:1386-1 RHSA-2011:1479-1 4. Java has been updated to java-1.6.0-openjdk-1.6.0.0-1.25.1.1.0.6.ei5_8.x86_64 5. Tomcat has been updated to tomcat 6.0.35 6. During installation of the Application Enablement Services R6.2 template with System Platform 6.2, the Domain-0 may undergo a kernel panic and reboot the entire server. This issue has been resolved in. Please install or upgrade Application Enablement Services R6.2 (installed on servers with a R200 RAID controller) with the. 7. Resolved the issue during a System Platform upgrade with the Avaya Aura Solution for Midsize Enterprise template, where the System Platform High Availability (HA) synchronization paused and stalled. 3
8. For WebLM on System Platform and System Manager the primary licensing interface will now be the MAC address of the server s physical eth0 and the generated MAC address will be listed as a secondary licensing interface. Previously, the physical eth0 MAC address was listed as a secondary licensing interface in WebLM and a generated MAC address was listed as the primary. WebLM will validate licenses against primary or secondary license interfaces so no changes will be needed to existing licenses with the introduction of this feature. 9. After a network interface restart, the following alarm example may have logged 3 to 4 times per hour: Date voip68-cm1dom0-eus ntpd[4079]: sendto (xx.xx.x.x) (fd=xx): Invalid argument This issue has been mitigated in 6.2.1. 10. An issue where SSH sessions from Domian-0 were considerably slower when the DNS was unreachable has been resolved. 11. Updating the host name from the Network Configuration page on the Management Console was not updating the rsyslog on CDOM resulting in the logs displaying the old host name has been resolved. 12. Using the Machine Preserving High Availability (MPHA), the Management Console was not accessible for approximately 15 minutes after a network failure. This issue has been resolved by logging out of the Management Console after a network failure. Re-login is less than 5 minutes. 13. During an upgrade, MPHA was not correctly backing up and restoring properly, causing future backups to fail. This issue has been resolved. 4
Known Issues and Workarounds 1. Occasionally, the System Platform patch installation page continues to display is being installed even when the patch is complete. Workaround: Manually refresh the browser via the browser refresh button. System Platform will display has been successfully installed if the patch has completed at that time. Note: System Manager updates may take up to 90 minutes to install. 2. In a System Platform High Availability (HA) system, do not make user administration changes including password modifications on the standby/secondary server before starting HA on the primary server. Upon starting HA: Changes made on the standby server cause the primary server to unexpectedly synchronize to the latest (new/modified) settings. LDAP replication, by default, captures the most recent administrative entries made on either the primary server or the standby/secondary server. These conditions can result in an unexpected updates to the primary server. 3. Applying System Platform patches on HA failover systems. Unless the release notes for a patch specify otherwise, apply the patch on both machines if the patch includes a Domain-0 patch. Always check the patch release notes for the detailed information on how to apply the patch on HA systems. On a HA failover system, stop HA and remove the HA configuration before applying the patch and apply it on the System Platform Management Consoles of both the primary and secondary nodes. For any operation that requires HA to be stopped (platform upgrade, template upgrade and patch application), the stop HA should be followed by the removal of the HA configuration. The user may then configure and start HA after the operation is completed. Failure to remove HA before performing a platform upgrade could lead to an incorrect configuration of the system and the inability to start HA. This condition could lead to the necessity of re-installing System Platform on the affected systems. 4. In a HA configuration, any hardware maintenance (e.g. replacing hard disks or power modules) must be conducted on the standby server after it is powered down. If the current active server needs hardware maintenance, perform an interchange to make it a standby server and then perform the maintenance operation after the server is powered down. If this guideline is not followed, it is possible that the HA system may not work as desired once the hardware is replaced. 5
5. Upgrading from R6.0.3 to R6.2.1 may hang at the HA synchronization step. After upgrading from R6.0.3 to R6.2.1 on an HA pair following the steps of stop HA and remove HA configuration, when HA is started, the HA synchronization step may hang and may say, Waiting for Connection. This can be rectified by rebooting the standby server while HA is running. 6. Changing the system time zone via the Management Console Date / Time configuration page requires a reboot. If the system time zone is changed, reboot the system. If the time is changed or NTP is turned on after setting the time zone, the system will reboot automatically. To only change the time zone, ensure the server is rebooted via the Server Reboot/Shutdown Management Console page. Failure to reboot the system will cause some processes not to pick up the new time zone. 7. Do not use the media check on an HP DL360 G7, the installation will stall. If this occurs, reboot the server and proceed with the installation without performing the media check. 8. System Platform upgrades using a USB device are not supported on an HP DL360G7. When used for System Platform upgrades, USB drives cause boot problems on the HP DL360G7. USB devices may be used for template upgrades although the USB drive must not be attached when the System Platform upgrade is performed. 9. Configure the System Platform internal network avprivate before template installation to avoid duplicate IP address conflict. Before installing a template, check the Network Configuration page on the System Platform Management Console (select Server Management Network Configuration ) to view the addresses allocated on the bridge named avprivate. System Platform creates an internal, private bridge that allows virtual machines to communicate with each other. This private bridge does not have any connection to the user s LAN. During installation, System Platform runs an algorithm to find a set of IP addresses that do not conflict with the addresses configured on the System Domain Network Configuration screen. However, it is still possible that the addresses selected will conflict with other addresses in the network. Since this private bridge is not connected to the user s LAN, this address conflict could result in the failure of System Platform or an installed template to route packets correctly. The internal routing tables might not differentiate between the private bridge and the user s LAN, causing an application to direct packets to some host on the user s LAN rather than to another application within the System Platform server that has that same IP address on the private bridge. If the IP address for Domain-0 s interface on avprivate is changed (which appears in the bridge section of the Network Configuration page) or for CDOM s interface on avprivate (which appears under CDOM in the Group by Domain section), the 6
addresses must be consecutive with Domain-0 s address 1 less than CDOM s (i.e., if CDOM s IP address for its interface on avprivate is 172.20.30.5, then Domain-0 s must be 172.20.30.4). Also, the netmask for Domain-0 s interface on avprivate must be the same as the netmask for CDOM s interface on avprivate (i.e., if one is changed, the other must change). In the event that there is a conflict in the network with the private IP address range, some functions may fail to work properly in System Platform and the installed template. For example, the System Platform Management Console may be inaccessible from a system that has an IP address in conflict with the private address range. Another example includes an IP phone that registers with Communication Manager with the same IP address as Domain-0 s or CDOM s address on avprivate. Packets targeted for the phone might actually instead go to Domain-0 or CDOM. 10. If the WebLM usage history file (that stores license usage information) becomes corrupt, the license acquisition requests made by the Avaya products will start failing with the error Client did not find a license server at given URL. In addition, the WebLM web pages that show usage information will fail to render properly. The WebLM usage history file could become corrupt for any one of the following reasons: If the time of the server hosting WebLM is changed to > 30 days while the Tomcat server is running. If the JDK and Tomcat versions are incompatible (not likely in a System Platform environment). WebLM is programmed to track the license usage information, it will compute if the usage is the peak usage over the last 7 to 30 days, and will save the information every day in the usage history file. Due to the reasons mentioned above, WebLM cannot save the usage information in the usage history file on some days. As a result, when a new license acquisition request comes in, it is not able to calculate if the license count being requested is for the peak in the last 7 to 30 days. This will lead to an exception at WebLM server side causing the license acquisition request to fail. When WebLM cannot serve licenses to the products, the products tend to go into a license grace period. Workaround: Restart Tomcat. In some rare cases, it has also been necessary to reinstall the license file. To avoid the issue: If there is a need to change server time, stop Tomcat, change the server time, and then start Tomcat. Ensure JDK-Tomcat versions in use are compatible 11. Changing the password for the first time while logged into WebLM causes Tomcat catalina.out to error and lists exceptions. This issue resides in WebLM standalone releases (all releases up to 4.5.5). The issue does not impact WebLM functionality. 7
12. The CDOM fully qualified hostname in /etc/hosts is not correct after being renamed from the Management Console. If a user renames the CDOM hostname using an extension of the old hostname, the CDOM hostname in /etc/hosts hosts file will be misconfigured as shown in the following example: Old hostname: hostname.example.com New hostname: hostname-2.example.com Resulting misconfigured new fully qualified hostname in the /etc/hosts file: hostname-2-2.example.com When changing the CDOM hostname, do not use an extension of the existing hostname. 13. System Platform Management Console will not be accessible if the Domain-0 disk becomes full. Domain-0 should not be used for file storage. System Platform will rotate log files and remove old tmp files to ensure files and directories are prevented from growing larger than their allowed sizes. However, directly loading large files unrelated to System Platform onto Domain-0 could fill the hard drive and result in system issues. 14. Internet Explorer (IE) may not load pages when accessing the Management Console. When accessing the Management Console page, IE (versions 7, 8 or 9) may display the following error: Internet Explorer cannot display the webapp, or it may stay within the current page instead of navigating to the selected page. This happens when a page cannot respond to IE within 30 seconds. The problem has been observed on some template installation/upgrade pages, on the High Availability Configuration page and on the Network Configuration page. If IE is your preferred browser, consider applying the proposed solutions form the Microsoft Knowledge Base 181050 (http://support.microsoft.com/kb/181050). 15. Upgrading from System Platform 6.0 requires the installation of the pre-upgrade patch 6.0.3.X.3 (this patch 6.0.3.X.3 needs to be applied on 6.0.3.0.3 build or higher). If presented with a blank table when upgrading from 6.0 to 6.2, install the latest 6.0.3.X.3 patch. 16. Depending on the BIOS version, it is possible to receive Invalid checksum errors during ACPI processing at boot time. These errors occur when the ACPI tables in the BIOS contain incorrect checksums. BIOS vendors often only test their BIOS on Windows. Windows is more lenient with ACPI checksums. As a result, invalid checksums in ACPI tables escape this type of testing. Linux is less forgiving of checksum errors and they are occasionally received during start up. 8
These errors are dependent purely on the version of BIOS installed. Sometimes, upgrading the BIOS will resolve the errors. Linux ignores the offending ACPI table and System Platform makes no use of ACPI power management, so these errors are completely benign. 17. When running System Platform on a S8300D from the gateway, the session icc command will not work unless the gateway is running firmware version 30.13.0 or higher. 18. Patch search results may not display. When using HTTP to download a patch, System Platform may not locate the patch file when the user enters the full patch URL (one that includes the patch filename). For example, http://www.myfileserver/patchdir/systemplatform.rpm may mean System Platform does not locate the patch correctly. One workaround is to use just the directory URL and not include the filename. For example, enter http://www.myfileserver/patchdir and then select the correct patch from the resulting list. However, this will not work if the web server does not allow browsing on that directory. In that instance, point the web browser at the patch and download it to a PC and then upload it to the server using the Local File System option on the patch upload page. Using a DVD or USB stick to deliver the patch file to the system would also be valid options. 19. Kernel patching rollback limitation automatic fall back to a previous kernel will not occur if the new kernel panics. The RHEL 5 based distribution of CentOS is missing the grub-set-default command which causes the system to not automatically fall back to a previous kernel if the new kernel panics. Additional information on the CentOS bug may be obtained at https://bugzilla.redhat.com/show_bug.cgi?id=212649. 20. If the reboot button is selected, but the VM never shuts down or restarts, the Management Console will display the rebooting status indefinitely. Workaround: In the case where the VM is a Windows HVM, log into Windows from vnc and shutdown the instance gracefully (consult documentation for applications running on Windows operating systems for more information). For other VMs that hang in the shutdown process, manually issue an xm destroy command (ensure the VM is actually stuck, some VMs are slow to shutdown and may take up to 30 minutes). Using the xm destroy command on a VM that is in the process of shutting down rather than one that has stalled may result in issues. Advanced users may be able to use xm console <machine name> to check the state of the machine from its console. 9
21. CDOM and Services VM IP addresses cannot be directly swapped on the network configuration page. If the addresses are swapped and if the network configuration page is submitted, CDOM will become unreachable. Instead, the process to swap the IP address of CDOM with the IP address of the Services VM is as follows: a. Uncheck Enable Services VM from the Network Configuration page and click the save button. b. Swap Services VM IP address into the CDOM IP address field and apply changes. c. Check the Enable Services VM and set the former CDOM IP address into the Services VM IP address field and click the save button. The Services VM and CDOM will now have successfully changed IP addresses. 22. Service Pack rpm R6.2.0.2.27 may have invalid vsp-all.log entries. After installing service pack rpm R6.2.0.2.27, the /var/log/vsp/vsp-all.log on CDOM may have entries in it such as: ERROR [com.avaya.vsp.webconsole.util.patch.statusparser] The key "This" is not supported. ERROR [com.avaya.vsp.webconsole.util.patch.statusparser] The key "Check" is not supported. These entries may appear when installing a future service pack or patch after this service pack rpm has been applied. These log entries should be ignored. 10