csmart.virt_infra

Ansible-Rolle: Virtuelle Infrastruktur

Diese Rolle ist dazu gedacht, Netzwerke und Gäste auf einem oder mehreren KVM-Hosts zu definieren und zu verwalten. Mit der Option --limit von Ansible können Sie diese einzeln oder als Gruppe verwalten.

Sie ist wirklich für Entwicklungsarbeiten gedacht, bei denen der KVM-Host Ihr lokaler Computer ist, und Sie haben sudo und kommunizieren mit libvirtd unter qemu:///system, jedoch funktioniert sie auch auf entfernten Hosts.

Es werden verschiedene Zustände für Gäste unterstützt: laufend, heruntergefahren, zerstört oder undefiniert (zum Löschen und Aufräumen).

Sie können beliebigen Speicher, CPU, Festplatten und Netzwerkkarten für Ihre Gäste festlegen, entweder über Hostgruppen oder individuell. Eine Mischung aus mehreren Festplatten wird unterstützt, einschließlich scsi, sata, virtio und sogar nvme (auf unterstützten Distributionen).

Sie können private NAT-Libvirt-Netzwerke auf dem KVM-Host erstellen und dann VMs auf beliebig vielen davon platzieren. Gäste können diese Libvirt-Netzwerke oder vorhandene Linux-Bridge-Geräte (z. B. br0) und Open vSwitch (OVS)-Bridges auf dem KVM-Host verwenden (dies erstellt keine Bridges auf dem Host, es wird jedoch überprüft, ob die Bridge-Schnittstelle vorhanden ist). Sie können das Modell der Netzwerkkarte sowie die MAC-Adresse für jede Schnittstelle angeben, wenn Sie möchten, jedoch wird standardmäßig eine idempotente Adresse basierend auf dem Hostnamen verwendet.

Sie können auch geroutete Libvirt-Netzwerke auf dem KVM-Host erstellen und dann VMs auf beliebig vielen davon platzieren. In diesem Fall wird eine neue Bridge mit dem von Ihnen angegebenen Namen (z. B. br1) erstellt, die mit einer vorhandenen Schnittstelle (z. B. eth0) verbunden ist. Auch hier können Sie die MAC-Adressen für jede Schnittstelle angeben, wenn Sie dies benötigen.

Dies unterstützt verschiedene Distributionen und nutzt deren qcow2 Cloud-Images zur Vereinfachung (obwohl Sie auch Ihre eigenen Bilder verwenden könnten). Ich habe CentOS Stream, Debian, Fedora, openSUSE, RHEL und Ubuntu getestet.

Für RHEL setzen Sie die Variable virt_infra_sm_creds (vielleicht aus einem Vault), um die Maschine vorübergehend beim Red Hat-Portal zu registrieren, wenn Sie das Disk-Image vorbereiten. Das folgt dem Format von virt-builder, wie folgt:

- virt_infra_sm_creds: MYUSER:password:MYPASSWORD

Die qcow2-Cloud-Base-Images, die für Gäste verwendet werden sollen, werden als Variablen im Inventar angegeben und sollten im Libvirt-Images-Verzeichnis vorhanden sein (Standard ist /var/lib/libvirt/images/). Das heißt, dies wird die Images nicht automatisch für Sie herunterladen.

Die bootfähigen qcow2-Images der Gäste werden aus diesen Basis-Images erstellt. Standardmäßig verwenden diese das Cloud-Image als Basisdatei, unterstützen jedoch auch das Klonen. Sie können zusätzliche Festplatten erstellen, wie Sie möchten. Sie können auch entscheiden, ob Sie ein Festplatten-Image behalten möchten, anstatt es zu löschen, wenn eine VM undefiniert ist. Die Cloud-Init-ISOs werden automatisch erstellt und dem Gast angehängt, um ihn beim Booten zu konfigurieren.

Die Zeitzone wird standardmäßig auf die des KVM-Hosts eingestellt, und der Ansible-Benutzer wird für den Gast verwendet, zusammen mit Ihren öffentlichen SSH-Schlüsseln auf dem KVM-Host (Sie können das überschreiben). Host-Einträge werden zu /etc/hosts auf dem KVM-Host hinzugefügt, und es wird auch die SSH-Konfiguration des Ansible-Benutzers geändert und der Fingerabdruck zu known_hosts hinzugefügt, damit Sie direkt per SSH zugreifen können (was als Teil des Deployments getestet wird). Sie können ein Root-Passwort festlegen, wenn Sie das wirklich möchten.

Damit könnten Sie OpenStack/Swift/Ceph-Cluster unterschiedlicher Größe mit mehreren Netzwerken, Festplatten und sogar Distributionen definieren und verwalten!

Anforderungen

Alles, was Sie wirklich benötigen, ist ein Linux-Host, der KVM ausführen kann, einige Gäste-Images und ein einfaches Inventar. Ansible wird den Rest erledigen (auf unterstützten Distributionen).

