vmtools should not expect gethostname() to return fqdn

dantran commented 3 years ago

According to this https://github.com/vmware/open-vm-tools/blob/677ddf97a85f8b96b95ac60f54b59df264d5c4d5/open-vm-tools/lib/nicInfo/nicInfoPosix.c#L189

vmtools expects gethostname() (same as command line hostname) to return fqdn so that it can display VM DNS name at vCenter VM summary. However, by default gethostname() only returns a short name by convention

On the command line of my host, the output to hostname command always return a short name, to return a long name, I have to run hostname -f

Would like to ask that vmtool use a correct API to get the hostname that always returns a long-form.

jonathanvmw commented 3 years ago

@dantran

Thank you for reporting the issue.

Why exactly do you want this change made? i assume you're running into a problem of some kind - what is the problem? Also, with which guest OS(es) are you seeing the problem?

Thank you.

dantran commented 3 years ago

we are using SLES12SP5 VMs. At vCenter, each VM Summary shows its DNS name as short DNS from (xyz) not the expected full name (xyz.domain.x).

I believe vmtool using gethostname() system call which is the equivalent of hostname command line, which always return short name by default

oranki commented 2 years ago

From Debian Reference guide:

The kernel maintains the system hostname. The system unit started by systemd-hostnamed.service sets the system hostname at boot time to the name stored in "/etc/hostname". This file should contain only the system hostname, not a fully qualified domain name.

Since the system hostname is not and should not be FQDN, the DNS field in vmware is also not FQDN.

FreeBSD man page for hostname(1) helpfully explains how FQDN is resolved:

