Avaya Secure Access Link Gateway Using VMware® in The Virtualized Environment Deployment Guide PDF

Avaya Secure Access Link Gateway
using VMware in the Virtualized

Environment Deployment Guide
Issue 2
April 2013
2013 Avaya Inc.
All Rights Reserved.

Notice
While reasonable efforts have been made to ensure that the
information in this document is complete and accurate at the time of
printing, Avaya assumes no liability for any errors. Avaya reserves the
right to make changes and corrections to the information in this
document without the obligation to notify any person or organization of
such changes.
Licence types
Documentation disclaimer
Documentation means information published by Avaya in varying
mediums which may include product information, operating instructions
and performance specifications that Avaya generally makes available
to users of its products. Documentation does not include marketing
materials. Avaya shall not be responsible for any modifications,
additions, or deletions to the original published version of
documentation unless such modifications, additions, or deletions were
performed by Avaya. End User agrees to indemnify and hold harmless
Avaya, Avaya's agents, servants and employees against all claims,
lawsuits, demands and judgments arising out of, or in connection with,
subsequent modifications, additions or deletions to this documentation,
to the extent made by End User.
Link disclaimer
Avaya is not responsible for the contents or reliability of any linked
websites referenced within this site or documentation provided by
Avaya. Avaya is not responsible for the accuracy of any information,
statement or content provided on these sites and does not necessarily
endorse the products, services, or information described or offered
within them. Avaya does not guarantee that these links will work all the
time and has no control over the availability of the linked pages.
Warranty
Avaya provides a limited warranty on its hardware and Software
(Product(s)). Refer to your sales agreement to establish the terms of
the limited warranty. In addition, Avayas standard warranty language,
as well as information regarding support for this Product while under
warranty is available to Avaya customers and other parties through the
Avaya Support website: http://support.avaya.com. Please note that if
you acquired the Product(s) from an authorized Avaya reseller outside
of the United States and Canada, the warranty is provided to you by
said Avaya reseller and not by Avaya. Software means computer
programs in object code, provided by Avaya or an Avaya Channel
Partner, whether as stand-alone products or pre-installed on hardware
products, and any upgrades, updates, bug fixes, or modified versions.
Licenses
THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA
WEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO ARE
APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR
INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC.,
ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER
(AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH
AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS
OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES
NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED
FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR
AN AVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE
RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE
ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE.
BY INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR
AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF
YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING,
DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER
REFERRED TO INTERCHANGEABLY AS YOU AND END USER),
AGREE TO THESE TERMS AND CONDITIONS AND CREATE A
BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE
APPLICABLE AVAYA AFFILIATE (AVAYA).
Avaya grants you a license within the scope of the license types
described below, with the exception of Heritage Nortel Software, for
which the scope of the license is detailed below. Where the order
documentation does not expressly identify a license type, the
applicable license will be a Designated System License. The applicable
number of licenses and units of capacity for which the license is granted
will be one (1), unless a different number of licenses or units of capacity
is specified in the documentation or other materials available to you.
Designated Processor means a single stand-alone computing device.
Server means a Designated Processor that hosts a software
application to be accessed by multiple users.
Designated System(s) License (DS). End User may install and use
each copy of the Software only on a number of Designated Processors
up to the number indicated in the order. Avaya may require the
Designated Processor(s) to be identified in the order by type, serial
number, feature key, location or other specific designation, or to be
provided by End User to Avaya through electronic means established
by Avaya specifically for this purpose.
Concurrent User License (CU). End User may install and use the
Software on multiple Designated Processors or one or more Servers,
so long as only the licensed number of Units are accessing and using
the Software at any given time. A Unit means the unit on which Avaya,
at its sole discretion, bases the pricing of its licenses and can be,
without limitation, an agent, port or user, an e-mail or voice mail account
in the name of a person or corporate function (e.g., webmaster or
helpdesk), or a directory entry in the administrative database utilized
by the Software that permits one user to interface with the Software.
Units may be linked to a specific, identified Server.
CPU License (CP). End User may install and use each copy of the
Software on a number of Servers up to the number indicated in the
order provided that the performance capacity of the Server(s) does not
exceed the performance capacity specified for the Software. End User
may not re-install or operate the Software on Server(s) with a larger
performance capacity without Avayas prior consent and payment of an
upgrade fee.
Named User License (NU). You may: (i) install and use the Software
on a single Designated Processor or Server per authorized Named
User (defined below); or (ii) install and use the Software on a Server so
long as only authorized Named Users access and use the Software.
Named User, means a user or device that has been expressly
authorized by Avaya to access and use the Software. At Avayas sole
discretion, a Named User may be, without limitation, designated by
name, corporate function (e.g., webmaster or helpdesk), an e-mail or
voice mail account in the name of a person or corporate function, or a
directory entry in the administrative database utilized by the Software
that permits one user to interface with the Software.
Shrinkwrap License (SR). You may install and use the Software in
accordance with the terms and conditions of the applicable license
agreements, such as shrinkwrap or clickthrough license
accompanying or applicable to the Software (Shrinkwrap License).
Heritage Nortel Software
Heritage Nortel Software means the software that was acquired by
Avaya as part of its purchase of the Nortel Enterprise Solutions
Business in December 2009. The Heritage Nortel Software currently
available for license from Avaya is the software contained within the list
of Heritage Nortel Products located at http://support.avaya.com/
LicenseInfo under the link Heritage Nortel Products. For Heritage
Nortel Software, Avaya grants Customer a license to use Heritage
Nortel Software provided hereunder solely to the extent of the
authorized activation or authorized usage level, solely for the purpose
specified in the Documentation, and solely as embedded in, for
execution on, or (in the event the applicable Documentation permits
installation on non-Avaya equipment) for communication with Avaya
equipment. Charges for Heritage Nortel Software may be based on
extent of activation or use authorized as specified in an order or invoice.
SAL Gateway in the Virtualized Environment Deployment Guide

Comments? infodev@avaya.com
April 2013
Copyright
Contact Avaya Support
Except where expressly stated otherwise, no use should be made of

materials on this site, the Documentation, Software, or hardware
provided by Avaya. All content on this site, the documentation and the
Product provided by Avaya including the selection, arrangement and
design of the content is owned either by Avaya or its licensors and is
protected by copyright and other intellectual property laws including the
sui generis rights relating to the protection of databases. You may not
modify, copy, reproduce, republish, upload, post, transmit or distribute
in any way any content, in whole or in part, including any code and
software unless expressly authorized by Avaya. Unauthorized
reproduction, transmission, dissemination, storage, and or use without
the express written consent of Avaya can be a criminal, as well as a
civil offense under the applicable law.
See the Avaya Support website: http://support.avaya.com for product