Ein funktionierender x86_64 KVM-Host, bei dem der Benutzer, der Ansible ausführt, mit libvirtd über sudo kommunizieren kann.

Es wird Hardwareunterstützung für KVM in der CPU erwartet, damit wir beschleunigte Gäste erstellen und die CPU durchreichen können (unterstützt verschachtelte Virtualisierung).

Sie benötigen möglicherweise Ansible und Jinja >= 2.8, da dies Dinge wie 'gleich' Vergleiche macht.

Ich habe dies auf CentOS Stream 8, Fedora 3x, Debian 10, Ubuntu Bionic/Eoan und openSUSE 15 Hosts getestet, aber andere Linux-Maschinen funktionieren wahrscheinlich auch.

Mindestens ein SSH-Schlüsselpaar auf Ihrem KVM-Host (Ansible wird eines generieren, wenn es fehlt). Der SSH-Schlüssel, der für Gäste verwendet wird, sollte kein SSH-Passwort benötigen, falls er sich auf einem entfernten KVM-Host befindet. Wenn lokal, stellen Sie sicher, dass Sie ihn dem SSH-Agenten hinzugefügt haben.

Einige Benutzertools sind ebenfalls auf dem KVM-Host erforderlich (Ansible wird diese auf unterstützten Hosts installieren).

qemu-img
osinfo-query
virsh
virt-customize
virt-sysprep

Laden Sie die Gäste-Images herunter, die Sie verwenden möchten (das habe ich heruntergeladen), und legen Sie sie in den Pfad für Libvirt-Images (normalerweise /var/lib/libvirt/images/). Dies wird überprüfen, ob die von Ihnen angegebenen Images vorhanden sind, und einen Fehler ausgeben, wenn sie nicht gefunden werden.

KVM-Host

Hier sind einige Anweisungen für die Konfiguration Ihres KVM-Hosts, falls sie nützlich sind.

HINWEIS: Diese Rolle erledigt all dies für Sie, einschließlich der Installation von KVM, libvirtd und anderen erforderlichen Paketen auf unterstützten Distributionen und stellt sicher, dass libvirtd läuft.

Es gibt auch eine Variable virt_infra_host_pkgs_custom, die eine Liste von Paketen akzeptiert, die auf dem Host installiert werden sollen, falls Sie oder die Rolle einige zusätzliche Pakete für Sie installieren möchten.

Beachten Sie, dass die Variable eine Liste sein muss und der Host in der Lage sein muss, die Pakete zu installieren, d.h. die Paketnamen müssen für den Host korrekt sein und falls der Host RHEL ausführt, muss er registriert sein.

Fedora

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben (kein Passwort festlegen, wenn der KVM-Host remote ist)
ssh-keygen

# libvirtd
sudo dnf install -y @virtualization
sudo systemctl enable --now libvirtd

# Ansible
sudo dnf install -y ansible

# Weitere Abhängigkeiten (über das Playbook installiert)
sudo dnf install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python3-libvirt \
python3-lxml \
qemu-img \
virt-install

CentOS 7

CentOS 7 funktioniert nicht, bis wir das Paket libselinux-python3 haben, das in 7.8 kommt...

Hier sind (hoffentlich) die restlichen Schritte, wenn es verfügbar ist.

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben
ssh-keygen

# libvirtd
sudo yum groupinstall -y "Virtualization Host"
sudo systemctl enable --now libvirtd

# Ansible und weitere Abhängigkeiten
sudo yum install -y epel-release
sudo yum install -y python36
pip3 install --user ansible

sudo yum install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python36-libvirt \
python36-lxml \
libselinux-python3 \
qemu-img \
virt-install

CentOS Stream 8

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben
ssh-keygen

# libvirtd
sudo dnf groupinstall -y "Virtualization Host"
sudo systemctl enable --now libvirtd

# Ansible
sudo dnf install -y epel-release
sudo dnf install -y ansible

# Weitere Abhängigkeiten (über das Playbook installiert)
sudo dnf install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python3 \
python3-libvirt \
python3-lxml \
qemu-img \
virt-install

Debian

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben
ssh-keygen

# libvirtd
sudo apt update
sudo apt install -y --no-install-recommends qemu-kvm libvirt-clients libvirt-daemon-system
sudo systemctl enable --now libvirtd

# Ansible
sudo apt install -y gnupg2
echo 'deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main' | sudo tee -a /etc/apt/sources.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
sudo apt update
sudo apt install -y ansible

# Weitere Abhängigkeiten (über das Playbook installiert)
sudo apt install -y --no-install-recommends \
cloud-image-utils \
dnsmasq \
git \
genisoimage \
libguestfs-tools \
libosinfo-bin \
python3-libvirt \
python3-lxml \
qemu-utils \
virtinst

Ubuntu

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben
ssh-keygen

# libvirtd
sudo apt update
sudo apt install -y --no-install-recommends libvirt-clients libvirt-daemon-system qemu-kvm
sudo systemctl enable --now libvirtd

