lae.proxmox

Installiert und konfiguriert die Proxmox Virtual Environment 6.x/7.x/8.x auf Debian-Servern.

Diese Rolle ermöglicht es Ihnen, Einzelknoten-PVE-Installationen und PVE-Cluster (3+ Knoten) auf Debian Buster (10) und Bullseye (11) bereitzustellen und zu verwalten. Sie können Folgendes mit Unterstützung dieser Rolle konfigurieren:

• PVE RBAC-Definitionen (Rollen, Gruppen, Benutzer und Zugriffssteuerlisten)
• PVE-Speicherdefinitionen
• datacenter.cfg
• HTTPS-Zertifikate für die Proxmox-Web-GUI (Eigenbeschaffung)
• PVE-Repository-Auswahl (z.B. pve-no-subscription oder pve-enterprise)
• Watchdog-Module (IPMI und NMI) mit entsprechender pve-ha-manager-Konfiguration
• ZFS-Modul-Setup und ZED-Benachrichtigungs-E-Mail

Mit aktivierter Cluster-Funktionalität ermöglicht diese Rolle Folgendes:

• Sicherstellen, dass alle Hosts miteinander als Root über SSH verbinden können
• Initialisieren eines neuen PVE-Clusters (oder Sie können möglicherweise einen bestehenden übernehmen)
• Erstellen oder Hinzufügen neuer Knoten zu einem PVE-Cluster
• Ceph auf einem PVE-Cluster einrichten
• Hochverfügbarkeitsgruppen erstellen und verwalten

Unterstützung/Beitragen

Für Unterstützung oder wenn Sie zu dieser Rolle beitragen möchten, aber Anleitung wünschen, können Sie diesem Discord-Server beitreten: https://discord.gg/cjqr6Fg. Bitte beachten Sie, dass dies eine temporäre Einladung ist. Daher müssen Sie warten, bis @lae Ihnen eine Rolle zuweist. Andernfalls entfernt Discord Sie vom Server, wenn Sie sich abmelden.

Schnellstart

Das Hauptziel dieser Rolle ist es, einen Proxmox VE-Cluster (siehe Beispiel-Playbook) zu konfigurieren und zu verwalten. Diese Rolle kann jedoch auch verwendet werden, um schnell Einzelknoten-Proxmox-Server zu installieren.

Ich gehe davon aus, dass Sie Ansible installiert haben. Sie müssen einen externen Computer verwenden, um Proxmox zu installieren (hauptsächlich wegen des Neustarts während der Installation, obwohl ich dies für diesen Anwendungsfall später möglicherweise etwas anders handhabe).

Kopieren Sie das folgende Playbook in eine Datei wie install_proxmox.yml:

    - hosts: all
      become: True
      roles:
        - role: geerlingguy.ntp
          vars:
            ntp_manage_config: true
            ntp_servers:
              - clock.sjc.he.net,
              - clock.fmt.he.net,
              - clock.nyc.he.net
        - role: lae.proxmox
          vars:
            - pve_group: all
            - pve_reboot_on_kernel_update: true

Installieren Sie diese Rolle und eine Rolle zur Konfiguration von NTP:

    ansible-galaxy install lae.proxmox geerlingguy.ntp

Jetzt können Sie die Installation durchführen:

    ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER

Wenn Ihr SSH_USER ein Sudo-Passwort hat, geben Sie das Flag -K in den obigen Befehl ein. Wenn Sie sich auch mit Passwort an den Host authentifizieren müssen, anstatt mit Pubkey-Auth, geben Sie das Flag -k an (stellen Sie sicher, dass Sie sshpass ebenfalls installiert haben). Sie können diese Variablen vor dem Ausführen des Befehls setzen oder sie einfach ersetzen. Beachten Sie, dass das Komma wichtig ist, da eine Liste erwartet wird (ansonsten wird versucht, eine Datei mit einer Liste von Hosts zu finden).

Nach Abschluss sollten Sie in der Lage sein, auf Ihre Proxmox VE-Instanz unter https://$SSH_HOST_FQDN:8006 zuzugreifen.

Bereitstellung eines voll funktionsfähigen PVE 8.x-Clusters

Erstellen Sie ein neues Playbook-Verzeichnis. Wir nennen unseres lab-cluster. Unser Playbook wird schließlich so aussehen, aber Ihres muss nicht alle Schritte folgen:

lab-cluster/
├── files
│   └── pve01
│       ├── lab-node01.local.key
│       ├── lab-node01.local.pem
│       ├── lab-node02.local.key
│       ├── lab-node02.local.pem
│       ├── lab-node03.local.key
│       └── lab-node03.local.pem
├── group_vars
│   ├── all
│   └── pve01
├── inventory
├── roles
│   └── requirements.yml
├── site.yml
└── templates
    └── interfaces-pve01.j2

