Nächste: , Vorige: , Nach oben: Dienste   [Inhalt][Index]


12.9.29 Virtualisierungsdienste

Das Modul (gnu services virtualization) bietet Dienste für die Daemons von libvirt und virtlog, sowie andere virtualisierungsbezogene Dienste.

Libvirt-Daemon

libvirtd ist die serverseitige Daemon-Komponente des libvirt-Systems zur Virtualisierungsverwaltung. Dieser Daemon läuft auf als Wirt dienenden Servern und führt anfallende Verwaltungsaufgaben für virtualisierte Gäste durch.

Scheme-Variable: libvirt-service-type

Dies ist der Diensttyp des libvirt-Daemons. Sein Wert muss ein libvirt-configuration-Verbundsobjekt sein.

(service libvirt-service-type
         (libvirt-configuration
          (unix-sock-group "libvirt")
          (tls-port "16555")))

Verfügbare libvirt-configuration-Felder sind:

libvirt-configuration-Parameter: „package“ libvirt

Libvirt-Paket.

libvirt-configuration-Parameter: Boolescher-Ausdruck listen-tls?

Option zum Lauschen auf sichere TLS-Verbindungen über den öffentlichen TCP/IP-Port. listen muss gesetzt sein, damit dies eine Wirkung hat.

Bevor Sie diese Funktionalität nutzen können, muss eine Zertifikatsautorität eingerichtet worden sein und Server-Zertifikate ausgestellt worden sein.

Die Vorgabe ist ‘#t’.

libvirt-configuration-Parameter: Boolescher-Ausdruck listen-tcp?

Auf unverschlüsselte TCP-Verbindungen auf dem öffentlichen TCP/IP-Port lauschen. listen muss gesetzt sein, damit dies eine Wirkung hat.

Nach Voreinstellung kann auf dem TCP-Socket nur gelauscht werden, wenn SASL-Authentifizierung möglich ist. Nur solche SASL-Mechanismen, die Datenverschlüsselung unterstützen, sind zugelassen. Das sind DIGEST_MD5 und GSSAPI (Kerberos5).

Vorgegeben ist ‘#f’.

libvirt-configuration-Parameter: Zeichenkette tls-port

Der Port, um sichere TLS-Verbindungen zu akzeptieren. Dies kann eine Portnummer oder ein Dienstname sein.

Die Vorgabe ist ‘"16514"’.

libvirt-configuration-Parameter: Zeichenkette tcp-port

Der Port, um unsichere TCP-Verbindungen zu akzeptieren. Dies kann eine Portnummer oder ein Dienstname sein.

Die Vorgabe ist ‘"16509"’.

libvirt-configuration-Parameter: Zeichenkette listen-addr

IP-Adresse oder Rechnername („Hostname“), der für von Clients ausgehende Verbindungen benutzt wird.

Die Vorgabe ist ‘"0.0.0.0"’.

libvirt-configuration-Parameter: Boolescher-Ausdruck mdns-adv?

Einstellung, ob der libvirt-Dienst mDNS-Mitteilungen sendet.

Dies kann alternativ für alle Dienste auf einem Rechner deaktiviert werden, indem man den Avahi-Daemon anhält.

Vorgegeben ist ‘#f’.

libvirt-configuration-Parameter: Zeichenkette mdns-name

Der voreingestellte Name in mDNS-Mitteilungen. Er muss auf dem direkten Broadcast-Netzwerk eindeutig sein.

Die Vorgabe ist ‘"Virtualization Host <Rechnername>"’.

libvirt-configuration-Parameter: Zeichenkette unix-sock-group

Besitzergruppe des UNIX-Sockets. Diese Einstellung kann benutzt werden, um einer als vertrauenswürdig geltenden Gruppe von Benutzern Zugriff auf Verwaltungsfunktionen zu gewähren, ohne dass diese als Administratornutzer root ausgeführt werden müssen.

Die Vorgabe ist ‘"root"’.

libvirt-configuration-Parameter: Zeichenkette unix-sock-ro-perms

UNIX-Socket-Berechtigungen für den Socket nur mit Lesezugriff („read only“). Dies wird nur zur Überwachung des Zustands der VM benutzt.

Die Vorgabe ist ‘"0777"’.

libvirt-configuration-Parameter: Zeichenkette unix-sock-rw-perms

UNIX-Socket-Berechtigungen für den Socket mit Schreib- und Lesezugriff („read/write“). Nach Vorgabe kann nur der Administratornutzer root zugreifen. Wenn auf dem Socket PolicyKit aktiviert ist, wird die Vorgabe geändert, dass jeder zugreifen kann (z.B. zu 0777)

Die Vorgabe ist ‘"0770"’.

libvirt-configuration-Parameter: Zeichenkette unix-sock-admin-perms

UNIX-Socket-Berechtigungen für den Administrator-Socket. Nach Vorgabg hat nur der Besitzer (der Administratornutzer root) hierauf Zugriff; ändern Sie es nur, wenn Sie sicher wissen, wer dann alles Zugriff bekommt.

Die Vorgabe ist ‘"0777"’.

libvirt-configuration-Parameter: Zeichenkette unix-sock-dir

Das Verzeichnis, in dem Sockets gefunden werden können bzw. erstellt werden.

Die Vorgabe ist ‘"/var/run/libvirt"’.

libvirt-configuration-Parameter: Zeichenkette auth-unix-ro

Authentifizierungsschema für nur lesbare UNIX-Sockets. Nach Vorgabe gestatten es die Socket-Berechtigungen jedem Nutzer, sich zu verbinden.

Die Vorgabe ist ‘"polkit"’.

libvirt-configuration-Parameter: Zeichenkette auth-unix-rw

Authentifizierungsschema für UNIX-Sockets mit Schreib- und Lesezugriff. Nach Vorgabe erlauben die Socket-Berechtigungen nur dem Administratornutzer root Zugriff. Wenn libvirt mit Unterstützung für PolicyKit kompiliert wurde, ist die Vorgabe, Authentifizierung über „polkit“ durchzuführen.

Die Vorgabe ist ‘"polkit"’.

libvirt-configuration-Parameter: Zeichenkette auth-tcp

Authentifizierungsschema für TCP-Sockets. Wenn Sie SASL nicht aktivieren, dann wird alle TCP-Kommunikation im Klartext verschickt. Tun Sie dies nicht, außer Sie benutzen libvirt nur als Entwickler oder zum Testen.

Die Vorgabe ist ‘"sasl"’.

libvirt-configuration-Parameter: Zeichenkette auth-tls

Authentifizierungsschema für TLS-Sockets. Für TLS-Sockets wird bereits durch die TLS-Schicht Verschlüsselung bereitgestellt und eingeschränkte Authentifizierung wird über Zertifikate durchgeführt.

Es ist möglich, auch hier den SASL-Authentifizierungsmechanismus anzuwenden, indem Sie für diese Option „sasl“ eintragen.

Die Vorgabe ist ‘"none"’, d.h. keine zusätzliche Authentifizierung.

libvirt-configuration-Parameter: Optional-nichtleere-Liste access-drivers

Welche Schemata zur Zugriffskontrolle auf Programmierschnittstellen (APIs) benutzt werden.

Nach Vorgabe kann ein authentifizierter Nutzer auf alle Programmierschnittstellen zugreifen. Zugriffstreiber können dies einschränken.

Die Vorgabe ist ‘()’.

libvirt-configuration-Parameter: Zeichenkette key-file

Pfad zur Schlüsseldatei für den Server. Wenn er auf eine leere Zeichenkette gesetzt ist, dann wird kein privater Schlüssel geladen.

Die Vorgabe ist ‘""’.

libvirt-configuration-Parameter: Zeichenkette cert-file

Pfad zur Zertifikatsdatei für den Server. Wenn er auf eine leere Zeichenkette gesetzt ist, dann wird kein Zertifikat geladen.

Die Vorgabe ist ‘""’.

libvirt-configuration-Parameter: Zeichenkette ca-file