# Ansible
sudo apt install -y software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install -y ansible

# Weitere Abhängigkeiten (über das Playbook installiert)
sudo apt install -y --no-install-recommends \
dnsmasq \
git \
genisoimage \
libguestfs-tools \
libosinfo-bin \
python3-libvirt \
python3-lxml \
qemu-utils \
virtinst

openSUSE

Wenn Sie JeOS verwenden, müssen wir den Kernel zu kernel-default ändern, da kernel-default-base, der mit JeOS kommt, keine KVM-Module enthält.

# Erstellen Sie einen SSH-Schlüssel, wenn Sie keinen haben
ssh-keygen

# Passenden Kernel installieren
sudo zypper install kernel-default
sudo reboot

Nach dem Neustart fortfahren.

# libvirtd
sudo zypper install -yt pattern kvm_server kvm_tools
sudo systemctl enable --now libvirtd

# Ansible
sudo zypper install -y ansible

# Weitere Abhängigkeiten (über das Playbook installiert)
sudo zypper install -y \
git \
guestfs-tools \
libosinfo \
mkisofs \
python3-libvirt-python \
python3-lxml \
qemu-tools \
virt-install

Verwendung von gerouteten Netzwerken

Sie können den Verkehr in eine neu erstellte Bridge leiten, indem Sie den Forward Typ: route angeben. Dieser Code unterstützt die automatische Erstellung einer neuen Bridge mit dem Namen bridge_dev, die mit einer vorhandenen Schnittstelle im Host verbunden wird, die durch den Parameter host_dev angegeben ist.

Das folgende Beispiel zeigt, wie eine Bridge erstellt werden kann, die sowohl IPv4 als auch IPv6 unterstützt:

kvmhost:
  hosts:
    localhost:
      ansible_connection: local
      ansible_python_interpreter: /usr/bin/python3
      virt_infra_host_libvirt_url: qemu:///system
  vars:
    virt_infra_host_networks:
      present:
        - name: example
          domain: f901.example.com
          type: route
          host_dev: eth0
          bridge_dev: virbr1
          bridge_stp: on
          bridge_delay: 0
          mac: 52:54:00:f9:01:00
          ip_address: 10.249.1.1
          ip_netmask: 255.255.255.0
          dhcp_start: 10.249.1.11
          dhcp_end: 10.249.1.254
          ip6_address: 2001:0db8::f901:1
          ip6_prefix: 64
          dhcp6_start: 2001:0db8::f901:0000
          dhcp6_end: 2001:0db8::f901:00ff

Hinweise:

Der IPv6-Block 2001:0db8/32, wie oben dargestellt, wird nur zu Dokumentationszwecken bereitgestellt. Sie müssen diesen durch Ihren eigenen delegierten /48-Block (im Allgemeinen) ersetzen, der Ihnen von Ihrem IPv6-Anbieter oder durch eine IPv6-über-IPv4-Tunnelungslösung wie den Hurricane Electric-Tunnelbroker-Dienst zugewiesen wurde.
Es wird dringend empfohlen, ip6_prefix: 64 zu verwenden, da es die empfohlene Einstellung in der libvirt-Dokumentation ist.

Konfigurieren von Bridges mit NetworkManager

Dieser Code unterstützt die Verbindung von VMs sowohl zu Linux- als auch zu Open vSwitch-Bridges, vorausgesetzt, sie existieren bereits auf dem KVM-Host.

So können Sie ein vorhandenes Ethernet-Gerät in eine Bridge umwandeln. Seien Sie vorsichtig, wenn Sie dies auf einem Remote-Rechner mit nur einer Verbindung tun! Stellen Sie sicher, dass Sie einen anderen Weg haben, sich anzumelden (z. B. Konsole), oder fügen Sie vielleicht zusätzliche Schnittstellen hinzu.

Zuerst exportieren Sie das Gerät, das Sie umwandeln möchten, damit wir es später leicht referenzieren können (z. B. eth1).

export NET_DEV="eth1"

Jetzt listen Sie die aktuellen NetworkManager-Verbindungen für Ihr oben exportiertes Gerät auf, damit wir wissen, was wir später deaktivieren müssen.

sudo nmcli con | egrep -w "${NET_DEV}"

Das könnte etwas wie System eth1 oder Wired connection 1 sein; exportieren wir es auch zur späteren Referenz.

export NM_NAME="Wired connection 1"

Linux-Bridge

Hier ist ein Beispiel für die Erstellung einer persistierenden Linux-Bridge mit NetworkManager. Sie nimmt ein Gerät wie eth1 (passend ersetzen) und wandelt es in eine Bridge um.

Denken Sie daran, den Namen der bestehenden NetworkManager-Verbindung Ihres Geräts von oben (z. B. Wired connection 1) zu verwenden.

export NET_DEV=eth1
export NM_NAME="Wired connection 1"
sudo nmcli con add ifname br0 type bridge con-name br0
sudo nmcli con add type bridge-slave ifname "${NET_DEV}" master br0

