Known Issues and Recommendations
Primary Server Disconnection
When the primary server goes down due to power or network disconnection, the script to disable the Virtual IP fails because the primary box is unavailable. When the primary server is started, there might be an IP conflict since Virtual IP is not disabled in the primary server. Genesys recommends you add the disable Virtual IP script as a startup script in the machine, so the Virtual IP is disabled by default when a system boots up and then according to the event (4563) from Genesys application in our case SIP Server the reaction scripts should be triggered. See Creating Virtual IP control scripts (Windows, Linux). Note: There is no resolution for an IP conflict caused by unplugging an IP cable. This is a known limitation.
VIP Not Enabled Issue
The VIP not enabled issue can only occur in Windows. In this scenario, the backup server is down when the primary server starts. If the VIP down service is started after the Primary SIP server is started and the alarm condition from the server has already enabled the VIP in the machine, the VIP is disabled and VM SIP server goes into a service unavailable state.
Preventing The VIP Not Enabled Issue
- Add the following script as a startup script in Windows.
- Copy the MLCMD utility files (mlcmd.exe and mlcmd.exe.manifest files) from the SCS host onto the host running the VM components.
Subnet for GSVM Servers
You must connect both the primary and backup GSVM Servers within the same subnet to prevent problems refreshing the ARP cache of the gateway after the switchover of the Virtual IP. You can use the ARPING command in the Virtual IP takeover scripts to resolve this issue. ARPING is a tool included in Linux. A third-party version of ARPING can also be downloaded and installed in Windows.