vCenter DB hack - changing host names from IP to DNS

[Wardy8124]

Hi all,

I have a requirement to change the host names being displayed in virtual center from IPaddress to DNS. I'm fully aware of the method of placing the host into maintenance mode - removing from the VC and then readding. However the environment is currently under contention for resources and can't really sustain a host failure (this is another story).

What I intended to do was to change the VPX_HOST and DNS_NAME entities in the VCDB however when I tried this and restarted the virtual center services the IPaddress reappears instead of the DNS name. It looks as though something is over writing the value I set using the sql script provided by an sql admin in another team. I am running this under admin credentials with have the dbo sql permissions assigned.

The procedure followed was:

• Stop VC services
• log on to the VC DB server and open Studio Manager
• Run the following in the SQL query :

select 8 from VPX_Host;      I then press return and then run:

update VPX_HOST set DNS_NAME='a server DNS name in here' where ID=31

• I execute the query and get the message 1 row affected and then refresh and can see the DNS name where I wanted it in the table.
• I then start the VC services on the VC and lo and behold the IP address still appears instead of the name

Question for you gurus.

1. Can I actually do what I'm trying to achieve i.e. change this in the VCDB so that it shows it in the VI client.

2. Can anyone see any risk to the VCDB in doing this?

3. If yes to question 1 - what the bloody hell am I doing wrong???

Looking forward to seeing your comments and feel free to request further info if needed but until then I shall mostely be scratching my head and impacting it repeatedly off a local wall.

[msatya]

please check this link-http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101825...

-------------------------
please award points if you see fit.Thanks

[AndreTheGiant]

You can disable HA and DRS, disconnect the hosts and reconnect them with the DNS name.

Then re-enable HA and DRS.

[Wardy8124]

Hi msatya Sorry but I'm not entirely sure what relevance your link has to what I'm trying to achieve so if you can explain further that would be great.

Thanks Andre however I don't think your suggestion will work because simply disconnecting the host and reconnecting it doesn't allow you to change the name/properties when you reconnect. When you disconnect a host, you can still see the host in the VC be it annotated with "disconnected". I still think the only way round this is to do a "remove host" and then re-add using the FQDN but I think I may have to reset all the resource pool settings when re-adding in to the VC?

[AndreTheGiant]

I mean disconnect (and remove).

[RParker]

Wardy8124 wrote:

Thanks Andre however I don't think your suggestion will work because simply disconnecting the host and reconnecting it doesn't allow you to change the name/properties when you reconnect. When you disconnect a host, you can still see the host in the VC be it annotated with "disconnected". I still think the only way round this is to do a "remove host" and then re-add using the FQDN but I think I may have to reset all the resource pool settings when re-adding in to the VC?

His point was for your host failure comment, not renaming the hosts.  I think you will need to actually put forth some effort to make the changes, which means, removing the host, and add them back with their DNS names.

There is no "hack" to rename, as the database has too many references to change.. maybe you can find a kludget that will work, but that's exactly what you will get.. a "kludge" and it may cause problems later.

So my advice is to simply do it the correct way... disable HA and renable it when done so you can rename the hosts PROPERLY.

[Wardy8124]

Hi I appreciate your comments and yes I would ideally like to do it the proper way and disable HA/DRS/Remove the hosts as well as ensure we have enough compute power to sustain a host failure.

However this isn't an ideal situation nor is the environment I've inherited so I need to look at options to minimise risk and downtime to these mission critical services so the obvious comments to apply time and effort to do things properly sadly can't always apply - I wish they would .

I think Andre has confirmed what I was already considering doing which was disabling the HA/DRS and removing the hosts so that VM's still are powered on and I can re-add the host. Just had small concern of keep all the resource group settings intact as well as the performance data stats as I'm not 100% sure these will remain after removing the host from the VC.

Thanks for sanity check though Andre

[RParker]

Wardy8124 wrote:

However this isn't an ideal situation nor is the environment I've inherited so I need to look at options to minimise risk and downtime to these mission critical services so the obvious comments to apply time and effort to do things properly sadly can't always apply - I wish they would .

I think Andre has confirmed what I was already considering doing which was disabling the HA/DRS and removing the hosts so that VM's still are powered on and I can re-add the host. Just had small concern of keep all the resource group settings intact as well as the performance data stats as I'm not 100% sure these will remain after removing the host from the VC.

Thanks for sanity check though Andre

ESX is more resilient than you think.. if you remove a host, it's not going to be down for more than 5 minutes, depends how quickly you can click remove, and then add it back.  5 minutes is a "buffer", it could be done in less than 1.

You will lose your history, that is a given, no way around that.  Databases are very anal.  If the object names do not match, you will not get a "hit".  It's as simple as that, so if you want to retain the history, there isn't much you can do.  That host even though it's part of the vCenter NOW when it's removed ALL traces of it are dissassociated with the original host, everything will be new.. just like you were introducing a completely new host.

THAT I can guarantee.  It's like starting over.. even the VM's.. they will be removed, and added back to inventory, they won't go down or interrupt network, but vCenter will treat them as brand new objects.  So if you have VM level permissions, gone!  Be aware of that as well.

[mcowger]

Richard is right - the only way to do these and keep your vCenter DB in a sane state is to do it the right way.  Modifying the database is asking for problems down the line, and is totally unsupported anyways.

If you want to minimize the time, I'd recommend writing a Perl or PowerCLI script to do each host for you, which would minimize the time without your hosts in the cluster.

[Wardy8124]

Hi again and thanks for taking the time to reply and a good call about the VM level permissions as this was a slight oversight on my part and I should know better!

I also think that all resource pool settings will be removed so will need to get these documented before any work is done. I'd like to point out that I know it should be properly as well as the correct method to do it however it's not my point which was is there another way.

Like you've already mentioned, playing around with any database is done at one's peril espcially the VC DB and I'm fully aware of potential issues that could/will occur down the line so it's not something I would do likely but I'd still like to know either way.

Thanks for the concerns and assistance

[AndreTheGiant]

You can keep existing resource pools.

Disable only HA, not DRS (just put it to manual) to preserve pools.