Jetzt haben Sie Ihr Bridge-Gerät! Beachten Sie, dass die Bridge eine andere MAC-Adresse als das zugrunde liegende Gerät haben wird. Wenn Sie erwarten, dass sie eine bestimmte Adresse erhält, müssen Sie Ihr DHCP-Stammangebot aktualisieren.

sudo ip link show dev br0

Deaktivieren Sie die aktuelle NetworkManager-Konfiguration für das Gerät, damit es nicht mit der Bridge in Konflikt gerät (löschen Sie es noch nicht, Sie könnten die Verbindung verlieren, wenn Sie sie für SSH verwenden).

sudo nmcli con modify id "${NM_NAME}" ipv4.method disabled ipv6.method disabled

Jetzt können Sie entweder einfach neustarten oder die aktuelle Schnittstelle stoppen und die Bridge mit einem Befehl aktivieren. Denken Sie daran, dass die Bridge eine neue MAC-Adresse erhält, sodass sie eine neue IP erhält, es sei denn, Sie haben Ihre DHCP-statischen Leases aktualisiert!

sudo nmcli con down "${NM_NAME}" ; sudo nmcli con up br0

Wie bereits erwähnt, wird Standardmäßig die Linux-Bridge über DHCP eine Adresse erhalten. Wenn Sie nicht möchten, dass sie im Netzwerk ist (vielleicht haben Sie eine andere dedizierte Schnittstelle), deaktivieren Sie DHCP auf ihr.

sudo nmcli con modify id br0 ipv4.method disabled ipv6.method disabled

Verwendung der Linux-Bridge im Inventar

Es gibt nichts, was auf der kvmhost-Seite des Inventars zu tun ist.

Für alle Gäste, die Sie mit der Bridge verbinden möchten, geben Sie dies einfach in ihrem Inventar an. Verwenden Sie br0 als name eines Netzwerks unter virt_infra_networks mit dem Typ bridge.

virt_infra_networks:
  - name: br0
    type: bridge

Open vSwitch (OVS) Bridge

Hier ist ein Beispiel zur Erstellung einer persistierenden OVS-Bridge mit NetworkManager. Sie nimmt ein Gerät wie eth1 (passend ersetzen) und wandelt es in eine OVS-Bridge um.

Sie müssen Open vSwitch installiert haben sowie das OVS NetworkManager-Plugin (ersetzen Sie es durch Ihre Distribution).

sudo dnf install -y NetworkManager-ovs openvswitch
sudo systemctl enable --now openvswitch
sudo systemctl restart NetworkManager

Jetzt können wir die OVS-Bridge erstellen (davon ausgehend, dass Ihr Gerät eth1 ist, und die bestehende NetworkManager-Konfiguration Wired connection 1 ist; entsprechend ersetzen).

export NET_DEV=eth1
export NM_NAME="Wired connection 1"
sudo nmcli con add type ovs-bridge conn.interface ovs-bridge con-name ovs-bridge
sudo nmcli con add type ovs-port conn.interface port-ovs-bridge master ovs-bridge
sudo nmcli con add type ovs-interface slave-type ovs-port conn.interface ovs-bridge master port-ovs-bridge
sudo nmcli con add type ovs-port conn.interface ovs-port-eth master ovs-bridge con-name ovs-port-eth
sudo nmcli con add type ethernet conn.interface "${NET_DEV}" master ovs-port-eth con-name ovs-int-eth

sudo nmcli con modify id "${NM_NAME}" ipv4.method disabled ipv6.method disabled

Jetzt können Sie entweder einfach neustarten oder die aktuelle Schnittstelle stoppen und die Bridge mit einem Befehl aktivieren.

sudo nmcli con down "${NM_NAME}" ; sudo nmcli con up ovs-slave-ovs-bridge

Standardmäßig wird die OVS-Bridge eine Adresse über DHCP erhalten. Wenn Sie nicht möchten, dass sie im Netzwerk ist (vielleicht haben Sie eine andere dedizierte Schnittstelle), deaktivieren Sie DHCP auf ihr.

sudo nmcli con modify id ovs-slave-ovs-bridge ipv4.method disabled ipv6.method disabled

Zeigen Sie die Switch-Konfiguration und die Bridge mit OVS-Tools an.

sudo ovs-vsctl show

Verwendung der ovs-Bridge im Inventar

Jetzt können Sie die ovs-bridge als device einer ovs-Bridge in Ihrem kvmhost-Inventar virt_infra_host_networks-Eintrag verwenden. Sie können mehrere VLANs einrichten und eines als standardmäßigen nativen (falls erforderlich) festlegen.

VLAN-Bereiche werden unterstützt, indem Sie sie als Liste definieren.

virt_infra_host_networks:
  present:
    - name: ovs-bridge
      bridge_dev: ovs-bridge
      type: ovs
      portgroup:
        - name: ovs-trunk
          trunk: true
          native_vlan: 1
          vlan:
            - 1
            - [20,29]
            - 99
        - name: default
          native_vlan: 1
          vlan:
            - 1
        - name: other
          native_vlan: 99
          vlan:
            - 99

