Usage meter 4.5, SRM collection fails

SRM collector logs are written in vccol_main.log

/opt/vmware/cloudusagemetering/var/logs/vccol_main.log

2021-12-22 17:30:24.159 ERROR --- [vCenter collector thread] c.v.um.vccollector.srm.SRMCollector      : Unknown Failure  HTTP transport error: org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46) :: https://srm02.ntitta.lab:443/drserver/vcdr/extapi/sdk
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
        at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:102)
        at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:193)
        at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:115)
        at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:109)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1106)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1020)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:989)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:847)
        at com.sun.xml.ws.client.Stub.process(Stub.java:433)
        at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
        at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
        at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:62)
        at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:131)
        at com.sun.proxy.$Proxy41.srmLoginLocale(Unknown Source)
        at com.vmware.um.vccollector.srm.api.SrmApiClient.openSrmPort(SrmApiClient.java:116)
        at com.vmware.um.vccollector.srm.SRMCollector.getSrmLicenses(SRMCollector.java:312)
        at com.vmware.um.vccollector.srm.SRMCollector.collect(SRMCollector.java:119)
        at com.vmware.um.vccollector.srm.SRMCollectionStage.collectUsage(SRMCollectionStage.java:45)
        at com.vmware.um.vccollector.VCCollector.collectStages(VCCollector.java:276)
        at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:202)
        at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:32)
        at com.vmware.um.collector.CollectionHelper.collectFromServer(CollectionHelper.java:1014)
        at com.vmware.um.collector.CollectionHelper.collectFromServersWithReporting(CollectionHelper.java:1170)
        at com.vmware.um.collector.CollectionHelper.collectWithReporting(CollectionHelper.java:990)
        at com.vmware.um.collector.CollectionHelper.lambda$start$9(CollectionHelper.java:1518)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(ProvSSLSocketDirect.java:135)
        at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(ProvTlsClient.java:360)
        at org.bouncycastle.tls.TlsUtils.processServerCertificate(TlsUtils.java:4813)
        at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(TlsClientProtocol.java:784)
        at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:670)
        at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:695)
        at org.bouncycastle.tls.TlsProtocol.processRecord(TlsProtocol.java:584)
        at org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:245)
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:843)
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:417)
        at org.bouncycastle.tls.TlsClientProtocol.connect(TlsClientProtocol.java:88)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:445)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(ProvSSLSocketDirect.java:426)
        at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(Unknown Source)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
        at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:89)
        ... 30 common frames omitted
Caused by: java.security.cert.CertificateException: There is no pinned certificate for this server and port
        at com.vmware.um.common.certificates.PinnedCertificateTrustManager.checkServerTrusted(PinnedCertificateTrustManager.java:81)
        at org.bouncycastle.jsse.provider.ImportX509TrustManager_7.checkServerTrusted(ImportX509TrustManager_7.java:56)
        at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(ProvSSLSocketDirect.java:131)
        ... 48 common frames omitted

Workaround:

Re-register SRM to vCenter using an IP instead of the FQDN

Navigate to https://SRM:5480, log in as admin and re-register. Change the local host field to the IP address from the dropdown

saltconfig 8.6.1 + vRA 8.6.1 Deploying VM’s with salsify driver fails and time’s out

error:

Resource [/resources/compute/e730e5b7-bd12-4803-809e-2d9655c0f448]:: Salt configuration CREATE with job id [5bae15fe-6903-42cb-b915-193b6d5e9d97] failed. Error:: : Minion deployment successful. JID - 20211202152858391410

investigation:

On salt-config > jobs , look for the deploy.minion task. This was a success in my case.

Re-ran the deployment, once the machine is provisioned and customization is successful (has IP when viewing VM from the vCenter view), open the console and I took a look at /etc/salt/minion

Here, the line: master: photon-machine is clearly wrong.

looking at the grains on the salt-config UI, we see the same grains:

Resolution:
restart salt-master and salt-minion service.
and then take a look at the grains on the CLI

salt saltmaster grains.get fqdn

Now, refresh grains

salt saltmaster saltutil.refresh_grains

and then take a look at the UI (in about a min time)

what that sorted, deploying new VM’s via VRA with the saltify driver now works!!