Das Erste, was Ihnen auffällt, ist, dass wir eine Reihe von .key- und .pem-Dateien haben. Dies sind private Schlüssel und SSL-Zertifikate, die diese Rolle verwendet, um die Webschnittstelle für Proxmox über alle Knoten zu konfigurieren. Diese sind nicht notwendig, wenn Sie weiterhin die von der CA signierten Zertifikate verwenden möchten, die Proxmox intern einrichtet. Typischerweise können Sie Ansible Vault verwenden, um die privaten Schlüssel zu verschlüsseln, z.B.:

    ansible-vault encrypt files/pve01/*.key

Das würde erfordern, dass Sie das Vault-Passwort beim Ausführen des Playbooks angeben.

Lassen Sie uns zunächst unsere Cluster-Hosts festlegen. Unsere Datei inventory könnte so aussehen:

[pve01]
lab-node01.local
lab-node02.local
lab-node03.local

Sie können mehrere Cluster haben, daher ist es eine gute Idee, eine Gruppe für jeden Cluster zu haben. Lassen Sie uns nun unsere Rollenanforderungen in roles/requirements.yml festlegen:

---
- src: geerlingguy.ntp
- src: lae.proxmox

Wir benötigen eine NTP-Rolle, um NTP zu konfigurieren, also verwenden wir die Rolle von Jeff Geerling dafür. Sie würden das nicht benötigen, wenn Sie NTP bereits konfiguriert haben oder eine andere Methode zur Konfiguration von NTP haben.

Jetzt lassen Sie uns einige Gruppenvariablen festlegen. Zuerst erstellen wir group_vars/all, um NTP-bezogene Variablen festzulegen:

---
ntp_manage_config: true
ntp_servers:
  - lab-ntp01.local iburst
  - lab-ntp02.local iburst

Natürlich ersetzen Sie diese NTP-Server mit denen Ihrer Wahl.

Jetzt zum Inhalt Ihres Playbooks, den Gruppenvariablen von pve01. Erstellen Sie eine Datei group_vars/pve01, fügen Sie Folgendes hinzu und passen Sie es entsprechend Ihrer Umgebung an.

---
pve_group: pve01
pve_watchdog: ipmi
pve_ssl_private_key: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.key') }}"
pve_ssl_certificate: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.pem') }}"
pve_cluster_enabled: yes
pve_groups:
  - name: ops
    comment: Operations Team
pve_users:
  - name: admin1@pam
    email: [email protected]
    firstname: Admin
    lastname: User 1
    groups: ["ops"]
  - name: admin2@pam
    email: [email protected]
    firstname: Admin
    lastname: User 2
    groups: ["ops"]
pve_acls:
  - path: /
    roles: ["Administrator"]
    groups: ["ops"]
pve_storages:
  - name: localdir
    type: dir
    content: ["images", "iso", "backup"]
    path: /plop
    maxfiles: 4
pve_ssh_port: 22

interfaces_template: "interfaces-{{ pve_group }}.j2"

pve_group ist auf den Gruppennamen unseres Clusters, pve01, gesetzt – er wird verwendet, um sicherzustellen, dass alle Hosts in dieser Gruppe miteinander kommunizieren und gruppiert sind. Beachten Sie, dass der PVE-Clustername ebenfalls auf diesen Gruppennamen gesetzt wird, sofern nicht anders durch pve_cluster_clustername angegeben. Wenn Sie dies undefiniert lassen, wird standardmäßig proxmox verwendet.

pve_watchdog hier aktiviert die Unterstützung für IPMI Watchdog und konfiguriert den HA-Manager von PVE, ihn zu verwenden. Lassen Sie dies undefiniert, wenn Sie es nicht konfigurieren möchten.

pve_ssl_private_key und pve_ssl_certificate zeigen auf die SSL-Zertifikate für den pvecluster. Hier wird ein Dateilookup verwendet, um den Inhalt einer Datei im Playbook zu lesen, z.B. files/pve01/lab-node01.key. Sie könnten möglicherweise einfach Hostvariablen anstelle von Dateien verwenden, wenn Sie es vorziehen.

pve_cluster_enabled ermöglicht der Rolle, alle Cluster-Management-Aufgaben durchzuführen. Dazu gehört das Erstellen eines Clusters, wenn keiner vorhanden ist, oder das Hinzufügen von Knoten zu einem bestehenden Cluster. Es gibt Überprüfungen, um sicherzustellen, dass Sie keine Knoten mischen, die bereits in anderen Clustern mit unterschiedlichen Namen sind.

pve_groups, pve_users und pve_acls autorisieren einige lokale UNIX-Benutzer (die bereits existieren müssen), auf PVE zuzugreifen und geben ihnen die Rolle Administrator als Teil der Gruppe ops. Lesen Sie den Abschnitt Benutzer- und ACL-Verwaltung für weitere Informationen.

pve_storages ermöglicht die Erstellung verschiedener Speicherarten und deren Konfiguration. Der Backend muss von Proxmox unterstützt werden. Lesen Sie den Abschnitt Speicherverwaltung für weitere Informationen.

pve_ssh_port ermöglicht es Ihnen, den SSH-Port zu ändern. Wenn Ihre SSH-Installation an einem anderen Port als dem Standardport 22 lauscht, setzen Sie diese Variable bitte. Wenn ein neuer Knoten dem Cluster beitritt, muss der PVE-Cluster einmal über SSH kommunizieren.

pve_manage_ssh (Standardmäßig auf true) ermöglicht es Ihnen, Änderungen zu deaktivieren, die dieses Modul an der SSH-Serverkonfiguration vornehmen würde. Dies ist nützlich, wenn Sie eine andere Rolle zur Verwaltung Ihres SSH-Servers verwenden. Beachten Sie, dass die Einstellung auf false nicht offiziell unterstützt wird; Sie sind dafür verantwortlich, die Änderungen zu replizieren, die normalerweise in ssh_cluster_config.yml und pve_add_node.yml vorgenommen werden.

interfaces_template ist auf den Pfad einer Vorlage gesetzt, die wir zur Konfiguration des Netzwerks auf diesen Debian-Maschinen verwenden. Dies ist nur notwendig, wenn Sie das Netzwerk über Ansible verwalten möchten und nicht manuell oder über jeden Host in PVE. Sie sollten sich wahrscheinlich mit Ansible vertraut machen, bevor Sie dies tun, da Ihre Methode möglicherweise das Setzen von Hostvariablen für die IP-Adressen jedes Hosts usw. beinhaltet.

Lassen Sie uns diese Schnittstellentemplate-Datei schnell erledigen. Fühlen Sie sich frei, diese Datei zu überspringen (und in group_vars/pve01 undefiniert zu lassen). Hier ist eine, die ich verwende:

# {{ ansible_managed }}
auto lo
iface lo inet loopback

allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet static
    address {{ lookup('dig', ansible_fqdn) }}
    gateway 10.4.0.1
    netmask 255.255.255.0
    bridge_ports enp2s0f0
    bridge_stp off
    bridge_fd 0

allow-hotplug enp2s0f1
auto enp2s0f1
iface enp2s0f1 inet static
    address {{ lookup('dig', ansible_hostname + "-clusternet.local") }}
    netmask 255.255.255.0

Möglicherweise sind Sie mit der dig-Abfrage nicht vertraut, aber hier führen wir im Grunde eine A-Record-Abfrage für jede Maschine durch (z.B. lab-node01.local) für die erste Schnittstelle (und konfigurieren sie als Brücke, die wir für VM-Schnittstellen verwenden), und dann eine weitere leicht modifizierte Abfrage für das "Clustering"-Netzwerk, das wir möglicherweise für Ceph verwenden ("lab-node01-clusternet.local"). Natürlich könnte Ihrer ganz anders aussehen, insbesondere wenn Sie Bonding, drei verschiedene Netzwerke für Verwaltung/Corosync, Speicherung und VM-Verkehr usw. verwenden.

Schließlich lassen Sie uns unser Playbook schreiben. site.yml könnte ungefähr so aussehen:

---
- hosts: all
  become: True
  roles:
    - geerlingguy.ntp

# Lassen Sie dies weg, wenn Sie das Netzwerk nicht über Ansible ändern
- hosts: pve01
  become: True
  serial: 1
  tasks:
    - name: Install bridge-utils
      apt:
        name: bridge-utils

    - name: Konfigurieren von /etc/network/interfaces
      template:
        src: "{{ interfaces_template }}"
        dest: /etc/network/interfaces
      register: _configure_interfaces

    - block:
      - name: Neustart für Netzwerkänderungen
        shell: "sleep 5 && shutdown -r now 'Netzwerkänderungen gefunden, Neustart'"
        async: 1
        poll: 0

      - name: Warten, bis der Server wieder online ist
        wait_for_connection:
          delay: 15
      when: _configure_interfaces is changed

- hosts: pve01
  become: True
  roles:
    - lae.proxmox

Im Grunde führen wir die NTP-Rolle über alle Hosts aus (Sie möchten möglicherweise einige Nicht-Proxmox-Maschinen hinzufügen), konfigurieren das Netzwerk auf pve01 mit unserem separaten Cluster-Netzwerk und Brückenlayout, starten den Server neu, damit diese Änderungen wirksam werden, und führen dann diese Proxmox-Rolle auf den Hosts aus, um ein Cluster einzurichten.

An diesem Punkt ist unser Playbook bereit und wir können es ausführen.

Stellen Sie sicher, dass Rollen und Abhängigkeiten installiert sind:

    ansible-galaxy install -r roles/requirements.yml --force
    pip install jmespath dnspython

jmespath wird für einige der Aufgaben, die mit Clustering zu tun haben, benötigt. dnspython wird nur benötigt, wenn Sie eine dig-Abfrage verwenden, die Sie wahrscheinlich nicht verwenden werden, wenn Sie die Netzwerk-Konfiguration übersprungen haben. Wir geben --force an ansible-galaxy weiter, damit die Rollen auf die neuesten Versionen aktualisiert werden, wenn sie bereits installiert sind.

Jetzt führen Sie das Playbook aus:

    ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'

Das -e '{"pve_reboot_on_kernel_update": true}' sollte hauptsächlich beim ersten Setup des Proxmox-Clusters ausgeführt werden, da es den Server neu startet, um in einen PVE-Kernel zu booten. Bei späteren Ausführungen sollte dies weggelassen werden, da Sie die Server sequentiell neu starten möchten, nachdem der Cluster läuft.

Um einen bestimmten Benutzer anzugeben, verwenden Sie -u root (ersetzen Sie root), und wenn Sie Passwörter angeben müssen, verwenden Sie -k für SSH-Passwort und/oder -K für Sudo-Passwort. Zum Beispiel:

    ansible-playbook -i inventory site.yml -K -u admin1

Dies wird nach einem Sudo-Passwort fragen, dann sich mit dem Benutzer admin1 (unter Verwendung von Public-Key-Auth – fügen Sie -k für das Passwort hinzu) anmelden und das Playbook ausführen.

Das war's! Sie sollten jetzt einen vollständig bereitgestellten Proxmox-Cluster haben. Möglicherweise möchten Sie danach Ceph-Speicher darauf erstellen (siehe Ceph für weitere Informationen) und andere Aufgaben möglicherweise, aber der schwierige Teil ist größtenteils abgeschlossen.

Beispiel-Playbook

Dies konfiguriert Hosts in der Gruppe pve01 als einen Cluster und startet die Maschinen neu, wenn der Kernel aktualisiert wurde. (Es wird nur empfohlen, dieses Flag während der Installation zu setzen - Neustarts im Betrieb sollten während eines Wartungszeitraums nacheinander erfolgen.) Es wird auch den IPMI-Watchdog aktivieren.

    - hosts: pve01
      become: True
      roles:
        - role: geerlingguy.ntp
            ntp_manage_config: true
            ntp_servers:
              - clock.sjc.he.net,
              - clock.fmt.he.net,
              - clock.nyc.he.net
        - role: lae.proxmox
            pve_group: pve01
            pve_cluster_enabled: yes
            pve_reboot_on_kernel_update: true
            pve_watchdog: ipmi

Rollenvariablen

[variable]: [default] #[Beschreibung/Zweck]
pve_group: proxmox # Hostgruppe, die die Proxmox-Hosts zusammenfassen soll
pve_repository_line: "deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription" # apt-repository-Konfiguration - ändern Sie zu enterprise, wenn nötig (obwohl TODO möglicherweise eine weitere Konfiguration erforderlich ist)
pve_remove_subscription_warning: true # behebt die Abonnement-Warnmeldungen in Proxmox, wenn Sie die Community-Edition verwenden
pve_extra_packages: [] # Alle zusätzlichen Pakete, die Sie installieren möchten, z.B. ngrep
pve_run_system_upgrades: false # Lassen Sie die Rolle System-Upgrades durchführen
pve_run_proxmox_upgrades: true # Lassen Sie die Rolle Proxmox VE-Upgrades durchführen
pve_check_for_kernel_update: true # Führt ein Skript auf dem Host aus, um Kernelversionen zu überprüfen
pve_reboot_on_kernel_update: false # Wenn auf true gesetzt, wird die Maschine bei Kernel-Updates automatisch neu gestartet
pve_reboot_on_kernel_update_delay: 60 # Anzahl von Sekunden, die vor und nach dem Neustartprozess gewartet werden soll, um mit der nächsten Aufgabe im Cluster-Modus fortzufahren
pve_remove_old_kernels: true # Entfernt derzeit den Kernel aus dem Haupt-Debian-Repository
pve_pcie_passthrough_enabled: false # Setzen Sie dies auf true, um PCIe-Passthrough zu aktivieren.
pve_iommu_passthrough_mode: false # Setzen Sie dies auf true, um VMs zu erlauben, die DMA-Übersetzung zu umgehen. Dies könnte die Leistung für IOMMU-Passthrough erhöhen.
pve_iommu_unsafe_interrupts: false # Setzen Sie dies auf true, wenn Ihr System keine Interrupt-Zuordnung unterstützt.
pve_mediated_devices_enabled: false # Setzen Sie dies auf true, wenn Ihr Gerät gtv-g unterstützt und Sie eine geteilte Funktionalität aktivieren möchten.
pve_pcie_ovmf_enabled: false # Setzen Sie dies auf true, um GPU OVMF PCI-Passthrough zu aktivieren.
pve_pci_device_ids: [] # Liste der PCI-Geräte-IDs (siehe https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # Liste der Gerätetreiber, die vom Proxmox-Host ausgeschlossen werden sollen (siehe https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Setzen Sie dies auf true, wenn die Durchleitung an ein Windows-Gerät erfolgt, um das VM-Abstürzen zu verhindern.
pve_pcie_report_msrs: true # Setzen Sie dies auf false, um das Protokollieren von msrs-Absturzberichten im dmesg-System zu verhindern.
pve_watchdog: none # Setzen Sie dies auf "ipmi", wenn Sie ein Hardware-Watchdog konfigurieren möchten. Proxmox verwendet standardmäßig ein Software-Watchdog (nmi_watchdog).
pve_watchdog_ipmi_action: power_cycle # Kann einer von "reset", "power_cycle" und "power_off" sein.
pve_watchdog_ipmi_timeout: 10 # Anzahl der Sekunden, die der Watchdog warten soll
pve_zfs_enabled: no # Gibt an, ob ZFS-Pakete installiert und konfiguriert werden sollen
# pve_zfs_options: "" # modprobe-Parameter, die an das zfs-Modul beim Booten/modprobe übergeben werden sollen
# pve_zfs_zed_email: "" # Sollte auf eine E-Mail gesetzt werden, um ZFS-Benachrichtigungen zu erhalten
pve_zfs_create_volumes: [] # Liste der ZFS-Volumes, die erstellt werden sollen (zur Verwendung als PVE-Speicher). Siehe Abschnitt zur Speicherverwaltung.
pve_ceph_enabled: false # Gibt an, ob Ceph-Pakete installiert und konfiguriert werden sollen. Siehe unten für ein Beispiel.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bullseye main" # apt-repository-Konfiguration. Wird automatisch für 6.x und 7.x eingestellt (weitere Informationen: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Ceph-Öffentliches Netzwerk
# pve_ceph_cluster_network: "" # Optional, wenn das Ceph-Cluster-Netzwerk anders ist als das öffentliche Netzwerk (siehe https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Hostgruppe mit allen Ceph-Knoten
pve_ceph_mon_group: "{{ pve_group }}" # Hostgruppe mit allen Ceph-Monitor-Hosts
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Hostgruppe mit allen Ceph-Manager-Hosts
pve_ceph_mds_group: "{{ pve_group }}" # Hostgruppe mit allen Ceph-Metadaten-Server-Hosts
pve_ceph_osds: [] # Liste der OSD-Datenträger
pve_ceph_pools: [] # Liste der Pools, die erstellt werden sollen
pve_ceph_fs: [] # Liste der CephFS-Dateisysteme, die erstellt werden sollen
pve_ceph_crush_rules: [] # Liste der CRUSH-Regeln, die erstellt werden sollen
# pve_ssl_private_key: "" # Sollte auf den Inhalt des privaten Schlüssels gesetzt werden, der für HTTPS verwendet werden soll
# pve_ssl_certificate: "" # Sollte auf den Inhalt des Zertifikats gesetzt werden, das für HTTPS verwendet werden soll
pve_roles: [] # Weitere Rollen mit spezifischen Berechtigungen hinzufügen. Siehe Abschnitt zur Benutzerverwaltung.
pve_groups: [] # Liste der Gruppendefinitionen, die in PVE verwaltet werden sollen. Siehe Abschnitt zur Benutzerverwaltung.
pve_users: [] # Liste der Benutzerdokumentationen, die in PVE verwaltet werden sollen. Siehe Abschnitt zur Benutzerverwaltung.
pve_storages: [] # Liste der Speichersysteme, die in PVE verwaltet werden sollen. Siehe Abschnitt zur Speicherverwaltung.
pve_datacenter_cfg: {} # Dictionary zur Konfiguration der PVE datacenter.cfg-Konfigurationsdatei.
pve_domains_cfg: [] # Liste der Realms zur Verwendung als Authentifizierungsquellen in der PVE domains.cfg-Konfigurationsdatei.
pve_no_log: false # Setzen Sie dies in der Produktion auf true, um zu verhindern, dass Speicheranmeldeinformationen in Laufprotokollen veröffentlicht werden. (Kann in anderen Aufgaben in Zukunft verwendet werden)

Um das Clustering mit dieser Rolle zu aktivieren, konfigurieren Sie die folgenden Variablen entsprechend:

pve_cluster_enabled: no # Setzen Sie dies auf yes, um Hosts zu konfigurieren, die zusammen gruppiert werden sollen
pve_cluster_clustername: "{{ pve_group }}" # Sollte auf den Namen des PVE-Clusters gesetzt werden
pve_manage_hosts_enabled : yes # Setzen Sie dies auf no, um die Konfigurationsdatei hosts NICHT zu konfigurieren (Fall, dass VPN verwendet wird und die hosts-Datei bereits konfiguriert ist)

Die folgenden Variablen werden verwendet, um Netzwerk-Informationen an corosync bereitzustellen. Diese sind bekannt als ring0_addr/ring1_addr oder link0_addr/link1_addr, abhängig von der PVE-Version. Sie должныIPv4 oder IPv6-Adressen sein. Sie können auch die Priorität dieser Schnittstellen konfigurieren, um Corosync zu veranlassen, welche Schnittstelle den Clusterverkehr verarbeiten soll (niedrigere Zahlen bedeuten höhere Priorität). Für weitere Informationen siehe das Cluster-Manager-Kapitel in der PVE-Dokumentation.

# pve_cluster_addr0: "{{ defaults to the default interface ipv4 or ipv6 if detected }}"
# pve_cluster_addr1: "IP-Adresse oder Hostname einer anderen Schnittstelle"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0

Sie können Optionen in der Konfigurationsdatei datacenter.cfg festlegen:

pve_datacenter_cfg:
  keyboard: en-us

Sie können auch HA-Managergruppen konfigurieren:

pve_cluster_ha_groups: [] # Liste der HA-Gruppen, die in PVE erstellt werden sollen.

Dieses Beispiel erstellt eine Gruppe „lab_node01“ für Ressourcen, die dem Host lab-node01 zugewiesen sind:

pve_cluster_ha_groups:
  - name: lab_node01
    comment: "Meine HA-Gruppe"
    nodes: "lab-node01"
    nofailback: 0
    restricted: 0

Alle Konfigurationsoptionen, die in der Datei datacenter.cfg unterstützt werden, sind im Proxmox-Handbuch zum Abschnitt datacenter.cfg dokumentiert.

Damit das Live-Neuladen von Netzwerkschnittstellen über die PVE-Web-Oberfläche funktioniert, müssen Sie das Paket ifupdown2 installieren. Beachten Sie, dass dies ifupdown entfernt. Sie können dies mit der Rollenvariablen pve_extra_packages angeben.

Sie können Realms/Domänen als Authentifizierungsquellen in der Konfigurationsdatei domains.cfg konfigurieren. Wenn diese Datei nicht vorhanden ist, sind nur die Realms „Linux PAM“ und „Proxmox VE-Authentifizierungsserver“ verfügbar. Unterstützte Typen sind pam, pve, ad und ldap. Es ist möglich, Benutzer und Gruppen automatisch für LDAP-basierte Realms (LDAP & Microsoft Active Directory) mit sync: true zu synchronisieren. Ein Realm sollte die default: 1-Eigenschaft haben, um ihn als Standard zu kennzeichnen:

pve_domains_cfg:
  - name: pam
    type: pam
    attributes:
      comment: Linux PAM standard authentication
  - name: pve
    type: pve
    attributes:
      comment: Proxmox VE authentication server
  - name: ad
    type: ad
    attributes:
      comment: Active Directory authentication
      domain: yourdomain.com
      server1: dc01.yourdomain.com
      default: 1
      secure: 1
      server2: dc02.yourdomain.com
  - name: ldap
    type: ldap
    sync: true
    attributes:
      comment: LDAP authentication
      base_dn: CN=Users,dc=yourdomain,dc=com
      bind_dn: "uid=svc-reader,CN=Users,dc=yourdomain,dc=com"
      bind_password: "{{ secret_ldap_svc_reader_password }}"
      server1: ldap1.yourdomain.com
      user_attr: uid
      secure: 1
      server2: ldap2.yourdomain.com

Abhängigkeiten

Diese Rolle installiert NTP nicht, daher sollten Sie NTP selbst konfigurieren, z.B. mit der Rolle geerlingguy.ntp, wie im Beispiel-Playbook gezeigt.

Wenn das Clustering aktiviert ist, nutzt diese Rolle den Filter json_query, für den die Bibliothek jmespath auf Ihrem Steuerhost installiert sein muss. Sie können entweder pip install jmespath ausführen oder es über den Paketmanager Ihrer Distribution installieren, z.B. apt-get install python-jmespath.

Benutzer- und ACL-Verwaltung

Sie können diese Rolle verwenden, um Benutzer und Gruppen innerhalb von Proxmox VE (sowohl in Einzelserver- als auch in Clusterbereitstellungen) zu verwalten. Hier sind einige Beispiele.

pve_groups:
  - name: Admins
    comment: Administratoren dieses PVE-Clusters
  - name: api_users
  - name: test_users
pve_users:
  - name: root@pam
    email: [email protected]
  - name: lae@pam
    email: [email protected]
    firstname: Musee
    lastname: Ullah
    groups: [ "Admins" ]
  - name: pveapi@pve
    password: "Proxmox789"
    groups:
      - api_users
  - name: testapi@pve
    password: "Test456"
    enable: no
    groups:
      - api_users
      - test_users
  - name: tempuser@pam
    expire: 1514793600
    groups: [ "test_users" ]
    comment: "Temporärer Benutzer, der am 1. Januar 2018 abläuft"
    email: [email protected]
    firstname: Test
    lastname: User

Verweisen Sie auf library/proxmox_user.py link und library/proxmox_group.py link für die Moduldokumentation.

Für die Verwaltung von Rollen und ACLs wird ein ähnliches Modul verwendet, jedoch sind die meisten Parameter nur Listen akzeptabel (Änderungen vorbehalten):

pve_roles:
  - name: Monitoring
    privileges:
      - "Sys.Modify"
      - "Sys.Audit"
      - "Datastore.Audit"
      - "VM.Monitor"
      - "VM.Audit"
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "Admins" ]
  - path: /pools/testpool
    roles: [ "PVEAdmin" ]
    users:
      - pveapi@pve
    groups:
      - test_users

Verweisen Sie auf library/proxmox_role.py link und library/proxmox_acl.py link für die Moduldokumentation.

Speicherverwaltung

Sie können diese Rolle nutzen, um Speicher innerhalb von Proxmox VE (sowohl in Einzelserver- als auch in Clusterbereitstellungen) zu verwalten. Derzeit sind nur die Typen dir, rbd, nfs, cephfs, lvm, lvmthin, zfspool, btrfs, cifs und pbs unterstützt. Hier sind einige Beispiele.

pve_storages:
  - name: dir1
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /ploup
    disable: no
    maxfiles: 4
  - name: ceph1
    type: rbd
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    username: admin
    pool: rbd
    krbd: yes
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: nfs1
    type: nfs
    content: [ "images", "iso" ]
    server: 192.168.122.2
    export: /data
  - name: lvm1
    type: lvm
    content: [ "images", "rootdir" ]
    vgname: vg1
  - name: lvmthin1
    type: lvmthin
    content: [ "images", "rootdir" ]
    vgname: vg2
    thinpool: data
  - name: cephfs1
    type: cephfs
    content: [ "snippets", "vztmpl", "iso" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: pbs1
    type: pbs
    content: [ "backup" ]
    server: 192.168.122.2
    username: user@pbs
    password: PBSPassword1
    datastore: main
    namespace: Top/something # Optional
  - name: zfs1
    type: zfspool
    content: [ "images", "rootdir" ]
    pool: rpool/data
    sparse: true
  - name: btrfs1
    type: btrfs
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    path: /mnt/proxmox_storage
    is_mountpoint: true
  - name: cifs1
    server: cifs-host.domain.tld
    type: cifs
    content: [ "snippets", "vztmpl", "iso" ]
    share: sharename
    subdir: /subdir
    username: user
    password: supersecurepass
    domain: addomain.tld

Verweisen Sie auf https://pve.proxmox.com/pve-docs/api-viewer/index.html für weitere Informationen.

Derzeit kann der Typ zfspool nur für den Inhalt images und rootdir verwendet werden. Wenn Sie die anderen Inhaltstypen auf einem ZFS-Volume speichern möchten, müssen Sie sie mit dem Typ dir, Pfad /<POOL>/<VOLUME> angeben und einen Eintrag in pve_zfs_create_volumes hinzufügen. Dieses Beispiel fügt einen iso-Speicher auf einem ZFS-Pool hinzu:

pve_zfs_create_volumes:
  - rpool/iso
pve_storages:
  - name: iso
    type: dir
    path: /rpool/iso
    content: [ "iso" ]

Verweisen Sie auf library/proxmox_storage.py link für die Moduldokumentation.

Ceph-Konfiguration

Diese Sektion könnte etwas mehr Liebe vertragen. Wenn Sie diese Rolle aktiv verwenden, um Ihren PVE-Ceph-Cluster zu verwalten, teilen Sie bitte etwas mehr aus und eröffnen Sie einen Pull-Request! Siehe Issue #68.

Die PVE-Ceph-Verwaltung mit dieser Rolle ist experimentell. Obwohl Benutzer diese Rolle erfolgreich verwendet haben, um PVE Ceph bereitzustellen, ist sie nicht vollständig in CI getestet (aufgrund des Fehlens verwendbarer Blockgeräte, die als OSDs in Travis CI dienen). Bitte stellen Sie sicher, dass Sie eine Testumgebung mit Ihrer Konfiguration zuerst bereitstellen, bevor Sie in die Produktion gehen, und melden Sie alle Probleme, wenn Sie auf Probleme stoßen.

Diese Rolle kann das Ceph-Speichersystem auf Ihren Proxmox-Hosts konfigurieren. Die folgenden Definitionen zeigen einige der möglichen Konfigurationen.

pve_ceph_enabled: true
pve_ceph_network: '172.10.0.0/24'
pve_ceph_cluster_network: '172.10.1.0/24'
pve_ceph_nodes: "ceph_nodes"
pve_ceph_osds:
  # OSD mit allem auf demselben Gerät
  - device: /dev/sdc
  # OSD mit block.db/WAL auf einem anderen Gerät
  - device: /dev/sdd
    block.db: /dev/sdb1
  # verschlüsselter OSD mit allem auf demselben Gerät
  - device: /dev/sdc
    encrypted: true
  # verschlüsselter OSD mit block.db/WAL auf einem anderen Gerät
  - device: /dev/sdd
    block.db: /dev/sdb1
    encrypted: true
# Crush-Regeln für verschiedene Speicherklassen
# Standardmäßig ist 'type' auf host gesetzt, Sie finden gültige Typen unter
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# aufgeführt unter 'TYPEN UND EIMER'
pve_ceph_crush_rules:
  - name: replicated_rule
    type: osd # Dies ist ein Beispiel, wie Sie eine vorhandene Regel überschreiben können
  - name: ssd
    class: ssd
    type: osd
    min-size: 2
    max-size: 8
  - name: hdd
    class: hdd
    type: host
# 2 Ceph-Pools für VM-Disketten, die ebenfalls als Proxmox-Speicher definiert werden
# Verwendung unterschiedlicher CRUSH-Regeln
pve_ceph_pools:
  - name: ssd
    pgs: 128
    rule: ssd
    application: rbd
    storage: true
# Dieser Ceph-Pool verwendet benutzerdefinierte Größen-/Replikationswerte
  - name: hdd
    pgs: 32
    rule: hdd
    application: rbd
    storage: true
    size: 2
    min-size: 1
# Dieser Ceph-Pool verwendet den automatischen Skaliermodus: "off" | "on" | "warn"> (Standard = "warn")
  - name: vm-storage
    pgs: 128
    rule: replicated_rule
    application: rbd
    autoscale_mode: "on"
    storage: true
pve_ceph_fs:
# Ein CephFS-Dateisystem, das nicht als Proxmox-Speicher definiert ist
  - name: backup
    pgs: 64
    rule: hdd
    storage: false
    mountpoint: /srv/proxmox/backup

pve_ceph_network verwendet standardmäßig den Filter ansible.utils.ipaddr, was erfordert, dass die Bibliothek netaddr installiert und von Ihrem Ansible-Controller verwendbar ist.

pve_ceph_nodes verwendet standardmäßig pve_group. Dieser Parameter ermöglicht es, auf welchen Knoten Ceph installiert werden soll (z.B. wenn Sie Ceph nicht auf allen Knoten installieren möchten).

pve_ceph_osds erstellt standardmäßig unverschlüsselte Ceph-Volumes. Um verschlüsselte Volumes zu verwenden, muss der Parameter encrypted pro Laufwerk auf true gesetzt werden.

PCIe-Passthrough

Diese Rolle kann so konfiguriert werden, dass der PCI-Geräte-Passthrough vom Proxmox-Host an VMs ermöglicht wird. Diese Funktion ist standardmäßig nicht aktiviert, da nicht alle Motherboards und CPUs diese Funktion unterstützen. Um den Durchgang zu aktivieren, muss das Gerät CPU-hardwarevirtualisierung unterstützen (VT-d für Intel-basierte Systeme und AMD-V für AMD-basierte Systeme). Verweisen Sie auf die Handbücher aller Komponenten, um festzustellen, ob diese Funktion unterstützt wird oder nicht. Die Benennungskonventionen variieren, werden jedoch normalerweise als IOMMU, VT-d oder AMD-V bezeichnet.

Durch Aktivierung dieser Funktion können dedizierte Geräte (wie eine GPU oder USB-Geräte) an die VMs weitergeleitet werden. Zusätzlich zu den dedizierten Geräten können auch verschiedene integrierte Geräte wie Intels oder AMDs integrierte GPUs an VMs weitergeleitet werden.

Einige Geräte können die Mediated-Nutzung nutzen. Mediated-Geräte können an mehrere VMs mit Ressourcen weitergegeben werden, bleiben jedoch dennoch für das Hosts-System verwendbar. Das Teilen von Geräten wird nicht immer unterstützt und sollte vor der Aktivierung validiert werden, um Fehler zu vermeiden. Überprüfen Sie das Handbuch des Geräts, das Sie weiterleiten möchten, um festzustellen, ob das Gerät mediatisch verwendet werden kann (derzeit unterstützt diese Rolle nur GVT-g; SR-IOV wird derzeit nicht unterstützt und muss manuell nach Abschluss der Rolle aktiviert werden).

Die folgende Konfiguration aktiviert den PCIe-Passthrough:

pve_pcie_passthrough_enabled: true
pve_iommu_passthrough_mode: true
pve_iommu_unsafe_interrupts: false
pve_mediated_devices_enabled: false
pve_pcie_ovmf_enabled: false
pve_pci_device_ids:
  - id: "10de:1381"
  - id: "10de:0fbc"
pve_vfio_blacklist_drivers:
  - name: "radeon"
  - name: "nouveau"
  - name: "nvidia"
pve_pcie_ignore_msrs: false
pve_pcie_report_msrs: true

pve_pcie_passthrough_enabled ist erforderlich, um jede PCIe-Passthrough-Funktionalität zu nutzen. Ohne diese Einstellung werden alle anderen PCIe-bezogenen Felder nicht verwendet.

pve_iommu_passthrough_mode kann die Geräteleistung erhöhen. Durch Aktivierung dieser Funktion können VMs die standardmäßige DMA-Übersetzung umgehen, die normalerweise von dem Hypervisor durchgeführt wird. Stattdessen übergeben VMs DMA-Anforderungen direkt an das Hardware-IOMMU.

pve_iommu_unsafe_interrupts muss aktiviert werden, um den PCI-Passthrough zuzulassen, wenn Ihr System keine Interrupt-Zuordnung unterstützt. Sie können überprüfen, ob das Gerät die Interrupt-Zuordnung unterstützt, indem Sie dmesg | grep 'remapping' verwenden. Wenn Sie eine der folgenden Zeilen sehen:

• "AMD-Vi: Interrupt remapping enabled"
• "DMAR-IR: Enabled IRQ remapping in x2apic mode" ('x2apic' kann bei alten CPUs unterschiedlich sein, sollte aber immer noch funktionieren)

Dann wird die Interrupt-Zuordnung des Systems unterstützt und Sie müssen unsichere Interrupts nicht aktivieren. Beachten Sie, dass durch das Aktivieren dieses Wertes Ihr System instabil werden kann.

pve_mediated_devices_enabled aktiviert die GVT-g-Unterstützung für integrierte Geräte wie Intels iGPUs. Nicht alle Geräte unterstützen GVT-g, sodass es empfohlen wird, im Vorfeld zu überprüfen, ob dies für Ihr spezifisches Gerät möglich ist.

pve_pcie_ovmf_enabled aktiviert den GPU-OVMF-PCI-Passthrough. Bei der Verwendung von OVMF sollten Sie 'OVMF' als BIOS-Option für die VM anstelle von 'SeaBIOS' innerhalb von Proxmox auswählen. Diese Einstellung wird versuchen, Geräte so weit wie möglich von der VGA-Synchronisierung auszunehmen.

pve_pci_device_ids ist eine Liste der Geräte- und Anbietervarianten, die vom Host an die VMs weitergeleitet werden sollen. Siehe den Abschnitt „GPU Passthrough“ im Proxmox-WIKI, um Ihre spezifischen Geräte- und Anbietervarianten zu finden. Bei dieser Einstellung ist es erforderlich, eine 'id' für jedes neue Element im Array anzugeben.

pve_vfio_blacklist_drivers ist eine Liste von Treibern, die vom Host ausgeschlossen/schwarzgelistet werden sollen. Diese ist erforderlich, wenn Sie ein PCI-Gerät durchleiten, um zu verhindern, dass der Host das Gerät verwendet, bevor es einer VM zugewiesen werden kann. Bei dieser Einstellung ist es erforderlich, einen 'name' für jedes neue Element im Array anzugeben.

pve_pcie_ignore_msrs verhindert, dass einige Windows-Anwendungen wie GeForce Experience, Passmark Performance Test und SiSoftware Sandra die VM zum Absturz bringen. Dieser Wert ist nur erforderlich, wenn PCI-Geräte an Windows-basierte Systeme weitergeleitet werden.

pve_pcie_report_msrs kann verwendet werden, um das Protokollieren von msrs-Warnungen zu aktivieren oder zu deaktivieren. Wenn Sie viele Warnmeldungen in Ihrem 'dmesg'-Systemprotokoll sehen, kann dieser Wert verwendet werden, um msrs-Warnungen zu unterdrücken.

Entwicklerhinweise

Wenn Sie neue Funktionen entwickeln oder etwas in dieser Rolle beheben, können Sie Ihre Änderungen testen, indem Sie Vagrant verwenden (derzeit wird nur libvirt unterstützt). Das Playbook finden Sie in tests/vagrant (stellen Sie sicher, dass Sie die Gruppenvariablen entsprechend ändern). Testen Sie Änderungen unbedingt sowohl auf Debian 10 als auch 11 (aktualisieren Sie die Vagrantfile lokal, um debian/buster64 zu verwenden), bevor Sie einen PR einreichen.

Sie können auch einen Apt-Caching-Proxy (z.B. apt-cacher-ng, der auf Port 3142 laufen muss) mit der Umgebungsvariablen APT_CACHE_HOST angeben, um die Paketdownloads zu beschleunigen, falls Sie einen lokal in Ihrer Umgebung ausgeführt haben. Das Vagrant-Playbook erkennt, ob der Caching-Proxy verfügbar ist und verwendet ihn nur, wenn er von Ihrem Netzwerk erreichbar ist. Sie können diese Variable also auch dauerhaft in Ihrer Entwicklungsumgebung festlegen, wenn Sie möchten.

Zum Beispiel könnten Sie Folgendes ausführen, um eine ausführlichere bzw. leichter lesbare Ausgabe zu zeigen, einen Caching-Proxy zu verwenden und die VMs im Fehlerfall am Laufen zu halten (damit Sie es beheben können oder vagrant provision nach der Behebung ausführen können):

    APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error

Mitwirkende

Musee Ullah (@lae, lae@lae.is) - Hauptentwickler
Fabien Brachere (@Fbrachere) - Unterstützung für die Speicher-Konfiguration
Gaudenz Steinlin (@gaundez) - Ceph-Unterstützung usw.
Richard Scott (@zenntrix) - Ceph-Unterstützung, PVE 7.x Unterstützung usw.
Thoralf Rickert-Wendt (@trickert76) - PVE 6.x Unterstützung usw.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@SniperCZE)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - PVE 8.x Unterstützung usw.
Bruno Travouillon (@btravouillon) - UX-Verbesserungen
Tobias Negd (@wu3rstle) - Ceph-Unterstützung
PendaGTP (@PendaGTP) - Ceph-Unterstützung
John Marion (@jmariondev)
foerkede (@foerkede) - ZFS-Speicherunterstützung
Guiffo Joel (@futuriste) - Unterstützung bei der Pool-Konfiguration
Adam Delo (@ol3d) - Unterstützung für PCIe-Passthrough

Gesamtübersicht der Mitwirkenden