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/03/12 13:11 CET] – [Erstellen einer neuen VM] chrclient:qemu [2024/04/22 11:00 CEST] (aktuell) – [Start der VM] chr
Zeile 1: Zeile 1:
-====== qemu-Unterstützung ======+====== qemu ======
  
-<note important>Achtung: Dies hier ist eine komplette Baustelle!</note> +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.
- +
-todo: Dynamische Auflösungen?+
  
 ===== Software ===== ===== Software =====
- 
-==== Host ==== 
  
 Zur Verwaltung und Anpassung von QEMU-VMs ist ein Linux-System sehr empfehlenswert. QEMU-Betrieb unter Windows scheint inzwischen zwar einigermaßen möglich zu sein((Binaries https://qemu.weilnetz.de/w64/, Anleitung etwa https://linuxhint.com/qemu-windows/)), wird von uns jedoch nicht getestet und daher nicht unterstützt. Zur Verwaltung und Anpassung von QEMU-VMs ist ein Linux-System sehr empfehlenswert. QEMU-Betrieb unter Windows scheint inzwischen zwar einigermaßen möglich zu sein((Binaries https://qemu.weilnetz.de/w64/, Anleitung etwa https://linuxhint.com/qemu-windows/)), wird von uns jedoch nicht getestet und daher nicht unterstützt.
Zeile 22: 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.
-==== Userkontext ====+
  
-Der lokal zum Umgang mit qemu/libvirt verwendende User sollte Mitglied der Gruppe libvirt sein. Fügen Sie ihn ggf. dieser Gruppe hinzu.+<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>
  
-==== Gastsysteme ====+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.
  
-Unter den jeweiligen Gastsystemen sollten ua. zur Performanzverbesserung folgende Gastprogramme installiert werden: 
  
-=== Linux ===+===== Virtuelle Maschinen (VMs) =====
  
-  * virtio Linux-Kernel-Treiber, +[{{ client:qemu:virt_Symbole_qemu.png?200|qemu-Symbol in Liste}}]Die bwLehrpool-Suite unterstützt den Umgang mit qemu-basierten VMs analog zu anderen Hypervisoren. Wie üblich sollte bei Erstellung eigener Versionen von einer von Ihrer Institution zur Verfügung gestellten Vorlage ausgegangen werden, wenn möglich.
-  * xf86-video-qxl (bei Verwendung der paravirtualisierten 2D QXL-Grafik), +
-  * qemu-ga (qemu-guest-agent), +
-  * spice-vdagent.+
  
-=== Windows ===+==== Download und Import ====
  
-  * virtio Windows-Treiber per [[https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso|virtio-win-ISO-Installer]], +Nach dem Download der VM erfolgt ein Import der Konfiguration in libvirt mit dem folgenden Konsolenaufruf: 
-  * qemu-ga (qemu-guest-agent), +<code>virsh -c qemu:///system define [xml-Datei.xml]</code> 
-  * spice-vdagent.+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>
 +==== Bearbeitung der VM ====
  
-==== Verbindung ====+Die Konfiguration der importierten VM kann nun editiert werden, wenn nötig. Diese Bearbeitung kann grafisch mittels des „Virtual Machine Manager“ (virt-manager), Cockpit oder dergleichen erfolgen.
  
-Operationen als normaler User ohne weitere connect-Angaben (-c, --connect) und ohne gesetzte %%LIBVIRT_DEFAULT_URI%% Umgebungsvariable landen im Kontext %%qemu:///session%%. Dabei Achtung auf geringere Berechtigung, z.B. bei Netzwerken. Bei Mitgliedschaft in der Gruppe libvirt daher besser -c %%qemu:///system%% benutzen.+==== Start der VM ==== 
 + 
 +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 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  ==== 
 + 
 +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> 
 + 
 +Folgender Befehl listet die vorhandenen VMs auf, falls Sie sich des VM-Namens nicht sicher sind: 
 +<code>virsh -c qemu:///system list --all</code> 
 + 
 +Das Festplattenabbild der VM muss dabei nicht explizit kopiert werden, da die exportierte Konfiguration (XML-Datei) automatisch auf das vorhandene Festplattenabbild verweist.  
 + 
 +<note important>Allgemein: Wenn die Konfiguration der VM geändert wurde, muss die xml-Datei per dumpxml neu geschrieben werden, bevor ein Upload per bwLehrpool-Suite erfolgt!</note> 
 + 
 +==== Optimierung (optional) ==== 
 + 
 +Vor dem Upload der VM kann optional eine Optimierung des qcow2-Festplattenabbildes der VM vorgenommen werden. Dies umfasst das Komprimieren des Festplattenabbilds. Zur besseren Komprimierung sollten zuvor im laufenden Gastsystem alle freien Speicherblöcke mit Nullen beschrieben werden ([[vm_anpassen#plattenplatz_freigeben|Anleitung]]). Als Komprimierungsalgorithmus kann zstd (Zstandard) oder zlib verwendet werden; empfohlen wird der zstd-Algorithmus. 
 + 
 +Die Kompression des Festplattenabbilds erfolgt mit folgenden Konsolenaufrufen: 
 +<code> 
 +qemu-img convert -f qcow2 -O qcow2 -c -o compression_type=zstd [Datei.qcow2] [temp_Datei.qcow2] 
 +mv [temp_Datei.qcow2] [Datei.qcow2] 
 +</code> 
 + 
 +==== Upload der VM ==== 
 + 
 +Die exportierte xml-Datei kann [[bwlehrpool-suite#neue_virtuelle_maschinen_hochladen|wie üblich]] zum Upload der VM mit der bwLehrpool-Suite verwendet werden.
  
-===== Virtuelle Maschinen (VMs) ===== 
  
-==== Erstellen einer neuen VM ====+===== Erstellen einer neuen VM =====
  
-Es stehen die folgenden Möglichkeiten zur Verfügung eine neue virtuelle Maschine, bestehend aus einer Maschinenkonfiguration und eines Festplattenabbilds, für ein Gastsystem zu erstellen. Nach der Erstellung erfolgt der Export und Upload der erstellten VM via bwSuite.+Von der allgemeinen Empfehlung abgesehen, besser Vorlagen-VMs herunterzuladen und anzupassen, können natürlich eigene VMs von Grund auf neu erstellt werden. Mitunter ist dies der einzige Weg, wenn Sie etwa ein exotischeres Betriebssystem, eine ungewöhnliche Ausführung usw. benötigen. Zu diesem Zweck müssen Sie eine Konfiguration mit zugeordnetem Festplattenabbild erstellen. Nach Erstellung und ggf. Export der Konfiguration kann die VM wie gewohnt mittels bwLehrpool-Suite hochgeladen werden.
  
-Für ein Erstellen einer VM werden folgende Optionen empfohlen:+Allgemein werden folgende Konfigurationsoptionen empfohlen:
  
-  * emulierte Hardwaregeräte, wenn möglich, immer auf den Typ „virtio“ stellen (z.B., aber nicht nur, NIC, HD). +  * Emulierte Hardwaregeräte, wenn möglich, immer auf den Typ „virtio“ stellen (z.B., aber nicht nur, Netzwerkkarten, Festplatten). 
-  * dies gilt prinzipiell auch für die grafische Ausgabe („Video“); „virtio“ kann jedoch in Windows-Gästen Probleme bereiten. Mit dem etwas weniger performanten QXL ist man da auf der sicheren Seite. +  * 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“. +  * „Anzeige Spice“ sollte auf „SPICE-Server“ gesetzt werden. 
-  * das QCOW2-Format 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 [[client:qemu#optionale_optimierung_der_vm|Optionale 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 des Virtual Machine Managers oder mit Hilfe von Cockpit. Für die Erstellung wird der jeweilige Assistent (Wizard) gestartet und befolgt.+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 ====
  
 Ein manuelles Erstellen der VM kann alternativ über den folgenden Konsolenaufruf erfolgen. Ein manuelles Erstellen der VM kann alternativ über den folgenden Konsolenaufruf erfolgen.
Zeile 86: Zeile 111:
 <code> <code>
 virt-install --connect qemu:///system \ virt-install --connect qemu:///system \
-             --name Windows10_x64_Vorlage_Standard \+             --name openSuse_Tumbleweed_64bit \
              --memory 3072 \              --memory 3072 \
              --vcpus 2 \              --vcpus 2 \
-             --disk Windows10_x64_Vorlage_STANDARD.qcow2,bus=sata \ +             --disk openSuse_Tumbleweed_64bit.qcow2,bus=sata \ 
-             --os-variant win10 \+             --os-variant opensusetumbleweed \
              --network default \              --network default \
              --check path_in_use=off \              --check path_in_use=off \
-             --cdrom /home/chr/isos/virtio-win-0.1.196.iso+             --cdrom /home/chr/isos/tumbleutils.iso
 </code> </code>
  
-Anmerkung: Mit „osinfo-query os“ (osinfo-query aus libosinfo) können verfügbare Werte für --os-variant angezeigt werden. cdrom-Angabe wertvoll, damit gleich in VM enthalten.+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.
  
-=== Export und Upload der VM === 
  
-== Export der VM ==+==== Software ====
  
-Die Konfiguration der erstellten virtuellen Maschine sollte für einen Upload via bwLehrpool-Suite in einem ersten Schritt mittels des folgenden Konsolenaufrufs exportiert werden. Das Festplattenabbild der VM muss dabei nicht explizit kopiert werden, da die exportierte Konfiguration (XML-Datei) automatisch auf das vorhandene Festplattenabbild verweist.+Unter den jeweiligen Gastsystemen sollten u.a. zur Performanzverbesserung folgende Gastprogramme installiert werden:
  
-<code>virsh -c qemu:///system dumpxml [VM-Name] > [xml-Datei]</code>+=== Linux ===
  
-Hinweis: Folgender Befehl listet die vorhandenen VMs auf, falls Sie sich des VM-Namens nicht sicher sind: +  * virtio Linux-Kernel-Treiber, 
-<code>virsh -c qemu:///system list --all</code>+  * xserver-xorg-video-qxl bzw. xf86-video-qxl (bei Verwendung der paravirtualisierten 2D QXL-Grafik), 
 +  * qemu-ga (qemu-guest-agent), 
 +  * spice-vdagent.
  
-<note important>Allgemein: Wenn per virt-manager etwas an der Konfiguration geändert wurde, muss die xml-Datei per dumpxml neu geschrieben werden, bevor ein Upload per bwLehrpool-Suite erfolgt.</note>+=== Windows ===
  
-== Optionale Optimierung der VM == +  * virtio Windows-Treiber per [[https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso|virtio-win-ISO-Installer]], 
- +  * qemu-ga (qemu-guest-agent), 
-Bevor der Upload via bwLehrpool-Suite vorgenommen wird, kann eine optionale Optimierung des QCOW2 Festplattenabbildes der VM vorgenommen werden. Die Optimierung umfasst das Komprimieren des Festplattenabbilds vor dem Upload der VM, um spätere Bootzeiten der VM zu verringern. Dazu sollten zuvor im Gastsystem alle freien Speicherblöcke mit Nullen beschrieben werden, um die best-möglichste Kompression zu erzielen. Die Kompression des Festplattenabbilds erfolgt mit folgenden Konsolenaufrufen. +  * spice-vdagent.
- +
-<code> +
-mv [Datei.qcow2] [tmp-Datei.qcow2] +
-qemu-img convert -f qcow2 -O qcow2 -c -o compression_type=zstd [tmp-Datei.qcow2] [Datei.qcow2] +
-rm [tmp-Datei.qcow2] +
-</code> +
- +
-Hinweis: Als Komprimierungsalgorithmus kann zstd (Zstandard) oder zlib verwendet werden. Empfohlen wird der zstd-Algorithmus.+
  
-== Upload der VM ==+==== Export und Upload ====
  
-Die exportierte XML-Datei kann in einem nachfolgenden Schritt zum Upload via bwLehrpool-Suite verwendet werden.+Der Export und Upload der VM erfolgt analog zu dem Vorgang ab [[#export_der_konfiguration|Export der Konfiguration]].
  
-== Export Windows Guests == 
  
-Beim Export von Windows VMs in Infrastrukturen wie bwClouds OpenStack gilt der folgende Workflow :+===== Startprobleme =====
  
-  - VM Disk [[client:qemu#Optionale Optimierung der VM|konvertieren]] mit qemu-img convert in raw format (Erforderlich Stand 05.22) +==== Netzwerk ====
-  - Es wird empfohlen, [[client:qemu#VirtIO: Installationsanleitung Windows|VirtIO Treiber zu installieren]] +
-  - Je nach Anwendungsfall sind folgende Schritte notwendig: \\ a) [[client:qemu#Cloudbase für Windows -> Cloudbase-init: Installationsanleitung|Cloudinit installieren]] \\ b) und ebenfalls [[client:qemu#SSH Server für Windows Clients oder Guests : Installationsanleitung|OpenSSH.Server]] +
-  - VM Disk als Image ins OpenStack hochladen. (API oder mit Openstack CLI). +
- +
- +
- **Troubleshooting zum Export von Windows Guests:** +
- +
- +
- +
-Wichtig ist es auch, auf die Eigenschaften der Machine zu achten (in OpenStack sog. [[https://docs.openstack.org/glance/latest/admin/useful-image-properties.html|Properties]] ). Diese Eigenschaften werden als Metadaten in OpenStack aufgefasst. \\ +
-Bei der Fehlersuche können die folgenden Properties eine Rolle spielen und sollten auf diese Werte überprüft werden: +
-<code> +
-hw_cdrom_bus +
-sata +
-hw_disk_bus +
-sata +
-hw_firmware_type +
-uefi +
-hw_machine_type +
-q35 +
-hw_video_model +
-vga +
-hw_vif_model +
-e1000 +
-</code> +
-Die Optionen cd-rom und disk bus sind wichtig, denn sie erzwingen die Verwendung eines Bustyps, der mit dem von bwLehrpool kommenden vm in der Regel funktioniert. +
- +
-Der Firmware-Typ hilft bei der Auswahl des richtigen Bootloaders. +
- +
-Der Maschinentyp wählt einen Chipsatz (entweder i440FX oder Q35), der mit dem Virt-Manager für diese Maschinen funktioniert (in der Regel Q35). +
- +
-Das Videomodell ist dazu da, um Probleme mit der Standardgrafik von Cirrus zu vermeiden. VGA wurde gewählt, da es das einfachste Anzeigeformat ist. +
- +
-Schließlich gab es noch Probleme mit der Netzwerkkarte und dem Ethernet-Controller. +
-Um dies zu vermeiden, konnten wir ein virtuelles Netzwerkschnittstellengerät (vif) vom Typ e1000 wählen, das normalerweise auch im virt-manager verwendet wird.  +
-Derartige Problemen treten jedoch nur auf, wenn man VirtIO nicht vorher installiert hat.  +
- +
-==== Bearbeiten einer existierenden VM ==== +
- +
-=== Download und Import der VM === +
- +
-Eine existierende VM kann für eine Bearbeitung via bwSuite heruntergeladen werden. Vor dem Download sollte geprüft werden, welche Busart zum Ansprechen des Massenspeichers im auf dem Image befindlichen Gastbetriebssystem verwendet wurde (scsi, sata, ata). Ansonsten kann es zu Problemen beim Gast-Boot kommen. Bei Linuxgästen („a start job is running… for dev/disk…“ 1:30) Hibernation kontrollieren (systemd-hibernate-resume), ggf. resume aus KCL entfernen. Nach dem Download der VM erfolgt ein Import der Konfiguration in libvirt mit einem der beiden folgenden Konsolenaufrufen. +
- +
-<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 === +
- +
-Die Konfiguration der importierten VM kann nun editiert werden und das Gastsystem gestartet werden, wenn noch nicht geschehen. Diese Bearbeitung kann grafisch mittels Virtual Machine Manager oder Cockpit erfolgen. +
- +
-=== Startprobleme === +
- +
-== Netzwerk ==+
  
 Mitunter tritt beim Start der VM die Meldung „Requested operation is not valid: network 'default' is not active“ auf. Zur Behebung können Sie entweder das default-Netzwerk starten, oder je nach Ihrer lokalen Umgebung ein anderes (virtuelles) Netzwerk benutzen. Falls Sie ein anderes, lokal definiertes Netzwerk nutzen wollen, importieren Sie die VM mittels „define“, also ohne sie zu starten, und ändern die Einstellung unter (virt-manager) NIC, „Virtuelle Netzwerkschnittstelle“, „Netzwerkquelle“. Mitunter tritt beim Start der VM die Meldung „Requested operation is not valid: network 'default' is not active“ auf. Zur Behebung können Sie entweder das default-Netzwerk starten, oder je nach Ihrer lokalen Umgebung ein anderes (virtuelles) Netzwerk benutzen. Falls Sie ein anderes, lokal definiertes Netzwerk nutzen wollen, importieren Sie die VM mittels „define“, also ohne sie zu starten, und ändern die Einstellung unter (virt-manager) NIC, „Virtuelle Netzwerkschnittstelle“, „Netzwerkquelle“.
Zeile 199: Zeile 160:
  default   inactive   no         yes</code>  default   inactive   no         yes</code>
  
-[{{ client:qemu:qemu_default_network_inaktiv.png?200|inaktives Default-Netzwerk}}]In o. a. Beispiel ist das default-Netzwerk inaktiv. Starten Sie es mit „virsh -c qemu:///system net-start default“. Wenn wie in obigem Beispiel kein Autostart des default-Netzwerks gegeben ist, können Sie dem mit „virsh -c qemu:///system net-autostart default“ abhelfen. Eine erneute Abfrage mit net-list sollte dann folgende Ausgabe liefern:+[{{ client:qemu:qemu_default_network_inaktiv.png?200|inaktives Default-Netzwerk}}]In o. a. Beispiel ist das default-Netzwerk inaktiv. Starten Sie es mit  
 +<code>virsh -c qemu:///system net-start default</code>. Wenn wie in obigem Beispiel kein Autostart des default-Netzwerks gegeben ist, können Sie dem mit <code>virsh -c qemu:///system net-autostart default</code> abhelfen. Eine erneute Abfrage mit net-list sollte dann folgende Ausgabe liefern:
  
 <code>Name      State    Autostart   Persistent <code>Name      State    Autostart   Persistent
Zeile 207: Zeile 169:
 Das sollte das Problem beheben. Das sollte das Problem beheben.
  
-== Laufwerke ==+==== Laufwerke ====
  
 [{{ client:qemu:qemu_cdrom_fehlend.png?200|Kein DVD/CDROM?}}] Wenn Ihr Rechner nicht über ein DVD-Laufwerk verfügt, die heruntergeladene xml-Steuerdatei aber auf eines verweisen sollte, kann die Fehlermeldung jedoch  „Fehler beim Starten der Domain: Cannot access storage file '/dev/sr0': Datei oder Verzeichnis nicht gefunden“ auftreten. [{{ client:qemu:qemu_cdrom_fehlend.png?200|Kein DVD/CDROM?}}] Wenn Ihr Rechner nicht über ein DVD-Laufwerk verfügt, die heruntergeladene xml-Steuerdatei aber auf eines verweisen sollte, kann die Fehlermeldung jedoch  „Fehler beim Starten der Domain: Cannot access storage file '/dev/sr0': Datei oder Verzeichnis nicht gefunden“ auftreten.
  
 In desem Fall: In desem Fall:
-  * „Konsole der virtuellen Maschine und Details anzeigen“ +  * „Konsole der virtuellen Maschine und Details anzeigen“, 
-  * „Details der virtuellen Geräte anzeigen“ +  * „Details der virtuellen Geräte anzeigen“, 
-  * „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“.
  
-=== Export und Upload der VM ===+==== Verzeichnisberechtigungen ====
  
-Die bearbeitete Maschine wird anschließend wieder exportiert und dann mittels bwSuite gemäß den Instruktionen im Abschnitt [[client:qemu#export_und_upload_der_vm|Export und Upload der VM]] als neue Maschinenversion hochgeladen.+=== 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>
  
-==== Notizen ====+… 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. 
  
-CDROM-Wechsel für Gast: +=== Abhilfe ===
-  * virsh -c qemu:///system list --all (VMs auflisten), +
-  * virsh -c qemu:///system domblklist [VM-Name] (listet Blockdevs a la sda usw.),  +
-  * virsh -c qemu:///system change-media [VM-Name] [blockdev] --eject (auswerfen), +
-  * virsh -c qemu:///system change-media [VM-Name] [blockdev] [iso-Datei] --insert +
  
-  * virsh change-media [VM-Name] [blockdev] [iso-Datei] --insert --live (--> Fehler: Die Disk Einheit 'sdb' hat bereits Medien, also immer eject vorher)+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 ===== 
 + 
 +<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: 
 + 
 +  - Plattenabbild mit „qemu-img convert“ in's raw-Format [[#optimierung_optional|konvertieren]] (erforderlich, Stand 05.22). 
 +  - Es wird empfohlen, soweit möglich virtio-Treiber zu installieren. 
 +  - Je nach Anwendungsfall sind folgende Schritte notwendig: 
 +    -  [[client:qemu#Cloudbase für Windows -> Cloudbase-init: Installationsanleitung|Cloudinit installieren]] 
 +    -  und ebenfalls [[client:qemu#SSH Server für Windows Clients oder Guests: Installationsanleitung|OpenSSH.Server]] 
 +  - Plattenabbild API oder mit Openstacks CLI als Image nach OpenStack hochladen. 
 + 
 +==== Troubleshooting zum Export von Windows Guests ==== 
 + 
 +Es ist wichtig, auf die Eigenschaften der Machine zu achten (in OpenStack sog. [[https://docs.openstack.org/glance/latest/admin/useful-image-properties.html|Properties]] ). Diese Eigenschaften werden als Metadaten in OpenStack aufgefasst. Bei der Fehlersuche können die folgenden Properties eine Rolle spielen und sollten auf diese Werte überprüft werden: 
 + 
 +<code> 
 +hw_cdrom_bus sata 
 +hw_disk_bus sata 
 +hw_firmware_type uefi 
 +hw_machine_type q35 
 +hw_video_model vga 
 +hw_vif_model e1000 
 +</code> 
 + 
 +Die Optionen hw_cdrom und hw_disk_bus sind wichtig zur Verwendung eines Bustyps, der mit dem von bwLehrpool kommenden VMs in der Regel funktioniert Ist dem so? Prüfen!). Der Firmware-Typ hilft bei der Auswahl des richtigen Bootloaders, der Maschinentyp wählt einen Chipsatz (entweder i440FX oder Q35), der mit dem Virt-Manager für diese Maschinen funktioniert (in der Regel Q35). Das Videomodell ist dazu da, um Probleme mit der Standardgrafik von Cirrus zu vermeiden. VGA wurde gewählt, da es das einfachste Anzeigeformat ist. 
 + 
 +Schließlich ergaben sich Probleme mit der Netzwerkkarte/Ethernet-Controller. Zur Vermeidung konnte ein virtuelles Netzwerkschnittstellengerät (vif) vom Typ e1000 gewählt werden, das normalerweise auch im virt-manager verwendet wird. Derartige Problemen treten jedoch nur auf, wenn VirtIO nicht installiert wurde.
  
 „“ „“
 +

Zuletzt angesehen:

Drucken/exportieren