Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
client:qemu [2024/04/02 18:36 CEST] – [Netzwerk] chrclient:qemu [2024/04/22 11:00 CEST] (aktuell) – [Start der VM] chr
Zeile 1: Zeile 1:
 ====== qemu ====== ====== qemu ======
  
-QEMU im Verbund mit libvirt bietet eine leistungsfähige open Source-Virtualisierungsumgebung, die auch in Hinblick auf spätere Clouddienste eine Vielzahl an Vorteilen bietet.+QEMU im Verbund mit libvirt bietet eine leistungsfähige, nicht mit Lizenzproblematiken behaftete open Source-Virtualisierungsumgebung, die auch in Hinblick auf spätere Clouddienste eine Vielzahl an Vorteilen bietet.
  
 ===== Software ===== ===== Software =====
Zeile 18: Zeile 18:
 </code> </code>
  
-Prüfen Sie ggf. nach Abschluß der Installation, ob der libvirtd-Daemon läuft ('systemctl status libvirt-daemon'). Falls nicht automatisch geschehen, sorgt ein 'systemctl enable libvirt-daemon' sorgt für den Start beim Booten; ein 'systemctl start libvirt-daemon' startet ihn manuell.+Prüfen Sie ggf. nach Abschluß der Installation, ob der libvirtd-Daemon läuft ('systemctl status libvirtd')((Anmerkung: Der libvirt-Dienst kann je nach Distribution anders heißen; libvirtd dürfte am gebräuchlichsten sein.)). Falls nicht automatisch geschehen, sorgt ein 'systemctl enable libvirtd' für den Start beim Booten; ein 'systemctl start libvirtd' startet ihn manuell.
  
 <note tip>Der lokal zum Umgang mit qemu/libvirt verwendende User sollte Mitglied der Gruppe libvirt sein. Fügen Sie ihn ggf. dieser Gruppe hinzu.</note> <note tip>Der lokal zum Umgang mit qemu/libvirt verwendende User sollte Mitglied der Gruppe libvirt sein. Fügen Sie ihn ggf. dieser Gruppe hinzu.</note>
  
-Operationen als normaler User ohne weitere connect-Angaben (-c, --connect) und ohne gesetzte %%LIBVIRT_DEFAULT_URI%%-Umgebungsvariable werden im Kontext %%qemu:///session%% interpretiert. Der session-Kontext trägt geringere Berechtigungen, z.B. beim Umgang mit Netzwerken. Bei Mitgliedschaft des Users in der Gruppe libvirt sollte daher besser -c %%qemu:///system%% benutzt werden.+Operationen als normaler User ohne weitere connect-Angaben (-c, --connect) und ohne gesetzte %%LIBVIRT_DEFAULT_URI%%-Umgebungsvariable werden im Kontext %%qemu:///session%% interpretiert. Der session-Kontext arbeitet mit geringeren Berechtigungen, z.B. beim Umgang mit Netzwerken. Bei Mitgliedschaft des Users in der Gruppe libvirt sollte daher besser -c %%qemu:///system%% benutzt werden.
  
  
Zeile 31: Zeile 31:
 ==== Download und Import ==== ==== Download und Import ====
  
-Nach dem Download der VM erfolgt ein Import der Konfiguration in libvirt mit einem der beiden folgenden Konsolenaufrufen.+Nach dem Download der VM erfolgt ein Import der Konfiguration in libvirt mit dem folgenden Konsolenaufruf: 
 +<code>virsh -c qemu:///system define [xml-Datei.xml]</code> 
 +Dies führt statische Überprüfungen (Validierung des XML) aus und trägt diese ein.
  
 +Für dem Fall, daß eine VM nur einmalig gestartet werden soll, steht der „create“-Befehl zur Verfügung. Da diese wird jedoch nicht dauerhaft eingetragen wird, ist dieser Weg nur in Spezialfällen empfehlenswert:
 <code>virsh -c qemu:///system create [xml-Datei.xml]</code> <code>virsh -c qemu:///system create [xml-Datei.xml]</code>
-<code>virsh -c qemu:///system define [xml-Datei.xml]</code> 
- 
-  * „create“: Startet VM ausgehend von XML-Datei, trägt diese jedoch nicht dauerhaft ein. 
-  * **„define“: Führt statische Überprüfungen (Validierung des XML) aus und trägt diese ein.** 
- 
 ==== Bearbeitung der VM ==== ==== Bearbeitung der VM ====
  
