Manually deploying a Conferencing Node on an ESXi host
The manual deployment process generates an .ova file that must then be manually deployed from within VMware on to an ESXi host. Note that:
- This file is specific to the Conferencing Node being deployed. It cannot be used to deploy multiple Conferencing Nodes.
- The file is single-use. It cannot be used to re-deploy the same Conferencing Node at a later date. To re-deploy the Conferencing Node, you must first delete it from the Pexip Infinity Management Node and from VMware, and then deploy a new Conferencing Node with the same configuration as the deleted node.
- Before you start, ensure that you are currently using the same machine that you will subsequently want to use to upload the generated file on to your host server.
To manually deploy a new Conferencing Node on to a VMware ESXi host:
- Go to and select .
- From the Deployment type field, select either Manual (ESXi 6.0), Manual (ESXi 5.x) or Manual (ESXi 4.1) as appropriate.
- Select .
You are now asked to provide information regarding the CPUs and memory of the Conferencing Node, by completing the following fields:
Option Description Number of virtual CPUs to assign Enter the number of virtual CPUs to assign to the Conferencing Node. We recommend no more than one virtual CPU per physical core, unless you are making use of CPUs that support hyperthreading; see Achieving additional performance with VMware NUMA affinity and hyperthreading for more details. System memory (in megabytes) to assign
Enter the amount of RAM (in megabytes) to assign to the Conferencing Node. The number entered must be a multiple of 4.
We recommend 1024 MB (1 GB) RAM for each virtual CPU.
- Select .
You are now asked to provide the network configuration to be applied to the Conferencing Node, by completing the following fields:
Option Description Name Enter the name that will be used to refer to this Conferencing Node in the Pexip Infinity Administrator interface. Description An optional field where you can provide more information about the Conferencing Node. Hostname
Enter the hostname and domain to be assigned to this Conferencing Node. Each Conferencing Node and Management Node must have a unique hostname.
The Hostname and Domain together make up the Conferencing Node's DNS name or FQDN. We recommend you assign valid DNS names to all your Conferencing Nodes. For more information, see Assigning hostnames and FQDNs.
IPv4 address Enter the IP address to be assigned to this Conferencing Node when it is created. Network mask Enter the IP network mask to be assigned to this Conferencing Node. Gateway IPv4 address Enter the IP address of the default gateway to be assigned to this Conferencing Node. Secondary interface IPv4 address The optional secondary interface IPv4 address for this Conferencing Node. If configured, this interface is used for signaling and media communications to clients, and the primary interface is used for communication with the Management Node and other Conferencing Nodes. For more information, see Conferencing Nodes with dual network interfaces (NICs). Secondary interface network mask The optional secondary interface network mask for this Conferencing Node. System location
Select the physical location of this Conferencing Node.
If the system location does not already exist, you can create a new one here by clicking to the right of the field. This will open up a new window showing the About system locations.page. For further information see
SIP TLS FQDN A unique identity for this Conferencing Node, used in signaling SIP TLS Contact addresses. For more information, see SIP TLS FQDN. TLS certificate The TLS certificate to use on this node. This must be a certificate that contains the above SIP TLS FQDN. Each certificate is shown in the format <subject name> (<issuer>). IPv6 address The IPv6 address for this Conferencing Node. Each Conferencing Node must have a unique IPv6 address. Gateway IPv6 address The IPv6 address of the default gateway. IPv4 static NAT address
The public IPv4 address used by this Conferencing Node when it is located behind a NAT device. Note that if you are using NAT, you must also configure your NAT device to route the Conferencing Node's IPv4 static NAT address to its IPv4 address.
For more information, see Configuring Pexip Infinity nodes to work behind a static NAT device.
Static routes From the list of Available Static routes, select the routes to assign to the node, and then use the right arrow to move the selected routes into the Chosen Static routes list. For more information, see Managing static routes. Enable distributed database
This should usually be enabled (checked) for all Conferencing Nodes that are expected to be "always on", and disabled (unchecked) for nodes that are expected to only be powered on some of the time (e.g. cloud bursting nodes that are likely to only be operational during peak times).
Enter the password to be used when logging in to this Conferencing Node's Linux operating system over SSH. The username will always be admin.
Logging in to the operating system is required when changing passwords or for diagnostic purposes only, and should generally be done under the guidance of your Pexip authorized support representative. In particular, do not change any configuration using SSH — all changes should be made using the Pexip Infinity Administrator interface.
You will be taken to thepage.
A file with the name pexip-<hostname>.<domain>.ova will be downloaded.
When you wish to deploy the Conferencing Node VM, use a vSphere client to log in to vCenter Server (or the ESXi host directly, if it is not managed in vCenter Server) and select . Follow the on-screen prompts to deploy the .ova file.
After deploying a new Conferencing Node, it takes approximately 5 minutes before the node is available for conference hosting and for its status to be updated on the Management Node. (Until it is available, the Management Node will report the status of the Conferencing Node as having a last contacted and last updated date of "Never".)
After deploying a new Conferencing Node from VMware, you must enable automatic startup of that virtual machine (VM). In VMware, automatic startup is disabled by default for every new VM — which means that if the host server is powered down for any reason, when it restarts the VM will not restart and must be started manually.
You can only enable automatic startup after the Conferencing Node has been deployed.
Using the web client
To enable automatic startup using the vSphere web client:
- Log in to the VM manager (vCenter Server).
- From the left-hand panel, select and go to the host server on which the node's VM is installed.
- Select the tab.
- From the pane on the left-hand side, select VM Startup/Shutdown.
- At the top right of the page, select .
- Select the relevant node's VM and use the up arrow to move it to the Automatic Startup section.
- Select .
Using the desktop client
To enable automatic startup using the vSphere desktop client:
- Log in to the VM manager (vCenter Server or the ESXi host).
- From the left-hand panel, select the host server on which the node's VM is installed.
- Select the Configuration tab.
- From the Software pane on the left-hand side, select Virtual Machine Startup/Shutdown.
- At the top right of the page, select .
- Select the relevant VM and use the Automatic Startup section. button to move it to the
- Select .
We strongly recommend that you disable EVC (Enhanced vMotion Compatibility) for any ESXi clusters hosting Conferencing Nodes that include a mix of old and new CPUs. If EVC is enabled on such clusters, the Pexip Infinity platform will run more slowly because the Conferencing Nodes will assume they are running on older hardware.
For more information, see Enhanced vMotion Compatibility (EVC).
To disable EVC:
- Log in to vCenter Server using either the vSphere desktop or web client.
- Display the cluster in the inventory.
- Right-click the cluster and select Edit Settings.
In the left panel, select VMware EVC.
The dialog box displays the current EVC settings.
- Select Change EVC Settings.
- Select Disable EVC.