Schlagwort: proxmox

Proxmox LXC Container überschreibt /etc/resolv.conf

Wenn man auf Proxmox LXC Container betreibt, wird die /etc/resolv.conf immer wieder beim Neustart überschrieben. Das ist von Vorteil, damit die Einstellungen aus der GUI konsequent gesetzt werden. Allerdings fehlt dadurch die Möglichkeit auch mal keine search(domain) zu setzen. Bei einem leeren Feld werden die Einstellungen des Proxmox Hosts gezogen, und diese dürfen nicht leer sein.

Bei meinen unbound DNS Resolvern müssen diese aber leer sein, u.a. aus mehreren Gründen (dazu später mehr).

Die Lösung ist eine wenig dokumentiertes Proxmox Feature, bei welchem man in der VM bzw. im Container selbst eine „Ignore“-Datei anlegt.

sudo touch /etc/.pve-ignore.resolv.conf

sorgt dafür, dass die resolv.conf nicht mehr verändert wird. Das geht auch mit anderen Dateien, die normalerweise beim Reboot geschrieben werden.

P.S: Fast die Gründe vergessen, warum ein DNS Resolver (der wohlgemerkt das hier in der /etc/resolv.conf stehen hat)

nameserver 127.0.0.1

sich beim selbst befragen nicht auch noch auf eine search(domain) stürzen sollte:

  • fehlerhafte oder verlängerte DNS-Auflösungen
  • Query-Erweiterungen, die nicht gewollt sind
  • potenzielle NXDOMAIN-Fehler
  • Debugging-Aufwand bei internen Zonen

By the way, eigene Resolver helfen übrigens hervorragend, wenn man SPAM-Listen mit eigenen Mailservern befragen möchte. Happy Resolving 😉

Hinweis: Bei einigen Distributionen (z. B. Ubuntu-LXCs) oder bei aktiviertem DHCP/systemd-resolved kann Proxmox Standard-Konfiguration trotzdem erneut die resolv.conf überschreiben — selbst wenn die Datei /etc/.pve-ignore.resolv.conf existiert. In diesem Fall kann es notwendig sein, zusätzlich systemd-resolved zu deaktivieren oder einen dhclient-Hook zu nutzen, der das automatische Neuschreiben von /etc/resolv.conf verhindert.

Quellen: https://pve.proxmox.com/wiki/Linux_Container#_guest_operating_system_configuration

Run ESXi on Proxmox

Fortsetzung zum vorherigen Beitrag, in dem Proxmox Virtual Environment selbst auf seinem eigenen Hypervisor betrieben wird. Diesmal lassen wir VMWare ESXi auf dem Proxmox VE laufen, ebenfalls als Testumgebung.

Zu beachten ist, das die Virtualisierungs-Unterstützung der CPU wie im vorherigen Blog-Beitrag geschildert aktiviert werden muss, und der CPU Typ ebenfalls auf Host gesetzt werden muss.

Hier die Übersicht, wie die VM konfiguriert werden muss, damit sich ESXi installieren lässt:

  • General Tab
    • Leave Defaults
  • OS Tab
    • Guest OS -> Type: Linux
    • Guest OS -> Version: 6.x – 2.6 Kernel
  • System Tab
    • SCSI-Controller: VirtIO SCSI single (default) works, but better use VMware PVSCI
  • Disk Tab
    • Bus/Device: SATA (ESXi did not find any other Type!)
    • Disk size (GiB): 29 is absolut minimum vor OS Partition (otherwise Installation will fail with something like …. does not support OSDATA
  • CPU Tab
    • Sockets: 2
    • Cores: 2
    • Type: host
      (don’t now if there is a minimum, but 2 Cores on 2 Sockets worked)
  • Memory Tab
    • Memory (MiB): 4096 (required minimum)
  • Network Tab
    • Model: VMware VMXnet3 (ESXi did not find any other Type!)

This Setting worked pretty well for me, some other Blog-Posts recommended the following, which had no performance improvement in my case, but should not stay unmentioned :

  • System Tab
    • Machine: q35
  • Disk Tab
    • Discard: ☑️
    • SSD Emulation: ☑️
  • CPU Tab
    • Enable NUMA: ☑️

Nested Virtualization auf Proxmox

Manchmal möchte man auf einem Hypervisor eine weitere Virtualisierungs-Host (oder mehrere) aufsetzen, zum Beispiel für Labor und Testumgebungen. Damit das einigermaßen flott funktioniert, muss die Virtualisierungs-Unterstützung der CPU an die VM durchgereicht werden. Zuerst muss man den Support auf dem Physischen Hypervisor aktivieren.

Man verbindet sich mit Konsole oder der Proxmox Shell auf den Host direkt und führt folgendes Kommando für eine Intel CPU aus

cat /sys/module/kvm_intel/parameters/nested

oder

cat /sys/module/kvm_amd/parameters/nested

für eine AMD CPU. Wenn ein Y ausgegeben wird, ist die Unterstützung aktiv, falls nein kann man die Module wie folgt aktivieren:

Intel:

echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf

AMD:

echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf

Im Anschluss den Host neu starten und mit den Befehlen oben prüfen, ob ein Y raus kommt. Wenn ja geht es mit dem Anlegen der VM weiter.

Hier ist beim CPU Typ unbendingt Host auszuwählen.

Und bei den Options die KVM Hardware Virtualization.

In dieser VM kann dann wieder z.B. Proxmox VE installiert werden. Bei der Installation sollte dann auch keine Warnung auftauchen, das der KVM/VT Support der CPU nicht gegeben ist. Wenn die Installation abgeschlossen ist, kann man die erfolgreiche Umsetzung testen, indem man sich auf diese VM selbst verbindet und folgendes Kommando ausführt

egrep '(vmx|svm)' --color=always /proc/cpuinfo

Wenn hier Ergebnisse geliefert werden, läuft die Virtualisierungs-Unterstützung auch in der VM