Zeile 47: Zeile 45:
 Das Gastsystem kann nun gestartet und natürlich bearbeitet werden. Beim ersten Start einer VM allgemein können gewisse Probleme auftreten; mehr dazu unter [[#startprobleme|Startprobleme]] Das Gastsystem kann nun gestartet und natürlich bearbeitet werden. Beim ersten Start einer VM allgemein können gewisse Probleme auftreten; mehr dazu unter [[#startprobleme|Startprobleme]]
  
-Bei Problemen beim Boot à la Bluescreens usw. sollte geprüft werden, welche Busart zum Ansprechen des Massenspeichers im auf dem Image befindlichen Gastbetriebssystem verwendet wurde (scsi, sata, ata). Bei Linuxgastsystemen („a start job is running… for dev/disk…“ 1:30) ggf. Hibernation kontrollieren (systemd-hibernate-resume), wenn vorhanden „resume“ aus KCL entfernen.+Bei Problemen beim Boot à la Bluescreens usw. sollte geprüft werden, welche Busart zum Ansprechen des Massenspeichers im auf dem Image befindlichen Gastbetriebssystem verwendet wurde (scsi, sata, ata). Bei Linuxgastsystemen („a start job is running… for dev/disk…“ 1:30) ggf. Hibernation kontrollieren (systemd-hibernate-resume), wenn vorhanden „resume“ aus KCL entfernen. Bei der Meldung „a start job is running… for dev/fd1“ kann ggf. der Timeout erniedrigt werden((Das kommt mitunter vor, wenn die Pseudofloppy fd1 eingehängt werden soll)).
  
  
 ==== Export der Konfiguration  ==== ==== Export der Konfiguration  ====
  
-Die Konfiguration der erstellten virtuellen Maschine muß vor einem Upload via bwLehrpool-Suite exportiert werden, da virtlibd die Konfiguration intern führt und daher die ursprünglich per bwLehrpool-Suite geschriebe, zum Import verwendete xml-Datei nicht aktualisiert wird. Das kann derzeit nur mit einem Kommandozeilenbefehl geschehen:+Die Konfiguration der erstellten virtuellen Maschine muß vor einem Upload via bwLehrpool-Suite exportiert werden, da virtlibd die Konfiguration intern führt und daher die ursprünglich durch die bwLehrpool-Suite geschriebene, zum Import verwendete xml-Datei nicht aktualisiert wird. Das kann derzeit nur mit einem Kommandozeilenbefehl geschehen:
  
 <code>virsh -c qemu:///system dumpxml [VM-Name] > [xml-Datei]</code> <code>virsh -c qemu:///system dumpxml [VM-Name] > [xml-Datei]</code>
Zeile 87: Zeile 85:
   * Dies gilt prinzipiell auch für die grafische Ausgabe („Video“); „virtio“ kann jedoch mitunter besonders in Windows-Gästen Probleme bereiten. Mit dem etwas weniger performanten QXL ist man auf der sicheren Seite. Verwenden Sie daher im Zweifel QXL.   * Dies gilt prinzipiell auch für die grafische Ausgabe („Video“); „virtio“ kann jedoch mitunter besonders in Windows-Gästen Probleme bereiten. Mit dem etwas weniger performanten QXL ist man auf der sicheren Seite. Verwenden Sie daher im Zweifel QXL.
   * „Anzeige Spice“ sollte auf „SPICE-Server“ gesetzt werden.   * „Anzeige Spice“ sollte auf „SPICE-Server“ gesetzt werden.
-  * Das qcow2-Format sollte als Format für das Festplattenabbild bevorzugt werden, alternativ sind auch .vmdk und .vdi möglich.+  * Das qcow2-Format sollte als Format für das Festplattenabbild bevorzugt werden, alternativ sind auch vmdk und vdi möglich.
   * Optional: Komprimierung des Festplattenabbilds vor dem Upload (siehe [[#optimierung_optional|Optimierung der VM]])   * Optional: Komprimierung des Festplattenabbilds vor dem Upload (siehe [[#optimierung_optional|Optimierung der VM]])
  
 ==== Grafisches Erstellen der VM ==== ==== Grafisches Erstellen der VM ====
  
-Ein grafisches Erstellen einer neuen VM erfolgt mittels virt-manager (Virtual Machine Manager), Cockpit oder dergleichen. Zur Erstellung den jeweiligen Assistent en (Wizard) starten (virt-manager: „Datei“, „Neue virtuelle Maschine“ ff.).+Ein grafisches Erstellen einer neuen VM erfolgt mittels virt-manager (Virtual Machine Manager), Cockpit oder dergleichen. Zur Erstellung den jeweiligen Assistenten (Wizard) starten (virt-manager: „Datei“, „Neue virtuelle Maschine“ ff.).
  
 ==== Manuelles Erstellen der VM ==== ==== Manuelles Erstellen der VM ====
Zeile 123: Zeile 121:
 </code> </code>
  
-Der Befehl „osinfo-query os“ (aus der Bibliothek osinfo-query) zeigt verfügbare Werte für --os-variant an. Häufige Werte sind beispielsweise opensuse15.5, ubuntu22.04, debian9, win10 usw. Eine cdrom-Angabe ist manchmal praktisch, damit sie gleich in der Konfiguration enthalten ist.+Der Befehl „osinfo-query os“ (aus dem Paket osinfo-query) zeigt verfügbare Werte für %%--%%os-variant an. Häufige Werte sind beispielsweise opensuse15.5, ubuntu22.04, debian9, win10 usw. Eine cdrom-Angabe ist manchmal praktisch, damit sie gleich in der Konfiguration enthalten ist.
  
  
Zeile 180: Zeile 178:
   * „SATA CDROM 1" rechtsklick, "Gerät entfernen"“,   * „SATA CDROM 1" rechtsklick, "Gerät entfernen"“,
   * „Zugehörige Dateien löschen" markieren“.   * „Zugehörige Dateien löschen" markieren“.
 +
 +==== Verzeichnisberechtigungen ====
 +
 +=== Berechtigungen ===
 +
 +[{{ client:qemu:qemu_keine_berechtigung.png?200|Dateiberechtigungen?}}] Bei einer Defaultinstallation verwendet libvirt zum Ausführen einer VM den niedrig berechtigten („nologin“) User qemu. Zudem wird für die Dauer der Ausführung die qcow2-Datei diesem Umser (und der Gruppe qemu) übertragen. Das bedingt auch, daß die Verzeichnisse im Verzeichnisbaum bis hinunter zum Verzeichnis, das die zur qcow2- und xml-Datei enthält, vom Standarduser qemu geöffnet werden können muß. Genauer ausgedrückt: Jedes Verzeichnis muß das executable-Bit für User/Gruppe qemu tragen, was üblicherweise bedeutet, daß das executable-Bit im dritten Tripel „others (andere)“ gesetzt sein muß.
 +
 +Nehmen wir beispielsweise an, wir wollten eine qcow2-/xml-Datei im Verzeichnis /home/chr/virtual/xyz des Users chr starten. Das würde dank durchgehend gesetztem executable-Bit funktionieren:
 +<code>drwxr-xr-x 22  root root 4096 24. Nov 15:24 /
 +drwxr-xr-x  9  root root 4096  7. Feb 13:30 /home
 +drwxr-x--x 132 chr users 20480 3. Apr 13:46 /home/chr/
 +drwxr-xr-x 33  chr users 4096  2. Apr 17:08 /home/chr/virtual/
 +drwxr-xr-x 33  chr users 4096  2. Apr 17:08 /home/chr/virtual/xyz</code>
 +
 +… aber das nicht:
 +<code>drwxr-xr-x 22  root root 4096 24. Nov 15:24 /
 +drwxr-xr-x  9  root root 4096  7. Feb 13:30 /home
 +drwxr-x--- 132 chr users 20480 3. Apr 13:46 /home/chr/
 +drwxr-xr-- 33  chr users 4096  2. Apr 17:08 /home/chr/virtual/
 +drwxr-xr-x 33  chr users 4096  2. Apr 17:08 /home/chr/virtual/xyz</code>
 +… da die Verzeichnisse /home/chr und /home/chr/virtual, wie man sieht, kein „executable“-Bit für „others“ tragen. 
 +
 +=== Abhilfe ===
 +
 +Zur Abhilfe bieten sich mehrere Möglichkeiten an:
 +
 +  * Am einfachsten dürfte sein, das executable-Bit für „others“ zu setzen.
 +  * Die Verwendung eines Teils der Verzeichnishierarchie mit passend gesetzten Berechtigungen, falls Bedenken bzgl. /home/[user] bestehen.
 +  * Schließlich kann in der libvirtd-Konfigurationsdatei /etc/libvirt/qemu.conf der Standarduser qemu in der Zeile „user = qemu“ (wenn „#user = qemu“ als Platzhalter „#“ entfernen) durch einen geeigneteren Usernamen ersetzt werden - dies bietet sich evtl. an, wenn der Rechner nur von einer Person benutzt wird.
  
  
 ===== Export in Cloudsysteme ===== ===== Export in Cloudsysteme =====
  
-<note>Hier getroffene Angaben müssen noch optimiert werden, daher bitte nur als Möglichkeit werten.</note>+<note>Die hier getroffene Angaben sind veraltet und müssen aktualisiert und verifiziert werden. Bitte daher bitte nur als Möglichkeit ansehen.</note>
  
 Zum Export von Windows-VMs in Cloud-Infrastrukturen wie bwClouds/OpenStack ist folgender Ablauf empfehlenswert: Zum Export von Windows-VMs in Cloud-Infrastrukturen wie bwClouds/OpenStack ist folgender Ablauf empfehlenswert:

Zuletzt angesehen:

Drucken/exportieren