VCSA 5.5 to 6.0 upgrade is changing FQDN

[kheimann]

I'm getting this message during the upgrade process to 6.0 on our VCSA that I haven't seen in any of the guides I've read online:

Will this have any affect on any fqdn-based connections we have to the appliance (e.g. our Citrix XenApp environment, Veeam) if we don't change the certificate and keep our static DNS entry for the VCSA the same?

[kheimann]

So I did eventually find a reference to this here: vCenter Server Appliance Upgrade from 5.x to 6.0 - virtuallyBoring

According to him this is because the original appliance was deployed using the FQDN, and I entered the ip address this time. However, I tried switching to FQDN and I had a few problems. First, the legacy FQDN is just the host name. Instead of "vcenter.domain.com" it is just "vcenter". This caused it to fail to resolve in the upgrade wizard. I created a hosts entry for "vcenter", which allowed the upgrade wizard to resolve it, but it still just displayed the same message that the FQDN will be changing to the IP address.

Even using vcenter.domain.com as the FQDN generates the same message that the new appliance will be deployed with the IP as the FQDN. Does anyone know of anything else I could try?

[UmeshAhuja]

Hi ,

Try setting a Static Hostname and IP Address

The VCSA has a web-page front-end which listens on port 5840, and can be accessed remotely by IP Address the appliance finds a DHCP service. The front-end and port number is common one for many VMware Appliances. In this example we will configure the vCSA with a static IP address and hostname.

1. Locate the VCSA IP address. This can be seen in the General panel of the VCSA or by opening a Remote Console on the VM.

2. Open a web-browser at this IP address with

https://<IP_Address>:5480

3. Accept any certificate warnings that are displayed.

4. Next you should be presented with a login page – the default username is root and the password is vmware

5. At first logon a vCenter Server Step wizard will appear. You must Accept the EULA before proceeding

6. If you want to configure the VCSA with static IP address, you must cancel the welcome wizard.

7. Click the Network tab, select the Address column and switch the Eth0 interface to be Static

8. In the Hostname field, type a new hostname – confirm this hostname/FQDN is registered in DNS.

9. Set an Alternative DNS Server if you have secondary. Set the Static IPv4 IP Address and Subnet Mask - and click Save Settings

Note: Carrying out this task will result in a disconnect to the web admin page. The administrator will need to reload the web admin page to carry on with the remaining configuration. The web interface will warn the administrator of this fact.

[kheimann]

Thanks for the reply, unfortunately all of that is set correctly from what I can tell. The hostname is the same as what the upgrade installer is reporting as the FQDN. DNS servers are correct, etc.

The weird thing is, on the server I am running the installation from, I can ping or run nslookup on the vCenter FQDN and it resolves, but the upgrade wizard can't resolve the host name. I went ahead and opened a support ticket so someone can take a closer look.

[SavkoorSuhas]

Hello,

I believe you had opened a ticket with VMware support regarding this and I was assigned to this ticket.

I worked with Geoff on this and we checked that we had the short-name under the "hostname" in VCSA.

However, the SSO certificates were signed to the FQDN

So, we changed the "hostname" to the FQDN and under Admin Tab we checked certificate regeneration and rebooted the VCSA.

Once this was done, the "hostname" was registered to the FQDN which matched with the SSO.

Then, we made sure we unchecked the certificate regeneration, as we did not want to create new certs on every reboot.

After this, we were successfully able to proceed with the installation.

I also had another solution, but was unsure about that. The other one was:

Go ahead and continue with the upgrade.

Once the upgrade is done, we log into web management console with IP (FQDN will not work)

Then set it to FQDN and perform certificate regeneration.

Nevertheless, it was wonderful working with you.

Thanks

Suhas

[michaelgioia]

Suhas,

What about certificate regeneration for SSO in VCSA 6.0 ?

I built a VCSA 6.0 with specifying an IP address instead of FQDN/hostname.  I have no DNS in this setup i'm referring to.  I

Post VCSA deployment, all services are available on IP address.  And I want to keep it this way...

However, I notice the hostname of the appliance is 'localhost.localdom'.  And all certificates presented have CN set to 'localhost.localdom'.

I want to change this, and can change this with, script,

/opt/vmware/share/vami/vami_set_hostname

And then I can regenerate certificates with,

/usr/lib/vmware-vmca/bin/certificate-manager
And select Option 4: Regenerate a new VMCA Root Certificate and replace all certificates

Most of vSphere Web Client then works after doing this, except OVF deployment at the step when specifying storage... I think STS certificate is still referencing a certificate with CN=localhost.localdom.

Can I not change the hostname post deployment of VCSA ?

[blabarbera]

This entire process is the biggest cluster, and I am in the middle of it right now. This fixation on DNS to the extent that "vcenter" vs. "vcenter.domain.com" causes an upgrade to fail is ridiculous. Are you kidding me? As long as the DNS records resolve, why should it matter? The successful upgrade of my entire deployment with custom certificates hinges on whether or not I used a short-name vs a FQDN in the VAMI? Are you kidding? I have wild-card certs installed on my appliances specifically so that I can use a short-name, FQDN or IP. I have been with the product since version 4, and ever since SSO came around upgrades have been absolute nightmares. Worse than any other platform or product that I have yet used, and it just keeps getting worse. It's no wonder I still meet people that would rather run EOL builds than take these upgrades.