Sie können dann angeben, dass Ihre VMs auf bestimmten Portgruppen sind, und libvirt wird die Ports automatisch für Ihre VMs einrichten.

virt_infra_networks:
  - name: ovs-bridge
    portgroup: default
    type: ovs

Sobald Ihre VMs laufen, können Sie ihre OVS-Ports mit sudo ovs-vsctl show sehen.

Gäste-Cloud-Images

Dies ist darauf ausgelegt, Standard-Cloud-Images zu verwenden, die von verschiedenen Distributionen bereitgestellt werden (OpenStack bietet einige Empfehlungen).

Stellen Sie sicher, dass das Image, das Sie für Ihre Gäste angeben, bereits im Libvirt-Speicherverzeichnis vorhanden ist (standardmäßig ist dies /var/lib/libvirt/images/).

Ich habe die folgenden Gäste erfolgreich getestet:

Damit wir den Gast konfigurieren und seine IP erhalten können, werden sowohl cloud-init als auch qemu-guest-agent in das Image Ihres Gastes installiert, nur für den Fall.

Dies kann mit der Variablen virt_infra_guest_deps geändert oder überschrieben werden, die eine Liste ist.

Sysprep wird ebenfalls im Gast-Image ausgeführt, um sicherzustellen, dass es von Dingen wie alten MAC-Adressen bereinigt ist.

Rollenvariablen

Die Standardeinstellungen für die Rolle befinden sich in der Datei defaults/main.yml.

Diese können bei Bedarf auf Host- oder Hostgruppenebene überschrieben werden. Die Rolle ist jedoch so konzipiert, dass sie nahezu sofort funktioniert (solange Sie das Standard-CentOS-Stream-8-Image haben).

---
# Vorgaben für die virt-infra Ansible-Rolle
# Auskommentierte Werte sind optional

## Gäste bezogen

# Gültige Gästezustände sind: laufend, heruntergefahren, zerstört oder undefiniert
virt_infra_state: "running"

# Gäste werden beim Booten nicht automatisch gestartet
virt_infra_autostart: "no"

# Gastbenutzer, standardmäßig wird dieser auf denselben Benutzer wie der KVM-Hostbenutzer gesetzt
virt_infra_user: "{{ hostvars[kvmhost].ansible_env.USER }}"

# Passwort des Standardbenutzers (denken Sie an einen Vault, wenn Sie sichere Passwörter benötigen)
# Kein Root-Passwort standardmäßig
virt_infra_password: "password"
#virt_infra_root_password:

# VM-Spezifikationen für Gäste
# Siehe virt-install man-Seite für unterstützte Werte
virt_infra_ram: "1024"
virt_infra_ram_max: "{{ virt_infra_ram }}"
virt_infra_cpus: "1"
virt_infra_cpus_max: "{{ virt_infra_cpus }}"
virt_infra_cpu_model: "host-passthrough"
virt_infra_machine_type: "q35"

# SSH-Schlüssel sind eine Liste, Sie können mehr als einen hinzufügen
# Wenn nicht angegeben, verwenden wir standardmäßig alle öffentlichen Schlüssel auf dem KVM-Host
virt_infra_ssh_keys: []

# Wenn keine SSH-Schlüssel auf dem KVM-Host angegeben oder gefunden werden, erstellen wir einen mit dieser Größe
virt_infra_ssh_key_size: "2048"
virt_infra_ssh_key_type: "rsa"

# Ob die SSH-Passwortauthentifizierung aktiviert werden soll
virt_infra_ssh_pwauth: true

# Ob cloud-init zur Konfiguration des Netzwerks im Gast verwendet werden soll
virt_infra_network_config: false

# Netzwerke sind eine Liste, Sie können mehr als ein hinzufügen
# "type" ist optional, sowohl "nat" als auch "bridge" werden unterstützt
#  - "nat" ist der Standardtyp und sollte ein Libvirt-Netzwerk sein
#  - "bridge" erfordert, dass die Bridge-Schnittstelle (z. B. name: "br0") auch bereits auf dem KVM-Host eingerichtet ist
# "model" ist ebenfalls optional
virt_infra_networks:
  - name: "default"
    type: "nat"
    model: "virtio"

# Festplatten, unterstützen verschiedene Libvirt-Optionen
# Wir setzen sie normalerweise jedoch nicht und überlassen es dem Hypervisor-Standard
# Siehe die man-Seite von virt-install für unterstützte Werte
virt_infra_disk_size: "20"
virt_infra_disk_bus: "scsi"
virt_infra_disk_io: "threads"
virt_infra_disk_cache: "writeback"

