How to know the version of vIDM without GUI

Fwa · ‎04-25-2016

Hi expert,

How can we see the version of vIDM in vapp console without GUI? I'm glad if let me know about the directory, for example /opt/vmware/horizon/workspace/conf/.

Thanks.

Chakresh_IBM · ‎03-22-2021

Use below command.

/usr/local/horizon/update/updatemgr.hzn check
No Updates Available

Checking for updates...

Current version: 3.3.2.0
Update version available: none
No Updates Available

jrhaakenson · ‎02-07-2023

I am getting Current Version:

It is blank or null. My vIDM upgrade precheck is failing saying the current version is null. Where can I configure the current version for it to read correctly? My current version of vIDM is 3.3.6 and I'm trying to upgrade to 3.3.7

ogushia · ‎02-08-2023

Hi,
Running [/usr/local/horizon/update/updatemgr.hzn check] seems to read the version from /opt/vmware/var/lib/vami/update/data/manifest-installed.xml.
So first make sure the manifest-installed.xml exists.

If exists, run the following command to see the result
/opt/vmware/bin/vamicli version --appliance
If successful, you should see output like the following:
Version - 3.3.6.0 Build 19203469
Instructions - To update the appliance

If you get an error, please let me know what error is.

jrhaakenson · ‎02-08-2023

I do have a manifest-installed.xml file. It is located in /opt/vmware/var/lib/vami/update/data/info/manifest-installed.xml. I also have a manifest-installed.xml.00 file and manifest-installed.xml.01 file in this directory as well. They appear to all be identical and all show version 3.3.6 for my vIDM. Are these extra files creating the issue of being unable to read my appliance version?

When I run /opt/vmware/bin/vamicli version --appliance I receive the following output:

Traceback (most recent call last):

File "/opt/vmware/bin/vamicli", line 34, in <module>

import pywbem

File "/opt/vmware/lib/python/site-packages/pywbem/__init__.py", line 40, in <module>

from cim_types import *

ModuleNotFoundError: No module named 'cim_types'

I can't interpret this error because all the python packages are present in the proper locations for import to include cim_types.py. They are all located in the /opt/vmware/lib/python/site-packages/pywbem/ directory correctly. Thank you for your assistance.

ogushia · ‎02-09-2023

I think the extra files in the manifest folder are not problem.
I also checked my environment, and there are 3 files (original, 00, 01) as well.

I've recieved this output with the updatemgr.hzn check command and the update check failed. (Current version was blank)
Current version:
Update version available: internal
update is available

In my case, the cause was that vami-sfcb was stopped, so I was able to start vami-sfcb with the following command and successfully update from 3.3.6 to 3.3.7.
/etc/init.d/vami-sfcb restart

Try the command above.
(Your error message is different from mine, so it may not be helpful...)

jrhaakenson · ‎02-09-2023

When I run /etc/init.d/vami-sfcb restart I receive "Job for vami-sfcb.service failed because a timeout was exceeded". I then attempt to start the vami-sfcb service using systemctl start vami-sfcb.service and also receive the same timeout message. Below is a screenshot of the vami-sfcb service status. So the question now becomes why won't my vami-sfcb service start? Thank you for continually following up on this.

ogushia · ‎02-10-2023

vami-sfcb.log is located in the following path.
/opt/vmware/var/log/vami/vami-sfcb.log

The above log may contain information related to the error.

jrhaakenson · ‎02-10-2023

The log under /opt/vmware/var/log/vami/vami-sfcb.log does not show any current status from my recent attempts to start the vami-sfcb service. The last log entry is from June 2022 when the service was last working. Any other ideas for getting this service to start? Thank you.

ogushia · ‎02-12-2023

From your screen shot it seem that start operation timed out, so a possible solution is to increase timeout value in case vami-sfcb service would actually need more time than defined time out value to complete the startup.
In my test instance, successfully changed setting with following step.
1. Run following command.
systemctl edit --ful vami-sfcb.service
2. Chanege following value longer enough.
TimeoutSec=

However, I'm not sure if changing the timeout value of the vami-sfcb service is supported. Please contact VMware Support to see if it is supported.

jrhaakenson · ‎02-13-2023

Once again thank you for the reply. By increasing the timeout to 30 minutes using the process you provided, the vami-sfcb service successfully started. I'm not sure why it takes so long to startup, but nonetheless it started. However, even with this service running now, my vIDM is still not returning the current version using the /opt/vmware/bin/vamicli version --appliance command. I still get the error mentioned above:

Traceback (most recent call last):

File "/opt/vmware/bin/vamicli", line 34, in <module>

import pywbem

File "/opt/vmware/lib/python/site-packages/pywbem/__init__.py", line 40, in <module>

from cim_types import *

ModuleNotFoundError: No module named 'cim_types'

I even rebooted the appliance and verified the vami-sfcb service was still running after restart to ensure it's dependent services were also running. Because it is failing to return the current version, I cannot complete the Pre-Check during the 3.3.7.0 upgrade via vRLCM and I cannot upgrade. Thank you for your time and assistance.

jrhaakenson · ‎02-14-2023

