Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- tachtler:archlinux_-_virtualisierung_mit_kvm [2020/07/03 16:24] – [Installation] klaus
+++ tachtler:archlinux_-_virtualisierung_mit_kvm [2020/07/13 16:25] – [cannot open display] klaus
@@ Zeile 10: / Zeile 10: @@
 | - QEMU            | [[https://wiki.archlinux.org/index.php/QEMU]]                                   |
 | - libvirt         | [[https://wiki.archlinux.org/index.php/Libvirt]]                                |
-| - HowTo           | [[https://computingforgeeks.com/complete-installation-of-kvmqemu-and-virt-manager-on-arch-linux-and-manjaro/]] |
 Die hier vorgestellte Möglichkeit dies zu realisieren soll möglichst nach folgenden Vorgaben erfolgen:
@@ Zeile 33: / Zeile 32: @@
 durchgeführt werden, auf die dann aufbauend die **__noch__** benötigte Installation für eine **grafische Benutzeroberfläche**, hier z.B.
   * **[[tachtler:archlinux_-_minimal_desktop_gnome|ArchLinux - Minimal Desktop GNOME]]**
+**__oder__**
+  * **[[tachtler:archlinux_-_minimal_desktop_mate|ArchLinux - Minimal Desktop MATE]]**
 sukzessive durchgeführt werden soll.
+===== Installation =====
+Nachfolgende Pakete ermöglichen die Installation der Virtualisierungsplatform KVM (''qemu'') und die Möglichkeit über das Desktop-Programm **''virt-manager''** über eine GUI komfortabel virtuelle Maschinen unter
+[[https://www.archlinux.de/|ArchLinux]] zu erstellen.
+  * **''qemu''** - Virtualisierungsumgebung selbst mit allen dafür benötigten Paketen
+  * **''virt-manager''** - Desktop GUI zur Verwaltung von virtuellen Maschinen
+  * **''dnsmasq''** - DNS "Forwarder" und DHCP-Server
+  * **''ebtables''** - Netzwerk Brücken (ethernet bridge) Filter Werkzeuge
+  * **''dmidecode''** - Desktop Management Interface Tabellen Werkzeuge
+<code>
+# pacman -S qemu virt-manager dnsmasq ebtables dmidecode
+</code>
+===== Dienst/Daemon einrichten =====
+Damit nach einem Neustart des Servers auch die Virtualisierungsumgebung zur Verfügung steht, muss der ''libvirtd''-Dienst/Daemon gestartet werden, was mit nachfolgendem Befehl eingerichtet werden muss:
+<code>
+[root@archlinux ~]# systemctl enable libvirtd.service
+Created symlink /etc/systemd/system/multi-user.target.wants/libvirtd.service → /usr/lib/systemd/system/libvirtd.service.
+Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket → /usr/lib/systemd/system/virtlockd.socket.
+Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket → /usr/lib/systemd/system/virtlogd.socket.
+Created symlink /etc/systemd/system/sockets.target.wants/libvirtd.socket → /usr/lib/systemd/system/libvirtd.socket.
+Created symlink /etc/systemd/system/sockets.target.wants/libvirtd-ro.socket → /usr/lib/systemd/system/libvirtd-ro.socket.
+</code>
+Eine Überprüfung, ob beim Neustart des Server der ''libvirtd''-Dienst/Daemon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben:
+<code>
+[root@archlinux ~]# systemctl list-unit-files --type=service | grep -E ^libvirtd
+libvirtd.service                           enabled         disabled
+</code>
+bzw.
+<code>
+[root@archlinux ~]# systemctl is-enabled libvirtd.service
+enabled
+</code>
+===== Dienst: libvirtd starten =====
+Anschließend kann der Dienst/Daemon gestartet werden, was mit nachfolgendem Befehl durchgeführt wird:
+<code>
+# systemctl start libvirtd.service
+</code>
+und mit nachfolgendem Befehl überprüft werden, ob der Start auch erfolgreich funktioniert hat:
+<code>
+# systemctl status libvirtd.service
+● libvirtd.service - Virtualization daemon
+     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: disabled)
+     Active: active (running) since Mon 2020-07-13 13:06:28 CEST; 2s ago
+TriggeredBy: ● libvirtd-admin.socket
+             ● libvirtd-ro.socket
+             ● libvirtd.socket
+       Docs: man:libvirtd(8)
+             https://libvirt.org
+   Main PID: 6340 (libvirtd)
+      Tasks: 17 (limit: 32768)
+     Memory: 8.4M
+     CGroup: /system.slice/libvirtd.service
+             └─6340 /usr/bin/libvirtd --timeout 120
+Jul 13 13:06:28 archlinux systemd[1]: Started Virtualization daemon.
+</code>
+===== Benutzer libvirt anlegen =====
+Nachfolgender Befehl erstellt einen **neuen** Benutzer mit
+  * dem **Kommentar**: ''libvirt''
+  * der **Gruppen-ID**: ''972''
+  * und mit der Erstellung eines **''home''**-Verzeichnisses
+  * der **''shell''**: ''/bin/bash''
+  * der **Benutzer-ID**: ''972''
+  * der **Bezeichnung**: hier ''libvirt''
+<code>
+[root@archlinux ~]# useradd -c 'libvirt' -g 972 -m -s /bin/bash -u 972 libvirt
+</code>
+Ein Überprüfung ob der Benutzer ordnungsgemäß erstellt wurde, kann durch ausführen von nachfolgendem Befehl und einer Anzeige wie folgt, durchgeführt werden:
+<code>
+[root@archlinux ~]# cat /etc/passwd | grep libvirt
+libvirt:x:972:972:libvirt:/home/libvirt:/bin/bash
+</code>
+Abschließend soll noch ein Passwort für den Benutzer ''libvirt'' mit nachfolgendem Befehl gesetzt werden:
+<code>
+[root@archlinux ~]# passwd libvirt
+New password
+Retype new password:
+passwd: password updated successfully
+</code>
+===== X-Session Übernahme ermöglichen =====
+Damit eine Übernahme der **X-Session** vom Benutzer der sich via ''SSH'' verbindet, auf den zuvor engelegten Benutzer ''libvirt'' möglich wird, sind nachfolgende Ergänzungen der Konfigurationsdateien:
+  * **''/etc/pam.d/su''**
+  * **''/etc/pam.d/su-l''**
+notwendig.
+Nachfolgende Zeilen sind an die jeweils zuvor genannten Konfigurationsdateien anzuhängen was mit nachfolgenden Befehlen durchgeführt werden kann:
+==== /etc/pam.d/su ====
+<code>
+# echo session         optional        pam_xauth.so >> /etc/pam.d/su
+</code>
+==== /etc/pam.d/su-l ====
+<code>
+# echo session         optional        pam_xauth.so >> /etc/pam.d/su-l
+</code>
+===== Starten des virt-managers über eine Remote-Verbindung =====
+==== Login via SSH-Benutzer ====
+Zuerst soll eine ''SSH''-Remote-Verbindung zum Server hergestellt werden, auf dem der ''libvirtd''-Dienst/Daemon läuft. Nachfolgend soll der Benuzter ''klaus'' dazu verwendet werden:
+<code>
+$ ssh -A -X -2 -t klaus@192.168.0.125
+klaus@192.168.0.125's password:
+Last login: Mon Jul 13 15:36:07 2020 from 192.168.0.20
+[klaus@archlinux ~]$
+</code>
+==== Benutzerwechsel: libvirt ====
+Anschließend soll vom Benutzer ''klaus'' zum Benutzer ''libvirt'' mit nachfolgendem Befehl gewechselt werden:
+<code>
+[klaus@archlinux ~]$ su libvirt -
+Password:
+[libvirt@archlinux klaus]$
+</code>
+==== Starten des virt-manager ====
+Nun kann als Benutzer ''libvirt'' der ''virt-manager'' mit nachfolgendem Befehl gestartet werden:
+<code>
+$ virt-manager &
+[1] 1074
+[libvirt@archlinux klaus]$
+</code>
+Mit nachfolgendem Befehl kann nach erfolgreichem Wechsel zum Benutzer ''libvirt'' und Start des ''virt-manager'''s überprüft werden, ob dieser auch unter dem Benutzer ''libvirt'' gestartet wurde und **__nicht__** unter dem Benutzer, unter dem die ''SSH''-Verbindung hergestellt wurde:
+<code>
+$ ps auxwf | grep virt-manager
+libvirt      978  0.0  0.0   6596  2256 pts/0    S+   15:33   0:00                      \_ grep virt-manager
+libvirt      922  2.1  0.1 784460 76688 ?        Ssl  15:31   0:01 python3 /usr/share/virt-manager/virt-manager
+</code>
+Nach ein wenig Anpassungen am Aussehen des ''virt-manager''s, könnte dieser nun wie folgt, nach dessen Start, aussehen:
+{{:tachtler:virtualisierung:archlinux:archlinux_virt-manager_configured.png|ArchLinux - virt-manager - angepasstes Aussehen}}
+===== Problembehandlung =====
+==== cannot open display ====
+Falls nach einer erfolgreichen ''SSH''-Remote-Verbindung und der Wechsel zum Benutzer ''libvirt'' nachfolgende Fehlermeldung beim **Starten des ''virt-manager'''s** erscheinen sollte:
+<code>
+[libvirt@archlinux klaus]$ virt-manager &
+[1] 1158
+[libvirt@archlinux klaus]$ Unable to init server: Could not connect: Connection refused
+Unable to init server: Could not connect: Connection refused
+Unable to init server: Could not connect: Connection refused
+(virt-manager:1159): Gtk-WARNING **: 15:45:42.590: cannot open display:
+</code>
+liegt dies daran, dass in der Konfigurationsdatei
+  * **''/etc/ssh/sshd_config''**
+das
+  * ''X11Forwarding no''
+noch gesetzt ist.
+Eine Korrektur der Einstellung in der Konfigurationsdatei ''/etc/ssh/sshd_config'' bei ''X11Forwarding'' wie folgt dargestellt, einem **Neustart des SSH-Dienstes/Daemon** und dem kompletten Verlassen der ''SSH''-Remote-Verbindung mit allen Benutzer und einer entsprechenden Neuanmeldung, sollte das Problem lösen:
+**Nur relevanter Ausschnitt**:
+<code bash>
+# Tachtler
+# default: #X11Forwarding no
+X11Forwarding yes
+</code>