# Festplatten sind eine Liste, Sie können mehr als eine hinzufügen
# Wenn Sie dies überschreiben, müssen Sie weiterhin das 'boot'-Gerät zuerst in der Liste einfügen
# Nur 'name' ist erforderlich, die anderen sind optional (Standardgröße ist 20GB)
# Alle Gäste benötigen mindestens ein Bootlaufwerk (was der Standard ist)
virt_infra_disks:
  - name: "boot"
    size: "{{ virt_infra_disk_size }}"
    bus: "{{ virt_infra_disk_bus }}"
#   io: "{{ virt_infra_disk_io }}"
#   cache: "{{ virt_infra_disk_cache }}"

# Standard-Distribution ist CentOS Stream 8, im Gast oder in Gruppen überschreiben
virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"

# Ermitteln Sie die unterstützten Varianten auf Ihrem KVM-Host mit dem Befehl "osinfo-query os"
# Dies macht in der Regel keinen großen Unterschied für den Gast, vielleicht eine leicht andere Bus-Konfiguration
# Sie könnten dies wahrscheinlich einfach als "centos7.0" für alle Distributionen einstellen, wenn Sie möchten
#virt_infra_variant: "centos7.0"

# Diese Distro-Variablen sind hier zur Referenz und Bequemlichkeit
virt_infra_distro: "centos-stream"
virt_infra_distro_release: "8"
virt_infra_distro_image_url: "https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"
virt_infra_distro_image_checksum_url: "https://cloud.centos.org/centos/8-stream/x86_64/images/CHECKSUM"

## KVM-Host-bezogen

# Verbindung zur System-Libvirt-Instanz
virt_infra_host_libvirt_url: "qemu:///system"

# Pfad, in dem die Disk-Images gespeichert werden
virt_infra_host_image_path: "/var/lib/libvirt/images"

# Standardmäßig den qemu-Sicherheits-Treiber deaktivieren
# Dies wird in distributionspezifischen Variablen überschrieben
virt_infra_security_driver: "none"

# Virtuelles BMC standardmäßig deaktiviert
virt_infra_vbmc: false

# Im Standard verwenden wir pip für die Installation, aber wenn Sie es manuell tun möchten, setzen Sie dies auf falsch
virt_infra_vbmc_pip: true

# Standard vbmc-Service, überschreiben, wenn etwas anderes auf Ihrer Distribution
virt_infra_vbmc_service: vbmcd

# Netzwerke auf dem kvmhost sind eine Liste, Sie können mehr als ein hinzufügen
# Sie können NAT-Netzwerke auf dem kvmhost erstellen und entfernen (Bridges erstellen nicht unterstützt)
# Das 'default'-Netzwerk ist das Standardnetzwerk, das mit libvirt geliefert wird
# Standardmäßig entfernen wir keine Netzwerke (leere Abwesenheitsliste)
virt_infra_host_networks:
  absent: []
  present:
    - name: "default"
      type: "nat"
      ip_address: "192.168.122.1"
      subnet: "255.255.255.0"
      dhcp_start: "192.168.122.2"
      dhcp_end: "192.168.122.254"

# Befehl zum Erstellen von ISO-Images
virt_infra_mkiso_cmd: genisoimage

# Liste der Binaries, die auf dem KVM-Host überprüft werden sollen
virt_infra_host_deps:
  - qemu-img
  - osinfo-query
  - virsh
  - virt-customize
  - virt-sysprep

# Durch Kommas getrennte Liste von Paketinstallationen in Gast-Disks
virt_infra_guest_deps:
  - cloud-init
  - qemu-guest-agent

Abhängigkeiten

Keine

Beispiel-Inventar

Das separate virt-infra Repo hat Beispiel-Inventardateien und eine Site-Playbook, um die Rolle aufzurufen, was hilfreich sein könnte.

Es könnte am besten sein, wenn die Inventare in mehrere Dateien aufgeteilt werden, um die Verwaltung zu erleichtern, unter einem inventory-Verzeichnis oder Ähnlichem. Ich schlage ein gemeinsames kvmhost.yml vor und dann separate Inventardateien für jede Gruppe von Gästen wie openstack.yml. Beim Ausführen von Ansible geben Sie das gesamte Verzeichnis als Inventarquelle an.

Das Inventar, das mit dieser Rolle verwendet wird, muss eine Hostgruppe namens kvmhost und andere Hostgruppen für Gäste enthalten.

Benutzerdefinierte Einstellungen können für jeden Host oder jede Gruppe von Hosts im Inventar bereitgestellt werden.

Um eine neue Gruppe von Gästen zu erstellen, die verwaltet werden sollen, erstellen Sie eine neue yml-Datei unter dem Inventarverzeichnis. Zum Beispiel, wenn Sie eine Gruppe von Gästen für OpenStack möchten, könnten Sie eine Datei openstack.yml erstellen und sie nach Bedarf befüllen.

Um bestimmte Hosts oder Gruppen zu verwalten, verwenden Sie einfach die --limit-Option von Ansible, um die Hosts oder Hostgruppen anzugeben (muss auch die kvmhost-Gruppe enthalten). So können Sie dasselbe Inventar für viele verschiedene Gäste verwenden und sie separat verwalten.

