After reading the title of this article I’m sure you’re saying, ‘You can’t change VCSA hostname. You have to redeploy.’ That is what I was told and all the documentation I have read says you have to redeploy. Well it is not true. With that said here is your warning about mucking with the VCSA configuration. Don’t do it! Unless you are working in your test environment and you came across a ‘workaround’ that you wanted to try. I still wouldn’t recommend using this ‘workaround’ in your production environment without extensive testing and upon recommendation from VMware Support.
Why did I need to change the hostname in my test lab? I applied 6.5 U1 to the VCSA in my test lab. I then checked the VCSA and saw that the hostname was changed to ‘localhost’ and AD authentication was broken. It also broke ssl certificates. I was getting ready to redeploy the VCSA when I came across this ‘workaround’ and I gave it a try. It worked great.
Change VCSA 6.5 U1 Hostname with vami_config_net
The ‘workaround’ is really a built in utility called vami_config_net. The full name of this utility is configure-network command-line utility. Here is what the utility looks like in use with relevant configuration names blacked out.
Option # 3 will prompt with ‘New hostname’ and show the current hostname. I made this change in my test lab and it did not require a reboot to start working. However, I made this change after the VCSA had lost domain trust. I had to take the VCSA completely out of the domain, delete the computer object, and join it to the domain again. The VCSA is working wonderfully once more.
If I had tried to change the ip address it would have failed without changing the dns to reflect this before making the change. In this very limited use case vami_config_net worked because I changed the hostname back to the original name. I would not have faith in using this utility to just to change from one hostname to a completely different hostname until I have tested further.
This week brought another unusual problem. We have a multi-domain environment that includes 2 different active directory forests with a trust. Like most of the world we have disabled SSLv3 on desktops as well as servers to prevent SSLv3 connections but this was only done completely in our main active directory domain. Everything has been working fine until this week. Over the weekend a new change was introduced to the environment in the form of a new sha2 certificate for domain controllers in the other active directory domain. Once this change was implemented user accounts from the other domain would no longer authenticate for our Horizon View vCenter.
Settings were checked and the LDAPs identity source was identical on both our vCenters in our main domain but one did not work. Certificate stores were checked and they both had the relevant certificates. After digging further there was one difference between the 2 vcenter servers concerning SSL.
Look under vCenter Server Settings.
There is a setting located under Advanced Settings called SSL.Version.
Choose TLSv1 to completely stop vCenter from trying to communicate over SSLv3.
Do you ever find that as a VMware admin that you have to defend your choices when it comes to virtual machine sizing? We’ve all been there when our customers (i.e. internal I.T. analysts) or even your co-workers on your team question why you didn’t give their vm as much cpu or memory as originally requested. How do you deal with it? Often it is easy to just declare I am the VMware admin and I obviously know more than you so just accept what I am saying. Besides, you are just an ignorant newb when it comes to VMware. The other response is to elevate the conversation and educate the ignorati. I like to think that I choose the latter but I sometimes fantasize about the former. In that vein I choose to highlight some basic troubleshooting methods that VMware recommends to determine if indeed that vm is worthy of a bump in cpu, memory, or even diagnose storage or network issues. A great knowledge base article to start with is Troubleshooting ESX/ESXi virtual machine performance issues (2001003) .
Hopefully this is a good start in troubleshooting ESXI performance issues and hopefully your political and ignorance issues are few and far between. I’d love to hear from you about your experiences!