
Ausführen des Debian 10 Buster-Image (erstellt mit build-openstack-debian-image --release buster
) mit Cloud-Init-Image, erstellt von cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml
.
Das Problem besteht darin, dass der Bootvorgang durch das Warten auf DHCP verzögert wird, obwohl ich eine gültige Netzwerkkonfiguration habe und diese nach dieser Verzögerung angewendet wird.
[ 3.619937] cloud-init[210]: Cloud-init v. 20.2 running 'init-local' at Sun, 10 Jan 2021 10:50:20 +0000. Up 3.40 seconds.
[ OK ] Started Initial cloud-init job (pre-networking).
[ OK ] Reached target Network (Pre).
Starting Raise network interfaces...
[ OK ] Started ifup for eth0.
[ *] A start job is running for Raise network interfaces (35s / 5min 1s)
Was kann ich tun, um diese Verzögerung zu umgehen?
Bei Bedarf kann ich weitere Informationen bereitstellen. Danke.
# systemd-analyze blame
1min 2.639s networking.service
951ms cloud-init-local.service
773ms cloud-init.service
657ms cloud-final.service
540ms cloud-config.service
421ms dev-vda1.device
310ms ifupdown-pre.service
Mein network-config-v2.yaml
:
version: 2
renderer: networkd
ethernets:
eth0:
match:
name: e*
addresses:
- private.ipv4/24
- public.ipv4/32
- ipv6/64
gateway4: private.ipv4
routes:
- to: 0.0.0.0/0
via: private.ipv4
gateway6: ipv6
nameservers:
addresses:
- ipv4
- ipv6
search: [domain.com]
Antwort1
Tolle Hinweise von @zany
In meinem Fall habe ich versucht, ein generisches Debian 11-Cloud-Image mit Cloud-Init und einer statischen IP auf meinem KVM-Host zu konfigurieren (unter Verwendung des Terraform-Anbieters dmacvicar libvirt).
Meine Netzwerkkonfigurationsdatei war:
version: 2
ethernets:
ens3:
dhcp4: false
addresses: [10.1.0.100]
gateway4: 10.1.0.1
nameservers:
addresses: [10.1.0.1 1.1.1.1]
search: [home.lab]
Dann war ich überrascht, dass die Schnittstelle während der VM-Erstellung eine DHCP-Lease anforderte ( journalctl
ist dein Freund)VorDie Cloud-Init-Konfiguration würde tatsächlich eingreifen und die Schnittstelle gemäß meinen statischen Einstellungen konfigurieren (genau wie im OP beschrieben).
Nach ungefähr einer Minute gab der „mysteriöse“ dhclient das Warten auf ein Angebot auf (was zu erwarten war, da DHCP in meinem libvirt-Netzwerk deaktiviert ist) und lief dann im Hintergrund weiter. Dann wird die Startsequenz fortgesetzt und gestartet cloud-init
, wobei die korrekte statische Konfiguration in . gerendert wird /etc/network/interfaces.d/50-cloud-init.cfg
. An diesem Punkt erhält die Schnittstelle die erwartete statische IP ( ip address show
beweist das, und Sie können Dinge auch per IP anpingen), die DNS-Auflösung bleibt jedoch unterbrochen. Ich vermute, das ist eine Nebenwirkung des dhclient-Fiaskos.
Nach einigem Suchen stellt sich heraus /etc/network/interfaces
, dass die Datei neben der Quelle source-directory /etc/network/interfaces.d
auch das zusätzliche Verzeichnis enthält /run/network/interfaces.d/
. Zu meiner Überraschung /run
enthält dieses Verzeichnis eine Schnittstellendefinition für ens3
den Ort, an dem es im Modus konfiguriert wird dhcp
!
Nachdem ich nun wusste, woher die unerwartete DHCP-Anforderung kam, musste ich sie deaktivieren, da sie mit den korrekten Einstellungen in in Konflikt stand /etc/network/interfaces.d/50-cloud-init.cfg
.
Leider wird die anfängliche DHCP-Anforderung deaktiviert, bevor Cloud-Init einsetzt. Es gibt also wirklich keine einfache Möglichkeit zu verhindern, dass der DHCP-Client eine kostbare Minute oder so damit vergeudet, ein Angebot zu erhalten, das nie kommen wird.
Was ich jedoch erreichen konnte, war die Reparatur der DNS-Auflösung durch die Verwendung des folgenden bootcmd:
Blocks in meinemuser-data
bootcmd:
- cloud-init-per once down ifdown ens3
- cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
- cloud-init-per once up ifup ens3
In den obigen Befehlen schalte ich die Schnittstelle ab, wodurch der inaktive Dhclient-Prozess gestoppt wird. Anschließend entferne ich die Schnittstellendefinitionsdatei, die den ens3
DHCP-Modus zunächst einstellt. Abschließend schalte ich die ens3
Schnittstelle wieder an, wodurch die Einstellungen /etc/network/interfaces.d/50-cloud-init.cfg
sofort angewendet werden.
Damit konnten die nachfolgenden Cloud-Init-Phasen im ersten Startvorgang das Internet nun vollständig über den Namen erreichen. Dies war entscheidend für den packages:
Erfolg der späteren Phasen, wie z. B. der Blockierung, da DNS funktionieren musste, um den Namen des Apt-Repo-Servers aufzulösen.
Hier ist der ausführlichere user-data
Auszug:
bootcmd:
- cloud-init-per once ifdown ifdown ens3
- cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
- cloud-init-per once ifup ifup ens3
packages:
- qemu-guest-agent
- locales-all
package_update: true
package_upgrade: true
package_reboot_if_required: true
runcmd:
- [ systemctl, start, qemu-guest-agent ]
final_message: "The system is finally up, after $UPTIME seconds"
Obwohl ich kein Debian10 verwende, kam mir das Problem so bekannt vor, dass ich meine Erfahrungen mit Ihnen teilen wollte, falls Sie bei neueren Versionen auf dieses Problem stoßen.
Verweise:
- https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration
- https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
- https://cloudinit.readthedocs.io/en/latest/topics/modules.html#bootcmd
- https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
- https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-genericcloud-amd64.qcow2
Antwort2
Ich bin auf das Beispielproblem gestoßen: Die Verwendung einer statischen Netzwerkkonfiguration (NoCloud-Provider-Metadaten-ENI oder Netzwerkkonfiguration v1/v2) deaktiviert den DHCP-Client nicht.
Es scheint, dass eine Netzwerkkonfiguration aus einer Vorlage ( /etc/network/cloud-interfaces-template
) angewendet wird, bevor die Cloud-Init-Konfiguration geschrieben wird.
auto $INTERFACE
allow-hotplug $INTERFACE
iface $INTERFACE inet dhcp
Sie können testen, ob diese Vorlage der Übeltäter ist, indem Sie das Cloud-Image vor dem ersten Start ändern:
(Patchen des Images, da das Ändern der Netzwerkkonfiguration beispielsweise bootcmd
zu spät ist.)
qemu-nbd --connect=/dev/nbd0 /tmp/debian-10-genericcloud-amd64-20210208-542.qcow2
fdisk /dev/nbd0 -l
mkdir /tmp/nbd
mount /dev/nbd0p1 /tmp/nbd
sed -i 's/dhcp/manual/' /tmp/nbd/etc/network/cloud-interfaces-template
umount /tmp/nbd
rmdir /tmp/nbd
qemu-nbd --disconnect /dev/nbd0
Ich muss jedoch noch einen Weg finden, diese Änderung anzuwenden oder die Verwendung dieser Vorlage mit Cloud-Init zu verhindern.
Diese Vorlage scheint von bearbeitet zu werden /etc/network/cloud-ifupdown-helper
, sodass das Skript möglicherweise geändert oder beeinflusst werden könnte.
Antwort3
Ich hatte das gleiche Problem.
Es gibt eine bessere Möglichkeit, das Problem zu lösen: Stellen Sie das DHCP-Timeout einfach auf eine kürzere Zeit ein.
# virt-edit debian-10-generic-amd64.qcow2 /etc/dhcp/dhclient.conf
timeout 15;
Dann kann dieses Image in einer NoCloud-Umgebung oder einem DHCP-Netzwerk ordnungsgemäß funktionieren.
Antwort4
Die Antwort von agittins scheint die beste zu sein, aber in meinem Fall wurde der Cloud-Init-Befehl „bootcmd“ in der Benutzerdatendatei nach „75-cloud-ifupdown.rules“ von Debian verarbeitet. Daher musste ich diese Debian-Skripte im Disk-Image entfernen (zuerst VM-Speicher mounten, Skript löschen und dann unmounten):
sudo qemu-nbd --connect=/dev/nbd0 debian-11-genericcloud-arm64-backing.qcow2
sudo mount /dev/nbd0p1 /mnt
sudo rm -v /mnt/etc/udev/rules.d/75-cloud-ifupdown.rules
sudo rm -v /mnt/etc/network/cloud-ifupdown-helper
sudo rm -v /mnt/etc/network/cloud-interfaces-template
sudo umount /mnt