1 Reply Latest reply on Jan 9, 2013 3:36 PM by dmease729

    Known VM is not being assigned 'VM' tag in ePO / Unable to confirm registered vCentre communications at logging level




      McAfee MOVE Scheduler 2.5 Product Guide page 28, I cannot see a new VM host, that I know to be running on a hypervisor within the registered vCentre host.  I can see other hosts, however, and I have waited a couple of days. 


      From p12 of above document: "The Scheduler regularly queries registered hypervisors and applies the VM tag to any virtual machines managed by ePolicy Orchestrator".  I cannot seem to locate any troubleshooting information that would show how often the registered hypervisors are being queried, and also if there are any relevant logs which would prove that they are being queried (and also show if there had been any issues related to this process).  I have looked through all logs on ePO and cannot seem to find anything relevant.


      I would test the connection again in 'registered servers' however you need to account password to do this, which I do not have access to.  This connection has been working in the past, however, as there are existing hosts that have automatically assigned the VM tag.


      Note that I have found ePO logs relating to issues detected, however nothing of any relevance was found to my issue and I am assuming/hoping that some form of logging exists so I can have better visibility of what is happening.




      Message was edited by: dmease729 on 02/01/13 10:08:27 CST
        • 1. Re: Known VM is not being assigned 'VM' tag in ePO / Unable to confirm registered vCentre communications at logging level

          Not yet got to the bottom of why the VM tag is not being assigned to some VMs when they are running on registered hypervisors, and I need to delve into this a little more, however the following may help others in similar situations, or in the situation that they need to debug what is happening with the communications between ePO and the registered hypervisors/vcenters etc.


          Firstly, I had missed the MOVE scheduler category in the ePO server settings, so that answered my question as to the frequency of polls!


          For the debugging, McAfee support advised that the log file I needed to look at was Orion.log, and in order to enable debugging, to follow steps in:

          KB52369 How to enable debug logging and log size for Orion.log in ePO 4.x


          I followed the above, and worked my way through the large number of debugging events, and confirmed my understanding of what was going on (below) with the support technician:



          After reading through the logs to find the best way to read them, in the logs I have essentially ended up looked for the following lines (INFO):


          INFO  [mfs:pool-1-thread-XXX] command.SyncVICommand  - Sync Virtual Machines command invoked for moveResourceId = X
          INFO  [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - VMware getVINodeHirearchy called for url: https://<VCENTER>/sdk


          I am essentially looking for the VCENTER in question, and then looking at the thread reference.  From this point on, I grep for that thread reference in the full log, and I can see (INFO/DEBUG) lines similar to the below:


          DEBUG [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - Successfully tested connection with https://<VCENTER>/sdk
          INFO  [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - VMware getVINodeHirearchy called for url: https://<VCENTER>/sdk

          DEBUG [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - Found Datacenter. Name: <DATACENTER>
          DEBUG [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - Found cluster. Name: <CLUSTER>
          DEBUG [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - Found Esx Server. Name: <ESX SERVER>
          DEBUG [mfs:pool-1-thread-XXX] services.VMwareServiceImpl  - found VM hostname: <HOSTNAME> (VM name = <HOSTNAME>, uuid=<UUID>), powered state = POWERED_ON, guest state = running, VM tools status = <TOOLS STATUS>, overallStatus = green


          From here, this looks to enumerate all of the VM hostnames running on each Esx Server (even if found before), then it moves on to the next Cluster, then the next DataCenter until all VM hosts have been found.




          So on the next deployment to a virtual machine, if the VM tag is not automatically assigned, I will once again enable debugging, confirm which hypervisor the VM is currently running on, and then check Orion.log and take it from there.


          IMPORTANT:  As with any debugging, please ensure that you disable debugging when it is no longer required, as the Orion.log activity increases substantially, and the files grow very large very fast (although total size can be controlled - further details in the KB article mentioned above)


          I hope this helps somebody out there who may be seeing similar things.  I would like to take this opportunity to say that the KB article was very helpful, and McAfee support even more so in this case - definitely a job well done.


          For reference, ePO server in this case was 4.6.1, and agent was 4.6p2