Bug 1918673 - guest's hostname can not be resolved by the libvirt_nss module
Summary: guest's hostname can not be resolved by the libvirt_nss module
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.4
Assignee: fkuchar
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1948358 1950255
TreeView+ depends on / blocked
 
Reported: 2021-01-21 10:42 UTC by yalzhang@redhat.com
Modified: 2021-05-07 06:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1950255 (view as bug list)
Environment:
Last Closed: 2021-04-19 08:06:06 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yalzhang@redhat.com 2021-01-21 10:42:11 UTC
Description of problem:
guest's hostname can not be resolved by the libvirt_nss module

Version-Release number of selected component (if applicable):
libvirt-7.0.0-1.module+el8.4.0+9464+3e71831a.x86_64

How reproducible:
100%

Steps to Reproduce:
1. install the libvirt-nss package
# rpm -q libvirt-nss
libvirt-nss-7.0.0-1.module+el8.4.0+9464+3e71831a.x86_64

2. Edit the nsswitch.conf file to be with:
hosts:      files libvirt dns myhostname

3. start a vm connected to the default network:
# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>5f596afb-cbbd-4cb9-baab-be585536d844</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:37:1c:18'/>
  <ip address='192.168.124.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.124.2' end='192.168.124.254'/>
    </dhcp>
  </ip>
</network>

# virsh start test

4. login the guest and configure the hostname:
# hostnamectl set-hostname guest_test
 # hostname
guest_test
reboot the guest
# reboot

5. after the guest boot successfully, check on host for the guest's hostname by net-dhcp-leases, it can not get the hostname:
# virsh domifaddr test
 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet6      52:54:00:f3:f5:ee    ipv4         192.168.124.17/24

# virsh net-dhcp-leases default
 Expiry Time           MAC address         Protocol   IP address           Hostname   Client ID or DUID
------------------------------------------------------------------------------------------------------------
 2021-01-21 05:49:18   52:54:00:f3:f5:ee   ipv4       192.168.124.17/24    -          01:52:54:00:f3:f5:ee

Actual results:
guest's hostname can not be resolved by the libvirt_nss module

Expected results:
there should be hostname showed in the net-dhcp-leases output

Additional info:
same issue exists on libvirt-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64,
but it can not be reproduced on libvirt-6.6.0-12.module+el8.3.1+9458+e57b3fac.x86_64

Comment 1 smitterl 2021-04-16 09:01:05 UTC
I cannot reproduce with 
libvirt-nss-7.0.0-13.module+el8.4.0+10604+5608c2b4.s390x

# cat /etc/nsswitch.conf|grep libvirt
hosts:      files libvirt dns myhostname

# virsh domifaddr avocado-vt-vm1 
 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet0      52:54:00:8e:38:30    ipv4         192.168.122.92/24

# virsh net-dhcp-leases default
 Expiry Time           MAC address         Protocol   IP address          Hostname   Client ID or DUID
-----------------------------------------------------------------------------------------------------------
 2021-04-16 05:55:28   52:54:00:8e:38:30   ipv4       192.168.122.92/24   myhost     01:52:54:00:8e:38:30

Comment 2 Michal Privoznik 2021-04-16 11:22:32 UTC
Yeah, question is why. There were not any notable changes in the NSS plugin since libvirt-6.10.0. However, there are other components at play: firstly it's our leaseshelper which is a small binary that's executed on each DHCP transaction and updates internal DB (which is where NSS looks too). And this binary is executed by dnsmasq which passes arguments through command line and/or env variables. But hostname is not guaranteed to be always set. Then there's the guest alone - we are not guaranteed that it sends hostname when doing DHCP.

IOW, I haven't spot anything obviously wrong in our implementation. So if hostname is missing then it might not had been sent in the first place.

Comment 3 yalzhang@redhat.com 2021-04-19 08:06:06 UTC
Hi Michal, after some testing and confirming with Sebas, we confirmed it is because I have set a improper hostname "guest_test" in comment 0. Refer to http://en.wikipedia.org/wiki/Hostname, a valid hostname should not include "_". 
"The Internet standards (Requests for Comments) for protocols specify that labels may contain only the ASCII letters a through z (in a case-insensitive manner), the digits 0 through 9, and the hyphen-minus character ('-')." - wiki
As I have confirmed "libvirt" works well with hostname such as "nssguest", and the "libvirt_guest" also works well, I will close this as "NOTABUG".


Note You need to log in before you can comment on or make changes to this bug.