The FQDN is the name gethostbyname(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.

Confusingly, this information is made available to PowerCLI from VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine data structure, specifically in Guest.ExtensionData.HostName string. Why it's renamed into "DNS" in vCenter UI, I haven't the slightest, but clearly no attempt is made to ensure it actually were resolvable.

This may also be interpreted as vCenter UI bug; it shouldn't use the HostName string directly as "DNS" name, but instead parse Guest.ExtensionData.IpStack[].DnsConfig more intelligently to build the FQDN.

Please either fix this or close the issue as will not fix.

johan-chassaing commented 2 years ago

I agree, open-vm-tools returns the vm short host name and not the long one. It should be based on the result of the command hostname -f or concatenate information like @oranki said.

Currently, it returns: ╰▸ hostname server1

it should return: ╰▸ hostname -f server1.domain.tld

thank you

johan-chassaing commented 2 years ago

I try to use the short-name and long-name in the tools.conf. I see in the log "Using values in tools.conf to override OS Name" but the long-name is not displayed in the summary page. it's still the same short name.

With a vm deployed and customized by vmware, the /etc/hostname is a short name, but the open-vm-tools don't like a short name in this file.

lemke1458 commented 2 years ago

"OS Name" means the name of the operating system, typically from the contents of /etc/*release (eg Redhat, Ubuntu, etc). Nothing to do with FQDN names.

As far the FQDN issue, unfortunately we have no good answer. Different distros and OS configs can return different values, and any changes made to Tools are likely to break something else, so we've left it as-is.

oranki commented 2 years ago

As far the FQDN issue, unfortunately we have no good answer. Different distros and OS configs can return different values, and any changes made to Tools are likely to break something else, so we've left it as-is.

This makes sense.

May I suggest mending the source to reflect the fact that it does not fetch FQDN, without any functional changes?

Either change the "fqdn" references in source to "hostname", or if this risks breaking something (anything), simply add a comment disclaimer of what the function actually does.

jonathanvmw commented 2 years ago

An internal bug has been filed with your suggestion.

yokhahn commented 1 year ago

any word on this?

jonathanvmw commented 1 year ago

@yokhahn - No, sorry, there is no update at this time.

koraz-0815 commented 1 year ago

Hello, we have the same problem. Debian system did not show fqdn i vcenter

vcenter-Version 7.0.3

DNS-Name in vcenter: rhel7test.example.com

[root@rhel7test ~]# cat /etc/*release | grep VERSION_ID
VERSION_ID="7.9"
[root@rhel7test ~]# hostname
rhel7test.example.com
[root@rhel7test ~]# hostname -f
rhel7test.example.com

DNS-Name in vcenter: rhel8test.example.com

[root@rhel8test ~]# cat /etc/*release | grep VERSION_ID
VERSION_ID="8.8"
[root@rhel8test ~]# hostname
rhel8test.example.com
[root@rhel8test~]# hostname -f
rhel8test.example.com

DNS-Name in vcenter: rhel9test.example.com

[root@rhel9test ~]# cat /etc/*release | grep VERSION_ID
VERSION_ID="9.2"
[root@rhel9test ~]# hostname
rhel9test.example.com
[root@rhel9test ~]# hostname -f
rhel9test.example.com

DNS-Name in vcenter: debiantest

root@debiantest:~# cat /etc/*release | grep VERSION_ID
VERSION_ID="11"
root@debiantest:~# hostname
debiantest
root@debiantest:~# hostname -f
debiantest.example.com

The problem is that hostname in Debian only show the hostname. If the script will use hostname -f everything would be ok.

morete commented 1 year ago

Hello,

I see the same issue when we configure RedHat following the SAP recommendations/requirements... the hostname is just a short-name a system will have regardless of being part of a domain or not... once you connect a system to a network and the domain/connectivity concept is part of the system then, and only then, you have a domain and the FQDN concept is introduced and is possible to be defined at system level...

Right now all our sap systems show in vCenter as just a short-name and not the DNS FQDN... so, I agree 100% with the idea of making vm tools to use "hostname -f" to report the VM DNS name as this name is actually a name on a network and not just a hostname.

We have a tool that collects the DNS name from vCenter and builds an inventory across all vCenters of our enterprise, I had many times the question about why the SAP systems do not have the correct domain in the inventory... it all came down to vmtools not reading it as it should.

Please give some priority to agree on a solution to get the correct value in the correct way.

Maybe gathering domain using getdomainname() and concatenating it behind the hostname? in case there is no domain returned then just return the hostname... or run command instead: system("hostname -f");

Thank you!

JesseHermes commented 10 months ago

I see the same issue with Ubuntu. vCenter shows just short name, running hostname on the VM shows short, hostname -f shows FQDN.

morete commented 10 months ago

"OS Name" means the name of the operating system, typically from the contents of /etc/*release (eg Redhat, Ubuntu, etc). Nothing to do with FQDN names.

As far the FQDN issue, unfortunately we have no good answer. Different distros and OS configs can return different values, and any changes made to Tools are likely to break something else, so we've left it as-is.

Why not having a solution instead? Maybe a proper implementation behind a feature flag we could config to chose what we need to get back? Then we can chose legacy broken concept or corrected implementation... Make the old default and make everyone happy.... Why just letting thing done wrong? Just because is not a so satisfying reason....

mleiner commented 3 months ago

I've stumbled over this today when we tried to generated inventory information for all our systems.

We too have a mixture of hostnames and fqdns in the DNS Name field of the summary page.

After doing another research of how these pieces play together, reading man pages, code documentation and experiences, I have come up with this:

the system's hostname will typically return whatever is in /etc/hostname
Boot process will set the hostname from /etc/hostname
Traditionally the dnsdomainname and nisdomainname have been set during boot process too, but this is no longer the case (do not rely on this!)
Today the FQDN gets composed from resolving the hostname through /etc/hosts
/etc/hosts is supposed to list the FQDN as an alias to the hostname (127.0.0.1 or 127.x.y.z) - people still disagree wether the FQDN or the shortname shall be first or wether to use 127.0.0.1 or another IP address
hostname is expected to return a hostname without domain, so does gethostname()
hostname -f is expected to return the FQDN
The functions of the getnameinfo are able to resolve the local hostname and its fqdn
getnameinfo is part of POSIX.1-2001, POSIX.1-2008, RFC 2553. I see references back to 1999.

This is an example code for getting the FQDN using modern and reliable methods:

/* Credits to the partial submission at
   https://unix.stackexchange.com/questions/572418/how-to-query-fqdn-of-myself-under-posix-2018
*/
/* for printf */
#include <stdio.h>

/* for gethostname */
#include <unistd.h>

/* for getaddrinfo */
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main() {
    char buf[256];
    struct addrinfo *res, *cur;
    struct addrinfo hints = {0};
    hints.ai_family = AF_UNSPEC;
    hints.ai_flags = AI_CANONNAME;
    hints.ai_socktype = SOCK_DGRAM;

    gethostname(buf, sizeof(buf));
    getaddrinfo(buf, 0, &hints, &res);
    for (cur = res; cur; cur = cur->ai_next) {
        printf("Host name: %s\n", cur->ai_canonname);
    }
    return 0;
}

vmware / open-vm-tools

vmtools should not expect gethostname() to return fqdn #551