I've solved my issue of the current version of vIDM not returning properly using the /opt/vmware/bin/vamicli version --appliance command. The script found in /opt/vmware/bin/vamicli utilized the shebang #!/usr/bin/env python at the top of the script. I compared this to a working vRA appliance which utilized the shebang #!/usr/bin/env python2. I modified my vIDM script to utilize the shebang #!/usr/bin/env python2 and my version was returned successfully when running the /opt/vmware/bin/vamicli version --appliance command. My only guess is that python got updated on my vIDM where it required the use of the python2 command but the vamicli script was never updated and specified the use of standard python command.

The Pre-Upgrade check on vRLCM successfully passed all checks. The subsequent 3.3.7.0 install once again failed, but it seems to have failed because in a previous troubleshooting step I had modified the vami-sfcb service timeout to be 30 minutes. Upon reboot the vIDM appliance would take roughly 18-19 minutes to start because this service takes so long to startup. During the 3.3.7.0 upgrade the appliance reboots and subsequently the vRLCM upgrader cannot connect back to the vIDM appliance because it remains in the process of starting up for too long due to the vami-sfcb service starting. As a result the upgrader fails out. I reverted the vami-sfcb service timeout back to 5 minutes (using the systemctl edit --ful vami-sfcb.service) command and still had the same issue. I then configured the vami-sfcb service timeout to be 1 minute just to ensure the vIDM appliance would restart quicker during the upgrade. Still the upgrader fails. The failure occurs in Stage 1 during the Upgrade VMware Identity Manager Offline step. It only reports Error Code: LCMUPGRADEVIDM71205 vIDM upgrade failed. Revert to snapshot and try again. Additional info shows at com.vmware.vrealize.lcm.vidm.core.task.VidmRebootTask.execute(VidmRebootTask.java:218).

Furthermore, the only logs I can see that may apply come from the vami.log show:
14/02/2023 19:06:46 [INFO] Checking available updates. jobid=1
14/02/2023 19:06:46 [INFO] Downloading latest manifest. jobId=1, url=Caution-http://localhost:8008//, username=, password=
14/02/2023 19:06:47 [INFO] Using download cache
14/02/2023 19:06:47 [INFO] Downloading file. Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:06:47 [ERROR] CURL error: Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:06:47 [ERROR] Sleep 10 seconds and retry.
14/02/2023 19:06:57 [ERROR] CURL error: Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:06:57 [ERROR] Sleep 10 seconds and retry.
14/02/2023 19:07:07 [ERROR] CURL error: Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:07:07 [ERROR] Sleep 10 seconds and retry.
14/02/2023 19:07:17 [ERROR] CURL error: Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:07:17 [ERROR] Error downloading manifest: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:07:17 [ERROR] Error: Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:07:17 [ERROR] Setting job error information. jobid=1, errorCode=20, errorString=Error downloading manifest. Please contact your vendor. Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml
14/02/2023 19:07:17 [ERROR] Job <1> failed. Error code:20Error message: Error downloading manifest. Please contact your vendor. Failed to connect to localhost port 8008: Connection refused Caution-URL: Caution-http://localhost:8008///manifest/manifest-latest.xml

I don't know what is trying to connect on port 8008, but I verified port 8008 is open between our vRLCM and vIDM for the upgrade. It looks like it is trying to connect to itself on port 8008 so there shouldn't even be a firewall concern. If someone could explain these port 8008 manifest-latest.xml errors that would be appreciated.

ogushia · ‎02-15-2023

Looking at the contents of the offline upgrade script (/usr/local/horizon/update/updateoffline.hzn), it seems that the Python http server is running on port 8008.
-----------
# Start the service
python -m $PYTHON_HTTP_SERVER $PORT 2>/dev/null &
-----------
($PORT is defined as 8008 as a variable at the biginning.)

How about trying an offline upgrade locally as an alternative way?
https://docs.vmware.com/en/VMware-Workspace-ONE-Access/3.3/vidm-336-upgrade-guide/GUID-8744E48D-59D0...
If you run it locally, even if it fails, you may be able to see which process is failing.

jrhaakenson · ‎02-15-2023

I will resort to trying a manual upgrade using the method you provided if I cannot solve the vRLCM upgrade discussed here. But I'd like to have a working vRLCM upgrade deployment. I think we're getting close. I don't think port 8008 is a concern anymore. The log file found at /opt/vmware/horizon/vrslcm_vidm_upgrade.log shows the following after the failed upgrade via vRLCM:

It looks like the local http server running on port 8008 is validated. It then moves to "Installing custom provider-runtime" and errors out with:

tput: No value for $TERM and no -T specified

basename: extra operand >

Unable to query remote site for update rpm.

I can more or less follow the multiple scripts found in /usr/local/horizon/update to the point of "Installing custom provider-runtime" which is found on line 284 of the configureupdate.hzn script, but then I can't find the script where the tput: No value for $TERM and no -T specified, basename: extra operand >, and Unable to query remote site for update rpm are output from. Does anyone know why these errors would be output while running a vIDM 3.3.7.0 upgrade via vRLCM? Could there be something wrong with the vRLCM upgrade package provided by VMware?

All

How to know the version of vIDM without GUI