Der KVM-Host ist dort, wo die Libvirt-Netzwerke erstellt werden und daher als Variablen unter dieser Hostgruppe angegeben werden.

Hier ist eine Beispiel-Inventardatei kvmhost.yml im YAML-Format. Sie gibt kvmhost als localhost mit einer lokalen Verbindung an. Beachten Sie, dass zwei Netzwerke erstellt werden (default und example) und eines, das entfernt wird (other).

---
## Inventar im YAML-Format, siehe:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
kvmhost:
  hosts:
    # Geben Sie hier Ihre KVM-Hostverbindung und -einstellungen ein
    localhost:
      ansible_connection: local
      ansible_python_interpreter: /usr/bin/python3
  vars:
    # Netzwerke sind eine Liste, Sie können mehr als eine hinzufügen
    # Sie können NAT-Netzwerke auf dem kvmhost erstellen und entfernen (Bridges erstellen nicht unterstützt)
    # Das 'default'-Netzwerk ist das Standardnetzwerk, das mit libvirt geliefert wird
    # Standardmäßig entfernen wir keine Netzwerke (leere Abwesenheitsliste)
    virt_infra_host_networks:
      absent:
        - name: "other"
      present:
        - name: "default"
          ip_address: "192.168.112.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.112.2"
          dhcp_end: "192.168.112.254"
        - name: "example"
          ip_address: "192.168.113.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.113.2"
          dhcp_end: "192.168.113.99"

Hier ist ein Beispiel für ein Gästeinventar namens simple.yml, das CentOS Stream 8-Gäste in einer Gruppe namens simple definiert und die Standardwerte der Rolle verwendet.

---
## Inventar im YAML-Format, siehe:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
simple:
  hosts:
    centos-simple-[0:2]:
      ansible_python_interpreter: /usr/libexec/platform-python

Wenn Sie eine Gruppe von VMs möchten, die alle gleich sind, setzen Sie die Variablen auf der Hostgruppenebene. Sie können jedoch weiterhin Variablen der Hostgruppe mit einzelnen Variablen für bestimmte Hosts überschreiben, falls erforderlich.

Hier ein Beispiel, wie verschiedene Hostgruppen- und individuelle Hostvariablen gesetzt werden.

---
## Inventar im YAML-Format, siehe:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
example:
  hosts:
    centos-7-example:
      virt_infra_state: shutdown
      virt_infra_timezone: "Australien/Melbourne"
      ansible_python_interpreter: /usr/bin/python
      virt_infra_networks:
        - name: "br0"
          type: bridge
        - name: "extra_network"
          type: nat
          model: e1000
        - name: ovs-bridge
          portgroup: ovs-portgroup
          type: ovs
      virt_infra_disks:
        - name: "boot"
        - name: "nvme"
          size: "100"
          bus: "nvme"
    centos-8-example:
      virt_infra_timezone: "Australien/Adelaide"
      ansible_python_interpreter: /usr/libexec/platform-python
    opensuse-15-example:
      virt_infra_distro: opensuse
      virt_infra_distro_image: openSUSE-Leap-15.1-JeOS.x86_64-15.1.0-OpenStack-Cloud-Current.qcow2
      virt_infra_variant: opensuse15.1
      virt_infra_disks:
        - name: "boot"
          bus: "scsi"
    ubuntu-eoan-example:
      virt_infra_cpu: 2
      virt_infra_distro: ubuntu
      virt_infra_distro_image: eoan-server-cloudimg-amd64.img
      virt_infra_variant: ubuntu18.04
  vars:
    virt_infra_ram: 1024
    virt_infra_disks:
      - name: "boot"
      - name: "data"
        bus: "sata"
    virt_infra_networks:
      - name: "example"
        type: nat

Mehrere KVM-Hosts

Sie können auch mehrere KVM-Hosts angeben.

---
kvmhost:
  hosts:
    kvmhost1:
    kvmhost2:
    kvmhost3:
  vars:
    ansible_python_interpreter: /usr/bin/python3
    virt_infra_host_networks:
      absent: []
      present:
        - name: "default"
          ip_address: "192.168.112.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.112.2"
          dhcp_end: "192.168.112.254"

Um eine VM auf einem bestimmten KVM-Host zu platzieren, müssen Sie die Variable kvmhost mit einer Zeichenfolge hinzufügen, die mit einem KVM-Host aus der Gruppe kvmhost übereinstimmt.

Beispielsweise sechs CentOS Stream 8-Hosts auf drei KVM-Hosts.

---
simple:
  hosts:
    simple-centos-[1:2]:
      kvmhost: kvmhost1
    simple-centos-[3:4]:
      kvmhost: kvmhost2
    simple-centos-[5:6]:
      kvmhost: kvmhost3
  vars:
    ansible_python_interpreter: /usr/libexec/platform-python
    virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"

Wenn kein KVM-Host für eine VM angegeben ist, wird standardmäßig der erste KVM-Host in der Gruppe kvmhost verwendet (d. h. kvmhost[0]), was dem ursprünglichen Verhalten der Rolle entspricht.

