Hello.
Debian 13 uses cloud-init version 25.1.4. This version uses a different structure to configure DNS servers.
Proxmox 9 cloud-init generate files from previous version that doesn't work to set DNS servers for Debian 13.
Hope Proxmox fix its file structure for cloud-init.
Thanks!
same here
pve host
Code:
$ pveversion
pve-manager/9.0.6/49c767b70aeb6648 (running kernel: 6.14.11-1-pve)Code:
$ qm cloudinit dump 100 network
version: 1
config:
- type: physical
name: eth0
mac_address: 'xx:xx:xx:xx:xx:xx'
subnets:
- type: static
address: '192.168.1.150'
netmask: '255.255.255.0'
gateway: '192.168.1.1'
- type: nameserver
address:
- '9.9.9.9'
- '8.8.8.8'
search:
- 'xyz.local'Debian 13 vm
Code:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 13 (trixie)
Release: 13
Codename: trixieCode:
$ cloud-init --version
/usr/bin/cloud-init 25.1.4Code:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTENCode:
$ resolvconf --version
Debian resolvconf 1.94
Copyright:
2003-2017 Thomas Hood <jdthood@gmail.com>
License: GPL-2+Code:
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp
# This is an autoconfigured IPv6 interface
iface ens18 inet6 autoCode:
$ cat /etc/network/interfaces.d/50-cloud-init
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
dns-nameservers 9.9.9.9 8.8.8.8
dns-search xyz.local
auto eth0
iface eth0 inet static
address 192.168.1.150/24
gateway 192.168.1.1Code:
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
altname enp0s18
altname enxbc241100ffbc
altname ens18
inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fdf8:9a78:f086:e900:be24:11ff:fe00:ffbc/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 7087sec preferred_lft 3487sec
inet6 fe80::be24:11ff:fe00:ffbc/64 scope link proto kernel_ll
valid_lft forever preferred_lft foreverCode:
$ cloud-init status --long
status: done
extended_status: done
boot_status_code: enabled-by-generator
last_update: Thu, 01 Jan 1970 00:00:25 +0000
detail: DataSourceNoCloud [seed=/dev/sr0]
errors: []
recoverable_errors: {}I have had no problems using cloud-init in PVE9 to create a Debian 13 VM (server) based on the cloud image (https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2).
I should point out that I do not set any DNS settings, only user, password & NW/GW.
I suspect you weren't using a cloud image based on your output.
For example: In the created Debian Trixie VM, I get
Code:
root@Copy-of-VM-Debian-Trixie-CloudINIT-Template:~# resolvconf --version
systemd 257 (257.7-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVEHowever Proxmox is using an outdated version of Cloud-init, as if you set a User (possibly even if you don't) you will get a warning:
Code:
root@Copy-of-VM-Debian-Trixie-CloudINIT-Template:~# cloud-init status --long
status: done
extended_status: degraded done
boot_status_code: enabled-by-generator
last_update: Thu, 01 Jan 1970 00:00:08 +0000
detail: DataSourceNoCloud [seed=/dev/sr0]
errors: []
recoverable_errors:
DEPRECATED:
- 'user' of type string is deprecated in 22.2 and scheduled to be removed in 27.2. Use 'users' list instead.
- 'user' of type string is deprecated in 22.2 and scheduled to be removed in 27.2. Use 'users' list instead.This has already been posted here.
I suspect you weren't using a cloud image based on your output.
Yep, that's what I suspect too.
Also, in the cloud image I'm using (https://cdimage.debian.org/cdimage/cloud/trixie/latest/debian-13-generic-amd64.raw) there's no /etc/network/interfaces.d/50-cloud-init file, but rather /etc/netplan/50-cloud-init.yaml, which looks like this in the VM:
YAML:
network:
version: 2
ethernets:
eth0:
match:
macaddress: "xx:xx:xx:xx:xx:xx"
addresses:
- "192.168.220.116/24"
nameservers:
addresses:
- 192.168.220.1
search:
- local.mydomain.tld
set-name: "eth0"
routes:
- to: "default"
via: "192.168.220.1"And it seems to work:
Code:
root@trixie:/etc/cloud# resolvectl status
Global
Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: uplink
Link 2 (eth0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.220.1
DNS Servers: 192.168.220.1
DNS Domain: local.mydomain.tld
Default Route: yes
root@trixie:/etc/cloud# resolvectl show-server-state
Server: 192.168.220.1
Type: link
Interface: eth0
Interface Index: 2
Verified feature level: UDP+EDNS0
Possible feature level: UDP+EDNS0
DNSSEC Mode: no
DNSSEC Supported: yes
Maximum UDP fragment size received: 512
Failed UDP attempts: 0
Failed TCP attempts: 0
Seen truncated packet: no
Seen OPT RR getting lost: no
Seen RRSIG RR missing: no
Seen invalid packet: no
Server dropped DO flag: noSo, for DNS configuration to apply correctly, the
systemd-resolvedpackage must be installed.
Yes, but as far as I understand it, that should already be pre-installed in the cloud images and then be used by Netplan by default. For me, at least, it worked out of the box without having to install the systemd-resolved package manually via virt-customize beforehand.
Last edited:
that should already be pre-installed in the cloud images
no it is not installed by default in debian cloud images
no it is not installed by default in debian cloud images
Then, it gets installed by default, at least with the Trixie RAW images, because it is installed in my Trixie test VM, and I definitely didn't install it via virt-customize or manually in the VM after it was up and running.
I create my test VMs via a script using qm create and qm importdisk, and the netweork setings are set like this:
Code:
qm set $VMID --nameserver 192.168.220.1
qm set $VMID --ipconfig0 ip=192.168.220.$VMID/24,gw=192.168.220.1Im using the following Cloud Image: https://cdimage.debian.org/cdimage/cloud/trixie/latest/debian-13-generic-amd64.raw
Last edited:
The only difference possible, are you choosing to Update packages Yes within the cloud-init?
The only difference possible, are you choosing to
Update packages Yeswithin the cloud-init?
yes, it is enabled by default
When I set --nameserver and --searchdomain to a VM, it will render to loopback interface in /etc/network/interfaces.d/50-cloud-init
I can capture these values into /etc/cloud/cloud.cfgto update resolv.conf
So it looks like
Code:
> more /etc/cloud/cloud.cfg
...
runcmd:
- sh -c '
grep -E "^\s+dns-nameservers\s" /etc/network/interfaces.d/50-cloud-init | sed -E "s/^\s*dns-(nameservers)/nameserver/g" > /etc/resolvconf/resolv.conf.d/base;
grep -E "^\s+dns-search\s" /etc/network/interfaces.d/50-cloud-init | sed -E "s/^\s*dns-(search)/\1/g" >> /etc/resolvconf/resolv.conf.d/base;
resolvconf -u;
echo "DNS Updated via cloud-init cmd."
'
Note: You have to install resolvconf first
Last edited:
Hi everyone.
I recently found this issue when setting my homelab and I created a small workaround.
It's a shell script that corrects the generated interfaces file by moving the DNS directives from the lo interface to the physical interface.
Also, it sets a systemd service that invokes the script at the right moment — after cloud-init-local.service writes the network file and before networking.service brings up the interfaces.
The script can also be invoked directly at package install time to fix already-running VMs without requiring a reboot.
I tried to do it as innocuous as possible.
Here's the repo. I hope you find it useful.
Best regards
Zeke
When I set
--nameserverand--searchdomainto a VM, it will render to loopback interface in/etc/network/interfaces.d/50-cloud-init
This is the cause that also prevents systemd-resolved from working with cloud-init on Debian 13, at least when assuming ifupdown being used for VM network configuration (the default, and also used on our own images).
In the helper ifupdown script located at /etc/network/if-up.d/resolved, there's a special exemption for the lo interface, which prevents any dns-nameservers for that interface to become effective.
During my investigation, I noticed that /usr/share/doc/cloud-init/examples/network-config-v1-nameserver.yaml uses this notation to explicitly bind the generated dns-nameserver configuration to a named interface:
Code:
network:
version: 1
config:
- type: physical
name: interface0
mac_address: '00:11:22:33:44:55'
subnets:
- type: static
address: 192.168.23.14/27
gateway: 192.168.23.1
- type: nameserver
interface: interface0 # Ties nameserver to interface0 only ## <<< THIS HERE ##
address:
- 192.168.23.2
- 8.8.8.8
search:
- exemplaryI am not yet sure where in PVE this should be rectified, if at all. I guess it depends if there's cloud-init versions out there that break existing configs if the cloud-init drive's network config -type: nameserver stanza contains a interface: some_value key...
Last edited:
OK, so I came up with this brief patch against PVE/QemuServer/Cloudinit.pm:
Code:
diff --git a/src/PVE/QemuServer/Cloudinit.pm b/src/PVE/QemuServer/Cloudinit.pm
index c1311da8..b3d2e9e2 100644
--- a/src/PVE/QemuServer/Cloudinit.pm
+++ b/src/PVE/QemuServer/Cloudinit.pm
@@ -564,6 +564,10 @@ sub nocloud_network {
my ($searchdomains, $nameservers) = get_dns_conf($conf);
if ($searchdomains || $nameservers) {
$content .= "${i}- type: nameserver\n";
+ if (defined(my $first_non_lo_iface = (sort { $a lt $b } @ifaces)[0])) {
+ (my $first_iface_idx = $first_non_lo_iface) =~ s/^net//;
+ $content .= "${i} interface: eth${first_iface_idx}\n";
+ }
if (defined($nameservers) && @$nameservers) {
$content .= "${i} address:\n";
$content .= "${i} - '$_'\n" foreach @$nameservers;... which, after restarting pvedaemon.service on the PVE node, generates YAML on the cidata drive as expected, and structurally equivalent to the Debian-provided cloud-init example as mentioned before - let's take another look at it for good measure:
Code:
network:
version: 1
config:
- type: physical
name: interface0
mac_address: '00:11:22:33:44:55'
subnets:
- type: static
address: 192.168.23.14/27
gateway: 192.168.23.1
- type: nameserver
interface: interface0 # Ties nameserver to interface0 only
address:
- 192.168.23.2
- 8.8.8.8
search:
- exemplaryThe equivalent of these settings passed in via PVE's cloud-init support will result in this file and content on cidata ISO fs (I also chose to configure IPv6 via DHCPv6, fwiw):
Code:
$ cat /media/cdrom0/network-config
version: 1
config:
- type: physical
name: eth0
mac_address: 'bc:24:11:11:22:33'
subnets:
- type: static
address: '192.168.23.14/27'
gateway: '192.168.23.1'
- type: dhcp6
- type: nameserver
interface: eth0
address:
- '192.168.23.2'
- '8.8.8.8'
search:
- 'exemplary'... but when cloud-init on a Debian 13 host is tasked with rendering its "eni" stuff, THIS JUNK is what comes out as soon as an "interface" key with a valid interface value is present in the resulting dict:
Code:
$ cat /etc/network/interfaces.d/50-cloud-init
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.23.13/24
gateway 192.168.23.1
dns {'nameservers': ['8.8.8.8', '192.168.23.3'], 'search': ['exemplary']}
# control-alias eth0
iface eth0 inet6 dhcp... which, afaiui, suggests a bug in the eni renderer of cloud-init as provided by Debian 13.
My disappointment is immeasurable and my day is ruined.
Here I generated this /etc/network/interfaces.d/50-cloud-init script to workaround this ridiculous issue when setting static IP in cloud-init for a debian 13 guest vm, while not touching the setup when configured DHCP:
Bash:
#!/bin/sh
CFG=/etc/network/interfaces.d/50-cloud-init
[ -f "$CFG" ] || exit 0
# Skip DHCP configurations
grep -q "iface .* inet dhcp" "$CFG" && exit 0
DNS=$(awk '/dns-nameservers/ {for(i=2;i<=NF;i++) print $i}' "$CFG")
SEARCH=$(awk '/dns-search/ {print $2}' "$CFG")
[ -n "$DNS" ] || exit 0
{
echo "# Generated from cloud-init network config"
[ -n "$SEARCH" ] && echo "search $SEARCH"
for ns in $DNS; do
echo "nameserver $ns"
done
} > /etc/resolv.conf此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。