Has anyone successfully done this? We have an issue whereby the manifest file upload (to SDDC Manager) using the latest lcm-bundle-transfer-util fails (SDDC Manager FQDN invalid). However we know the FQDN is correct and the tool even confirms this by asking you to accept the certificate fingerprint (which matches the cert used for SDDC Manager). It looks like the last section of the code, where Java is invoked, has changed significantly and as a result might not be correctly referencing the temp cacerts keystore that is updated by the tool itself (so is referencing another cacerts somewhere that doesn't have an alias in it for the SDDC Manager FQDN, hence the error).

Previous version of lcm-bundle-transfer-util invokes Java via:

exec "$JAVACMD" $JAVA_OPTS -Dspring.profiles.env=prod -Djavax.net.ssl.trustStore=$TMP_TRUST_STORE_DIR/cacerts \

...you can clearly see it's referencing the temp version of cacerts.

However the latest version of lcm-bundle-transfer-util (v2023.12-22910458) uses this command:

exec "$JAVACMD" $JAVA_OPTS -XX:+IgnoreUnrecognizedVMOptions -XX:+UseParallelGC --illegal-access=warn --add-opens=java.base/java.lang.module=ALL-UNNAMED --add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED --add-opens=java.base/jdk.internal.module=ALL-UNNAMED -Djavax.xml.ws.spi.Provider=com.sun.xml.ws.spi.ProviderImpl -Dspring.profiles.env=prod \

...which doesn't seem to reference the temp cacerts (which is in /opt/vmware/vcf/lcm/lcm-tools/btuJre/lin64/lib/security/cacerts) although I can't say I understand all those new parameters on the command line so perhaps that is supposed to be doing it?

I have an SR opened but no fix yet, surely VMware QA tested the new version of lcm-bundle-transfer-util though or others have had the same issue?

We ended up uploading the manifest file using the older version of the tool, however the v5.1 upgrade process has changed a bit and requires additional files (e.g. compatibility sets) to be uploaded by the tool, but the old version of the tool doesn't contain the logic to do that. We can probably still progress by using the API but given VCF upgrades are problematic enough I'd rather not go off script at the upgrade prep stage!

As a follow-up to this - VMware have released an updated version of the OBTU (released 28th Feb) that allows you to skip a domain validation check they added to VCF v5.x versions of the tool (if your domain name has a number in it then it will error unless you skip it).

This domain validation seems to have been introduced within SDDC Manager to as we get warnings in upgrade pre-checks for hostnames, however when you actually run the upgrade it doesn't seem to cause any issues.

As a follow-up to this - VMware have released an updated version of the OBTU (released 28th Feb) that allows you to skip a domain validation check they added to VCF v5.x versions of the tool (if your domain name has a number in it then it will error unless you skip it).

This domain validation seems to have been introduced within SDDC Manager to as we get warnings in upgrade pre-checks for hostnames, however when you actually run the upgrade it doesn't seem to cause any issues.