Hi community,
I'm thinking what are benefits and drawbacks of using FQDN or IP address for ESXi host.
Assumptions
Option 1/ ESXi FQDN hostname
Option 2./ ESXi IP address
Here is my point of view ...
Option 1 Advantages:
Option 1 Drawbacks:
Option 2 Advantages:
Option 2 Drawbacks:
What do option you prefer and why?
Any opinion is highly appreciated.
Hi,
definitely DNS.
DNS should be redundant. So DNS Service should never be offline. If so, you have an other big issue that you have to resolve first.
It is a lot more easier to have names instead of ip adresses.
Also a lot of Services have a proper DNS configuration as a requirement. SSO, Active Directoy Integration and more.
https://communities.vmware.com/message/2261904
In my opinion, using ip adresses is not an alternative way.
Frank
Frank,
thanks for quick reply and link to another thread with the same topic.
I have mentioned in assumptions that DNS exists and all host are registered in DNS. This is mainly important for troubleshooting and asset management. So DNS service is in use.
But the question is different.
I'm thinking only about ESXi hosts.
vCenter and SSO have FQDN.
I know fully functional DNS and ESXi FQDN hostnames are VMware best practices and recommendations however the question is why it is recommended.
In production we all strictly recommend FQDN and typical answer is because VMware recommends it and it is Best Practice.
But almost anybody who has lab is using IP addresses there.
I'm not exception. I also use IP addresses in my lab and I would like to test and see any situation when ESXi registered into vCenter with IP address cause the error.
Right now I'm preparing the test plan so I'm collecting all reasons why ESXi FQDN is needed.
Simple vSphere HA Cluster with DRS doesn't need FQDN.
Here are components generally requiring ESXi without FQDN:
Any other reason(s) or vSphere component(s) requiring ESXi with FQDN?
Thanks in advance.
SSL certs is the biggest one. And they're used extensively in vSphere.
You can probably get along with IPs till the point where you start hardening your management connections with trusted certificates.
Another thing is the ease of management. Most people tend to read words better than numbers. If I'd need to manage an environment with 10+ hosts by their IPs, I would be lost without a proper IP-to-name/purpose/whateverID mapping table (and more chances for human errors).
Hope this helps.
Just in case you're afraid that HA won't work if DNS is down:
This used to be an issue with the old AAM HA agent until ESX(i) 4.x. But the newer FDM HA agent architecture that was introduced with ESXi 5.0 completely eliminated the dependancy on DNS for HA once and for all.
In a production environment, I would pick DNS over IPs any day for reasons mentioned by other people above already.
But obviously you should still document your environment properly in case you really need to connect to hosts IPs when your DNS is down or something similar.
Thanks everybody for your opinions. Let's change the question little bit. At the original question I have assumed ESXi hosts are registered in DNS. I have forgotten to write down another assumption: ESXi hostname and DNS is configured correctly with FQDN. Now reformulated question: Is better to add host to vSphere Cluster with FQDN or IP address.
Both configurations should be ok for
I Know at least of advantage of IP registration. I think IP registration has advantage against FQDN for users opening VM console from workstation without access to DNS where ESXi hosts are registered.
Do you know about other advantages or drawbacks?
Thanks in advance.
One thing to consider...vCAC requires each ESXi host to be added to vCenter by FQDN in order for the implementation to work properly. Also, I believe if you're going to use SRM, it also requires the ESXi hosts to be added by FQDN.
FQDN is the way, you should really have a working dns, I agree with Kermic regarding SSL certs, also VMware products now perform dns resolution during install, and it is a good practise to have a working dns.
First of all thanks guys for your replies.
I would like to highlight that I already mentioned in the thread that ...
ESXi hostnames are configured correctly on DNS server with FQDN, so everybody can resolve ESXi FQDN based on given IP address.
IP address of ESXi host is used only during ESX host registration (adding) in to vCenter.
@munozajj:
Are you sure SRM would have issue in this situation. I don't think so but I'll test SRM scenario in my lab in 2 weeks because I'm right now working on lab re-installation. I'll let you know.
I'm not planing vCAC installation in my lab this year so I cannot test vCAC scenario.
@Kermic,vfk:
Self-signed certificates works with IP addresses without problem.
I'm pretty sure CA signed certificates can be also generated to accept IP addresses.
Only you have to use subjectAltName with IP which is recommended anyway.
Below is example of vCenter CSR but the principle is same for ESXi.
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS: vc51-1, IP:10.0.0.10, DNS:vc51-1.vmware.com
To be honest I don't see any disadvantage of adding ESXi host to vCenter with IP address is everything is correctly configured on DNS and ESXi network settings.
I used this design decision in my design 6 months ago. Right now everything is implemented an works like a charm.
David.
This may work for now, but it is actually getting phased out if you are looking to use public CA : Internal Server Name SSL Certificate Issuance After 2015 - however, internal CA will work just fine. This will entirely depend which CA you use to secure your environment. Most VMware install will most likely be using internal CA.
@vfk: thanks for follow up. Your information about public CA new policy is helpful. I didn't know about this this new SSL Certificates policy and to be honest it makes perfect sense for me. However it make sense for publicly facing services. I don't think any VC, WebClient or ESXi will have public IP addresses and hostnames therefore SSL Cetificate will be always signed by internal CA and not by public CA. Therefore I think this policy is not relevant for this case. Am I right?
BTW VMware recommends to include component (vCenter, VUM, Inventory Service, ...) IP addresses as SANs (Subject Alternative Names) in Certificate Sign Requests.
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com, DNS:ServerIPAddress
More info at
VMware KB: Creating certificate requests and certificates for vCenter Server 5.5 components
Therefore I assume ESXi registered to vCenter with IP address should work even with CA Signed SSL Certificate.
Do you agree or I missed something?
Hi David,
You're right, as long as you are using internal CA, this should not make a difference and will work just fine. But I suspect these recommendation guidelines are likely/can to change overtime. The only reason for the current recommendation for maintain compatibility across systems and resolve inconsistencies.
