With the adventure of Virtual Machines usage it is very common that CA Service Desk Manager (SDM) and other products involving it are installed on such environments.
Most specifically, VMWare has the VMotion solution which is largely used among its users.
This document explains how VMotion can affect CA Service Desk Manager.
We may consider the following SDM installation types being affected:
- SDM Conventional installation: Primary server only
- SDM Conventional installation: Primary server with Secondary server(s)
- SDM Advanced Availability (AA) Installation
CA Service Desk Manager r12.x / 14..x / 17.x
The main behavior observed when the usage of VMotion interferes in the SDM usage is that SDM dies unexpectedly.
What we usually see in the environment is:
- One or more Application Servers dies
- One or more Secondary Servers dies
- The Primary server dies
The SDM standard logs (stdlog.*) show a pure "slump died detected".
No other error or evidences appear in the logs.
In this scenario, the team managing the VMWare solution needs to be engaged to validate in the logs when the machine move was done.
When the VMotion affects SDM, what is seeing is that the machine move was done at the time the SDM services stopped running.
Why does this happen?
It all depends on how much time VMotion takes to perform the action. CA SDM is sensitive to network hiccups (which would be caused in this scenario).
If any movement takes more than 30 seconds, SDM understands there was a network hiccup or other network issue and slump dies, causing SDM to stop running.
To resolve this, the SDM machines must be removed from the VMotion configuration.
Additional explanations or causes on slump died messages are available also at Support.ca.com.