LXC Hostname PVE Config not working

[D0peX]

Hey guys,

I've encountered an issue with setting host names on LXC containers.
When I set a hostname on creation for LXC, it doesn't correctly push over the config. I can also not manually set it! (well, i can. but it is lost on reboot)

Check the screenshots. Anyone has any clue? please let me know.
This is on a default ubuntu 16.04 template from proxmox repo.

root@:~# pveversion
pve-manager/5.2-2/b1d1c7f4 (running kernel: 4.15.17-3-pve)

Changing this when powered down, or up. does not work either



Search domain is correct though:


I'd love to hear some suggestions!

 

[D0peX]

bump

 

[Alwin]

Try to use the hostname not the FQDN in the 'Hostname' config.

 

[D0peX]

Try to use the hostname not the FQDN in the 'Hostname' config.

Hi Alwin,

Ty for your response @Alwin . I've already tried. Nonetheless i've tried again, without success. Also, I have noticed that on some other containers it does work. Also Ubuntu images.

 

[Alwin]

Try to create a new container with the same image, might be there something wrong with this container.

 

[D0peX]

Try to create a new container with the same image, might be there something wrong with this container.

Nope. Does not work. i've tried the following:
- Static IP
- other vlan / (dns zone)
- downloaded new template
- deleted this container in particular and recreated it under new container ID

 

[Alwin]

Please post how your vmid.conf looks like and what template you are using.

 

[D0peX]

Please post how your vmid.conf looks like and what template you are using.

root@HOSTNAME:/etc/pve/lxc# cat 312.conf
arch: amd64
cores: 1
hostname: tig.internal.domain.tld
memory: 4096
nameserver: 1.1.1.1 1.0.0.1
net0: name=eth0,bridge=vmbr1,hwaddr=MACADDRESS,ip=dhcp,tag=1337,type=veth
ostype: ubuntu
rootfs: local-lvm:vm-312-disk-1,size=20G
searchdomain: internal.domain.tld
swap: 512

And as stated before. Default Ubuntu 16.04 LXC template from proxmox repo.
So as you can see, hostname is correctly written in the conf file. But it does not get written correctly in the containter itself.

Either i'm missing something very obvious, or something is wrong with PVE a script.
I'm checking now on another host, but i doubt it since they are the exact same version.

 

[Alwin]

Works on my machine with the ubuntu 16.04 template.

pve-manager/5.2-3/f830fbe9 (running kernel: 4.15.17-3-pve)

 

[D0peX]

Works on my machine with the ubuntu 16.04 template.

pve-manager/5.2-3/f830fbe9 (running kernel: 4.15.17-3-pve)

Hi Alwin,
That is strange. I noticed you are on a diffrent version. I updated && upgraded my hosts. but i'm still on 5.2-2. You are on 5.2-3. I'm not sure if it makes a difference. (I'm on non-sub repo)

 

[Alwin]

My machine runs on the pvetest repository, but that shouldn't make a difference.

hostname: tig
searchdomain: internal.domain.tld

The /etc/hosts entry is put together from hostname & searchdomain, but it should work also with FQDN. I just can't reproduce it.

 

[D0peX]

Okay. I'm bumping this.
This is still not working and it is driving me crazy...

I have tested different templates. Made sure host settings are correct and what not.
Until now, i have been able to find it is working correctly for a container that has been given a static IP. But not for one with a DHCP lease.

Steps to reproduce:
create 2 containers, using ubuntu 16.04 OR 18.04 template (from proxmox repo)

1. set a hostname such as 'dnstest1'
2. set one with a static IP. using host settings for DNS (new container)
3. set one with DHCP with host settings for DNS (new container)

No other special steps

running 'hostname -f' on the container with a static IP will return a proper FQDN i.e. 'dnstest1.domain.tld'
running the same command on the one with DCHP, will only return the hostname that you have set. 'dnstest1'

Lets continue to investigate the DHCP container:
Checking the LXC config for that container shows that there is NO 'searchdomain' being added.
> Adding a searchdomain in the webUI manually > LXC config does include a searchdomain
> reboot the container > 'hostname -f' will still show 'dnstest1'
Even checking '/etc/hosts/'shows that proxmox config did not append the searchdomain like it did for the static configured container!

If someone could look in to this, please. This looks like an issue with how proxmox is pushing the settings to the container.

-D0peX

 

[Alwin]

What DHCP options does the DHCP server send?

 

[D0peX]

What DHCP options does the DHCP server send?

Hi Alwin,

Option 15 was been set correctly.


My own workstation also has a lease from the same scope and does get this information (which is not domain joined)


Also my iPhone, within that scope, literally says: "Searchdomain = int.domain.tld"
Checked resolv.conf on one of my test containers. Searchdomain did get added:

root@dnstest:~# cat /etc/resolv.conf
# --- BEGIN PVE ---
search int.domain.tld
...

Ping from another server does work though:

[win16DC1.int.domain.tld]: PS C:\Users\[]\Documents> ping dnstest

Pinging dnstest.int.domain.tld [10.10.30.57] with 32 bytes of data:
Reply from 10.10.30.57: bytes=32 time<1ms TTL=64

I'm not sure what is up now. DHCP setting, or a proxmox thing ¯\_(ツ)_/¯

 

[Alwin]

What is not working now? I am a little confused.

 

[Sessa45]

Hello,

I currently have a problem changing the hostname of my LXC CT.

The CT is executed by CentOS.
I changed the / etc / hosts and / etc / hostname entries followed by a reboot.
After logging in to CT, the changes did not seem to be made, so the old hostname was active.

 

[Stoiko Ivanov]

The hostname (and fqdn) get set by PVE during the container start (as long as it's not type unmanaged) - see https://pve.proxmox.com/pve-docs/chapter-pct.html#_guest_operating_system_configuration

 

[avdol]

Did you manage to get this resolved? I'm also having the same issue which is preventing me from setting up a nextcloud server

 

[fst]

Proxmox says you can
# touch /etc/.pve-ignore.hosts
on https://pve.proxmox.com/wiki/Linux_Container#_guest_operating_system_configuration

However this is not really a nice workaround. Fixing the bug would be a better solution.

I am using DHCP, proxmox 7.0-1 and fedora-34-default_20210427_amd64.tar.xz