Pfad zur Datei mit dem Zertifikat der Zertifikatsautorität. Wenn er auf eine leere Zeichenkette gesetzt ist, dann wird kein Zertifikat der Zertifikatsautorität geladen.

Die Vorgabe ist ‘""’.

libvirt-configuration-Parameter: Zeichenkette crl-file

Pfad zur Zertifikatssperrliste („Certificate Revocation List“). Wenn er auf eine leere Zeichenkette gesetzt ist, dann wird keine Zertifikatssperrliste geladen.

Die Vorgabe ist ‘""’.

libvirt-configuration-Parameter: Boolescher-Ausdruck tls-no-sanity-cert

Keine Überprüfung unseres eigenen Serverzertifikats durchführen.

Beim Start vom libvirtd prüft dieser, ob bei seinem eigenen Zertifikat alles in Ordnung ist.

Vorgegeben ist ‘#f’.

libvirt-configuration-Parameter: Boolescher-Ausdruck tls-no-verify-cert

Keine Überprüfung von Clientzertifikaten durchführen.

Die Überprüfung des Zertifikats eines Clients ist der primäre Authentifizierungsmechanismus. Jeder Client, der kein von der Zertifikatsautorität signiertes Zertifikat vorweist, wird abgelehnt.

Vorgegeben ist ‘#f’.

libvirt-configuration-Parameter: Optional-nichtleere-Liste tls-allowed-dn-list

Liste der erlaubten Einträge für den „Distinguished Name“ bei x509.

Die Vorgabe ist ‘()’.

libvirt-configuration-Parameter: Optional-nichtleere-Liste sasl-allowed-usernames

Liste der erlaubten Einträge für SASL-Benutzernamen. Wie Benutzernamen aussehen müssen, ist abhängig vom jeweiligen SASL-Mechanismus.

Die Vorgabe ist ‘()’.

libvirt-configuration-Parameter: Zeichenkette tls-priority

Dies wird vorrangig statt der beim Kompilieren voreingestellten TLS-Prioritätszeichenkette verwendet. Die Voreinstellung ist in der Regel ‘"NORMAL"’, solange dies nicht bei der Erstellung geändert wurde. Ändern Sie dies nur, wenn die Einstellungen für libvirt von den globalen Voreinstellungen abweichen sollen.

Die Vorgabe ‘"NORMAL"’.

libvirt-configuration-Parameter: Ganze-Zahl max-clients

Maximalzahl gleichzeitiger Client-Verbindungen, die für alle Sockets zusammen zugelassen werden sollen.

Die Vorgabe ist ‘5000’.

libvirt-configuration-Parameter: Ganze-Zahl max-queued-clients

Maximale Länge der Warteschlange für Verbindungen, die darauf warten, vom Daemon angenommen zu werden. Beachten Sie, dass sich manche Protokolle, die Neuübertragung unterstützen, danach richten könnten, damit ein erneuter Verbindungsversuch angenommen wird.

Die Vorgabe ist ‘1000’.

libvirt-configuration-Parameter: Ganze-Zahl max-anonymous-clients

Maximale Länge der Warteschlange für Clients, die angenommen wurden, aber noch nicht authentifiziert wurden. Setzen Sie dies auf null, um diese Funktionalität abzuschalten.

Die Vorgabe ist ‘20’.

libvirt-configuration-Parameter: Ganze-Zahl min-workers

Anzahl an Arbeiter-Threads, die am Anfang gestartet werden sollen.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl max-workers

Maximale Anzahl an Arbeiter-Threads.

Wenn die Anzahl aktiver Clients die min-workers übersteigt, werden weitere Threads erzeugt, bis die max_workers-Beschränkung erreicht wurde. Typischerweise würden Sie für max_workers die maximale Anzahl zugelassener Clients angeben.

Die Vorgabe ist ‘20’.

libvirt-configuration-Parameter: Ganze-Zahl prio-workers

Die Anzahl priorisierter Arbeiter-Threads. Wenn alle Arbeiter aus diesem Pool festhängen, können manche, mit hoher Priorität versehene Aufrufe (speziell domainDestroy) in diesem Pool hier ausgeführt werden.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl max-requests

Wie viele nebenläufige RPC-Aufrufe global ausgeführt werden können.

Die Vorgabe ist ‘20’.

libvirt-configuration-Parameter: Ganze-Zahl max-client-requests

Wie viele nebenläufige Anfragen von einer einzelnen Client-Verbindung ausgehen können. Um zu verhindern, dass ein einzelner Client den gesamten Server für sich beansprucht, sollte der Wert hier nur einen kleinen Teil der globalen max_requests- und max_workers-Parameter ausmachen.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-min-workers

Wie bei min-workers, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘1’.

libvirt-configuration-Parameter: Ganze-Zahl admin-max-workers

Wie bei max-workers, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-max-clients

Wie bei max-clients, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-max-queued-clients

Wie bei max-queued-clients, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-max-client-requests

Wie bei max-client-requests, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl log-level

Protokollstufe. 4 für Fehler, 3 für Warnungen, 2 für Informationen, 1 zur Fehlersuche.

Die Vorgabe ist ‘3’.

libvirt-configuration-Parameter: Zeichenkette log-filters

Protokollfilter.

Ein Filter ermöglicht es, für eine bestimmte Kategorie von Protokollen eine andere Protokollierungsstufe festzulegen. Filter müssen eines der folgenden Formate haben:

  • x:Name
  • x:+Name

wobei Name eine Zeichenkette ist, die zu einer in der Umgebungsvariablen VIR_LOG_INIT() am Anfang jeder Quelldatei von libvirt angegebenen Kategorie passen muss, z.B. ‘"remote"’, ‘"qemu"’ oder ‘"util.json"’ (der Name im Filter kann auch nur ein Teil des vollständigen Kategoriennamens sein, wodurch mehrere, ähnliche passende Kategoriennamen möglich sind). Das optionale Präfix „+“ bedeutet, dass libvirt eine Rückverfolgung (d.h. ein „Stack Trace“) für jede zum Namen passende Nachricht ins Protokoll schreiben soll. x benennt jeweils die kleinste Stufe, deren passende Nachrichten protokolliert werden sollen.

  • 1: Fehlersuche („DEBUG“)
  • 2: Informationen („INFO“)
  • 3: Warnungen („WARNING“)
  • 4: Fehler („ERROR“)

Mehrere Filter können in einer einzelnen Filteranweisung definiert werden; sie müssen nur durch Leerzeichen voneinander getrennt werden.

Die Vorgabe ist ‘"3:remote 4:event"’.

libvirt-configuration-Parameter: Zeichenkette log-outputs

Ausgaben für die Protokollierung.

Eine Ausgabe ist einer der Orte, wohin Informationen aus der Protokollierung gespeichert werden. Eine Ausgabe kann auf eine der folgenden Arten angegeben werden:

x:stderr

Protokolle werden auf der Standardausgabe („Stderr“) ausgegeben.

x:syslog:Name

Syslog wird zur Ausgabe benutzt. Der Name dient dabei als Identifikator für libvirt-Protokolle.

x:file:Dateipfad

Protokolle werden in die Datei unter dem angegebenen Dateipfad ausgegeben.

x:journald

Die Ausgabe läuft über das journald-Protokollsystem.

In allen Fällen steht das x vorne für die kleinste Stufe und wirkt als Filter.

  • 1: Fehlersuche („DEBUG“)
  • 2: Informationen („INFO“)
  • 3: Warnungen („WARNING“)
  • 4: Fehler („ERROR“)

Mehrere Ausgaben können definiert werden, dazu müssen sie nur durch Leerzeichen getrennt hier angegeben werden.

Die Vorgabe ist ‘"3:stderr"’.

libvirt-configuration-Parameter: Ganze-Zahl audit-level

Ermöglicht Anpassungen am Auditierungs-Subsystem.

  • 0: Jegliche Auditierung deaktivieren.
  • 1: Auditierung nur aktivieren, wenn sie beim Wirtssystem aktiviert ist.
  • 2: Auditierung aktivieren. Beenden, wenn das Wirtssystem Auditierung deaktiviert hat.