notices and articles, or to report a problem with your Avaya product.
For a list of support telephone numbers and contact addresses, go to
the Avaya Support website: http://support.avaya.com, scroll to the
bottom of the page, and select Contact Avaya Support.
Virtualization
Each vAppliance will have its own ordering code. Note that each
instance of a vAppliance must be separately ordered. If the end user
customer or Business Partner would like to install 2 of the same type
of vAppliances, then 2 vAppliances of that type must be ordered.
Third Party Components
Third Party Components mean certain software programs or portions
thereof included in the Software that may contain software (including
open source software) distributed under third party agreements (Third
Party Components), which contain terms regarding the rights to use
certain portions of the Software (Third Party Terms). Information
regarding distributed Linux OS source code (for those Products that
have distributed Linux OS source code) and identifying the copyright
holders of the Third Party Components and the Third Party Terms that
apply is available in the Documentation or on Avayas website at: http://
support.avaya.com/Copyright. You agree to the Third Party Terms for
any such Third Party Components.
Preventing Toll Fraud
Toll Fraud is the unauthorized use of your telecommunications
system by an unauthorized party (for example, a person who is not a
corporate employee, agent, subcontractor, or is not working on your
company's behalf). Be aware that there can be a risk of Toll Fraud
associated with your system and that, if Toll Fraud occurs, it can result
in substantial additional charges for your telecommunications services.
Avaya Toll Fraud intervention
If you suspect that you are being victimized by Toll Fraud and you need
technical assistance or support, call Technical Service Center Toll
Fraud Intervention Hotline at +1-800-643-2353 for the United States
and Canada. For additional support telephone numbers, see the Avaya
Support website: http://support.avaya.com. Suspected security
vulnerabilities with Avaya products should be reported to Avaya by
sending mail to: securityalerts@avaya.com.
Trademarks
The trademarks, logos and service marks (Marks) displayed in this
site, the Documentation and Product(s) provided by Avaya are the
registered or unregistered Marks of Avaya, its affiliates, or other third
parties. Users are not permitted to use such Marks without prior written
consent from Avaya or such third party which may own the Mark.
Nothing contained in this site, the Documentation and Product(s)
should be construed as granting, by implication, estoppel, or otherwise,
any license or right in and to the Marks without the express written
permission of Avaya or the applicable third party.
Avaya is a registered trademark of Avaya Inc.
All non-Avaya trademarks are the property of their respective owners,
and Linux is a registered trademark of Linus Torvalds.
Downloading Documentation
For the most current versions of Documentation, see the Avaya
Support website: http://support.avaya.com.
April 2013

April 2013
Contents
Chapter 1: Introduction...................................................................................................... 7
Purpose..................................................................................................................................................... 7
Intended audience.................................................................................................................................... 7
Document changes since last issue.......................................................................................................... 7
Related resources..................................................................................................................................... 8
Documentation................................................................................................................................. 8
Training............................................................................................................................................ 8
Avaya Mentor videos........................................................................................................................ 9
Support...................................................................................................................................................... 9
Chapter 2: Architecture overview...................................................................................... 11
Avaya Aura Virtualized Environment overview....................................................................................... 11
VMware components................................................................................................................................ 13
Deployment guidelines.............................................................................................................................. 13
Chapter 3: Planning and configuration............................................................................. 15
Planning.................................................................................................................................................... 15
Server hardware and resources................................................................................................................ 15
SAL Gateway virtual machine resource requirements.............................................................................. 16
Editing the virtual machine resources.............................................................................................. 17
VMware software requirements................................................................................................................ 17
Software requirements.............................................................................................................................. 17
Specifications of bundled software in the OVA......................................................................................... 18
Capacity of SALGateway in a virtualization environment......................................................................... 18
Chapter 4: VMware best practices for performance........................................................ 19
BIOS.......................................................................................................................................................... 19
Intel Virtualization Technology support............................................................................................ 19
Dell PowerEdge Servers BIOS settings....................................................................................... 20
HP ProLiant Servers BIOS settings............................................................................................. 20
VMware Tools........................................................................................................................................... 21
Time keeping............................................................................................................................................. 21
Configuring timing............................................................................................................................ 22
VMware networking best practices........................................................................................................... 23
Thin vs. thick deployments........................................................................................................................ 24
Best practices for VMware features.......................................................................................................... 25
VMware Snapshots.......................................................................................................................... 25
VMware High Availability.................................................................................................................. 26
VMware vMotion............................................................................................................................... 27
Hyperthreading................................................................................................................................. 27
Chapter 5: Initial setup and pre-deployment.................................................................... 29
Downloading the SAL Gateway OVA........................................................................................................ 29
Registering for PLDS........................................................................................................................ 29
Downloading software from PLDS................................................................................................... 29
Registering the SAL Gateway virtual machine.......................................................................................... 30
Chapter 6: Deploying the SAL Gateway OVA................................................................... 33
SAL Gateway OVA deployment overview................................................................................................. 33
April 2013
Deployment checklist................................................................................................................................
Deploying the SAL Gateway OVA to vCenter...........................................................................................
Properties field descriptions......................................................................................................................
Deploying the SAL Gateway OVA directly to the ESXi server..................................................................
Deployment of cloned and copied OVAs..................................................................................................
33
34
36
40
41
Chapter 7: Initial configuration.......................................................................................... 43
Starting the SAL Gateway virtual machine............................................................................................... 43
Configuring the virtual machine automatic start and stop settings............................................................ 43
Configuring the SAL Gateway and the network parameters..................................................................... 45
Chapter 8: Validation of the SAL Gateway implementation............................................ 47
Testing the alarming service of SAL Gateway.......................................................................................... 47
Testing the remote access service of SAL Gateway................................................................................ 47
Testing the SAL Watchdog service........................................................................................................... 48
Testing the Gateway UI............................................................................................................................. 48
Chapter 9: Reconfiguration of the virtual machine.......................................................... 49
Reconfiguring the virtual machine deployed through vCenter.................................................................. 49
Reconfiguring the virtual machine deployed directly on an ESXi server................................................... 50
Chapter 10: Backing up and restoring the virtual machine............................................ 51
Backup and restore overview.................................................................................................................... 51
Backing up the virtual machine................................................................................................................. 51
Restoring a virtual machine....................................................................................................................... 52
Chapter 11: Upgrading the SAL Gateway OVA................................................................ 53
Upgrading the SAL Gateway vAppliance.................................................................................................. 53
Validating an upgrade operation............................................................................................................... 54
Chapter 12: Troubleshooting............................................................................................. 55
FAQ........................................................................................................................................................... 55
Appendix A: PCN and PSN notifications.......................................................................... 59
PCN and PSN notifications....................................................................................................................... 59
Viewing PCNs and PSNs.......................................................................................................................... 59
Signing up for PCNs and PSNs................................................................................................................ 60
Glossary............................................................................................................................... 61
Index..................................................................................................................................... 63
April 2013
Chapter 1: Introduction
Purpose
This document provides procedures for deploying the Secure Access Link (SAL) Gateway
virtual application in the Avaya Aura Virtualized Environment. The document includes
installation, configuration, initial administration, troubleshooting, and basic maintenance
checklists and procedures.
This document does not include optional or customized aspects of a configuration.
Intended audience
The primary audience for this document is anyone who installs, configures, and verifies SAL
Gateway on a VMware vSphere 5.0 or 5.1 virtualization environment at a customer site.
The audience includes and is not limited to implementation engineers, field technicians,
business partners, solution providers, and customers.
Document changes since last issue

The following changes have been made to this document since the last issue:
Added VMware ESXi 5.1 support information for SAL Gateway virtual application in the
VMware software requirements section.
Added the details of the application software and the operating system in the
Specifications of bundled software in the OVA section.
Added the Deployment of cloned and copied OVAs section.
April 2013
Introduction
Related resources
Documentation
The following table lists the documents related to this product. Download the documents from
the Avaya Support website at http://support.avaya.com
Title
Description
Audience
Design
Describes the Virtualized
Sales engineers
Environment solution from a
functional view. Includes a high-level
description of the solution as well as
topology diagrams, customer
requirements, and design
considerations.
Avaya Aura Virtualized

Environment Solution
Description
Implementation and administration

Implementing Secure Access
Link Gateway
Describes the implementation

requirements and procedures for
standalone SAL Gateway. Provides
information about configuring and
administering SAL Gateway for
remote servicing of Avaya products at
a customer site.
Solution
architects,
implementation
engineers,
support personnel
Training
The following courses are available on the Avaya Learning website at http://www.avayalearning.com. To search for the course, log on to Avaya Learning Center, enter the course
code in the Search field, and click Go.
Course code
1A00232V
Course title
Avaya Aura Essentials

April 2013
Support
Avaya Mentor videos

Avaya Mentor is an Avaya-run channel on YouTube that includes technical content on how to
install, configure, and troubleshoot Avaya products.
Visit the Avaya Mentor Videos website at http://www.youtube.com/AvayaMentor and enter
virtual appliance in the Search channel field to view the list of available videos.
You can also enter the application product name to view videos that are available for a
particular product.
Support
Visit the Avaya Support website at http://support.avaya.com for the most up-to-date
documentation, product notices, and knowledge articles. You can also search for release
notes, downloads, and resolutions to issues. Use the online service request system to create
a service request. Chat with live agents to get answers to questions, or request an agent to
connect you to a support team if an issue requires additional expertise.
April 2013
Introduction
10

April 2013
Chapter 2: Architecture overview
Avaya Aura Virtualized Environment overview

Traditionally, Avaya Aura has been sold and installed as an individual appliance within
customer networks to offer collaboration capabilities and business advantages. Avaya Aura
Virtualized Environment integrates real-time Avaya Aura applications with VMware
virtualized server architecture. Virtualized Environment provides the following benefits:
simplifies IT management by providing common software administration and
maintenance.
requires fewer servers and racks which reduces the footprint.
lowers power consumption and cooling requirements.
enables capital equipment cost savings.
lowers operational expenses.
uses standard operating procedures for both Avaya and non-Avaya products.
satisfies customer demand for Avaya products in a virtualized environment on customerspecified servers and hardware.
enables business to scale rapidly to accommodate growth and to respond to changing
business requirements.
For existing customers who have a VMware IT infrastructure, Avaya Aura Virtualized
Environment provides an opportunity to upgrade to the next release level of collaboration using
their own VMware infrastructure. For customers who need to add more capacity or application
interfaces, Avaya Aura applications on VMware offer flexible solutions to expansion. For
customers who want to migrate to the latest collaboration solutions, Avaya Aura Virtualized
Environment provides a hardware-efficient simplified solution for upgrading to the latest Avaya
Aura release and adding the latest Avaya Aura capabilities.
The Virtualized Environment project is only for VMware and is not intended to include any other
industry hypervisor. Virtualized Environment is inclusive of the Avaya Aura portfolio.
Note:
This document uses the following terms, and at times, uses the terms interchangeably.
April 2013
11
Architecture overview
server and host

reservations and configuration values
Virtualized Environment applications

The Virtualized Environment supports the following Avaya products:
Avaya Aura Communication Manager Release 6.2 (Simplex & Duplex)
Avaya Agile Communication Environment Release 6.2 (ACE)
Avaya Aura Application Enablement Services Release 6.2 (AES)
WebLM Standalone Release 6.2 (WebLM)
Secure Access Link Release 2.2 (SAL)
Avaya Aura System Manager Release 6.2 (SMGR)
Avaya Aura Presence Services Release 6.1 (PS)
Avaya Aura Session Manager Release 6.2 (SM)
Avaya Aura Utility Services Release 6.2 (US)
Customer deployment
Deployment into the blade, cluster, and server is managed by vCenter or vSphere.
The customer provides the servers, the virtual appliances, the hardware, and the VMware
infrastructure including the VMware licenses.
Software delivery
The software is delivered as a pre-packaged Open Virtualization Application (OVA) file posted
on the Avaya Product Licensing and Download System (PLDS). The OVA contains the
following components:
the application software and operating system.
pre-installed VMware tools for deployment on VMware ESXi 5.0 and ESXi 5.1.
preset configuration details for
- RAM and CPU reservations and storage requirements
- Network Interface Card (NIC)
- other settings
Patches and upgrades

A minimum patch level can be required for each supported application. See the Compatibility
Matrix at Compatibility Matrix for more information regarding the application patch
requirements.
Important:
Do not update the VMware tools software which is packaged with each OVA unless
instructed to do so by Avaya. The supplied version is the supported release and has been
thoroughly tested.
12

April 2013
VMware components
Performance and capacities

The OVA template is built with configuration values which optimize performance and follow
recommended Best Practices.
Caution:
Modifying these values can have a direct impact on the performance, capacity, and stability
of the virtual machine. It is the responsibility of the customer to understand the
aforementioned impacts when changing configuration values. Avaya Global Support
Services (GSS) may not be able to assist in fully resolving a problem if the resource
allocation has been changed for a virtual application. Avaya GSS could require the customer
to reset the values to the optimized values before starting to investigate the issue.
VMware components
VMware Software
Component
Description
ESXi Host
The physical machine running the ESXi Hypervisor

software.
ESXi Hypervisor
A platform that runs multiple operating systems on a host

computer at the same time.
vSphere Client
The client application that is installed on a personal computer

or accessible through a Web interface. It connects to a
vCenter server or directly to an ESXi host in the case where
vCenter Server is not used. Enables the installation and
management of virtual machines.
vCenter Server
vCenter Server provides centralized control and visibility at

every level of the virtual infrastructure. Virtual machines are
managed through vSphere Client software which provides
alarming and performance monitoring of ESXi hosts and
virtual machines. vCenter Server provides VMware features
such as High Availability and vMotion.
Deployment guidelines
The high-level steps are:
1. Deployment of the .ova.
2. Configuration procedures.
3. Verification of the installation.
April 2013
13
Architecture overview
The following are deployment guidelines for the virtual machines:

Deploy the virtual appliances on the same host as possible, depending on host size and
VMs.
Deploy the virtual appliances on the same cluster if it goes beyond the host boundary.
Segment redundant elements on a different cluster. For example, Communication
Manager duplication pair.
Create a tiered or segmented cluster infrastructure that isolates critical applications, such
as Avaya Aura, from other VMs.
Ensure that you have enough resources for rainy day scenarios or conditions. Resources
may only be configured for traffic or performance on an average day.
Do not over-subscribe resources. Over-subscribing causes performance problems.
Monitor the blade, host, and virtual appliance performance.
Important:
The values for performance, occupancy, and use can vary greatly. The blade may be
running at 5% occupancy, but a VM may be running at 50%. Note that some VMs will
behave differently at a higher CPU usage.
14

April 2013
Chapter 3: Planning and configuration
Planning
As an Avaya customer, ensure that you complete the following before deploying the SAL
Gateway open virtual application (OVA):
#
Action
Notes
Register for the Avaya Product

Licensing and Delivery System
(PLDS) website at https://
plds.avaya.com.
See Registering for PLDS on

page 29.
Download the SAL Gateway OVA

file from PLDS.
To log on to the PLDS website, use

your Avaya Single Sign On (SSO)
login, which is associated with the
Sold-To number that identifies the
location where you want to install
SAL Gateway.
Ensure that you have all the

required hardware for the VMware
environment.
See Server hardware and

resources on page 15.
Ensure that you plan the staging

and verification activities and the
virtualization environment has
enough resources to be assigned
for the SAL Gateway vAppliance.
See SAL Gateway virtual machine

resource requirements on
page 16.
Server hardware and resources

VMware offers certified compatibility guides which list System, I/O, Storage/SAN and Backup
compatibility with VMware Infrastructure See http://www.vmware.com/resources/guides.html
to view the VMware certified Compatibility Guides and the Product Interoperability Matrixes.
The VMware-certified servers must be running ESXi 5.0 and any of its updates, or ESXi 5.1
and any of its updates.
April 2013
15
Planning and configuration
Important:
You must configure the time and NTP settings on each ESXi server before you deploy and
configure the OVA. Otherwise, the deployed virtual machine may not boot correctly.
SAL Gateway virtual machine resource requirements

The SAL Gateway virtual machine requires the following minimal set of resources to be
available on the ESXi host for deployment. These resources are specified in the SAL Gateway
OVA.
VMware Resource
Value
vCPU
CPU speed
2 GHz
Memory
2 GB
Storage reservation
40 GB
Shared NIC
1 @ 1000 Mbps
You might deploy the SAL Gateway vAppliance on a host that does not have the resources to
allocate to the virtual machine for starting the virtual machine. For a specific server speed,
CPU reservations are assigned to the vAppliance through the OVA.
In case of CPU resource limitations, the system displays the Insufficient capacity on
each physical CPU, or some similar message after the start-up request. To correct this
limitation, you can adjust the virtual machine properties.
In some cases, the CPU adjustments might not correct the start-up conditions, and you might
have to lower the CPU speed more. You can adjust other virtual machine resources as
required.
Important:
Do not modify any other resource settings, for example, downsizing of allocated resources.
Modifying these allocated resources could have a direct impact on the performance,
capacity, and stability of the SAL Gateway virtual machine. To run at full capacity, the virtual
machine must meet these resource size requirements. Removing or downsizing
reservations could put this requirement at risk.
For SAL Gateway to perform at maximum capacity, Avaya recommends that you adjust the
resource allocation for the virtual machine to have 2 vCPUs with CPU speed of 2 GHz or
higher.
Related topics:
Editing the virtual machine resources on page 17
16

April 2013
VMware software requirements
Editing the virtual machine resources

About this task
Use this procedure to adjust the virtual machine resources if the host does not have enough
resources to allocate according to the reservations that are specified in the OVA.
Procedure
1. Right click the virtual machine, and select Edit Settings.
2. On the Virtual Machine Properties window, select the Resources tab.
The tab displays the virtual machine resources, including CPU, Memory, Disk, and
Advanced CPU.
3. For CPU limitations, select CPU from the left pane and adjust the CPU reservation
to an appropriate number so that the virtual machine can function properly.
Alternatively, enter the exact number into the Reservations field.
4. Adjust the other resource allocations, as required.
5. Click OK.
VMware software requirements

For optimal results, use the following VMware software versions:
VMware vSphere Client ESXi 5.0 or ESXi 5.1
VMware vCenter Server ESXi 5.0 or ESXi 5.1
ESXi 5.0 can be added under vCenter Server 5.0 and vCenter Server 5.1. However, ESXi 5.1
can be added only under vCenter Server 5.1. See VMware Product Interoperability Matrixes
at http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php to view compatibility
with other solution releases.
Software requirements
SAL Gateway uses the current release, 2.2, of software as the standard release of SAL
Gateway vAppliance on VMware vSphere 5.0 or 5.1. SAL Gateway vAppliance currently does
not support VMware vSphere 4.1. The SAL Gateway VMware virtualization environment is
packaged as a vAppliance ready for deployment on VMware-certified hardware.
April 2013
17
Planning and configuration
The following table lists the required software and the supported versions for the SAL Gateway
VMware virtualization environment.
Equipment
Software versions
VMware vCenter Server
5.0.0, build 623373

5.1.0, build 880146
VMware vSphere Client
5.0.0, build 623373

5.1.0, build 860230
VMware ESXi Host
5.0.0, build 623860

5.1.0, build 799733
VMware Tools
8.6.0.6261, build 426873
Specifications of bundled software in the OVA

The SAL Gateway OVA contains the application software, operating system, and other
required software components, along with preinstalled VMware tools.
The following are the specifications of the software components included as part of the SAL
Gateway OVA.
Operating system
CentOS 5.8, 64-bit
Java
Oracle JRE 1.6.0_33
Application software
SAL Gateway 2.2.0.0.24
Capacity of SALGateway in a virtualization environment

The capacity of SAL Gateway VMware virtualization environment is the same as the capacity
of a standalone SAL Gateway. To run at full capacity, the virtual machine must meet the
required specifications and the resource allocation. Also, the alarm flow, remote sessions, and
network conditions must the normal. For the capacity matrix of a standalone SAL Gateway,
see Implementing Secure Access Link Gateway 2.2.
18

April 2013
Chapter 4: VMware best practices for

performance
The following sections define the required best practices for the SAL Gateway virtualization environment.
For standard virtualization best practices for VMware vSphere 5.0, see Performance Best Practices for
VMware vSphere 5.0. For standard virtualization best practices for VMware vSphere 5.1, see Performance
Best Practices for VMware vSphere 5.1.
BIOS
For details on BIOS settings to improve the environment for latency-sensitive workloads for an
application, see the Best Practices for Performance Tuning of Latency-Sensitive Workloads in
vSphere VMs technical white paper at http://www.vmware.com/files/pdf/techpaper/VMWTuning-Latency-Sensitive-Workloads.pdf.
The following are the best performance BIOS settings for a few specific servers from the
VMware-certified server list. In general, turn off power-saving server options for optimal
performance. Consult the manufacturer technical data for your particular server.
Related topics:
Intel Virtualization Technology support on page 19
Dell PowerEdge Servers BIOS settings on page 20
HP ProLiant Servers BIOS settings on page 20
Intel Virtualization Technology support

Intel CPUs require EM64T and Virtualization Technology (VT) support in the chip and in the
BIOS to run 64bit virtual machines.
All Intel Xeon processors feature:
Intel Virtualization Technology
Intel Extended Memory 64 Technology
Execute Disable Bit
April 2013
19
VMware best practices for performance
Ensure that VT is enabled in the host system BIOS. The feature may be called VT, Vanderpool
Technology, Virtualization Technology, VMX, or Virtual Machine Extensions.
Note:
The VT setting is locked (either on or off) at boot time. After enabling VT in the system BIOS,
save your changes to the BIOS settings and exit. The host server will reboot, and the BIOS
changes will take effect.
Other suggested BIOS settings

Servers with Intel Nehalem class and newer Intel Xeon CPUs also offer two power
management options: C-states and Intel Turbo Boost.
Disabling C-states lowers latencies to activate the CPUs from halt or idle states to full
power on.
Intel Turbo Boost steps up the internal frequency of the processor if the workload requires
more power. The default for this option is enabled. Do not change the default.
These settings depend on the OEM make and model of the server. The BIOS parameter
terminology for current Dell and HP servers are described in the following sections. Other
server make and models may have other terminology but equivalent BIOS controls.
Dell PowerEdge Servers BIOS settings

When the Dell server starts, you select F2 to display the system setup options. The following
are the recommended BIOS settings for the Dell PowerEdge servers:
Set the Power Management Mode to Maximum Performance.
Set the CPU Power and Performance Management Mode to Maximum Performance.
Under Processor Settings, set Turbo Mode to enable.
Under Processor Settings, set C States to disabled.
HP ProLiant Servers BIOS settings

The following are the recommended BIOS settings for the HP ProLiant servers:
Set the Power Regulator Mode to Static High Mode.
Disable Processor C-State Support.
Disable Processor C1E Support.
Disable QPI Power Management.
Enable Intel Turbo Boost.
20

April 2013
VMware Tools
VMware Tools
VMware Tools are included as part of the application OVA. The tools are a suite of utilities that
enhances the performance of the guest operating system on the virtual machine and improves
the management of the virtual machine.
The tools provide:
VMware Network acceleration
Host to Guest time synchronization
Disk sizing
Startup/Shutdown
For more information, see Overview of VMware Tools at http://kb.vmware.com/kb/340.
Important:
Do not update the VMware tools software which is packaged with each OVA unless
instructed to do so by Avaya. The supplied version is the supported release and has been
thoroughly tested.
Time keeping
For accurate time keeping, use the Network Time Protocol (NTP) as a time source instead of
the ESXi hypervisor.
The NTP servers can be local to the LAN or over the Internet. If the NTP servers are on the
Internet, the corporate firewall must open UDP port 123 so that NTP service can communicate
with the external NTP servers.
VMware tools time synchronization is disabled at application deployment time to avoid dueling
clock masters. You must configure the NTP service first because the applications are not
receiving clock updates from the hypervisor. To verify VMware Tools Timesync is Disabled,
run the command /usr/bin/vmware-toolbox-cmd timesync status.
In special situations, such as powering up the virtual machine, after vMotion, and after
resuming a suspended virtual machine, the ESXi hypervisor will push an updated view of its
clock into a virtual machine. If this view is very different from that received over the network
(over 1000 seconds), the NTP service might not adjust to the network time and shutdown. In
this situation, the guest administrator must manually set the guest clock to be the same or as
close as possible to the network time source clock. To keep the NTP service active, the clock
April 2013
21
on the ESXi host must also use an accurate clock source, such as the same network time
source that is used by the guest. The VMware recommendation is to add tinker panic 0 to the
first line of the ntp.conf file so that the NTP can adjust to the network time even with large
differences.
If you use the names of the time servers instead of the IP address in setting the NTP
configuration, you must configure the Domain Name Service in the guest before administering
the NTP service. Otherwise, the NTP service will not be able to locate the time servers. If the
NTP service is administered first, you must restart the NTP service after administering the DNS
service.
After you administer the NTP service in the application, run the ntpstat or /usr/sbin/ntpq -p
command from a command window to verify the NTP service is getting time from a network
time source. The results indicate which network time source is being used, how close the guest
is to the network time, and how often the guest checks the time. The guest polls the time source
between every 65 and 1024 seconds. Larger time intervals indicate that the guest clock is
tracking the network time source closely. If the time source is local, then the NTP service is
not using a network time source and a problem exists.
If the clock value seems to be consistently wrong, look through the system log for entries
regarding ntpd. The NTP service writes the activities it performs to the log, including when it
loses synchronization with a network time source.
For more information, see Timekeeping best practices for Linux guests at http://
kb.vmware.com/kb/1006427. The article presents best practices for Linux timekeeping. These
recommendations include specifics on the particular kernel command line options to use for
the Linux operating system of interest. There is also a description of the recommended settings
and usage for NTP time sync, configuration of VMware Tools time synchronization, and Virtual
Hardware Clock configuration to achieve best timekeeping results.
Related topics:
Configuring timing on page 22
Configuring timing
The SAL Gateway virtual machine relies on NTP for timekeeping. The SAL Gateway virtual
machine has an NTP service running that you can configure to synchronize with an external
NTP server.
Important:
To maintain the system time of the SAL Gateway virtual machine, you must configure NTP
on the SAL virtualized environment. Timekeeping is also important for managing and
isolating alarms that SAL Gateway forwards.
About this task

Use this procedure to configure the NTP service on the SAL Gateway virtual machine.
22

April 2013
VMware networking best practices
Procedure
1. Connect to the virtual machine through an SSH client.
2. Log in as admin, and switch to the root user.
3. Run the following command to stop the NTP service:
service ntpd stop
4. Open the /etc/ntp.conf file in a text editor.
5. Add the following line at the top of the file:
tinker
panic
6. If you do not want to use the CentOS NTP servers, comment out the following lines:
server
server
server
0.centos.pool.ntp.org
7. After those lines, add the NTP servers for time synchronization as the following:
server <IP/hostname>
server <IP/hostname>
8. Comment out the following two lines:

server 127.127.1.0
# local clock
fudge 127.127.1.0 stratum 10
9. Save and close the /etc/ntp.conf file.

10. Run the following command to start the NTP service:
service ntpd start
Next steps
If the NTP servers are on the Internet, you must configure the corporate firewall to open the
UDP port 123 so that the NTP service can communicate with the external NTP servers.
VMware networking best practices

You can have many different configurations for networking in a VMware environment. The
information in this section includes a number of best practices and recommendations from the
perspective of Avaya.
This section is not a substitute for the actual VMware documentation. If you do not have
experience with VMware networking, you must review the VMware networking best practices
before deploying any applications on an ESXi host.
The following are the suggested best practices for configuring a network that supports
applications deployed on VMware hosts:
April 2013
23
Create a vSphere standard or distributed switch with dedicated NICs for each service to
achieve greater security and performance. If separate switches are not possible, use port
groups with different VLAN IDs.
Configure the vMotion connection in such as way that the connection is located on a
separate network that is devoted to vMotion.
To protect sensitive VMs, deploy firewalls in the VM that route between virtual networks
with uplinks to physical networks and pure virtual networks with no uplinks to physical
networks.
Specify VM NIC hardware type vmxnet3 for best performance. Avaya .ova files are built
using vmxnet3 by default.
Connect all physical NICs that are connected to the same vSphere standard or distributed
switch to the same physical network.
Configure all VMkernal vNICs to the same IP Maximum Transmission Unit (MTU).
References
Title
Link
Performance Best Practices for http://www.vmware.com/pdf/

Perf_Best_Practices_vSphere5.0.pdf
VMware vSphere 5.0
Performance Best Practices for http://www.vmware.com/pdf/
Perf_Best_Practices_vSphere5.1.pdf
VMware vSphere 5.1
VMware vSphere Basics
http://pubs.vmware.com/vsphere-50/index.jsp?topic=
%2Fcom.vmware.vsphere.introduction.doc_50%2FGUI
D-F7A7E6C0-FA25-4806-8921-0438F1B2AEAE.html
Thin vs. thick deployments

The general recommendation is to deploy thick disks which are lazy-zeroed. A lazy-zeroed
thick disk has all of the space allocated at the time of creation, but each block is zeroed only
on the first write. The result is a shorter creation time but reduced performance the first time a
block is written.
Some configurations require eager-zeroed thick disks. An eager-zeroed thick disk
has all space allocated and zeroed out at the time of creation.
results in the best performance, even on the first write to each block.
has a longer disk creation time. Because of the extra time required to deploy an eager
zero disk, it is not uncommon for the deployment operation to time out and fail.
Thin provisioned disks can over-allocate storage. If the storage is over-allocated, thin virtual
disks can grow to fill an entire datastore if left unchecked. You can use thin provisioned disks,
24

April 2013
Best practices for VMware features
but you must use strict control and monitoring to maintain adequate performance and ensure
that storage is not completely consumed. If operational procedures are in place to mitigate the
risk of performance and storage depletion, then thin disks are a viable option.

VMware Snapshots
A snapshot preserves the state and data of a virtual machine at a specific point in time. A
snapshot is useful as a short-term fallback for patching and upgrading the system.
Snapshots can:
consume large amounts of data resources.
cause increased CPU loads on the host.
affect performance.
affect service.
Caution:
Snapshot operations can adversely affect service. The application that is running on
the virtual machine must be stopped or set to out-of-service before you perform a
snapshot operation. When the snapshot operation has completed, the application can
then be restarted or brought back into service.
Due to the adverse behaviors, consider the following recommendations when using the
Snapshot feature.
Do not rely on VMware snapshots as a robust backup and recovery method. Snapshots
are not backups. The snapshot file is only a change log of the original virtual disk.
Do not run a virtual machine off of a snapshot. Do not use a single snapshot for more
than 24-72 hours. The recommended actions are to take the snapshot, make the changes
to the virtual machine, and delete or commit the snapshot as soon as the virtual machine
is verified to be working properly. Following the recommended actions prevents
snapshots from growing so large as to cause issues when deleting or committing the
snapshots to the original virtual machine disks.
When taking a snapshot, do not save the memory of the virtual machine. The length of
time the host takes to write the memory onto the disk is relative to the amount of memory
the virtual machine is configured to use and can add several minutes to the time it takes
to complete the operation. If the snapshot is activated, saving memory will make calls
April 2013
25
appear to be active or in progress and can cause confusion to the user. When creating a
snapshot, make sure that you:
- uncheck the Snapshot the virtual machines memory check box in the Take
Virtual Machine Snapshot window.
- select the Quiesce guest file system (Needs VMware Tools installed) check box
to make sure all writes to the disks have completed. It gives a better chance of
creating a clean snapshot image from which to boot.
If you are going to use snapshots over a long period of time, you must consolidate the
snapshot files on a regular basis to improve performance and reduce disk usage. Before
merging the snapshot delta disks back into the base disk of the virtual machine, you must
first delete stored snapshots.
Note:
In the event of a consolidate failure, end-users can use the actual Consolidate option
without opening a service request with VMware. If a commit or delete operation does
not merge the snapshot deltas into the base disk of the virtual machine, a warning is
displayed in the UI.
Related resources
Title
Web page
Best practices for virtual machine snapshots Best Practices for virtual machine snapshots
in the VMware environment
in the VMware environment
Understanding virtual machine snapshots in Understanding virtual machine snapshots in
VMware ESXi and ESX
VMware ESXi and ESX
Working with snapshots
Working with snapshots
Configuring VMware vCenter Server to send Send alarms when virtual machines are
alarms when virtual machines are running
running from snapshots
from snapshots
Consolidating snapshots in vSphere 5.x
Consolidating snapshots in vSphere 5.x
VMware High Availability

VMware High Availability (HA) is a viable option for SAL recovery in the VMware environment.
If you have configured VMware HA on the ESXi host on which a SAL Gateway virtual machine
is installed, failure of this ESXi host results in SAL Gateway vAppliance being moved to a
standby ESXi host. After the cold boot of SAL Gateway on the standby ESXi host is complete,
SAL Gateway resumes to provide all the usual features and services.
26

April 2013
Keep the following points in mind while configuring to use VMware HA:
All virtual machines and the configuration files of the virtual machine must be on a shared
storage, such as Fibre Channel SAN, iSCSI SAN, or SAN iSCI NAS.
To have reliable failure detection for HA clusters, the console network must have
redundant network paths. The reason is that VMware HA monitors the heartbeat between
hosts on the console network for failure detection.
VMware HA uses the virtual machine priority to decide the order of restart.
VMware vMotion
VMware uses the vMotion technology to migrate a running virtual machine from one physical
server to another physical server without incurring downtime. The migration process, also
known as a hot-migration, enables the live migration of running virtual machines with zero
downtime, continuous service availability, and complete transaction integrity.
With vMotion, you can
schedule migration to occur at predetermined times and without the presence of an
administrator.
perform hardware maintenance without scheduled downtime.
migrate virtual machines away from failing or under-performing servers.
Before using vMotion, note the following:
Ensure that each host that migrates virtual machines to or from the host uses a licensed
vMotion application and the vMotion is enabled.
Ensure that you have identical vSwitches. You must enable vMotion on these
vSwitches.
Ensure identical Port Groups for vMotion.
Use a dedicated NIC to ensure the best performance.
Hyperthreading
VMware recommends that you enable hyperthreading on the ESXi host as hyperthreading
can enhance the processor performance. Hyperthreading is enabled by default on the ESXi
host. For the procedure to enable hyperthreading, see the VMware ESXi host
documentation.
April 2013
27
28

April 2013
Chapter 5: Initial setup and pre-deployment
Downloading the SAL Gateway OVA

Registering for PLDS
Procedure
1. Go to the Avaya Product Licensing and Delivery System (PLDS) Web site at https://
plds.avaya.com.
The PLDS Web site redirects you to the Avaya single sign-on (SSO) Web page.
2. Log in to SSO with your SSO ID and password.
The PLDS registration page is displayed.
3. If you are registering:
as an Avaya Partner, enter the Partner Link ID. If you do not know your Partner
Link ID, send an e-mail to prmadmin@avaya.com.
as a customer, enter one of the following:
- Company Sold-To
- Ship-To number
- License authorization code (LAC)
4. Click Submit.
Avaya will send you the PLDS access confirmation within one business day.
Downloading software from PLDS

About this task
Note:
You can download product software from http://support.avaya.com also.
April 2013
29
Initial setup and pre-deployment
Procedure
1. Type http://plds.avaya.com in your Web browser to go to the Avaya PLDS
website.
2. Enter your Login ID and password to log on to the PLDS Web site.
3. On the Home page, select Assets.
4. Select View Downloads.
5. Search for the available downloads using one of the following methods:
By actual download name
By selecting an application type from the drop-down list
By download type
By clicking Search Downloads
6. Click the download icon from the appropriate download.
7. When the system displays the confirmation box, select Click to download your
file now.
8. If you receive an error message, click on the message, install Active X, and continue
with the download.
9. When the system displays the security warning, click Install.
When the installation is complete, PLDS displays the downloads again with a
checkmark next to the downloads that are completed successfully.
Registering the SAL Gateway virtual machine

Registering a product with Avaya is a process that uniquely identifies the product so that Avaya
can provide service to the product. To register a product, you must notify Avaya Registration
Team and provide the appropriate product information.
When you register a new SAL Gateway, Avaya assigns a Solution Element ID (SEID) and a
Product ID to the SAL Gateway. You require these identifiers to install the SAL Gateway virtual
machine software. Using these IDs, Avaya can uniquely identify the SAL Gateway at your
location.
About this task

Use this procedure to register a SAL Gateway virtual machine with Avaya and to obtain the
unique identifiers prior to the SAL Gateway virtual machine implementation.
30

April 2013
Registering the SAL Gateway virtual machine
Procedure
1. Using the Secure Access Link Registration Form that is available with the software
download, complete Step 1 of the form. On the form, enter the following information:
Customer name.
Avaya Sold-To number or customer functional location (FL) number that
identifies the location where you want to install SAL Gateway.
Customer contact information, so that Avaya can contact you for sending the
IDs or for any queries.
2. (Optional) To obtain SEIDs of registered devices from other functional locations,
complete Step 2 of the registration form.
3. Send the registration form to salreg@avaya.com using the link provided on the
form.
Result
Avaya uses this information to register the new SAL Gateway. When the registration is
complete, Avaya sends you an email message with the following information:
The SEID and the Product ID of the new SAL Gateway. You require these identifiers to
install SAL Gateway.
A list of Avaya devices currently registered at the same location.
A list of other FLs for your company.
If you completed Step 2 of the registration form, Avaya sends you a list of SEIDs and Product
IDs of the devices installed in the locations you selected.
Next steps
Implement the SAL Gateway virtual machine.
Add managed devices to your SAL Gateway using the SEIDs provided to you in Step 1
and Step 2 of the registration form.
Submit the registration form after completing Step 2 for the added managed devices.
April 2013
31
Initial setup and pre-deployment
32

April 2013
Chapter 6: Deploying the SAL Gateway

OVA
SAL Gateway OVA deployment overview

The SAL Gateway OVA supports two models of deployment on a VMware vSphere 5.0 or 5.1
environment:
vCenter deployment through a vSphere client
Direct deployment to the ESXi server through a vSphere client
Based on the VMware environment you have, select one of the two methods of deployment.
Deployment checklist
Use the following checklist for deploying the SAL Gateway vAppliance.
#
Action
Link/Notes
Ensure that the ESXi host server is

ready.
Ensure that you have the Solution

Element ID and the Product ID for
SAL Gateway.
You receive these IDs after you

register SAL Gateway with Avaya.
For more information, see
Registering the SAL Gateway
virtual machine on page 30.
Deploy the OVA.
See Deploying the SAL Gateway

OVA directly to the ESXi server on
page 40 or Deploying the SAL
Gateway OVA to vCenter on
page 34.
April 2013
33
Deploying the SAL Gateway OVA
Deploying the SAL Gateway OVA to vCenter

If you have a vCenter server to administer your VMware infrastructure, use this procedure to
deploy the SAL Gateway OVA to your VMware infrastructure. In the vCenter deployment, you
get the options to provide the SAL Gateway configuration information through the deployment
wizard windows.
Procedure
1. Connect to the vCenter server through the vSphere client.
2. Select File > Deploy OVF Template.
3. In the Deploy OVF Template window, perform one of the following to select the OVA
file, and click Next:
If the OVA file is downloaded at a location accessible from your computer, click
Browse to select the location.
If the OVA file is located on an HTTP server, enter the full URL in the Deploy
from a file or URL field.
4. In the OVF Template Details window, verify the details about the SAL Gateway OVA
template, and click Next.
5. In the End User License Agreement window, read the license agreement, and click
Accept.
6. Click Next.
7. Perform the following to specify the location for the deployment:
a. In the Name and Location window, in the Name field, type a unique name for
the new virtual machine.
b. From the Inventory Location field, select the inventory location to deploy the
virtual machine.
c. Click Next.
If you did not select a host when you started the deployment process, the wizard
displays the Host/Cluster window.
d. Select the host or cluster where you want to deploy the virtual machine, and
click Next.
If the host or cluster has resource pools, the wizard displays the Resource
Pool window.
e. Select the resource pool you want to use, and click Next.
8. In the Storage window, select the data store location to store the virtual machine
files, and click Next.
34

April 2013
Deploying the SAL Gateway OVA to vCenter
9. In the Disk Format window, accept the default disk format, Thick Provision Lazy
Zeroed, which allocates the required 40-GB disk space for the SAL Gateway virtual
machine, and click Next.
For information about virtual disk, see Thin vs. thick deployments on page 24.
10. In the Properties window, perform the following to configure the SAL Gateway
specifications:
a. In the Application section of the Properties window, complete the following fields
for configuring the SAL Gateway parameters:
Timezone setting
Hostname
Solution Element ID
Alarm ID
Platform Qualifier
Primary Destination Core
Port
Secondary Destination Core
Port
Primary Destination Remote
Port
Secondary Destination Remote
Port
(Optional) Proxy Type
(Optional) Proxy Hostname
(Optional) Proxy Port
(Optional) Proxy User
(Optional) Proxy Password
(Optional) Policy Server Hostname
(Optional) Policy Server Port
Master Agent Hostname
Master AgentX Port
Role
b. In the Network Properties section of the Properties window, complete the
following fields according to your network settings:
Default Gateway
April 2013
35
DNS
Network 1 IP Address
Network 1 Netmask
For more information about the fields, see Properties field descriptions on
page 36.
11. Click Next.
12. (Optional) In the Ready to Complete window, select the Power on after
deployment check box to automatically start the virtual machine after the
deployment.
If you do not select this check box, you can manually start the virtual machine after
the deployment.
13. In the Ready to Complete window, verify the deployment properties settings, and
click Finish.
The deployment process takes about 10 to 12 minutes to complete. If the OVA file
location is an HTTP server, the deployment process might take more time.
Next steps
If you did not select the option to start the virtual machine automatically, start the virtual
machine.
Related topics:
Starting the SAL Gateway virtual machine on page 43
Properties field descriptions

The following table provides the descriptions of the fields available in the Application section
of the Properties page.
Name
36
Description
Timezone setting
The appropriate time zone for the location where

you deploy the SAL Gateway virtual machine.
Hostname
The host name of the SAL Gateway virtual

machine.
Solution Element ID
A unique identifier in the format (nnn)nnn-nnnn,

where n is a digit from 0 through 9. Using this ID,
Avaya Services or Avaya Partners can uniquely
identify and connect to this SAL Gateway.
You must replace the default value with the
Solution Element ID you receive from Avaya.

April 2013
Name
Description
Otherwise, the remote access and product alarm
functionalities through SAL Gateway are affected.
You receive this ID after you register SAL Gateway
with Avaya.
Note:
Register your SAL Gateway before you perform
the deployment so that you have the Solution
Element ID and Product ID ready for the
deployment. You can modify the Solution
Element ID and the Product ID information later
through the SAL Gateway user interface (UI).
Alarm ID
A unique 10-character ID, also called Product ID,

assigned to a device, for example, this SAL
Gateway. The Product ID is included in alarms that
are sent to alarm receivers from the managed
device. Avaya uses the Alarm ID to identify the
device that generated the alarm.
You must replace the default value with the Product
ID you receive from Avaya. Otherwise, the remote
access and product alarm functionalities through
SAL Gateway are affected. You receive this ID
after you register SAL Gateway with Avaya.
Platform Qualifier
An alphanumeric string to establish a channel for

communication between SAL Gateway and Secure
Access Concentrator Core Server.
The default platform qualifier is Enterpriseproduction. Do not change the default value
unless you receive instructions to do so.
Primary Destination Core
The host name of the Concentrator Core Server

that SAL Gateway first contacts.
The default value is
secure.alarming.avaya.com, which is
used to communicate with the Concentrator Core
Server located at Avaya.
If you have a local Concentrator Core Server or one
at a partner location, you must enter the host name
or the IP address of that server. Otherwise, you
must retain the default value to communicate with
Avaya.
Port
The port number for the primary Concentrator Core

Server.
The default port is 443. For the Avaya Concentrator
Core Server, you must retain the default value. For
a local Concentrator Core Server, you must enter
the value as 8443.
April 2013
37
Name
Description
Secondary Destination Core
The host name of the secondary Concentrator

Core Server.
The default value for this field is
secure.alarming.avaya.com.
Note:
If you do not have a secondary server, accept
the default value.
Port
The port number for the secondary Concentrator

Core Server.
The default value for this field is 443.
Note:
If you do not have a secondary server, accept
the default value.
Primary Destination Remote
The host name or IP address of the primary Secure

Access Concentrator Remote Server that requests
and facilitates remote access for service
personnel.
The default value is sl1.sal.avaya.com,
where sl1 has a lower case letter L and then the
number 1 following the letter s.
Port
The port number of the primary Secure Access

Concentrator Remote Server.
The default value is 443.
Secondary Destination Remote
The host name or IP address of the secondary

Concentrator Remote Server.
The default value is sl1.sal.avaya.com.
Port
The port number of the secondary destination.

The default value is 443.
Proxy Type
(Optional) The type of channel that the SAL

Gateway virtual machine uses to communicate
with the servers outside your network. This field is
required only if you use a proxy server for Internet
access outside the firewall of your network. The
options are:
HTTP: For an HTTP proxy without
authentication.
Authenticated HTTP: For an HTTP proxy with
authentication.
SOCKS: For a SOCKS proxy without
authentication.
38

April 2013
Name
Description
Proxy Hostname
(Optional) The host name or IP address of the

proxy server. This field is required only if you have
a proxy server for Internet access outside your
network.
Proxy Port
(Optional) The port number of the proxy server.
Proxy User
(Optional) The user name for the authenticated

HTTP proxy. This field is required only if the proxy
type is authenticated HTTP.
Proxy Password
(Optional) The password for the authenticated

HTTP proxy. This field is required only if the proxy
type is authenticated HTTP.
Policy Server Hostname
(Optional) The host name or the IP address of

Policy Server installed on your network.
The use of Policy Server is optional. You can add
the Policy Server information later through the SAL
Gateway user interface (UI).
Policy Server Port
(Optional) The port number that Policy Server uses

for communication with SAL Gateway.
The host name or IP address of the SNMP master

agent to which the SNMP subagent must
connect.
The default value is 127.0.0.1. If you have not
configured an SNMP master agent before the OVA
deployment, you must update the SNMP master
agent information on the SAL Gateway UI after you
complete OVA deployment.
For information about SNMP master agent
configuration, see Implementing Secure Access
Link Gateway.
Master AgentX Port
The AgentX listener port number of the SNMP

master agent.
Role
The role or permission level of the Avaya support

personnel to the SAL Gateway UI. Avaya support
personnel can have one of the following roles:
Administrator: With full permissions to all the
SAL Gateway UI pages except a few.
Browse: With the read-only access to all
pages.
Deny: Without access to the SAL Gateway UI.
The following table provides the descriptions of the fields available in the Network Properties
section of the Properties page.
April 2013
39
Name
Description
Default Gateway
The IP address of the default gateway on your

network. You can leave this field blank if you plan
to use Dynamic Host Configuration Protocol
(DHCP).
DNS
The comma-separated addresses of the Domain

Name Servers (DNS) for the virtual machine. You
can leave this field blank if you plan to use
DHCP.
Network 1 IP Address
The IP address of the network interface. You can

leave this field blank if you plan to use DHCP.
Network 1 Netmask
The netmask or prefix for the network interface.

You can leave this field blank if you plan to use
DHCP.
Deploying the SAL Gateway OVA directly to the ESXi

server
Use this procedure to deploy the SAL Gateway OVA directly to the ESXi server through a
vSphere client.
During this direct deployment, you cannot configure the SAL Gateway parameters. After the
deployment, when you start the SAL Gateway virtual machine console for the first time, the
console displays a series of prompts to set the SAL Gateway parameters.
Procedure
1. Connect to the ESXi host server through the vSphere client.
2. Select File > Deploy OVF Template.
3. On the Deploy OVF Template window, perform one of the following to select the
OVA file:
If the OVA file is downloaded at a location accessible from your computer, click
Browse to select the location.
If the OVA file is located on an http server, enter the full URL in the Deploy
from a file or URL field.
4. Click Next.
5. On the OVF Template Details window, verify the details about the SAL Gateway
OVA template, and click Next.
40

April 2013
Deployment of cloned and copied OVAs
6. On the End User License Agreement window, read the license agreement, click
Accept, and click Next.
7. On the Name and Location window, in the Name field, type a unique name for the
new virtual machine, and click Next.
8. On the Disk Format window, accept the default disk format, Thick Provision Lazy
Zeroed, which allocates the required 40-GB disk space for the SAL Gateway virtual
machine, and click Next.
For information about virtual disk, see Thin vs. thick deployments on page 24.
9. (Optional) On the Ready to Complete window, select the Power on after
deployment check box to automatically start the virtual machine after the
deployment.
If you do not select this check box, you can manually start the virtual machine after
the deployment.
10. On the Ready to Complete window, verify the deployment settings, and click
Finish.
The deployment process takes about 10 to 12 minutes to complete. If the OVA file
location is an http server, the deployment process might take more time.
Next steps
If you did not select the option to start the virtual machine automatically, start the virtual
machine.
Start the SAL Gateway virtual machine console, and configure the SAL Gateway
parameters.
Related topics:
Starting the SAL Gateway virtual machine on page 43
Configuring the SAL Gateway and the network parameters on page 45
Deployment of cloned and copied OVAs

To re-deploy a virtual machine, you can create a copy of the virtual machine or clone the virtual
machine. These processes have subtle technical details that require a thorough understanding
of the effects of these approaches. To avoid any complexities and unexpected behavior, deploy
a new OVA.
Installing a guest operating system and applications can be time consuming. With cloning, you
can make several copies of a virtual machine from a single installation and configuration
process. However, if you are making a clone of an Avaya application, do not perform any
Guest Customization. If you are making a clone of an Avaya application, select Do not
customize.
April 2013
41
42

April 2013
Chapter 7: Initial configuration
Starting the SAL Gateway virtual machine

Use this procedure to start the virtual machine.
Procedure
1. In the vSphere client, right-click the virtual machine, and click Power > Power
On.
2. In the vSphere client, right click the virtual machine, and click Open Console.
Result
The console displays the system startup messages. The system starts the system services
and the SAL Gateway services. After the startup process is complete, the system displays a
message to log in to the virtual machine.
If you deploy the virtual machine directly on the ESXi host server, the system displays
messages to set the SAL Gateway parameters and the network parameters whenever you
start the virtual machine.
Configuring the virtual machine automatic start and stop

settings
Configure the virtual machine to start automatically after a power failure or a restart of the
hypervisor. The default is set to no.
In high availability (HA) clusters, the VMware HA software ignores the Startup selections.
Procedure
1. In the vSphere Client inventory, select the host where the virtual machine is
located.
2. Click the Configuration tab.
3. In the Software section, click Virtual Machine Startup/Shutdown.
April 2013
43
Initial configuration
4. Click Properties in the upper right corner of the screen.

5. In the System Settings section, select Allow virtual machines to start and stop
automatically with the system.
6. In the Manual Startup section, select the virtual machine.
7. Use the Move up button to move the virtual machine under Automatic Startup.
8. Click OK.
Example
The following is an example of the Virtual Machine Startup/Shutdown screen.
44

April 2013
Configuring the SAL Gateway and the network parameters
Configuring the SAL Gateway and the network parameters

If you deploy the SAL Gateway virtual machine directly on an ESXi host server, you must
configure the network and the SAL Gateway parameters when you start the virtual machine
for the first time.
At each subsequent restart of the virtual machine that was deployed directly on an ESXi host,
you get the options to reconfigure the virtual machine. You can either proceed with the
configuration or skip the configuration.
Procedure
1. After you start the virtual machine for the first time, open the virtual machine
console.
As a part of the startup, the system prompts you to configure the SAL Gateway
vAppliance.
2. If required, select the appropriate option in the configuration wizard to change the
following network settings:
The IP address of the default gateway on your network.
Note:
Set the IP address and netmask before entering the default gateway
information for the virtual machine.
The hostname of the virtual machine.
The domain name server (DNS) information.
The proxy server information.
The IP address allocated to the virtual machine.
3. At the system prompt, select the time zone for the SAL Gateway virtual machine.
4. At the appropriate system prompts, complete the following SAL Gateway
parameters. To accept the default values, press Enter at each prompt:
SAL Gateway Solution Element ID
SAL Gateway Alarm ID
Platform Qualifier
Primary Destination Core Server
Primary Destination Core Server Port
Secondary Destination Core Server
Secondary Destination Core Server Port
April 2013
45
Initial configuration
Primary Destination Remote Server

Primary Destination Remote Server Port
Secondary Destination Remote Server
Secondary Destination Remote Server Port
(Optional) Proxy Type
(Optional) Proxy Server Hostname
(Optional) Proxy Server Port
(Optional) Policy Server Hostname
(Optional) Policy Server Port
Master Agent Port
For more information about the fields, see Properties field descriptions on
page 36.
5. When the system prompts, select the role to be assigned to Avaya service
personnel.
6. Confirm the configuration changes.
The system configures SAL Gateway according to the settings you entered.
Result
After the SAL Gateway configuration is complete, the system starts the SAL Gateway services
and prompts you to log on to the virtual machine.
46

April 2013
Chapter 8: Validation of the SAL Gateway

implementation
You can run a number of tests to validate whether the SAL Gateway implementation is successful. The
validation involves ensuring that the SAL Gateway services, which include alarming, remote access, SAL
Watchdog, and SAL Gateway UI, are running properly.
Testing the alarming service of SAL Gateway

Procedure
1. Log on to the SAL Gateway virtual machine as admin, and switch to the root user.
2. Run the following command, and check the outcome of the command:
service spiritAgent status
3. If the service is not running, run the following command to start the service:
service spiritAgent start
4. Check the status again to verify that the service is running properly.
Testing the remote access service of SAL Gateway

About this task
Use the following procedure to test whether the remote access service of SAL Gateway is
running properly.
Procedure
service axedaAgent status
April 2013
47
Validation of the SAL Gateway implementation
service axedaAgent start

Testing the SAL Watchdog service

Procedure
service salWatchdog status
service salWatchdog start
Testing the Gateway UI

About this task
You can browse to the SAL Gateway Web interface using a Web browser.
Procedure
1. From another terminal on the network where SAL Gateway is deployed, open a
Web browser.
2. In the address bar, type the following URL:
https://<IP address of the SAL Gateway virtual machine>:7443
You can replace the host IP with the DNS host name if the host server is registered
under DNS.
The browser must display the SAL Gateway login page.
48

April 2013
Chapter 9: Reconfiguration of the virtual

machine
After you deploy the SAL Gateway virtual machine, you can reconfigure the virtual machine at any time.
The reconfiguration procedures differ based on the type of deployment, which can be vCenter deployment
or direct ESXi deployment.
Reconfiguring the virtual machine deployed through

vCenter
About this task
Use this procedure to reconfigure the virtual machine deployed using vCenter.
Procedure
1. Connect to the vCenter server through the vSphere client.
2. Shut down the virtual machine.
3. Right click the virtual machine, and click Edit Settings.
4. On the Edit Settings window, select the Options tab, and click Properties.
5. Modify the properties according to your requirements.
Note:
On the Edit Settings window, you can modify the time zone and the network
settings, which include the hostname, the netmask, the IP Address, the DNS, and
the default gateway. To change any SAL Gateway-specific parameters, use the
SAL Gateway Web interface.
6. Click OK.
7. Power on the virtual machine.
Result
When the virtual machine boots up, all the settings are applied automatically.
April 2013
49
Reconfiguration of the virtual machine
Reconfiguring the virtual machine deployed directly on an

ESXi server
If you deploy the SAL Gateway virtual machine directly on an ESXi host, then at every reboot,
a script runs during the boot up process that waits for user inputs. By following the interactive
messages from the script, you can reconfigure the virtual machine. The script waits for your
input for 30 seconds before proceeding with the normal boot process. If you do not provide
any input within 30 seconds, the script skips the reconfiguration of the virtual machine and
proceeds with the normal boot process.
About this task

Use this procedure only when you need to reconfigure the virtual machine deployed directly
on an ESXi host server.
Procedure
1. Connect to the ESXi host server through the vSphere client.
2. Shut down the virtual machine.
3. Start the virtual machine, and open the virtual machine console.
As part of the startup, the system prompts you to configure the virtual machine.
4. Follow the interactive messages that the system displays to reconfigure the virtual
machine.
Note:
Using this procedure, you can modify the time zone and the network settings,
which include hostname, netmask, IP Address, DNS, and default gateway. To
change any SAL Gateway-specific parameters, use the SAL Gateway Web
Interface.
For more information about the network parameters, see Configuring the SAL
Gateway and the network parameters on page 45.
50

April 2013
Chapter 10: Backing up and restoring the

virtual machine
Backup and restore overview

You can use the backup and restore capabilities of the SAL Gateway virtual machine for the
long-term backup and recovery of the SAL Gateway virtual machine that runs on VMware.
As the customer, you have the responsibility to run the backup at periodic intervals.
Alternatively, you can schedule a job to run the backup at a periodic interval and copy the
backup archive to an external system for preserving the data in the event of a system
failure.
Backing up the virtual machine

About this task
Use this procedure to back up the SAL Gateway virtual machine.
Procedure
1. Open a virtual machine console, or connect to the virtual machine using an SSH
client.
3. Run the following command:
backup
The system displays the directory location where the backup archive is saved.
You can find the latest backup archive file at the /vm-data/backup/
archives/ directory. The archive file is saved with a file name similar to
vmbackup_xxxxxxxx.tar.gz.
4. Copy the backup archive to an external host to prevent loss of data in the event of
a system failure.
To copy the file to a remote server, you can use the Linux scp command:
April 2013
51
Backing up and restoring the virtual machine
scp <archive_file>
<username>@<remote_server_ip>:<directory_path>
Restoring a virtual machine

About this task
Use this procedure to restore a virtual machine from a backup archive.
Procedure
1. Deploy the virtual machine.
2. Start the virtual machine.
3. Log in to the virtual machine as admin, and switch to the root user.
4. Copy the backup archive file to a directory on the virtual machine.
If you are copying the file from a remote system, you can use the following:
From a Linux remote system: Use the scp command to copy the file back to
the virtual machine.
scp
<user>@<SAL_VM_IP_or_hostname>:<directorypath_and_filena
me_on_remote_system_location>
From a Windows remote system: Use WinSCP or a similar file transfer utility
to copy the file back to the virtual machine.
5. From the virtual machine console, run the following command:
restore <Archive_file_path_on_VM>
52

April 2013
Chapter 11: Upgrading the SAL Gateway

OVA
Upgrading the SAL Gateway vAppliance

About this task
Use this procedure to upgrade to a new version of the SAL Gateway vAppliance. That is, if
you have already deployed the Beta version of the SAL Gateway virtual machine, you can use
this procedure to upgrade to the GA version of the SAL Gateway virtual machine.
Procedure
1. Take a backup of the existing SAL Gateway virtual machine, and copy the backup
file to an external host.
For more information, see Backing up the virtual machine on page 51.
2. Shut down the existing SAL Gateway virtual machine.
3. Deploy the new SAL Gateway OVA on an ESXi host server.
You can accept the default values for configuring the virtual machine and the SAL
Gateway software as you are going to restore the configuration values from the
backup file of the earlier virtual machine.
4. Start the new SAL Gateway virtual machine.
5. Log in to the new SAL Gateway virtual machine as admin, and switch to the root
user.
6. Copy the backup file from the external host to a directory on the new virtual
machine.
7. Restore the backup file on the new SAL Gateway virtual machine.
For more information, see Restoring a virtual machine on page 52.
Next steps
Check the network configuration, services, and SAL Gateway configuration to validate that the
upgrade process is successful.
After you validate the upgrade process, you can remove the earlier virtual machine from the
host server.
April 2013
53
Upgrading the SAL Gateway OVA
Related topics:
Deploying the SAL Gateway OVA to vCenter on page 34
Deploying the SAL Gateway OVA directly to the ESXi server on page 40
Backing up the virtual machine on page 51
Restoring a virtual machine on page 52
Validating an upgrade operation

After you upgrade the SAL Gateway virtual machine by restoring the backup of an earlier virtual
machine, you must check whether the network configuration and the SAL Gateway
configuration are properly restored. Additionally, you must check that all the services are
running on the new virtual machine.
About this task

Use the following steps to validate that the upgrade process is successful.
Procedure
2. Run the following command to check the version of the new SAL Gateway virtual
machine:
swversion -v
The version number for the GA release of the SAL Gateway vAppliance is
SALGateway-2.2.0.0-vApp-1.0.0.0-e50-09.
3. Run the following commands to view and verify that the network configuration
parameters, including IP address and hostname, are restored properly:
ifconfig
hostname
less /etc/host
4. Run the following commands to verify that the SAL Gateway services are up and
running:
service spiritAgent status
service axedaAgent status
service gatewayUI status
5. Log on to the SAL Gateway Web interface, and check the SAL Gateway
configuration.
To report a problem with the upgrade operation or to contact Avaya Support for
assistance, visit the Avaya Support website at http://support.avaya.com.
54

April 2013
Chapter 12: Troubleshooting
FAQ
Q. Do I require a console access while rebooting the SAL Gateway virtual machine?
A.
No. A console access is not necessary while you reboot the SAL Gateway virtual
machine. However, depending on the deployment scenario and the user needs, having
a console access can be useful.
If the SAL Gateway virtual machine was deployed through vCenter, then you do not
require a console access during the rebooting. If the SAL Gateway virtual machine was
deployed directly on an ESXi host using a vSphere client, then having a console access
can help you to reconfigure the virtual machine during the boot process. When you
reboot a SAL Gateway virtual machine that is deployed directly on an ESXi host, a
script runs during the boot process that waits for user inputs. You can utilize the script
to reconfigure the virtual machine. The script waits for user input for 30 seconds before
proceeding with the normal boot process. If you do not provide input within 30 seconds,
the script considers that you do not want to reconfigure the virtual machine. To be able
to utilize the script, you require a console access. In absence of a console access, the
script waits for 30 seconds and then continues with the normal boot process. This
process is applicable only in the case of direct deployment.
Q. How do I reconfigure my virtual machine after I have deployed the virtual machine?
A.
For information about reconfiguring your virtual machine, see Reconfiguring the virtual
machine deployed through vCenter on page 49 and Reconfiguring the virtual machine
deployed directly on an ESXi server on page 50.
Q. How do I manage the system date and time?

A.
The SAL Gateway virtual machine uses NTP to synchronize the system time with an
NTP server. For information about configuring NTP servers on the SAL Gateway virtual
machine, see Configuring timing on page 22.
Q. Can I use the Ethernet interface other than eth0 for the SAL Gateway virtual machine?
A.
No. Currently the SAL Gateway virtual machine can work only with eth0.
Q. Can I use DHCP for the network parameters for the SAL Gateway virtual machine?
A.
Even though the SAL Gateway virtual machine supports DHCP, Avaya does not
recommend using DHCP for the SAL Gateway virtual machine. The SAL Gateway
virtual machine has SAL Gateway running on the machine, which onboards the devices
in the customer network. For onboarding, SAL Gateway uses the IP address of the SAL
Gateway virtual machine. If you use DHCP for configuring the network parameters of
April 2013
55
Troubleshooting
the SAL Gateway virtual machine, then chances are that the IP address of the SAL
Gateway virtual machine might change. In such cases, you must again onboard all the
devices, which were already onboard, one by one with the new IP address.
Configure static parameters for the networking of the SAL Gateway virtual machine so
that you do not encounter similar issues.
Q. I have installed the SAL Gateway virtual machine using DHCP through vCenter. How
do I change to static configuration?
A.
Perform the following steps to apply static configuration for networking to the SAL
Gateway virtual machine installed using vCenter:
1. Open a virtual machine console, or connect to the virtual machine through an SSH
client.
/opt/vmware/share/vami/vami_ovf_process -s eth0
4. Shut down the virtual machine using the vCenter administration.
5. Edit the virtual machine settings.
6. Provide static configuration for the networking parameters in the Properties
page.
7. Start the virtual machine using the vCenter administration.
Q. Why do I get an VM communication interface: [FAILED] error on the
virtual machine console during the first boot?
A.
Ignore these errors. During the first boot, the system recreates the initial ram disk (initrd)
to include the VMware Tools modules, which causes these errors. These errors have
no service impact. The errors do not occur on subsequent reboots.
Q. Why do I get an Unloading iptables modules: [FAILED] error during the

restore operation?
A.
Ignore this error. Apart from the SAL Gateway services, other processes in the SAL
Gateway virtual machine use the iptables modules. During the restore process, the
system tries to restart the iptables service. The restart attempt fails because these
shared modules cannot be unloaded while other processes are still running. Failure to
unload the iptables modules has no service impact.
Q. How do I find the version of the SAL Gateway virtual machine?

A.
Perform the following steps to find the version of the SAL Gateway virtual machine:
1. Open a virtual machine console, or connect to the virtual machine through an SSH
client.
2. Log in as admin.
sudo swversion
The system displays a verbose output.
4. To see only the SAL Gateway version, run the following command:
56

April 2013
FAQ
sudo swversion -s
5. To see only the version of the SAL Gateway virtual machine, run the following
command:
sudo swversion -v
Q. I got an error while running the restore command. What should I do?
A.
Try to run the restore command again. If the error persists, visit the Avaya Support
website at http://support.avaya.com to contact Avaya.
Q. Why do I have to configure the virtual machine every time I boot up?
A.
A. If you deployed the SAL Gateway virtual machine directly on an ESXi host, then
every time you boot the virtual machine, a script runs as part of the boot up process
that waits for user inputs. Through the interactive prompts from the script, you can
reconfigure the virtual machine.
The script runs in two parts. In the first part, you can configure the network parameters.
In the second part, you can configure the time zone settings.
If you want to skip the process, type n or N when the script prompts for reconfiguration
on the virtual machine console.
Q. Why pressing Control+C does not work during the configuration of the virtual machine
on the virtual machine console?
A.
The script for configuring network parameters for a direct deployment on an ESXi host
indicates that pressing Control+C opens the main menu. However, this script runs while
the virtual machine is still booting. Therefore, the Control+C key press sequence does
not work. This issue is a known issue.
Q. Will there be any service outage if I run the storage or host vMotion?
A.
Running the storage or host vMotion does not affect any service that is currently running
on the SAL Gateway virtual machine. Any remote connections created before running
the storage or host vMotion continue to work.
However, when the storage or host vMotion is in progress, you might not be able to
establish new remote connections to the managed devices. This outage lasts only until
the storage or host vMotion is complete. After the storage or host vMotion completes
successfully, you can establish new connections.
April 2013
57
Troubleshooting
58

April 2013
Appendix A: PCN and PSN notifications
PCN and PSN notifications

Avaya issues a product-change notice (PCN) in case of any software update. For example, a
PCN must accompany a service pack or a patch that needs to be applied universally. Avaya
issues product-support notice (PSN) when there is no patch, service pack, or release fix, but
the business unit or services need to alert Avaya Direct, Business Partners, and customers of
a problem or a change in a product. A PSN can also be used to provide a workaround for a
known problem, steps to recover logs, or steps to recover software. Both these notices alert
you to important issues that directly impact Avaya products.
Viewing PCNs and PSNs

About this task
To view PCNs and PSNs, perform the following steps:
Procedure
1. Go to the Avaya Support website at http://support.avaya.com.
Note:
If the Avaya Support website displays the login page, enter your SSO login
credentials.
2. On the top of the page, click DOWNLOADS & DOCUMENTS.
3. On the Downloads & Documents page, in the Enter Your Product Here field, enter
the name of the product.
4. In the Choose Release field, select the specific release from the drop-down list.
5. Select Documents as the content type.
6. Select the appropriate filters as per your search requirement. For example, if you
select Product Support Notices, the system displays only PSNs in the documents
list.
April 2013
59
PCN and PSN notifications
Note:
You can apply multiple filters to search for the required documents.
Signing up for PCNs and PSNs

About this task
Manually viewing PCNs and PSNs is helpful, but you can also sign up for receiving notifications
of new PCNs and PSNs. Signing up for notifications alerts you to specific issues you must be
aware of. These notifications also alert you when new product documentation, new product
patches, or new services packs are available. The Avaya E-Notifications process manages
this proactive notification system .
To sign up for notifications:
Procedure
1. Go to the Avaya Support Web Tips and Troubleshooting: eNotifications
Management page at https://support.avaya.com/ext/index?
page=content&id=PRCS100274#.
2. Set up e-notifications. For detailed information, see the How to set up your ENotifications procedure.
60

April 2013
Glossary
AFS
Authentication File System. AFS is an Avaya Web system that allows

you to create Authentication Files for secure Avaya Global Services
logins for supported non-Communication Manager Systems.
Application
A software solution development by Avaya that includes a guest

operating system.
Avaya Appliance
A physical server sold by Avaya running a VMware hypervisor that has

several virtual machines, each with its virtualized applications. The
servers can be staged with the operating system and application
software already installed. Some of the servers are sold as just the server
with DVD or software downloads.
Avaya Services
VM
A virtual machine that supports Avaya services applications. Currently

the services virtual machine is part of System Platform which uses a nonVMWare hypervisor.
Blade
A blade server is a stripped-down server computer with a modular design

optimized to minimize the use of physical space and energy. Although
many components are removed from blade servers to save space,
minimize power consumption and other considerations, the blade still
has all of the functional components to be considered a computer.
ESXi
A virtualization layer that runs directly on the server hardware. Also

known as a bare-metal hypervisor. Provides processor, memory,
storage, and networking resources on multiple virtual machines.
HA
High Availability. A VMware feature for supporting virtual application

failover by migrating the application from one ESXi host to another. Since
the entire host fails over, several applications or virtual machines can be
involved. The failover is a reboot recovery level which can take several
minutes.
Hypervisor
A hypervisor is also known as a Virtual Machine Manager (VMM). A

hypervisor is a hardware virtualization technique which runs multiple
operating systems on the same shared physical server.
MAC
Media Access Control address. A unique identifier assigned to network

interfaces for communication on the physical network segment.
OVA
Open Virtualization Appliance. An OVA contains the virtual machine

description, disk images, and a manifest zipped into a single file. The
April 2013
61
PLDS
OVA follows the Distributed Management Task Force (DMTF)

specification.
PLDS
Product Licensing and Download System. The Avaya PLDS provides

product licensing and electronic software download distribution.
Reservation
A reservation is the amount of physical RAM, CPU cycles, or memory

that are reserved for a virtual machine.
RFA
Remote Feature Activation. RFA is an Avaya Web system that you use
to create Avaya License Files. These files are used to activate software
including features, capacities, releases, and offer categories. RFA also
creates Authentication Files for secure Avaya Global Services logins for
Communication Manager Systems.
SAN
Storage Area Network. A SAN is a dedicated network that provides

access to consolidated data storage. SANs are primarily used to make
storage devices, such as disk arrays, accessible to servers so that the
devices appear as locally attached devices to the operating system.
Snapshot
Capture a virtual appliance configuration in time. Creating a snapshot

can affect service. Some Avaya virtual appliances have limitations and
others have specific instructions for creating snapshots.
Storage vMotion
A VMware feature that migrates virtual machine disk files from one data
storage location to another with limited impact to end users.
vCenter Server
An administrative interface from VMware for the entire virtual

infrastructure or data center, including VMs, ESXi hosts, deployment
profiles, distributed virtual networking, and hardware monitoring.
virtual appliance
A virtual appliance is a single software application bundled with an

operating system.
VM
Virtual Machine. Replica of a physical server from an operational

perspective. A VM is a software implementation of a machine (for
example, a computer) that executes programs similar to a physical
machine.
vMotion
A VMware feature that migrates a running virtual machine from one

physical server to another with minimal downtime or impact to end users.
vMotion cannot be used to move virtual machines from one data center
to another.
vSphere Client
vSphere Client is VMwares computer cloud virtualization operating

system.
62

April 2013
Index
A
downloading software .................................................29
Avaya applications ..................................................... 23

networking ............................................................23
Avaya Mentor videos ....................................................9
E
editing ......................................................................... 17
virtual machine resources .................................... 17
B
best practices ............................................................. 19
performance ......................................................... 19
BIOS ........................................................................... 19
BIOS for Dell servers ..................................................20
BIOS for HP servers ................................................... 21
bundled software specifications ................................. 18
C
capacity of SAL Gateway ........................................... 18
checklist ................................................................ 15, 33
deployment procedures ....................................... 33
planning procedures ............................................ 15
clones ......................................................................... 41
deployment .......................................................... 41
components ................................................................ 13
VMware ................................................................ 13
configure .....................................................................45
network parameters ............................................. 45
SAL Gateway parameters .................................... 45
configuring .................................................................. 22
timing ................................................................... 22
courses .........................................................................8
D
deploying copies .........................................................41
deploying OVA ...................................................... 34, 40
directly to ESXi .....................................................40
to vCenter ............................................................ 34
deployment ................................................................. 24
thick ......................................................................24
thin ....................................................................... 24
deployment guidelines ................................................13
deployment procedures .............................................. 33
checklist ............................................................... 33
document changes ....................................................... 7
document purpose ....................................................... 7
F
FAQ ............................................................................ 55
field descriptions .........................................................36
properties page .................................................... 36
G
guidelines ................................................................... 13
deployment .......................................................... 13
H
high availability ........................................................... 26
hyperthreading ........................................................... 27
I
Intel VT support .......................................................... 19
intended audience ........................................................ 7
N
network parameters ....................................................45
configure .............................................................. 45
networking Avaya applications ................................... 23
networking best practices ........................................... 23
O
overview .......................................................... 11, 33, 51
backup and restore .............................................. 51
OVA deployment .................................................. 33
P
PCN ............................................................................ 59
April 2013
63
PCN notification ..........................................................59

PCNs .......................................................................... 59
performance best practices ........................................ 19
planning procedures ................................................... 15
checklist ............................................................... 15
PLDS .......................................................................... 29
downloading software .......................................... 29
properties page .......................................................... 36
field descriptions .................................................. 36
PSN ............................................................................ 59
PSN notification .......................................................... 59
PSNs .......................................................................... 59
purpose of document ................................................... 7
upgrading ............................................................. 53
server hardware and resources ..................................15
signing up for PCNs and PSNs .................................. 60
snapshots ................................................................... 25
software requirements ................................................ 17
specifications .............................................................. 18
bundled software ..................................................18
starting virtual machine .............................................. 43
support ......................................................................... 9
contact ................................................................... 9
supported versions ..................................................... 17
VMware ................................................................ 17
T
R
reconfiguration ............................................................49
virtual machine ..................................................... 49
reconfiguring virtual machine ................................ 49, 50
at ESXi host ......................................................... 50
at vCenter ............................................................ 49
registering ............................................................. 29, 30
SAL Gateway ....................................................... 30
related documentation ..................................................8
related resources ......................................................... 9
Avaya Mentor videos ............................................. 9
requirements ......................................................... 16, 17
software ............................................................... 17
virtual machine resources .................................... 16
resource requirements ............................................... 16
resources ....................................................................15
server ................................................................... 15
restoring ..................................................................... 52
virtual machine ..................................................... 52
S
SAL Gateway ............................................................. 30
registering ............................................................ 30
SAL Gateway capacity ............................................... 18
SAL Gateway implementation .................................... 47
test alarming services .......................................... 47
test remote access service .................................. 47
validation .............................................................. 47
SAL Gateway parameters .......................................... 45
configure .............................................................. 45
SAL Gateway vAppliance ........................................... 53
64
test remote access service ......................................... 47

test the alarming service ............................................ 47
testing ......................................................................... 48
SAL Watchdog service .........................................48
thick deployment ........................................................ 24
thin deployment .......................................................... 24
time keeping ............................................................... 21
timekeeping ................................................................ 22
configuring ........................................................... 22
training ......................................................................... 8
U
upgrade operation ...................................................... 54
validating .............................................................. 54
upgrading ................................................................... 53
SAL Gateway vAppliance .................................... 53
V
validating .................................................................... 54
upgrade operation ................................................ 54
videos ........................................................................... 9
Avaya Mentor .........................................................9
virtual machine ......................................................43, 49
shutdown setting .................................................. 43
startup setting ...................................................... 43
reconfiguration ..................................................... 49
starting ................................................................. 43
virtual machine resource requirements ...................... 16
virtual machine resources .......................................... 17
editing .................................................................. 17
vMotion ....................................................................... 27
VMware software ........................................................17
supported ............................................................. 17
VMware Tools ............................................................ 21
VT support .................................................................. 19
April 2013

Avaya Secure Access Link Gateway Using VMware® in The Virtualized Environment Deployment Guide PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Avaya Secure Access Link Gateway Using VMware® in The Virtualized Environment Deployment Guide PDF

Transféré par

Droits d'auteur :

Formats disponibles

Avaya Secure Access Link Gateway

using VMware in the Virtualized

2013 Avaya Inc.

All Rights Reserved.

SAL Gateway in the Virtualized Environment Deployment Guide

Contact Avaya Support

Except where expressly stated otherwise, no use should be made of

See the Avaya Support website: http://support.avaya.com for product

SAL Gateway in the Virtualized Environment Deployment Guide

SAL Gateway in the Virtualized Environment Deployment Guide

SAL Gateway in the Virtualized Environment Deployment Guide

SAL Gateway in the Virtualized Environment Deployment Guide

Document changes since last issue

SAL Gateway in the Virtualized Environment Deployment Guide

Avaya Aura Virtualized

Implementation and administration

Describes the implementation

Avaya Aura Essentials

SAL Gateway in the Virtualized Environment Deployment Guide

Avaya Mentor videos

SAL Gateway in the Virtualized Environment Deployment Guide

SAL Gateway in the Virtualized Environment Deployment Guide

Chapter 2: Architecture overview

Avaya Aura Virtualized Environment overview

SAL Gateway in the Virtualized Environment Deployment Guide

server and host

Virtualized Environment applications

Patches and upgrades

SAL Gateway in the Virtualized Environment Deployment Guide

Performance and capacities

The physical machine running the ESXi Hypervisor

A platform that runs multiple operating systems on a host

The client application that is installed on a personal computer

vCenter Server provides centralized control and visibility at

SAL Gateway in the Virtualized Environment Deployment Guide

The following are deployment guidelines for the virtual machines:

SAL Gateway in the Virtualized Environment Deployment Guide

Chapter 3: Planning and configuration

Register for the Avaya Product

See Registering for PLDS on

Download the SAL Gateway OVA

To log on to the PLDS website, use

Ensure that you have all the

See Server hardware and

Ensure that you plan the staging

See SAL Gateway virtual machine

Server hardware and resources

SAL Gateway in the Virtualized Environment Deployment Guide

Planning and configuration

SAL Gateway virtual machine resource requirements

SAL Gateway in the Virtualized Environment Deployment Guide

VMware software requirements

Editing the virtual machine resources

VMware software requirements

SAL Gateway in the Virtualized Environment Deployment Guide

Planning and configuration

VMware vCenter Server

5.0.0, build 623373

VMware vSphere Client

5.0.0, build 623373

VMware ESXi Host

5.0.0, build 623860