I came across this bug after attempting to perform and in-place upgrade from NSX 6.3.5 to 6.4 Apparently upon the completion of the upgrade reboot, neither management component attempts to start or can even be started manually even though the upgrade process seemed to complete properly. Tech-support logs displayed the following sample errors:
upgrade/upgrade-script.log:7585:2018-01-24 03:00:07.052 GMT [4764]: [1-1] FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7586:FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7588: MESSAGE: FATAL: invalid value for parameter "TimeZone": "PST";
upgrade/upgrade-script.log:7589: CAUSE: (org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "PST") upgrade/upgrade-script.log:7595:Caused by: org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7610:2018-01-24 03:00:07.064 GMT [4765]: [1-1] FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7611:FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7613: MESSAGE: FATAL: invalid value for parameter "TimeZone": "PST";
upgrade/upgrade-script.log:7614: CAUSE: (org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "PST") upgrade/upgrade-script.log:7620:Caused by: org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7636:2018-01-24 03:00:07.066 GMT [4766]: [1-1] FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7637:FATAL: invalid value for parameter "TimeZone": "PST"
upgrade/upgrade-script.log:7639: MESSAGE: FATAL: invalid value for parameter "TimeZone": "PST";
upgrade/upgrade-script.log:7640: CAUSE: (org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "PST")
VMware support helped nail it down by changing the timezone of the NSX Manager to US/Pacific from PST on the NSX 6.3.5 recovered instance, and then performing the upgrade process once again in where everything successfully began working as engineered.
Hope this helps someone out in the meantime while VMware researches this bug in the meantime.
J
