Anyone tried the new feature that finally allows changing the FQDN of a vCenter Server? I cannot make it work, it just fails with the following error:
2019-09-08 11:38:39,050 - pnid_utils-update_task_status():1186 - INFO - Task : Failed to create replication placeholder.
The environment is pretty simple and meets the feature's requirements. I just don't know what to look at, so any ideas are appreciated.
The full pnid_change.log is attached (the real FQDN which has proper dns records is replaced with "test.local").
Did you find a solution for this issue?
Rename vCenter 6.7 update 3, stops in the middle of renaming with the error: "Failed to create replication placeholder".
I had to restore vCenter to get it operational again.
Renaming is on hold.
What I did is this, made a cname record of new vcenter name pointing on the old a record name.
I also had an issue with an upgrading DVS switch, it was not finished upgrading.
vCenter renaming stopped after about 5- 10 minutes with "Failed to create replication placeholder". And was staying there...
I have removed all of theese issues, and I am looking at this community tread, hoping you would find a solution for this issue!
Sorry, I didn't get it... Did adding a CNAME for vCenter solve your problem with fqdn change?
Regarding the SR I created previously, I was told a missing PTR record for vCenter might have been an issue but after I added one nothing changed...
Cname in DNS was not able to fix this issue.
Look here: Changing the FQDN of a vCenter Server | Configuration and Day 2 Operations | VMware vSphere Central
"If you did not setup DNS A records (Forward & Reverse) you may have an issue resolving the new FQDN of your vCenter Server.
Please create or edit those DNS Records to help resolve the VCSA hostname."
VMware vSphere central states, you may change name on vCenter without setting up DNS A and PTR record before renaming.
I have updated the vCenter with the latest patch after GA of vSphere 6.7 update 3. In the release notes it does not state any fixes of renaming issues.
I am reporting a new case to VMware on this case. I hope they have more experience with this issue now.
"Failed to create replication placeholder"
Next I will remove all DNS records for the new name before renaming is starting, ref vsphere central.
From 2 days ago VMware released this KB 74817.
vCenter 6.7 update 3a will fix the issue with this: Failed to create replication placeholder
You can find the update here: https://my.vmware.com/web/vmware/details?productId=742&rPId=38207&downloadGroup=VC67U3a
I have already updated the vCenter with this update, and I will retry the renaming procedure tomorrow.
I will post the result here tomorrow.
Failed to create replication placeholder is still showing up!
The update 3a did not fix the issue!
I did test with cname in DNS and with A record in DNS.
Both records did fail. A new message did appear when cname was gone and no new A record was in place.
The renaming would not go forward without an A Record of the new FQDN name. I removed the old A record, and registered the A Record of the new FQDN name.
The renaming did go forward to 30% and did stop with the (By now) well known "Failed to create replication placeholder".
This time i did my homework and did a backup and a snapshot of a turned off vCenter before doing the change.
I was up and running after some minutes after rolling back to snapshot, and started the server once more!
It would be nice if VMware did an update of vSpherecentral https://vspherecentral.vmware.com/t/vcenter-server/configuration-and-day-2-operations/changing-the-f...
And the blog they are using as a reference https://blogs.vmware.com/vsphere/2019/08/changing-your-vcenter-servers-fqdn.html
We have connected vrops to the vCenter it may have a hook into vcenter naming issue, we will remove it next time, and maybe replace the file /usr/lib/applmgmt/networking/py/vmware/appliance/networking/pnid/pnid_utils.py
As specified in the kb for this issue https://kb.vmware.com/s/article/74817
Close but no cigar!
I will keep you updated!
Working on the SR VMware engineers have updated some scripts on the VCSA, after that the procedure has finished successfully.
The issue is resolved, thanks to everyone!