Nächste: Versionskontrolldienste, Vorige: Audio-Dienste, Nach oben: Dienste [Inhalt][Index]
Das Modul (gnu services virtualization) bietet Dienste für die
Daemons von libvirt und virtlog, sowie andere virtualisierungsbezogene
Dienste.
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. Damit sich ein „unprivilegierter“ Benutzer ohne besondere
Berechtigungen mit dem libvirt-Daemon verbinden darf, muss er als Mitglied
der ‘libvirt’-Benutzergruppe eingetragen werden, wie unten gezeigt.
Dies ist der Diensttyp des libvirt-Daemons. Sein
Wert muss ein libvirt-configuration-Verbundsobjekt sein.
(users (cons (user-account (name "benutzer") (group "users") (supplementary-groups '("libvirt" "audio" "video" "wheel"))) %base-user-accounts)) (service libvirt-service-type (libvirt-configuration (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 ‘"libvirt"’.
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:
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.
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:stderrProtokolle werden auf der Standardausgabe („Stderr“) ausgegeben.
x:syslog:NameSyslog wird zur Ausgabe benutzt. Der Name dient dabei als Identifikator für libvirt-Protokolle.
x:file:DateipfadProtokolle werden in die Datei unter dem angegebenen Dateipfad ausgegeben.
x:journaldDie Ausgabe läuft über das journald-Protokollsystem.
In allen Fällen steht das x vorne für die kleinste Stufe und wirkt als Filter.
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.
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’.
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.
Dies ist der Diensttyp des virtlog-Daemons. Sein Wert muss eine
virtlog-configuration sein.
(service virtlog-service-type
(virtlog-configuration
(max-clients 1000)))
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:
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.
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:stderrProtokolle werden auf der Standardausgabe („Stderr“) ausgegeben.
x:syslog:NameSyslog wird zur Ausgabe benutzt. Der Name dient dabei als Identifikator für libvirt-Protokolle.
x:file:DateipfadProtokolle werden in die Datei unter dem angegebenen Dateipfad ausgegeben.
x:journaldDie Ausgabe läuft über das journald-Protokollsystem.
In allen Fällen steht das x vorne für die kleinste Stufe und wirkt als Filter.
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’.
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.
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.
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm" "aarch64"))))
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).
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:
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm"))))
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.
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.
Liefert wahr, wenn das Objekt ein Plattformobjekt ist.
Liefert den Namen der Plattform, also eine Zeichenkette wie z.B.
"arm".
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.
Diensttyp des Dienstes für den QEMU Guest Agent.
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.
Virtuelle Erstellungsmaschinen oder „Erstellungs-VM“ bzw. „Build-VM“ erlauben es Ihnen, Erstellungen an vollends kontrollierte Umgebungen auszulagern. „Wie kann man mehr Kontrolle haben als bei normalen Erstellungen? Und wozu das Ganze?“, fragen Sie. Und das sind berechtigte Fragen.
Erstellungen, die mit guix-daemon gestartet werden, laufen durchaus
in einer kontrollierten Umgebung, genauer gesagt erzeugt der Daemon die
Erstellungsprozesse in getrennten Namensräumen und in einer chroot-Umgebung,
damit Erstellungsprozesse nur ihre deklarierten Abhängigkeiten sowie einen
klar abgegrenzten Teil des Dateisystembaums sehen können (siehe Einrichten der Erstellungsumgebung für mehr Informationen). Jedoch tragen zur Umgebung auch
manche unkontrollierten Facetten bei: der Kernel des Betriebssystems, das
Prozessormodell und das Datum. Meistens sind diese Facetten unerheblich für
den Erstellungsprozess und das von guix-daemon garantierte
Isolationsniveau ist „gut genug“.
Manchmal allerdings haben diese Facetten aber doch Einfluss auf den Erstellungsprozess. Ein typisches Beispiel sind Zeitfallen: Erstellungsprozesse, die nicht mehr funktionieren, wenn ein festgeschriebener Zeitpunkt verstrichen ist35. Des Weiteren gibt es Software, die auf diejenige Prozessormikroarchitektur hin optimiert wird, auf der sie erstellt wird, oder schlimmer noch, sie hat Fehler, die nur auf ganz bestimmten CPU auftreten.
Um damit klarzukommen, können Sie einen Dienst des Typs
virtual-build-machine-service-type einrichten, so dass eine virtuelle
Erstellungsmaschine zu Ihrem System hinzugefügt wird, wie in diesem
Beispiel:
(use-modules (gnu services virtualization)) (operating-system ;; … (services (append (list (service virtual-build-machine-service-type)) %base-services)))
In der Vorgabeeinstellung ist es Ihre Aufgabe, die Erstellungsmaschine ausdrücklich zu starten, wenn Sie sie brauchen, damit Erstellungen auf sie ausgelagert werden können (siehe Nutzung der Auslagerungsfunktionalität):
herd start build-vm
Mit der oben gezeigten Vorgabeeinstellung wird die Uhr der virtuellen Erstellungsmaschine auf ein Datum einige Jahre in der Vergangenheit gesetzt und das Prozessormodell wird dem Datum entsprechend gewählt – unter Umständen ist dieses Modell älter als Ihre Maschine. Dadurch bietet sich Ihnen die Möglichkeit, Software aus vergangenen Jahren heute noch zu erstellen, wenn deren Erstellung unter normalen Umständen mittlerweile wegen einer Zeitfalle oder wegen eines anderweitig problematischen Erstellungsprozesses fehlschlägt. Die Konfiguration der VM können Sie so einsehen:
herd configuration build-vm
Sie können die Erstellungsmaschine nach Ihren Wünschen konfigurieren wie in diesem Beispiel:
(service virtual-build-machine-service-type
(virtual-build-machine
(cpu "Westmere")
(cpu-count 8)
(memory-size (* 1 1024))
(auto-start? #t)))
Die verfügbaren Optionen werden nun gezeigt.
Mit diesem Diensttyp führen Sie virtuelle Erstellungsmaschinen aus. Die virtuellen Erstellungsmaschinen werden so konfiguriert, dass Erstellungen darauf ausgelagert werden, wenn diese laufen.
Dies ist der Datentyp, der die Konfiguration einer Erstellungsmaschine repräsentiert. Sie enthält die folgenden Felder:
name (Vorgabe: 'build-vm)Der Name dieser Erstellungs-VM. Von ihm leitet sich der Name des zugehörigen Shepherd-Dienstes ab.
imageWelches Abbild für die virtuelle Maschine verwendet wird (siehe Systemabbilder erstellen). Erwähnenswert ist, dass damit auch die Größe der virtuellen Platte
und das darauf laufende Betriebssystem festgelegt werden (siehe
operating-system-Referenz). Mit dem Vorgabewert kommt ein minimales
Betriebssystemabbild zum Einsatz.
qemu (Vorgabe: qemu-minimal)Das QEMU-Paket, mit dem das Abbild laufen soll.
cpuDas Prozessormodell, das emuliert werden soll, angegeben als Zeichenkette, die das QEMU bekannte Modell angibt.
Der Vorgabewert für das Modell entscheidet sich anhand des in date
angegebenen Datums (siehe unten). Um zu wissen, welche CPU-Modelle verfügbar
sind, können Sie zum Beispiel dies ausführen:
qemu-system-x86_64 -cpu help
cpu-count (Vorgabe: 4)Die Anzahl, wie viele CPU in der virtuellen Maschine emuliert werden sollen.
memory-size (Vorgabe: 2048)Die Größe in Mebibyte (MiB) des Arbeitsspeichers der virtuellen Maschine.
date (Vorgabe: vor ein paar Jahren)Welches Datum die virtuelle Maschine kennt, wenn sie startet. Geben Sie ein Datumsobjekt gemäß SRFI-19 an (siehe SRFI-19 Date in Referenzhandbuch zu GNU Guile).
port-forwardings (Vorgabe: 11022 and 11004)Welche TCP-Ports der virtuellen Maschine an den Wirt weitergeleitet werden sollen. Vorgegeben ist, die Ports für SSH und Geheimnisse vom Wirt aus sichtbar zu machen.
systems (Vorgabe: (list (%current-system)))Die Liste der von der Erstellungs-VM unterstützten Systemtypen – etwa
"x86_64-linux".
auto-start? (Vorgabe: #f)Ob die virtuelle Maschine gestartet werden soll, sobald das System bootet.
Im nächsten Abschnitt lesen Sie über eine Variante: virtuelle Maschinen für GNU/Hurd!
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 10022 des Wirtssystems
weitergibt. Außerdem ist Auslagern der Vorgabe nach aktiviert, so dass
Erstellungen für GNU/Hurd vom auf dem Wirt laufenden guix-daemon
automatisch an die Childhurd weitergereicht werden (siehe Nutzung der Auslagerungsfunktionalität). Dazu führen Sie einen Befehl wie den folgenden
aus. i586-gnu ist dabei der Systemtyp für die 32-Bit-Variante von
GNU/Hurd:
guix build emacs-minimal -s i586-gnu
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.
Es bietet sich an, dass Sie sich auf der virtuellen GNU/Hurd-Maschine ein
eigenes Benutzerkonto deklarieren und die Anmeldung über Ihren SSH-Schlüssel
erlauben. Als Grundlage nehmen Sie eine normale GNU/Hurd-Systemdefinition
(siehe Das Konfigurationssystem nutzen) und übergeben dieses
Betriebssystem im os-Feld von hurd-vm-configuration, wie in
diesem Beispiel:
(define childhurd-os ;; Definition meines GNU/Hurd-Systems, abgeleitet vom vorgegebenen. (operating-system (inherit %hurd-vm-operating-system) ;; Benutzerkonto hinzufügen. (users (cons (user-account (name "charlie") (comment "Das bin ich!") (group "users") (supplementary-groups '("wheel"))) ;für 'sudo' %base-user-accounts)) (services ;; Wir passen die SSH-Konfiguration an, damit wir als "root" und ;; als "charlie" über öffentliche Schlüssel authentifiziert werden ;; können. (modify-services (operating-system-user-services %hurd-vm-operating-system) (openssh-service-type config => (openssh-configuration (inherit config) (authorized-keys `(("root" ,(local-file "/home/charlie/.ssh/id_rsa.pub")) ("charlie" ,(local-file "/home/charlie/.ssh/id_rsa.pub")))))))))) (operating-system ;; … (services ;; Den 'hurd-vm'-Dienst fügen wir mit einer Konfiguration hinzu, ;; durch die er obige Betriebssystemkonfiguration instanziiert. (append (list (service hurd-vm-service-type (hurd-vm-configuration (os %childhurd-os)))) %base-services)))
Das war’s schon! Der Rest dieses Abschnitts stellt die Referenz dieser Dienstkonfiguration dar.
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.
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)Das image-Objekt für ein Disk-Image, mit dem diese virtuelle Maschine
laufen soll (siehe Systemabbilder 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))
offloading? (Vorgabe: #t)Ob automatisch das Auslagern von Erstellungen auf die Childhurd eingerichtet werden soll.
Wenn dies aktiviert ist, können Sie Erstellungen für GNU/Hurd auf dem Wirtssystem auslösen, die transparent an die virtuelle Maschine ausgelagert werden, zum Beispiel mit so einem Befehl:
guix build coreutils -s i586-gnu
Das Auslagern mit dieser Option wird auf diese Weise automatisch eingerichtet:
guix archive
--authorize, für Informationen dazu).
offloading wird angelegt, welches für das
Auslagern auf die Childhurd bestimmt ist.
offloading-Benutzerkonto der Childhurd
eingerichtet wird.
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/authorized_keys.d/offloading /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
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 '())))
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-service-type) 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") ;; 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))) (simple-service 'ganeti-hosts-entries hosts-service-type (list (host "192.168.1.200" "ganeti.example.com") (host "192.168.1.201" "node1.example.com" '("node1")) (host "192.168.1.202" "node2.example.com" '("node2")))) (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.
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.
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“).
hooks (Vorgabe: #f)Wenn es gesetzt ist, gibt dies ein dateiartiges Objekt für ein Verzeichnis mit auszuführenden Cluster Execution Hooks an.
os (Vorgabe: %default-ganeti-os)Liste von <ganeti-os>-Verbundsobjekten.
Im Kern ist ganeti-service-type eine Kurzform davon, jeden Dienst
einzeln zu deklarieren:
(service ganeti-noded-service-type) (service ganeti-confd-service-type) (service ganeti-wconfd-service-type) (service ganeti-luxid-service-type) (service ganeti-kvmd-service-type) (service ganeti-mond-service-type) (service ganeti-metad-service-type) (service ganeti-watcher-service-type) (service ganeti-cleaner-service-type)
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.
Dieser Datentyp wird verwendet, um ihn an den os-Parameter der
ganeti-configuration zu übergeben. Er umfasst die folgenden
Parameter:
nameDer 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)).
Der Datentyp für eine Variante einer Art von Betriebssystem. Er nimmt die folgenden Parameter:
nameDer Name dieser Variante.
configurationEine Konfigurationsdatei für diese Variante.
Diese Variable enthält Anknüpfungspunkte („Hooks“), um das Netzwerk zu konfigurieren und den GRUB-Bootloader einzurichten.
Diese Variable führt eine Liste von Paketen auf, die für ein gänzlich virtualisiertes Gastsystem sinnvoll sind.
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.
Diese Hilfsprozedur erzeugt ein ganeti-os-variant-Verbundsobjekt. Sie
nimmt zwei Parameter entgegen: einen Namen und ein
debootstrap-configuration-Objekt.
Diese Hilfsprozedur erzeugt ein ganeti-os-Verbundsobjekt. Sie nimmt
eine Liste von mit debootstrap-variant erzeugten Varianten entgegen.
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.
Diese Hilfsprozedur erzeugt ein ganeti-os-Verbundsobjekt. Sie nimmt
eine Liste von durch guix-variant erzeugten Varianten entgegen.
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:
(list (debootstrap-variant
"default"
(debootstrap-configuration)))
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.
ganeti-noded ist der Daemon, der für knotenbezogene Funktionen des
Ganeti-Systems da ist. Sein Wert muss ein
ganeti-noded-configuration-Objekt sein.
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!
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Das verbreitetste Beispiel solcher Zeitfallen sind Testkataloge, die Auslaufdaten von Zertifikaten prüfen. Solche Tests finden sich in TLS-Implementierungen wie OpenSSL und GnuTLS, aber auch in anwendernäherer Software wie etwa Python.
Nächste: Versionskontrolldienste, Vorige: Audio-Dienste, Nach oben: Dienste [Inhalt][Index]