Highlighted
Acclaimed Contributor.
Acclaimed Contributor.
650 views

VMware discovery - powered off VM - conceptual question

Jump to solution

Hi all

i need to understand the concept of discovery in VMware regarding powered off VMs. There is a parameter "reportPoweredOffVMs" and it is explained briefly, and at the first glance it is understandable: wheather or not to "report" powered off VMs.

But what does this actually means? Lets assume the parameter is set to false (we do not want powered off VMs), and we connect to vCenter via VIM. Lets say there are 20 VMs in the VMware env, 10 are alive and 10 are powered off. The VMware jobs run once a day (daily).

1. on first initial connection, what happens? We only get 10 live VMs? We end up with 10 Node CI (assuming we do have additional OS accounts set up for discovery)? We do not see the powered off ones?

2. after some time, one of the alive VMs is powered off for some time (i.e. 10 days). The VMware jobs should see this and what happens then? What happens to the CI of the VM that was alive yesterday but it is now powered off?

3. what happens when the VM is powered back up after 10 days? And what happens if it remains powered down longer than the "age out" period?

To sum up, what is the true and practical effect of the parameter "reportPoweredOffVMs"? In what situation this parameter kicks in and in what way?

Any useful practical explanation is welcome!

Thanks

Marko

 

Labels (1)
Tags (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Hello Marko,

 

I was waiting for such a question for some time.

The vCenter Topology job has a discovery mechanism by connecting to the vCenter SDK (that's why we need the vim25.jar file) and retrieves from there whatever the vCenter SDK knows about its topology. If the VMware SDK contains wrong data then we will report wrong data. If it contains more details then we will report a rich topology which is good and desired.

The problem is that the VMware SDK relies on the VMware agents (the VMware Tools actually) in order to know details about the VMs from its topology/infrastructure. If a VM is running then the VMware tools/agent is also running and reporting to the VMware SDK a lot of details. If the VM is powered off then the agent isn't running and a lot of useful details aren't reported to the VMware SDK. We do have a few details on that VM like allocated resources but we don't know the MAC of an interface or the assigned IP (if any) to a particular interface. This details are available only when the VM is running and the VMware Tools report back to the VMware SDK and they are details very relevant to the identification process.

So in essence we have this parameter to avoid reporting weak nodes with few details about the interfaces and IPs amongst other details. Such powered off VMs aren't always important: they don't  resources, they don't consume power, etc...
Such powered VMs can cause problems in the identification process and they outside of the billing scope most of the times.

Still, some UCMDB users would still like to report the powered off VMs hence they can do this but with the possible consequences.

Another use case is that also the VM templates are a form of powered off VMs and they aren't needed. It's useless to report the VM templates as nodes in UCMDB.

1. only the 10 alive VMs will reported, the remaining 10 powered off VMs won't reported, we only have a log trace of them in the CommLog. 

2. the VM which was previously running and now it's powered off won't be reported from discovery. In the CommLog you will see 9 running VMs (which will be reported) and 11 powered off VMs (which won't be reported). The powered off VM will still be in UCMDB for another 40 days until they will be aged out.

3. after 10 days that UCMDB node will be updated. If it remains powered off for more than 40 days than it will be delete from UCMDB. You can use the vMotion job which is an event based discovery job and if that VM has an update, delete, create event then it will be updated in UCMDB.

 

Hope this helps.

 

Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success

View solution in original post

8 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Hello Marko,

 

I was waiting for such a question for some time.

The vCenter Topology job has a discovery mechanism by connecting to the vCenter SDK (that's why we need the vim25.jar file) and retrieves from there whatever the vCenter SDK knows about its topology. If the VMware SDK contains wrong data then we will report wrong data. If it contains more details then we will report a rich topology which is good and desired.

The problem is that the VMware SDK relies on the VMware agents (the VMware Tools actually) in order to know details about the VMs from its topology/infrastructure. If a VM is running then the VMware tools/agent is also running and reporting to the VMware SDK a lot of details. If the VM is powered off then the agent isn't running and a lot of useful details aren't reported to the VMware SDK. We do have a few details on that VM like allocated resources but we don't know the MAC of an interface or the assigned IP (if any) to a particular interface. This details are available only when the VM is running and the VMware Tools report back to the VMware SDK and they are details very relevant to the identification process.

So in essence we have this parameter to avoid reporting weak nodes with few details about the interfaces and IPs amongst other details. Such powered off VMs aren't always important: they don't  resources, they don't consume power, etc...
Such powered VMs can cause problems in the identification process and they outside of the billing scope most of the times.

Still, some UCMDB users would still like to report the powered off VMs hence they can do this but with the possible consequences.

Another use case is that also the VM templates are a form of powered off VMs and they aren't needed. It's useless to report the VM templates as nodes in UCMDB.

1. only the 10 alive VMs will reported, the remaining 10 powered off VMs won't reported, we only have a log trace of them in the CommLog. 

2. the VM which was previously running and now it's powered off won't be reported from discovery. In the CommLog you will see 9 running VMs (which will be reported) and 11 powered off VMs (which won't be reported). The powered off VM will still be in UCMDB for another 40 days until they will be aged out.

3. after 10 days that UCMDB node will be updated. If it remains powered off for more than 40 days than it will be delete from UCMDB. You can use the vMotion job which is an event based discovery job and if that VM has an update, delete, create event then it will be updated in UCMDB.

 

Hope this helps.

 

Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success

View solution in original post

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Bogdan

thanks for your answer, it explains a lot what happens "bellow the surface".

We have a customer complaining that some of their VMs were shut down recently and not going to be used anymore and since their parameter is set to false (no powered VMs) they expected the CIs to go away. I explained that they should go away after the ageout period, but the customer suspects that the VMware jobs are still "touching" the CIs (the VMs that are now turned off) and so that those CIs will not age out and go away. I believe the customer said there were some VMs turned off more than 40 days ago, but the CIs are still there. They mentioned this parameter and asked shouldn't this parameter prevent "touching" the Cis for dead VMs. So my doubt was also in this direction and i wanted to make sure i understand the process.    

Is it possible that Vmware connection / topology job are still "touching" the CIs representing turned off VMs (thus preventing them to become candidate for deletion) and if yes, is that okay and what is the logic behind that? How does this parameter come to play (if it does)?

Marko

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

The powered off VMs will apear as host_node CIs with an attached Interface CI so this nodes will be very difficult to reconcile.

In one of my lab environments I have the following. Do you see the difference?

For your particular scenario I think that you need to see in History who is touching those nodes and clear the result cache for the vCenter job. Also, youmay want to play a little bit with the automatic deletion or candidate for deletion mechanisms. Due to the size of CIs stored for the vcenter job maybe you are experiencing some probe cache perfomance degradation.

 

Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Bogdan

 

thanks for the guidance. In my lab we do not yet have a VMware discovery configured (we have a very small lab environment) but we do have an opportunity so i guess i will have to activate vmware discovery in our lab and set up some scenarios for testing and see how it goes.

On the other hand, it will be hard for me to do any comprehensive tests at the customer site as i do not / can not control their VMs so i can't set up a sound test scenario (discover a target VM, shut it down, fire discovery again, examine the logs, wait for 20 days, wait for 40 days, etc...)

But now i do understand what we "should" expect and what is the effect of the "reportPoweredOffVMs" and that we should look for VMs in the host_node (Computer) class once those are shut down, etc...

thank you

regards, Marko

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert
I don't have control over my vCenter lab environment but VMs get powered off quite frequent in a large vCenter so for sure you will catch one such VM. You just need a TQL to filter the VMs which get powered off.
Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

"...for sure you will catch one such VM. You just need a TQL to filter the VMs which get powered off." You mentioned earlier this is visible in the logs (which VMs were seen as powered off). Which CI attribute (i could use in a TQL) will tell me the VM is switched off? I have looked in the Node Ci type, and didn't find any such VM-specific attribute? Perhaps i missed it... Which is it?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert
In the remoteProcess.log we have only the count. The scripts can be modified to print debug messages with the powered off hostnames.
The TQL should include the VMs discovered by that job with a time attribute.
Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Btw, if you want to see the powered off VM in the Communitation log (if enabled from the adapter), go to the script _VMware_vim_base.py and on line 64 change the value from 0 to 1 for the variable _LOG_VERBOSE_FILTERING

 

_LOG_VERBOSE_FILTERING = 1

amongst others, this will print in the CommLog the VMs which are powered off

if not vm._hostKey:
_countNoHostKey += 1
if _LOG_VERBOSE_FILTERING:
logger.debug(" ......... VM '%s': cannot find host key, VM is skipped" % vm.name)
continue

 

 

Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.