Die Validierungsprüfungen wurden aktualisiert, um sicherzustellen, dass alle KVM-Hosts gültig sind und dass jeder angegebene KVM-Host für eine VM in der Gruppe kvmhost enthalten ist.

Um VMs auf bestimmten KVM-Hosts zu gruppieren, ziehen Sie in Betracht, Untergruppen zu erstellen und das kvmhost auf der Ebene der Untergruppe anzugeben.

Beispielsweise erneut diese CentOS Stream 8-Gäste.

---
simple:
  hosts:
    simple-centos-[1:6]:
  vars:
    ansible_python_interpreter: /usr/libexec/platform-python
    virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"
  children:
    simple_kvmhost1:
      hosts:
        simple-centos-[1:2]:
      vars:
        kvmhost: kvmhost1
    simple_kvmhost2:
      hosts:
        simple-centos-[3:4]:
      vars:
        kvmhost: kvmhost2
    simple_kvmhost3:
      hosts:
        simple-centos-[5:6]:
      vars:
        kvmhost: kvmhost3

Beispiel-Playbook

Ich habe versucht, das Ansible als eine einfache, logische Reihe von Schritten zu halten und nicht zu kompliziert zu machen. Dennoch ist das Playbook ziemlich spezifisch.

Es gibt einige Aufgaben, die nur auf dem KVM-Host ausgeführt werden können und andere in einer bestimmten Reihenfolge.

Dieser Code macht Ihnen die Arbeit leichter, indem er eine Reihe von Validierungsprüfungen auf dem KVM-Host und für Ihre Gastkonfigurationen durchführt, um zu versuchen, alles, was nicht stimmt, aufzufangen.

Hier ist ein Beispiel-Playbook virt-infra.yml, das die Rolle aufruft.

---
- hosts: all
  gather_facts: no
  roles:
    - ansible-role-virt-infra

Cloud-Image abrufen

Bevor wir das Playbook ausführen, laden Sie das CentOS Stream 8-Cloud-Image herunter.

curl -O https://cloud.centos.org/centos/8/x86_64/images/CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2
sudo mv -iv CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2 /var/lib/libvirt/images/

Playbook ausführen

Jetzt führen Sie das Ansible-Playbook gegen den KVM-Host und die Gäste in der Gruppe simple unter Verwendung der obigen Inventardatei aus (beachten Sie, dass wir sowohl die kvmhost- als auch die simple-Hostgruppen einschränken).

ansible-playbook \
--ask-become-pass \
--inventory ./inventory.d \
--limit kvmhost,simple \
./virt-infra.yml

Sie können auch viele Gäst Einstellungen an der Kommandozeile überschreiben.

ansible-playbook \
--ask-become-pass \
--limit kvmhost,simple \
./virt-infra.yml \
-e virt_infra_root_password=password \
-e virt_infra_disk_size=100 \
-e virt_infra_ram=4096 \
-e virt_infra_ram_max=8192 \
-e virt_infra_cpus=8 \
-e virt_infra_cpus_max=16 \
-e '{ "virt_infra_networks": [{ "name": "br0", "type": "bridge" }] }' \
-e virt_infra_state=running

Aufräumen

Um die Gäste in einer Hostgruppe zu löschen, könnten Sie sie (oder einen bestimmten Host) mit --limit angeben und das Argument virt_infra_state=undefined als zusätzliche Befehlszeilenargument übergeben.

Dies wird den Status des Gastes auf undefiniert ändern und, falls sie existieren, werden sie gelöscht.

Um beispielsweise alle VMs in der simple-Hostgruppe zu löschen.

ansible-playbook \
--ask-become-pass \
--inventory simple.yml \
--limit kvmhost,simple \
--extra-vars virt_infra_state=undefined \
./virt-infra.yml

Wenn Sie sie einfach nur herunterfahren möchten, versuchen Sie es stattdessen mit virt_infra_state=shutdown.

Zum Beispiel, um nur den simple-centos-2-Host herunterzufahren.

ansible-playbook \
--ask-become-pass \
--inventory simple.yml \
--limit kvmhost,simple-centos-2 \
--extra-vars virt_infra_state=shutdown \
./virt-infra.yml

Post-Setup-Konfiguration

Sobald Sie Ihre Infrastruktur eingerichtet haben, könnten Sie ein weiteres Playbook gegen dasselbe Inventar ausführen, um zu tun, was Sie mit diesen Maschinen möchten...

---
- hosts: all,!kvmhost
  tasks:
    - name: Upgrade aller Pakete
      package:
        name: '*'
        state: latest
      become: true
      register: result_package_update
      retries: 30
      delay: 10
      until: result_package_update is succeeded

    - name: Pakete installieren
      package:
        name:
          - git
          - tmux
          - vim
        state: present
      become: true
      register: result_package_install
      retries: 30
      delay: 10
      until: result_package_install is succeeded