Die Vorgabe ist ‘1’.

libvirt-configuration-Parameter: Boolescher-Ausdruck audit-logging

Audit-Nachrichten über die Protokollinfrastruktur von libvirt versenden.

Vorgegeben ist ‘#f’.

libvirt-configuration-Parameter: Optional-nichtleere-Zeichenkette host-uuid

Für das Wirtssystem zu verwendende UUID. Bei der UUID dürfen nicht alle Ziffern gleich sein.

Die Vorgabe ist ‘""’.

libvirt-configuration-Parameter: Zeichenkette host-uuid-source

Die Quelle, von der die UUID des Wirtssystems genommen wird.

  • smbios: Die UUID von dmidecode -s system-uuid holen.
  • machine-id: Die UUID aus /etc/machine-id holen.

Falls dmidecode keine gültige UUID liefert, wird eine temporäre UUID generiert.

Die Vorgabe ist ‘"smbios"’.

libvirt-configuration-Parameter: Ganze-Zahl keepalive-interval

Einem Client wird eine Nachricht zum Aufrechterhalten der Verbindung gesendet, nachdem keepalive_interval Sekunden lang keine Aktivität stattgefunden hat. Damit kann überprüft werden, ob der Client noch antwortet. Wird dieses Feld auf -1 gesetzt, wird libvirtd niemals Aufrechterhaltungsanfragen senden; Clients können diese aber weiterhin dem Daemon schicken und er wird auf diese antworten.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl keepalive-count

Wie viele Aufrechterhaltungsnachrichten höchstens zum Client geschickt werden dürfen, ohne dass eine Antwort zurückgekommen ist, bevor die Verbindung als abgebrochen gilt.

Mit anderen Worten wird die Verbindung ungefähr dann automatisch geschlossen, wenn keepalive_interval * (keepalive_count + 1) Sekunden seit der letzten vom Client empfangenen Nachricht vergangen sind. Wenn keepalive-count auf 0 gesetzt ist, werden Verbindungen dann automatisch geschlossen, wenn keepalive-interval Sekunden der Inaktivität vorausgegangen sind, ohne dass eine Aufrechterhaltungsnachricht versandt wurde.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-keepalive-interval

Wie oben, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl admin-keepalive-count

Wie oben, aber für die Administratorschnittstelle.

Die Vorgabe ist ‘5’.

libvirt-configuration-Parameter: Ganze-Zahl ovs-timeout

Zeitbeschränkung für Aufrufe über Open vSwitch.

Das Werkzeug ovs-vsctl wird zur Konfiguration benutzt; die dort eingestellte Zeitbeschränkung ist nach Voreinstellung auf 5 Sekunden festgelegt, um zu verhindern, dass libvirt durch unbegrenztes Warten blockiert werden kann.

Die Vorgabe ist ‘5’.

Virtlog-Daemon

Der virtlogd-Dienst ist eine serverseitige Daemon-Komponente von libvirt, die benutzt wird, um Protokolle der Konsolen von virtuellen Maschinen zu verwalten.

Dieser Daemon wird von libvirt-Clientanwendungen nicht direkt benutzt, sondern wird an deren Stelle vom libvirtd aufgerufen. Indem die Protokolle in einem eigenständigen Daemon vorgehalten werden, kann der eigentliche libvirtd-Daemon neu gestartet werden, ohne dass man riskiert, Protokolle zu verlieren. Der virtlogd-Daemon hat die Fähigkeit, sich selbst erneut mit exec() zu starten, wenn er SIGUSR1 empfängt, damit Aktualisierungen ohne Ausfall möglich sind.

Scheme-Variable: virtlog-service-type

Dies ist der Diensttyp des virtlog-Daemons. Sein Wert muss eine virtlog-configuration sein.

(service virtlog-service-type
         (virtlog-configuration
          (max-clients 1000)))
Variable: libvirt-Parameter „package“ libvirt

Libvirt-Paket.

virtlog-configuration-Parameter: Ganze-Zahl log-level

Protokollstufe. 4 für Fehler, 3 für Warnungen, 2 für Informationen, 1 zur Fehlersuche.

Die Vorgabe ist ‘3’.

virtlog-configuration-Parameter: Zeichenkette log-filters

Protokollfilter.

Ein Filter ermöglicht es, für eine bestimmte Kategorie von Protokollen eine andere Protokollierungsstufe festzulegen. Filter müssen eines der folgenden Formate haben:

  • x:Name
  • x:+Name

wobei Name eine Zeichenkette ist, die zu einer in der Umgebungsvariablen VIR_LOG_INIT() am Anfang jeder Quelldatei von libvirt angegebenen Kategorie passen muss, z.B. „remote“, „qemu“ oder „util.json“ (der Name im Filter kann auch nur ein Teil des vollständigen Kategoriennamens sein, wodurch mehrere, ähnliche passende Kategoriennamen möglich sind). Das optionale Präfix „+“ bedeutet, dass libvirt eine Rückverfolgung (d.h. ein „Stack Trace“) für jede zum Namen passende Nachricht ins Protokoll schreiben soll. x benennt jeweils die kleinste Stufe, deren passende Nachrichten protokolliert werden sollen.

  • 1: Fehlersuche („DEBUG“)
  • 2: Informationen („INFO“)
  • 3: Warnungen („WARNING“)
  • 4: Fehler („ERROR“)

Mehrere Filter können in einer einzelnen Filteranweisung definiert werden; sie müssen nur durch Leerzeichen voneinander getrennt werden.

Die Vorgabe ist ‘"3:remote 4:event"’.

virtlog-configuration-Parameter: Zeichenkette log-outputs

Ausgaben für die Protokollierung.

Als Ausgabe bezeichnen wir einen der Orte, an denen Protokollinformationen gespeichert werden. Eine Ausgabe wird auf eine der folgenden Arten angegeben:

x:stderr

Protokolle werden auf der Standardausgabe („Stderr“) ausgegeben.

x:syslog:Name

Syslog wird zur Ausgabe benutzt. Der Name dient dabei als Identifikator für libvirt-Protokolle.

x:file:Dateipfad

Protokolle werden in die Datei unter dem angegebenen Dateipfad ausgegeben.

x:journald

Die Ausgabe läuft über das journald-Protokollsystem.

In allen Fällen steht das x vorne für die kleinste Stufe und wirkt als Filter.

  • 1: Fehlersuche („DEBUG“)
  • 2: Informationen („INFO“)
  • 3: Warnungen („WARNING“)
  • 4: Fehler („ERROR“)

Mehrere Ausgaben können definiert werden, dazu müssen sie nur durch Leerzeichen getrennt hier angegeben werden.

Die Vorgabe ist ‘"3:stderr"’.

virtlog-configuration-Parameter: Ganze-Zahl max-clients

Maximalzahl gleichzeitiger Client-Verbindungen, die für alle Sockets zusammen zugelassen werden sollen.

Die Vorgabe ist ‘1024’.

virtlog-configuration-Parameter: Ganze-Zahl max-size

Wie groß eine Protokolldatei werden darf, bevor eine neue begonnen wird.

Die Vorgabe ist ‘2MB’.

virtlog-configuration-Parameter: Ganze-Zahl max-backups

Wie viele Dateien mit Sicherungskopien gespeichert bleiben sollen.

Die Vorgabe ist ‘3’.

Transparente Emulation mit QEMU

Mit qemu-binfmt-service-type wird transparente Emulation von Programm-Binärdateien, die für unterschiedliche Architekturen erstellt wurden, ermöglicht. Z.B. können Sie ein ARMv7-Programm „einfach so“ transparent auf einer x86_64-Maschine ausführen. Dazu wird der QEMU-Emulator mit der binfmt_misc-Funktionalität des Kernels Linux kombiniert. Mit dieser Funktionalität können Sie jedoch nur ein GNU/Linux-System, das auf einer anderen Architektur läuft, emulieren. Unterstützung für GNU/Hurd ist auch möglich, lesen Sie dazu unten weiter.

Scheme-Variable: qemu-binfmt-service-type

