I'm working at a MSP and I have a question about robots:
What is better? Have a vm guest (template) with an uim robot installed or I have a procedure to install a robot after vm working and delivered? Is it possible to have a robot intalled and with "generic" options configured and then, after vm working, setting up those "generic options" to specific options?
Is it possible to "clone" a vm with robot?
Hey Nelson, check out this link - http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec000004866.aspx
That article describes the best practices to cloning VM's with robots already installed.
Hope that helps!
So the robot must be stopped always in the master image server ?
Issac08 Yes, the robot needs to be stopped on the master server prior to cloning the image and the files detailed in the techdoc needs to be cleared before cloning . This is needed for it to regenerating new device ID for the clone once the nimsoft service is started back.
If not we would end up with duplicate device ID and one of the side effects would be the metrics collected by the new server being shown up under the master server in USM view because of the device ID match and not being reset .
Thanks Phani.Devulapalli ..Is there any way to find the duplicate robot ID in the current robots which are running ?
I am not sure if there is an easy way to identify the duplicate dev id's on robots. We had this issue recently in our environment when the metrics from two different servers started showing up under the same device in USM . Based on the symptoms and some inputs from customer that these were cloned machines we had to drill down to individual robots using the callbacks in the controller probe to identify whats wrong with these servers and thats when we noticed the duplicate device ID's and had to follow the procedure to cleanup and reset the niscache
I was going through the callbacks of discovery_server and controller to see if we can get just the dev_id of the robots using pu. Unfortunately, I was not getting the desired results.
You could try this in your test environment:
Set discovery_server > raw configure > correlation > robot_device_id to false
Deactivate and then activate discovery_server
Disabling correlation on dev_id should let d_s to populate the robots in question to CM* tables
Reading niscache of all the robots by d_s typically would take 60 to 90 minutes in large environment
Run the below query -
SELECT dev_id, robot, COUNT(dev_id) "Duplicate count"FROM cm_nimbus_robotGROUP BY dev_id, robotHAVING ( COUNT(dev_id) > 1);
This should get you dev_id duplicates. Once you perform the steps as per TechDoc on the problem robots, enable correlation on robot_device_id and then deactivate and then activate d_s. Eventually d_s would update dev_id field with the correct dev_id in cm_nimbus_robot table.
This is not really pretty but should help you finding the duplicates. Let me know if you have any questions, please.
casph02 It will cause any impact if some pre-defined probes are added in master image server already ?
I don't think you'll run into much trouble with other probes installed.
You'll likely have to 'validate security' for these probes (right click in IM --> security --> validate).
As long as you clear the niscache before creating the VM clones, I think you'll be in good shape.