Dies ist der Diensttyp des QEMU/binfmt-Dienstes für transparente Emulation. Sein Wert muss ein qemu-binfmt-configuration-Objekt sein, das das QEMU-Paket angibt, das benutzt werden soll, sowie die Architektur, die wir emulieren möchten.

In diesem Beispiel aktivieren wir transparente Emulation für die Plattformen ARM und aarch64. Wenn wir herd stop qemu-binfmt ausführen, wird diese abgeschaltet, und mit herd start qemu-binfmt wird sie wieder aktiv (siehe den herd-Befehl in The GNU Shepherd Manual).

Datentyp: qemu-binfmt-configuration

Dies ist die Konfiguration des qemu-binfmt-Dienstes.

platforms (Vorgabe: '())

Die Liste der emulierten QEMU-Plattformen. Jeder Eintrag muss ein Plattformobjekt sein, wie lookup-qemu-platforms eines zurückliefert (siehe unten).

Wenn wir zum Beispiel annehmen, Sie arbeiten auf einer x86_64-Maschine und haben diesen Dienst eingerichtet:

Dann können Sie das hier ausführen:

guix build -s armhf-linux inkscape

und alles verhält sich so, als würden Sie Inkscape für ARMv7 wie „nativ“ auf einem ARM-Rechner erstellen, wozu QEMU transparent benutzt wird, um den ARMv7-Prozessor zu emulieren. Das ist ganz schön praktisch, wenn Sie testen wollen, ob ein Paket für eine Architektur erstellt werden kann, die Ihnen nicht zur Verfügung steht.

qemu (Vorgabe: qemu)

Das QEMU-Paket, das benutzt werden soll.

Scheme-Prozedur: lookup-qemu-platforms Plattformen

Liefert die Liste der QEMU-Plattformobjekte, die den Plattformen… entsprechen. Plattformen muss eine Liste von Zeichenketten sein, die den Namen der Plattformen entsprechen, wie z.B. "arm", "sparc", "mips64el" und so weiter.

Scheme-Prozedur: qemu-platform? Objekt

Liefert wahr, wenn das Objekt ein Plattformobjekt ist.

Scheme-Prozedur: qemu-platform-name Plattform

Liefert den Namen der Plattform, also eine Zeichenkette wie z.B. "arm".

QEMU Guest Agent

Mit dem QEMU Guest Agent kann das emulierte System vom Wirtssystem aus gesteuert werden. Der Dienst für den qemu-guest-agent führt den Agenten auf einem Guix-basierten Gastsystem aus. Um den Agenten vom Wirt aus zu steuern, öffnen Sie einen Socket, indem Sie QEMU mit folgenden Argumenten aufrufen:

qemu-system-x86_64 \
	-chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 \
	-device virtio-serial \
	-device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \
	…

Dadurch wird auf dem Wirtssystem ein Socket unter /tmp/qga.sock angelegt. Sobald der Guest Agent gestartet hat, können Sie mit socat Befehle erteilen:

$ guix shell socat -- socat unix-connect:/tmp/qga.sock stdio
{"execute": "guest-get-host-name"}
{"return": {"host-name": "guix"}}

Siehe die Dokumentation zum QEMU Guest Agent für mehr Optionen und Befehle.

Scheme-Variable: qemu-guest-agent-service-type

Diensttyp des Dienstes für den QEMU Guest Agent.

Datentyp: qemu-guest-agent-configuration

Die Konfiguration des qemu-guest-agent-Dienstes.

qemu (Vorgabe: qemu-minimal)

Das QEMU-Paket, das benutzt werden soll.

device (Vorgabe: "")

Der Dateiname des Geräts bzw. Sockets, über das der Agent mit dem Wirtssystem kommuniziert. Wird nichts angegeben, verwendet QEMU einen voreingestellten Dateinamen.

GNU Hurd in einer virtuellen Maschine

Der hurd-vm-Dienst bietet Unterstützung, um GNU/Hurd in einer virtuellen Maschine (VM) laufen zu lassen, als eine sogenannte „Kind-Hurd“, englisch Childhurd. Der Dienst ist für die Nutzung mit GNU/Linux-Systemen gedacht; die angegebene GNU/Hurd-Konfiguration wird cross-kompiliert. Die virtuelle Maschine läuft als ein Shepherd-Dienst, der durch Namen wie hurd-vm und childhurd bezeichnet wird und mit Befehlen wie den folgenden gesteuert werden kann:

herd start hurd-vm
herd stop childhurd

Während der Dienst läuft, können Sie seine Konsole anzeigen lassen, indem Sie sich über einen VNC-Client mit ihm verbinden, z.B. durch den Befehl:

guix shell tigervnc-client -- vncviewer localhost:5900

Die Vorgabekonfiguration (siehe hurd-vm-configuration unten) lässt einen Server für Secure Shell (SSH) in Ihrem GNU/Hurd-System laufen, welchen QEMU (der Emulator für virtuelle Maschinen) an Port 10222 des Wirtssystems weitergibt. So können Sie sich mit der Childhurd über SSH verbinden:

ssh root@localhost -p 10022

Die Childhurd ist flüchtig und zustandslos: Jedes Mal, wenn Sie sie neu starten, hat sie wieder ihr ursprüngliches Wurzeldateisystem. Nur die Dateien unter /etc/childhurd im Wirtssystem werden nach Vorgabe in das Wurzeldateisystem der Childhurd übernommen, wenn sie startet. So können Sie einen Startwert für „Geheimnisse“ in der VM angeben: SSH-Rechnerschlüssel („Host Keys“), Autorisierungsschlüssel für Substitute und so weiter – siehe die Erklärung zu secret-root unten.

Scheme-Variable: hurd-vm-service-type

Dies ist der Diensttyp zum Hurd-in-einer-virtuellen-Maschine-Dienst. Dessen Wert muss ein hurd-vm-configuration-Objekt sein, das das Betriebssystem festlegt (siehe operating-system-Referenz) und die Plattengröße für die virtuelle Hurd-Maschine, das zu nutzende QEMU-Paket sowie die Befehlszeilenoptionen, um sie auszuführen.

Zum Beispiel:

(service hurd-vm-service-type
         (hurd-vm-configuration
          (disk-size (* 5000 (expt 2 20))) ;5G
          (memory-size 1024)))             ;1024MiB

würde zur Erzeugung eines Disk-Images führen, dessen Größe für die Erstellung von GNU Hello ausreichend ist und das noch ein wenig zusätzlichen Arbeitsspeicher zur Verfügung stellt.

Datentyp: hurd-vm-configuration

Der Datentyp, der die Konfiguration des hurd-vm-service-type repräsentiert.

os (Vorgabe: %hurd-vm-operating-system)

Welches Betriebssystem instanziiert werden soll. Nach Vorgabe wird ein minimales „Bare-Bones“-System mit uneingeschränktem OpenSSH-Secure-Shell-Daemon, der auf Port 2222 lauscht (siehe openssh-service-type).

qemu (Vorgabe: qemu-minimal)

Das QEMU-Paket, das benutzt werden soll.

image (Vorgabe: hurd-vm-disk-image)

Die Prozedur, um das Disk-Image aus dieser Konfiguration zu erstellen.

disk-size (Vorgabe: 'guess)

Die Größe des Disk-Images.

memory-size (Vorgabe: 512)

Die Größe des Arbeitsspeichers der virtuellen Maschine in Mebibyte.

options (Vorgabe: '("--snapshot"))

Weitere Befehlszeilenoptionen, mit denen QEMU ausgeführt wird.

id (Vorgabe: #f)

Wenn das Feld gesetzt ist, muss es eine positive ganze Zahl größer null sein, womit Childhurd-Instanzen parametrisiert werden. Es wird an den Dienstnamen angehängt, z.B. childhurd1.

net-options (Vorgabe: hurd-vm-net-options)

Die Prozedur, um die Liste der QEMU-Netzwerkoptionen zu erzeugen.

Nach Vorgabe liefert sie

'("--device" "rtl8139,netdev=net0"
  "--netdev" (string-append
              "user,id=net0,"
              "hostfwd=tcp:127.0.0.1:secrets-port-:1004,"
              "hostfwd=tcp:127.0.0.1:ssh-port-:2222,"
              "hostfwd=tcp:127.0.0.1:vnc-port-:5900"))

mit Portweiterleitungen:

secrets-port: (+ 11004 (* 1000 ID))
ssh-port: (+ 10022 (* 1000 ID))
vnc-port: (+ 15900 (* 1000 ID))
secret-root (Vorgabe: /etc/childhurd)

Das Wurzelverzeichnis von Geheimnissen, die auf der Childhurd „out of band“, d.h. abseits vom Zuständigkeitsbereich der Childhurd, installiert werden sollen, sobald sie gestartet wurde. Childhurds sind flüchtig, d.h. bei jedem Start würden Geheimnisse wie die SSH-Rechnerschlüssel und Signierschlüssel von Guix neu angelegt.

Wenn das Verzeichnis /etc/childhurd nicht existiert, wird dem im Childhurd laufenden secret-service-Dienst eine leere Liste von Geheimnissen geschickt.

Üblicherweise wird er benutzt, um in "/etc/childhurd" einen Dateibaum aus nicht flüchtigen Geheimnissen einzufügen, wenn diese noch nicht existieren:

/etc/childhurd/etc/guix/acl
/etc/childhurd/etc/guix/signing-key.pub
/etc/childhurd/etc/guix/signing-key.sec
/etc/childhurd/etc/ssh/ssh_host_ed25519_key
/etc/childhurd/etc/ssh/ssh_host_ecdsa_key
/etc/childhurd/etc/ssh/ssh_host_ed25519_key.pub
/etc/childhurd/etc/ssh/ssh_host_ecdsa_key.pub

Diese Dateien werden automatisch an die Gast-Hurd-VM geschickt, wenn sie bootet, einschließlich der Dateiberechtigungen.

Wenn diese Dateien platziert wurden, fehlen nur noch wenige Dinge, damit das Wirtssystem i586-gnu-Erstellungen auf die Childhurd auslagern kann:

  1. Der Schlüssel der Childhurd muss auf dem Wirtssystem authentifiziert werden, damit das Wirtssystem von der Childhurd stammende Erstellungsergebnisse annimmt. Das geht so:
    guix archive --authorize < \
      /etc/childhurd/etc/guix/signing-key.pub
    
  2. Die Childhurd muss zu /etc/guix/machines.scm hinzugefügt werden (siehe Nutzung der Auslagerungsfunktionalität).

Wir arbeiten daran, dass das automatisch passiert. Reden Sie mit uns unter guix-devel@gnu.org, wenn Sie dabei mitdiskutieren möchten!

Beachten Sie, dass nach Vorgabe ein flüchtiges Abbild für die virtuelle Maschine benutzt wird, also dessen Inhalt verloren geht, sobald sie gestoppt wurde. Wenn Sie stattdessen ein zustandsbehaftetes Abbild möchten, ändern Sie die Felder image und options in der Konfiguration, so dass keine --snapshot-Befehlszeilenoption übergeben wird, z.B. so:

(service hurd-vm-service-type
         (hurd-vm-configuration
          (image   (const "/nicht/im/store/mit/schreibzugriff/hurd.img"))
          (options '())))

Ganeti

Anmerkung: Dieser Dienst gilt als experimentell. Die Konfigurationsoptionen könnten in Zukunft noch auf eine Weise abgeändert werden, die keine Kompatibilität mit dem momentanen Verhalten gewährleistet, und nicht alle Funktionalitäten wurden gründlich getestet. Wenn Sie ihn benutzen, ermutigen wir Sie, Ihre Erfahrungen mit uns über guix-devel@gnu.org zu teilen.

Ganeti ist ein System zur Verwaltung virtueller Maschinen. Es ist dafür gedacht, virtuelle Maschinen auf einem Server-Cluster am Laufen zu halten, selbst wenn Hardware ausfällt, und deren Wartung und Wiederherstellung einfach zu machen. Es besteht aus mehreren Diensten, die später in diesem Abschnitt beschrieben werden. Zusätzlich zum Ganeti-Dienst brauchen Sie den OpenSSH-Dienst (siehe openssh-service-type) und müssen in die Datei /etc/hosts (siehe hosts-file) den Namen des Clusters mit Adresse eintragen lassen (oder Sie verwenden einen eigenen DNS-Server).

Alle Knoten, die an einem Ganeti-Cluster teilnehmen, sollten dieselbe Konfiguration von Ganeti und /etc/hosts aufweisen. Hier ist eine Beispielkonfiguration für einen Ganeti-Clusterknoten, der mehrere Hintergrundsysteme für Speichergeräte unterstützt und die Betriebssystemanbieter („OS providers“) debootstrap sowie guix installiert hat:

(use-package-modules virtualization)
(use-service-modules base ganeti networking ssh)
(operating-system
  ;; …
  (host-name "node1")
  (hosts-file (plain-file "hosts" (format #f "
127.0.0.1       localhost
::1             localhost

192.168.1.200   ganeti.example.com
192.168.1.201   node1.example.com node1
192.168.1.202   node2.example.com node2
")))

  ;; QEMU installieren, damit wir auf KVM aufsetzende Instanzen benutzen
  ;; können, sowie LVM, DRBD und Ceph, damit wir die Speicher-Hintergrundsysteme
  ;; "plain", "drbd" und "rbd" benutzen können.
  (packages (append (map specification->package
                         '("qemu" "lvm2" "drbd-utils" "ceph"
                           ;; Betriebssystemanbieter debootstrap und guix:
                           "ganeti-instance-guix" "ganeti-instance-debootstrap"))
                    %base-packages))
  (services
   (append (list (service static-networking-service-type
                          (list (static-networking
                                 (addresses
                                  (list (network-address
                                         (device "eth0")
                                         (value "192.168.1.201/24"))))
                                 (routes
                                  (list (network-route
                                         (destination "default")
                                         (gateway "192.168.1.254"))))
                                 (name-servers '("192.168.1.252"
                                                 "192.168.1.253")))))

                 ;; Ganeti benutzt SSH für die Kommunikation zwischen Knoten.
                 (service openssh-service-type
                          (openssh-configuration
                           (permit-root-login 'prohibit-password)))

                 (service ganeti-service-type
                          (ganeti-configuration
                           ;; Diese Liste führt die Pfade im Dateisystem auf,
                           ;; wo Abbilder virtueller Maschinen gespeichert
                           ;; werden.
                           (file-storage-paths '("/srv/ganeti/file-storage"))
                           ;; In dieser Variablen konfigurieren wir eine einzige
                           ;; „Variante“ jeweils für sowohl Debootstrap als auch
                           ;; Guix, die KVM benutzt.
                           (os %default-ganeti-os))))
           %base-services)))

Benutzern wird geraten, die Anleitung für Ganeti-Administratoren zu lesen, um die verschiedenen Optionen für Ganeti-Cluster und die häufigen Operationen zu erlernen. Es gibt auch einen Blogeintrag, der beschreibt, wie man einen kleinen Cluster konfiguriert und initialisiert.

Scheme-Variable: ganeti-service-type

Dieser Diensttyp umfasst all die verschiedenen Dienste, die auf Ganeti-Knoten ausgeführt werden sollen.

Sein Wert ist ein ganeti-configuration-Objekt, das das Paket für den Betrieb über die Befehlszeile sowie die Konfiguration der einzelnen Daemons festlegt. Auch werden zulässige Pfade für die Speicherung in Dateien sowie verfügbare Gastbetriebssysteme über diesen Datentyp konfiguriert.

Datentyp: ganeti-configuration

Der ganeti-Dienst akzeptiert folgende Konfigurationsoptionen:

ganeti (Vorgabe: ganeti)

Welches ganeti-Paket benutzt werden soll. Es wird ins Systemprofil installiert und macht die Befehlszeilenwerkzeuge gnt-cluster, gnt-instance usw. verfügbar. Beachten Sie, dass der hier angegebene Wert keinen Einfluss auf die anderen Dienste hat; jeder legt sein eigenes ganeti-Paket fest (siehe unten).

noded-configuration (Vorgabe: (ganeti-noded-configuration))
confd-configuration (Vorgabe: (ganeti-confd-configuration))
wconfd-configuration (Vorgabe: (ganeti-wconfd-configuration))
luxid-configuration (Vorgabe: (ganeti-luxid-configuration))
rapi-configuration (Vorgabe: (ganeti-rapi-configuration))
kvmd-configuration (Vorgabe: (ganeti-kvmd-configuration))
mond-configuration (Vorgabe: (ganeti-mond-configuration))
metad-configuration (Vorgabe: (ganeti-metad-configuration))
watcher-configuration (Vorgabe: (ganeti-watcher-configuration))
cleaner-configuration (Vorgabe: (ganeti-cleaner-configuration))

Mit diesen Optionen stellen Sie die verschiedenen Daemons und Cron-Aufträge ein, die mit Ganeti eingerichtet werden. Die möglichen Werte dafür werden im Folgenden genau beschrieben. Um eine Einstellung zu ändern, müssen Sie den Konfigurationstyp für den jeweiligen Dienst verwenden:

(service ganeti-service-type
         (ganeti-configuration
          (rapi-configuration
           (ganeti-rapi-configuration
            (interface "eth1"))))
          (watcher-configuration
           (ganeti-watcher-configuration
            (rapi-ip "10.0.0.1"))))
file-storage-paths (Vorgabe: '())

Liste zulässiger Verzeichnisse für das in Dateien speichernde Hintergrundsystem („File Storage Backend“).

os (Vorgabe: %default-ganeti-os)

Liste von <ganeti-os>-Verbundsobjekten.

Im Kern ist ganeti-service-type eine Kurzform davon, jeden Dienst einzeln zu deklarieren:

Außerdem enthalten ist eine Diensterweiterung für den etc-service-type, der das Hintergrundsystem für die Speicherung in Dateien und die Betriebssystemvarianten festlegt.

Datentyp: ganeti-os

Dieser Datentyp wird verwendet, um ihn an den os-Parameter der ganeti-configuration zu übergeben. Er umfasst die folgenden Parameter:

name

Der Name dieses Betriebssystemanbieters. Sein einziger Zweck ist, anzugeben, wohin die Konfigurationsdateien geschrieben werden. Wird „debootstrap“ angegeben, wird /etc/ganeti/instance-debootstrap erstellt.

extension (Vorgabe: #f)

Welche Dateinamenserweiterung die Varianten dieser Art von Betriebssystem benutzen, zum Beispiel .conf oder .scm. Wenn Sie Variantendateinamen angeben, wird sie angehängt.

variants (Vorgabe: '())

Entweder eine Liste der ganeti-os-variant-Objekte für dieses Betriebssystem oder ein „dateiartiges“ Objekt (siehe dateiartige Objekte), das das Variantenverzeichnis darstellt.

Wenn Sie den Betriebssystemanbieter für Guix möchten, die Definitionen Ihrer Varianten aber aus einem lokalen Verzeichnis lesen möchten, statt sie einzeln zu deklarieren (siehe dazu guix-variants weiter unten), dann geht das so:

(ganeti-os
 (name "guix")
 (variants (local-file "ganeti-guix-variants"
                       #:recursive? #true)))

Allerdings werden Sie sich um die Datei variants.list darin in diesem Fall selbst kümmern müssen (siehe ganeti-os-interface(7)).

Datentyp: ganeti-os-variant

Der Datentyp für eine Variante einer Art von Betriebssystem. Er nimmt die folgenden Parameter:

name

Der Name dieser Variante.

configuration

Eine Konfigurationsdatei für diese Variante.

Scheme-Variable: %default-debootstrap-hooks

Diese Variable enthält Anknüpfungspunkte („Hooks“), um das Netzwerk zu konfigurieren und den GRUB-Bootloader einzurichten.

Scheme-Variable: %default-debootstrap-extra-pkgs

Diese Variable führt eine Liste von Paketen auf, die für ein gänzlich virtualisiertes Gastsystem sinnvoll sind.

Datentyp: debootstrap-configuration

Mit diesem Datentyp werden Konfigurationsdateien erzeugt, die für den debootstrap-Betriebssystemanbieter geeignet sind.

hooks (Vorgabe: %default-debootstrap-hooks)

Wenn es nicht auf #f steht, muss hier ein G-Ausdruck angegeben werden, der ein Verzeichnis mit Scripts (sogenannten „Hooks“, d.h. Anknüpfungspunkte) festlegt, welche bei der Installation des Betriebssystems ausgeführt werden. Es kann auch eine Liste von Paaren der Form (Name . dateiartiges-Objekt) angegeben werden. Zum Beispiel:

`((99-hallo-welt . ,(plain-file "#!/bin/sh\necho Hallo Welt")))

Damit wird ein Verzeichnis mit einer ausführbaren Datei namens 99-hallo-welt festgelegt, die jedes Mal ausgeführt wird, wenn diese Variante installiert wird. Wird hier #f angegeben, werden die in /etc/ganeti/instance-debootstrap/hooks vorgefundenen Anknüpfungspunkte benutzt, falls vorhanden.

proxy (Vorgabe: #f)

Optional; welcher HTTP-Proxy genutzt werden soll.

mirror (Vorgabe: #f)

Der Spiegelserver für Debian. Üblicherweise wird etwas wie http://ftp.no.debian.org/debian angegeben. Die Voreinstellung hängt von der Distribution ab.

arch (Vorgabe: #f)

Die dpkg-Architektur. Setzen Sie dies z.B. auf armhf, um eine ARMv7-Instanz auf einem AArch64-Wirtssystem via debootstrap einzurichten. Bei der Vorgabeeinstellung wird die aktuelle Systemarchitektur übernommen.

suite (Vorgabe: "stable")

Wenn dieses Feld gesetzt ist, muss dafür eine Debian-Distributions-„Suite“ wie buster oder focal angegeben werden. Steht es auf #f, wird die Voreinstellung für den Betriebssystemanbieter benutzt.

extra-pkgs (Vorgabe: %default-debootstrap-extra-pkgs)

Liste zusätzlicher Pakete, die durch dpkg zusätzlich zum minimalen System installiert werden.

components (Vorgabe: #f)

Ist dies gesetzt, muss es eine Liste von Bereichen eines Debian-Repositorys sein, etwa '("main" "contrib").

generate-cache? (Vorgabe: #t)

Ob das generierte debootstrap-Archiv automatisch zwischengespeichert werden soll.

clean-cache (Vorgabe: 14)

Nach wie vielen Tagen der Zwischenspeicher verworfen werden soll. Geben Sie #f an, damit der Zwischenspeicher niemals bereinigt wird.

partition-style (Vorgabe: 'msdos)

Der Partitionstyp der anzulegenden Partition. Wenn er festgelegt ist, muss er entweder 'msdos oder 'none lauten oder eine Zeichenkette angegeben werden.

partition-alignment (Vorgabe: 2048)

Auf wie viele Sektoren die Partition ausgerichtet werden soll.

Scheme-Prozedur: debootstrap-variant Name Konfiguration

Diese Hilfsprozedur erzeugt ein ganeti-os-variant-Verbundsobjekt. Sie nimmt zwei Parameter entgegen: einen Namen und ein debootstrap-configuration-Objekt.

Scheme-Prozedur: debootstrap-os Varianten

Diese Hilfsprozedur erzeugt ein ganeti-os-Verbundsobjekt. Sie nimmt eine Liste von mit debootstrap-variant erzeugten Varianten entgegen.

Scheme-Prozedur: guix-variant Name Konfiguration

Diese Hilfsprozedur erzeugt ein ganeti-os-variant-Verbundsobjekt, das für den vorgegebenen Guix-Betriebssystemanbieter gedacht ist. Als Parameter anzugeben sind ein Name und ein G-Ausdruck, der ein „dateiartiges“ Objekt (siehe dateiartige Objekte) mit einer Konfiguration für Guix System liefert.

Scheme-Prozedur: guix-os Varianten

Diese Hilfsprozedur erzeugt ein ganeti-os-Verbundsobjekt. Sie nimmt eine Liste von durch guix-variant erzeugten Varianten entgegen.

Scheme-Variable: %default-debootstrap-variants

Zur Erleichterung kann diese Variable benutzt werden, damit der debootstrap-Anbieter sofort funktioniert, ohne dass seine Nutzer Varianten selbst deklarieren müssen. Enthalten ist eine einzige debootstrap-Variante mit der Standardkonfiguration:

Scheme-Variable: %default-guix-variants

Zur Erleichterung kann diese Variable benutzt werden, damit der Guix-Betriebssystemanbieter sofort und ohne weitere Konfiguration funktioniert. Damit wird eine virtuelle Maschine mit einem SSH-Server, einer seriellen Konsole und bereits autorisierten Ganeti-Wirts-SSH-Schlüsseln erzeugt.

(list (guix-variant
       "default"
       (file-append ganeti-instance-guix
                    "/share/doc/ganeti-instance-guix/examples/dynamic.scm")))

Benutzer können die Unterstützung für Guix nicht bekannte Betriebssystemanbieter implementieren, indem sie entsprechende Erweiterungen für die ganeti-os- und ganeti-os-variant-Verbundstypen implementieren. Ein Beispiel:

(ganeti-os
 (name "eigenes-os")
 (extension ".conf")
 (variants
  (list (ganeti-os-variant
         (name "foo")
         (configuration (plain-file "bar" "das genügt"))))))

Damit wird /etc/ganeti/instance-eigenes-os/variants/foo.conf erzeugt, das auf eine Datei im Store mit dem Inhalt das genügt verweist. Außerdem wird /etc/ganeti/instance-eigenes-os/variants/variants.list mit dem Inhalt foo erzeugt.

Natürlich kann man Betriebssystemanbieter finden, für die das nicht ausreicht. Wenn Sie sich durch die Schnittstelle in Ihren Möglichkeiten eingeschränkt fühlen, schreiben Sie bitte an guix-devel@gnu.org.

Der übrige Teil dieses Abschnitts beschreibt die verschiedenen Dienste, aus denen sich der ganeti-service-type zusammensetzt.

Scheme-Variable: ganeti-noded-service-type

ganeti-noded ist der Daemon, der für knotenbezogene Funktionen des Ganeti-Systems da ist. Sein Wert muss ein ganeti-noded-configuration-Objekt sein.

Datentyp: ganeti-noded-configuration

Dies ist die Konfiguration des ganeti-noded-Dienstes für Ganetis Knoten-Daemon.

ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

port (Vorgabe: 8081)

Der TCP-Port, auf dem der Knoten-Daemon (noded) auf Netzwerkanfragen lauscht.

address (Vorgabe: "0.0.0.0")

An welche Netzwerkadresse sich der Daemon binden wird. Die Vorgabeeinstellung bedeutet, sich an alle verfügbaren Adressen zu binden.

interface (Vorgabe: #f)

Wenn dieses Feld gesetzt ist, muss es eine bestimmte Netzwerkschnittstelle angeben (z.B. eth0), an die sich der Daemon binden wird.

max-clients (Vorgabe: 20)

Legt eine Maximalzahl gleichzeitiger Client-Verbindungen fest, um die sich der Daemon kümmert. Darüber hinaus werden Verbindungen zwar akzeptiert, aber erst beantwortet, wenn genügend viele Verbindungen wieder geschlossen wurden.

ssl? (Vorgabe: #t)

Ob SSL/TLS benutzt werden soll, um Netzwerkkommunikation zu verschlüsseln. Das Zertifikat wird automatisch vom Cluster eingespielt und kann über gnt-cluster renew-crypto rotiert werden.

ssl-key (Vorgabe: "/var/lib/ganeti/server.pem")

Hiermit kann ein bestimmter Schlüssel für mit TLS verschlüsselte Kommunikation festgelegt werden.

ssl-cert (Vorgabe: "/var/lib/ganeti/server.pem")

Hiermit kann ein bestimmtes Zertifikat für mit TLS verschlüsselte Kommunikation festgelegt werden.

debug? (Vorgabe: #f)

Steht dies auf wahr, führt der Daemon zum Zweck der Fehlersuche ausführlichere Protokolle. Beachten Sie, dass dadurch Details der Verschlüsselung in die Protokolldateien fließen können. Seien Sie vorsichtig!

Scheme-Variable: ganeti-confd-service-type

ganeti-confd beantwortet Anfragen, die mit der Konfiguration eines Ganeti-Clusters zu tun haben. Der Zweck dieses Daemons ist, eine hochverfügbare und schnelle Methode zum Anfragen von Cluster-Konfigurationswerten zu bieten. Er wird automatisch auf allen Kandidaten für die Rolle des „Master“-Knotens aktiviert. Der Wert dieses Dienstes muss ein ganeti-confd-configuration-Objekt sein.

Datentyp: ganeti-confd-configuration

Dies ist die Konfiguration des ganeti-confd-Dienstes.

ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

port (Vorgabe: 8081)

Der UDP-Port, auf dem auf Netzwerkanfragen gelauscht werden soll.

address (Vorgabe: "0.0.0.0")

An welche Netzwerkadresse sich der Daemon binden soll.

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-wconfd-service-type

ganeti-wconfd ist der Daemon, der mit autoritativem Wissen über die Cluster-Konfiguration ausgestattet ist, und die einzige Entität, die Änderungen daran akzeptieren kann. Alle Aufträge, die die Konfiguration ändern müssen, tun dies, indem sie entsprechende Anfragen an den Daemon stellen. Er läuft nur auf dem „Master“-Knoten und deaktiviert sich auf allen anderen Knoten automatisch.

Der Wert dieses Dienstes muss ein ganeti-wconfd-configuration-Objekt sein.

Datentyp: ganeti-wconfd-configuration

Dies ist die Konfiguration des ganeti-wconfd-Dienstes.

ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

no-voting? (Vorgabe: #f)

Der Daemon wird das Starten verweigern, sofern die Mehrheit der Knoten nicht anerkennt, dass er auf dem Master-Knoten läuft. Setzen Sie dies auf #t, um ihn selbst dann zu starten, wenn sich keine Mehrheit dafür findet (das ist gefährlich; hoffentlich wissen Sie, was Sie tun).

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-luxid-service-type

Der Daemon ganeti-luxid ist dazu da, Anfragen zur Konfiguration und zum aktuellen Zustand des laufenden Ganeti-Clusters zu beantworten. Des Weiteren ist es der autoritative Daemon für Ganetis Auftragsliste. Aufträge können über diesen Daemon eingereicht werden und werden von ihm geplant und gestartet.

Er nimmt ein ganeti-luxid-configuration-Objekt entgegen.

Datentyp: ganeti-luxid-configuration

Dies ist die Konfiguration des ganeti-luxid-Dienstes.

ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

no-voting? (Vorgabe: #f)

Der Daemon verweigert das Starten, wenn er sich nicht sicher sein kann, dass die Mehrheit der Cluster-Knoten überzeugt ist, dass er auf dem Master-Knoten läuft. Setzen Sie dies auf #t, um solche Hinweise zu ignorieren (das kann gefährlich sein!).

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-rapi-service-type

ganeti-rapi bietet eine Schnittstelle für entfernte Aufrufe (englisch Remote API) für Ganeti-Cluster. Sie läuft auf dem Master-Knoten und mit ihr können Aktionen auf dem Cluster programmatisch mittels eines JSON-basierten Protokolls für entfernte Prozeduraufrufe durchgeführt werden.

Die meisten Anfrageoperationen werden ohne Authentisierung zugelassen (außer wenn require-authentication? gesetzt ist), wohingegen Schreibzugriffe einer ausdrücklichen Authentisierung durch die Datei /var/lib/ganeti/rapi/users bedürfen. Siehe die Dokumentation der Ganeti Remote API für mehr Informationen.

Der Wert dieses Dienstes muss ein ganeti-rapi-configuration-Objekt sein.

Datentyp: ganeti-rapi-configuration

Dies ist die Konfiguration des ganeti-rapi-Dienstes.

ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

require-authentication? (Vorgabe: #f)

Ob selbst für Nur-Lese-Operationen eine Authentisierung verlangt werden soll.

port (Vorgabe: 5080)

Der TCP-Port, auf dem auf API-Anfragen gelauscht werden soll.

address (Vorgabe: "0.0.0.0")

An welche Netzwerkadresse sich der Dienst binden soll. Nach Vorgabe wird auf allen konfigurierten Adressen gelauscht.

interface (Vorgabe: #f)

Wenn dies gesetzt ist, muss es eine bestimmte Netzwerkschnittstelle angeben wie z.B. eth0, an die sich der Daemon binden wird.

max-clients (Vorgabe: 20)

Die Maximalzahl gleichzeitiger Verbindungen, um die sich der Dienst kümmern darf. Weitere Verbindungen sind möglich, über sie wird aber erst dann geantwortet, wenn genügend viele Verbindungen wieder geschlossen wurden.

ssl? (Vorgabe: #t)

Ob SSL-/TLS-Verschlüsselung auf dem RAPI-Port eingesetzt werden soll.

ssl-key (Vorgabe: "/var/lib/ganeti/server.pem")

Hiermit kann ein bestimmter Schlüssel für mit TLS verschlüsselte Kommunikation festgelegt werden.

ssl-cert (Vorgabe: "/var/lib/ganeti/server.pem")

Hiermit kann ein bestimmtes Zertifikat für mit TLS verschlüsselte Kommunikation festgelegt werden.

debug? (Vorgabe: #f)

Steht dies auf wahr, führt der Daemon zum Zweck der Fehlersuche ausführlichere Protokolle. Beachten Sie, dass dadurch Details der Verschlüsselung in die Protokolldateien fließen können. Seien Sie vorsichtig!

Scheme-Variable: ganeti-kvmd-service-type

ganeti-kvmd ist dafür verantwortlich, festzustellen, wenn eine gegebene KVM-Instanz durch einen Administrator oder Nutzer geschlossen wurde. Normalerweise wird Ganeti Instanzen neu starten, die nicht über ihn selbst gestoppt wurden. Wenn die Cluster-Option user_shutdown wahr ist, beobachtet der Daemon den durch QEMU bereitgestellten QMP-Socket und lauscht auf Abschalteereignisse. Solche Instanzen werden von ihm als durch den Benutzer heruntergefahren (USER_down) markiert statt als durch Fehler beendet (ERROR_down), wenn sie von selbst ordnungsgemäß heruntergefahren sind.

Der Dienst benutzt ein ganeti-kvmd-configuration-Objekt.

Datentyp: ganeti-kvmd-configuration
ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-mond-service-type

ganeti-mond ist ein optionaler Daemon, mit dem Ganetis Überwachungsfunktionalität gewährleistet wird. Er ist dafür verantwortlich, Datensammler auszuführen und die gesammelten Informationen über eine HTTP-Schnittstelle bereitzustellen.

Der Dienst benutzt ein ganeti-mond-configuration-Objekt.

Datentyp: ganeti-mond-configuration
ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

port (Vorgabe: 1815)

Der Port, auf dem der Daemon lauschen wird.

address (Vorgabe: "0.0.0.0")

Die Netzwerkadresse, an die sich der Daemon binden soll, nach Vorgabe an alle verfügbaren.

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-metad-service-type

ganeti-metad ist ein optionaler Daemon, der benutzt werden kann, um Informationen über den Cluster an Instanzen oder an Betriebssysteminstallationsskripte weiterzugeben.

Dazu nimmt er ein ganeti-metad-configuration-Objekt.

Datentyp: ganeti-metad-configuration
ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

port (Vorgabe: 80)

Der Port, auf dem der Daemon lauschen wird.

address (Vorgabe: #f)

Wenn es gesetzt ist, wird sich der Daemon nur an diese Adresse binden. Ist es nicht gesetzt, hängt das Verhalten von der Cluster-Konfiguration ab.

debug? (Vorgabe: #f)

Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche ausführlicher protokollieren.

Scheme-Variable: ganeti-watcher-service-type

ganeti-watcher ist ein Skript, das dafür gedacht ist, regelmäßig ausgeführt zu werden und die Verfügbarkeit des Clusters sicherzustellen. Instanzen, die ohne Ganetis Zustimmung abgebrochen sind, werden durch es automatisch neu gestartet und DRBD-Verbindungen werden repariert, wenn ein Knoten neu gestartet wurde. Außerdem werden alte Cluster-Aufträge archiviert und nicht laufende Ganeti-Daemons erneut gestartet. Wenn der Cluster-Parameter ensure_node_health gesetzt ist, wird der Watcher auch Instanzen und DRBD-Geräte herunterfahren, wenn der Knoten zwar läuft, aber von bekannten Kandidaten auf die Rolle des Master-Knotens als offline deklariert wurde.

Er kann mit gnt-cluster watcher pause auf allen Knoten pausiert werden.

Der Dienst benutzt ein ganeti-watcher-configuration-Objekt.

Datentyp: ganeti-watcher-configuration
ganeti (Vorgabe: ganeti)

Das ganeti-Paket, was für diesen Dienst benutzt werden soll.

schedule (Vorgabe: '(next-second-from (next-minute (range 0 60 5))))

Wie oft das Skript ausgeführt werden soll. Nach Vorgabe läuft es alle fünf Minuten.

rapi-ip (Vorgabe: #f)

Diese Option muss nur dann angegeben werden, wenn der RAPI-Daemon so konfiguriert wurde, dass er eine bestimmte Schnittstelle oder Adresse verwenden soll. Nach Vorgabe wird die Adresse des Clusters verwendet.

job-age (Vorgabe: (* 6 3600))

Cluster-Aufträge archivieren, die älter als diese Anzahl Sekunden sind. Die Vorgabe beträgt 6 Stunden. Dadurch wird gewährleistet, dass man gnt-job list noch sinnvoll bedienen kann.

verify-disks? (Vorgabe: #t)

Steht dies auf #f, wird der Watcher nicht versuchen, fehlgeschlagene DRBD-Verbindungen automatisch zu reparieren. Administratoren müssen stattdessen gnt-cluster verify-disks manuell aufrufen.

debug? (Vorgabe: #f)

Steht dies auf #t, so führt das Skript zum Zweck der Fehlersuche ausführlichere Protokolle.

Scheme-Variable: ganeti-cleaner-service-type

ganeti-cleaner ist ein Skript, das regelmaßig ausgeführt werden soll, um alte Dateien vom Cluster zu entfernen. Dieser Diensttyp steuert zwei cron-Aufträge (cron jobs): einer, um alte Cluster-Aufträge auf dem Master-Knoten andauernd zu löschen, und einer, der auf allen Knoten ausgelaufene X509-Zertifikate, -Schlüssel sowie veraltete Informationen des ganeti-watcher entfernt. Wie alle Ganeti-Dienste kann man ihn ohne Probleme auch auf Nicht-Master-Knoten in die Konfiguration mit aufnehmen, denn er deaktiviert sich selbst, wenn er nicht gebraucht wird.

Der Dienst benutzt ein ganeti-cleaner-configuration-Objekt.

Datentyp: ganeti-cleaner-configuration
ganeti (Vorgabe: ganeti)

Welches ganeti-Paket für den Befehl gnt-cleaner benutzt werden soll.

master-schedule (Vorgabe: "45 1 * * *")

Wie oft der Bereinigungsauftrag für den Master durchgeführt werden soll. Vorgegeben ist einmal täglich um 01:45:00 Uhr.

node-schedule (Vorgabe: "45 2 * * *")

Wie oft der Bereinigungsauftrag für Knoten durchgeführt werden soll. Vorgegeben ist einmal täglich um 02:45:00 Uhr.


Nächste: Versionskontrolldienste, Vorige: Audio-Dienste, Nach oben: Dienste   [Inhalt][Index]