libvirt - Verwaltungs-Frontend ############################## - Datum: 05.05.2026 - Distribution: openSUSE 15.6 **Motivation:** Libvirt ist ein umfangreiches, einheitliches Verwaltungswerkzeug für unterschiedlichste Hypervisor-Typen und für klassische Linux-Container (LXC). Der zentrale Daemon ist ``/usr/sbin/libvirtd``, für die Verwaltung und Konfiguration stehen viele Tools zur Verfügung, für die Installation ``virt-install``, dann vor allem das Kommandozeilenwerkzeug ``virsh`` sowie das grafische Werkzeug ``virt-manager``. .. figure:: img/Libvirt_support.* Bild 1: Vielfältige Steuerungsmöglichkeiten `(Bildquelle: Wikipedia) `_ Installation ============ Mit ``zypper in libvirt virt-manager virt-viewer vm-install`` gelangt die Software ins System, dabei werden viele weitere Pakete mitinstalliert. Nun aktivieren und starten wir die Daemons: :: systemctl enable libvirtd.service libvirt-guests.service systemctl start libvirtd.service libvirt-guests.service Schließlich verhilft ``usermod -aG qemu,kvm,libvirt tux`` dazu, dass der User "tux" die Konfigurationswerkzeuge selber verwenden kann. wobei es sich danach komplett aus- und wieder einloggen muss. Mit ``virsh nodeinfo`` kann man sich einen Überblick über die gelungende Installation verschaffen. Arbeitsmodi =========== Libvirt kann in drei Modi arbeiten: **1. System, QEMU/KVM** VMs laufen je nach Voreinstellung dank eines System-Accounts mit privilegierten Rechten des Hypervisors, womit sich komplexere Netzwerksituationen umsetzen lassen; z.B.: ``virsh -c qemu:///system list --all`` **2. Session, QEMU/KVM-Benutzersitzung:** VMs laufen nur mit den Privilegien eines User-Accounts, dabei sind Netzwerkoptionen sehr limitiert, es wird dabei einfach das Qemu-usernet benutzt; z.B.: ``virsh -c qemu:///session list --all``. In der Regel ist dieser Modus für einen User voreingestellt, so dass ``-c qemu:///session`` weggelassen werden kann. **3. LXC, Libvirt-LXC:** Damit lassen sich Anwendungs- oder Betriebssystem-Container verwalten; z.B.: ``virsh -c lxc:/// list --all`` HINWEIS: Mit ``export LIBVIRT_DEFAULT_URI="qemu:///system"`` kann man sich z.B. den ersten Modus zum Standard machen (falls das nicht schon der Fall ist), womit die Angabe von ``-c , --connect URI`` entfällt. Diese Variable kann in die ``~/.bashrc`` aufgenommen werden. Vom Endeffekt kann man sich mittels ``virsh uri`` überzeugen, es sollte "qemu:///system" erscheinen. Mit VMs arbeiten ================ VM mit openSUSE 15 erstellen ---------------------------- Dieses erste Minimal-Beispiel verwendet den session-Modus von libvirt, in Sachen Netzwerk den einfachen NAT-Modus (Qemu: "usernet"), weswegen das libvirt-Netzwerk *default* nicht aktiv sein muss. Außerdem kann die Installations-CD im Heimatverzeichnis des Users verbleiben (Im Modus "qemu:///session" würde der User nach dem Starten des Skriptes nicht mehr Eigentümer sein!). Wir schreiben das Folgende am besten in ein Shellskript und führen es aus: :: virt-install \ --name suse15 \ --memory 4096 \ --disk size=7,format=qcow2,bus=virtio \ --cdrom=/home/tux/Downloads/openSUSE-Leap-15.6-DVD-x86_64-Build710.3-Media.iso \ --graphics spice,keymap=de \ --network=user Während der Installation startet sich der Spice-Client (grafische Fernsteuerung), das Programm kann später bei laufendem Gast wieder mittels ``virt-viewer --connect qemu:///session suse15`` aufgerufen werden. Die VM kann z.B. so gesteuert werden (wir gehen hier davon aus, dass wie im Sitzungsmodus sind, also ``-c qemu:///session`` entfallen kann: :: # Zustand der VMs auflisten: virsh list --all # VM starten: virsh start suse15 # VM herunterfahren: virsh shutdown suse15 # VM gewaltsam ausschalten: virsh destroy suse15 Wenn wir wissen wollen, welche NAT-Übersetzungen in der VM stattgefunden haben, kann uns nur Qemu Auskunft geben -- wir benutzen hier seinen einfachen "NAT-Router": ``qemu ... -net nic -net usernet`` = default für Qemu. Die Kommandozeile lautet: :: virsh qemu-monitor-command suse15 --hmp "info usernet" OpenSUSE wirft bei diesem Setup übrigens anders als üblich die CD aus und ändert in der XML-Datei die Bootreihenfolge selbständig von ```` auf ````. Das ließe sich nachträglich mittels ``virsh -c qemu:///system edit suse15`` ändern. Sollte die Installation-CD doch wieder eingelegt werden müssen, ist ein *change-media* fällig: :: tux@suseHOST:~> virsh change-media suse15 sda /home/axl/Downloads/openSUSE-Leap-15.6-DVD-x86_64-Build710.3-Media.iso --insert Successfully inserted media. tux@suseHOST:~> tux@suseHOST:~> # => einfach nur sda angeben! tux@suseHOST:~> tux@suseHOST:~> virsh dumpxml suse15.6 | grep -i suse suse15.6 tux@suseHOST:~> VM mit Debian 13 erstellen -------------------------- Diesmal soll der System-Modus ("qemu:///system") verwendet werden, womit erweiterte Netzwerkfähigkeiten zur Verfügung stehen. Dazu muss aber ``virsh`` zeigen, dass das Netzwerk "default" aktiv ist. Falls nicht, helfen folgende Kommandos weiter: :: virsh -c qemu:///system net-list --all virsh -c qemu:///system net-start default virsh -c qemu:///system net-autostart default Möglicherweise meldet libvirtd beim Installieren einer VM, dass die Betriebssystemerkennung zur Optimierung fehlgeschlagen ist. Dann schauen wir mit ``virt-install --osinfo list | less`` nach, welche Version die richtige sein könnte, die dann mit ``--osinfo detect=on,name=debian13`` konfiguriert werden kann. Mit ``--osinfo detect=on,require=off`` lässt sich dieses Verhalten aber abstellen. Das nunmehr von https://debian.org heruntergeladene Netinstall-ISO-Abbild muss an die richtige Stelle gelangen: :: mv /home/tux/Downloads/debian-13.4.0-amd64-netinst.iso /var/lib/libvirt/boot/ Wir schreiben uns wieder ein Skript und bringen es zur Ausführung: :: virt-install --connect qemu:///system \ --name deb13-01 \ --osinfo detect=on,name=debian13 \ --memory 1024 \ --disk size=20,format=qcow2,bus=virtio \ --cdrom /var/lib/libvirt/boot/debian-13.4.0-amd64-netinst.iso \ --boot cdrom \ --graphics spice,keymap=de \ --network default Sehr wahrscheinlich wird aber die VM nicht booten können, es gibt nämlich ein Problem mit der Boot-Sequenz: :: Booting from DVD/CD... Boot failed: Could not read from CDROM No bootable device Wir müssen die VM nun stoppen und die Konfiguration editieren. An den eingehängten Block-Geräten liegt es nicht, wir sehen, dass sich nur die qcow2-Festplatte in der VM befindet: :: tux@suseHOST:~> virsh -c qemu:///system destroy deb13-01 Domain 'deb13-01' destroyed tux@suseHOST:~> virsh -c qemu:///system domblklist deb13-01 Ziel Quelle ------------------------------------------------ vda /var/lib/libvirt/images/deb13-01.qcow2 sda - tux@suseHOST:~> tux@suseHOST:~> virsh -c qemu:///system edit deb13-01 deb13-01 3116a247-e2d2-4500-8b88-8813c3b5391b 1048576 1048576 2 hvm ... => Geändert auf: => vim-gemäß speichern und beenden: ESC :wq Danach die VM wieder starten und sich über den Spice-Client verbinden: :: virsh -c qemu:///system start deb13-01 virt-viewer --connect=qemu:///system deb13-01 &>/dev/null & VMs klonen, entfernen, Snapshots ================================ VM klonen --------- Es sollte die VM zumindestens mit ``virsh -c qemu:///system suspend deb13-01`` angehalten werden, danach wird diese originale VM samt Standard-Verbindung und Festplattenpfad unter neuer Namensvergabe geklont: :: tux@suseHOST:~> virt-clone --connect qemu:///system --original deb13-01 --auto-clone Allocating 'deb13-01-snap-2026-05-06_07-00-clone.qcow2' | 20 GB 00:00:01 Klone »deb13-01-clone« wurde erfolgreich erstellt. tux@suseHOST:~> VMs entfernen ------------- Um eine VM komplett mitsamt all seinem Speicher (!) zu löschen, können wir folgende Zeilen benutzen: :: virsh -c qemu:///system destroy debian13 virsh -c qemu:///system undefine debian13 --remove-all-storage Snapshots ========= Externe Snapshots ----------------- Die sicherste Art sind externe Snapshots, die also in als separate Differenz-Datei auf der Festplatte landen. Das Ganze gescheht in der Art von *BACKING_FILE*, wie es manuell mittels ``qemu-img create -f qcow2 -o backing_file=basis-os.img overlay.img`` gemacht werden könnte. Die Kommandozeile ist etwas länger, drum lohnt es sich, das Ganze wieder in ein Shellskript zu schreiben und auszuführen: :: #!/bin/bash vmname="debian13" virsh -c qemu:///system snapshot-create-as \ --domain ${vmname} \ --name "extern-$(date +%F_%H-%M).snap" \ --disk-only \ --diskspec vda,snapshot=external,file=/var/lib/libvirt/images/${vmname}-$(date +%F_%H-%M)-snap.qcow2 \ --no-metadata \ --description "Ein OS-Schnappschuss!" Interne Snapshots ----------------- Diese Art von Differenzbildung benutzt dazu die virtuelle qcow2-Festplatte selber. Das ist nicht ganz so robust, gestaltet sich dafür aber einfacher. Als Beispiel wollen wir dazu eine weitere VM heranziehen. Alpine Linux ist schnell installiert... 1. wget https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-standard-3.21.0-x86_64.iso 2. Als root: ``mv /home/tux/alpine-standard-3.21.0-x86_64.iso /var/lib/libvirt/boot/`` 3. Als User tux schreiben wir ein Skript und führen es aus: :: virt-install --connect qemu:///system \ --name alpine321 \ --osinfo detect=on,name=alpinelinux3.21 \ --memory 1024 \ --disk size=20,format=qcow2,bus=virtio \ --cdrom /var/lib/libvirt/boot/alpine-standard-3.21.0-x86_64.iso \ --boot cdrom \ --graphics spice,keymap=de \ --network default Wir können beide Arten von Snapshots mit dem grafischen *virt-manager* erzeugen, was hier auch geschah, deshalb gibt es schon *snapshot1*. Mittels ``virsh snapshot-create-as --domain --name ""`` erzeugen wir solcherlei Momentaufnahmen mit der Kommandozeile. Im speziellen Fall mittels dieser Zeilen: :: virsh -c qemu:///system snapshot-create-as --domain alpine321 --name snapshot2 --description "before nfs install" virsh -c qemu:///system snapshot-create-as --domain alpine321 --name snapshot3 --description "before nmap install" Zur Kontrolle führen wir folgende beiden Zeilen aus, *snapshot-list* kennt eine Option, die eine Ausgabe in Baumform produziert: :: tux@suse15:~> virsh -c qemu:///system snapshot-list alpine321 Name Erstellungs-Zeit Status -------------------------------------------------- snapshot1 2026-05-06 05:42:45 +0200 shutoff snapshot2 2026-05-06 06:05:34 +0200 running snapshot3 2026-05-06 07:02:26 +0200 running tux@suse15:~> tux@suse15:~> virsh -c qemu:///system snapshot-list alpine321 --tree snapshot1 | +- snapshot2 | +- snapshot3 tux@suse15:~> Und hier kommt noch ein weiterer Snapshot hinzu, diesmal lassen wir uns aber mit *snapshot-info* viele Details anzeigen, allerdings ist *description* nicht dabei: :: tux@suse15:~> virsh -c qemu:///system snapshot-create-as --domain alpine321 --name snapshot4 "before big install actions" Domain snapshot snapshot4 erstellt tux@suse15:~> tux@suse15:~> virsh -c qemu:///system snapshot-info alpine321 --current Name: snapshot4 Domain: alpine321 Aktuell: ja Status: shutoff Standort: intern Übergeordnet: snapshot3 Untergeordnet: 0 Nachfahren: 0 Metadata: ja tux@suse15:~> Wenn wir die *description*-Angaben sehen wollen, müssen wir den XML-Output ausfiltern: :: tux@suse15:~> # Variante 1 mittels 'snapshot-dumpxml': tux@suse15:~> virsh -c qemu:///system snapshot-dumpxml alpine321 --snapshotname snapshot2 | grep description before nfs install tux@suse15:~> tux@suse15:~> # Variante 2 mittels 'snapshot-current': tux@suse15:~> virsh -c qemu:///system snapshot-current alpine321 | grep description before big install actions tux@suse15:~> Netzwerk ======== Im grafischen *virt-manager* sind über *Edit / Connection Details / Virtual Networks / Hinzufügen[+]* fünf Netzwerkmodi zu finden: 1. NAT (übliches NAT-Routing mit DHCP und cache-only DNS) 2. Routed (ein virtueller Router sitzt dazwischen, kein NAT, Isolation durch Subnetze) 3. Isolated (Keine Verbindung zum Host und anderen Netzwerken) 4. Open (Ähnlich wie "routed", es werden keine Firewallregeln hinzugefügt) 5. SR-IOV Pool (Direct / Passthrough für sehr hohe Performance) Siehe dazu: https://libvirt.org/formatnetwork.html Zum NAT Modus ------------- Eine VM wird im Normalfall hinter NAT betrieben, in diesem Modus versorgt virbr0 automatisch den Gast via vnet0 mit Adressen aus 192.168.122.0/24. Bei manchen Distributionen fehlt dieses default-Netzwerk, es kann leicht mittels einer neuen Datei *default-network.xml* erzeugt werden, die den folgenden Inhalt bekommt: :: default Mit ``virsh net-define default-network.xml`` wird diese Konfiguration eingebunden und danach gestartet und aktiviert: :: [artix ~]# virsh net-start default Netzwerk default gestartet [artix ~]# [artix ~]# virsh -c qemu:///system net-autostart default [artix ~]# [artix ~]# virsh net-info --network default Name: default UUID: f3031bbe-746b-49ae-8978-e7f58534a13a Aktiv: ja Bleibend: ja Automatischer Start: ja Brücke: virbr0 [artix ~]# Zum Routed Modus ---------------- - Mittels virt-manager, "Connection details", neu => "brided0" - Gast bekommt via NIC-Einstellung "bridged0" zugeordnet, via virbr1/vnet1 erhält er per DHCP 192.168.100.171 kommt aber nicht zu einem anderen, im LAN laufenden Rechner (192.168.2.108) und überhaupt nicht ins Internet. - Auf dem anderen, im LAN laufenden Rechner (GW ist der SuSE-Host): ``ip route add 192.168.100.0/24 via 192.168.2.102`` - Jetzt können der LAN-Rechner und Gast in beide Richtungen kommunizieren. Linux-Netzwerkbrücke -------------------- Dieser als "Bridged" bezeichneten Modus ist eine weitere Möglichkeit, alle Gäste können direkt die Host-Bridge *br0* benutzen, alles sind im selben LAN (im pysischen Netzsegment) und können uneingeschränkt kommunizieren. Gibt es eine solche, normale Linux-Brücke *br0*, dann benötigen wir den libvirt-Modus *qemu:///system*, das "default Netzwerk" verbindet sich dann transparent über virbr0 und vnet0 zum heimischen LAN (z.B. 192.168.2.0/24). Konfiguration: - Mittels *virt-manager*, in die Einstellungen das Gasts gehen - Bei NIC: einfach "Bridge Device..." wählen - Es wird die mit yast2 erstellte Linux-Bridge "br0" zur Auswahl gestellt - Nach Apply/start erhält der Gast die IP aus dem physichen LAN 192.168.2.107 Informationen erhalten ---------------------- Hier eine Auflistung von Möglickeiten, um verschiedene Informationen über das Netzwerk zu erhalten: :: [axl@artix ~]$ virsh -c qemu:///system domifstat debian13 vnet1 vnet1 rx_bytes 10149 vnet1 rx_packets 165 vnet1 rx_errs 0 vnet1 rx_drop 0 vnet1 tx_bytes 2268 vnet1 tx_packets 26 vnet1 tx_errs 0 vnet1 tx_drop 0 [axl@artix ~]$ [axl@artix ~]$ virsh -c qemu:///system dominfo debian13 Id: 2 Name: debian13 UUID: bf020d33-770d-47ac-b79f-bd87ed9f5cb2 OS Typ: hvm Status: laufend CPU(s): 2 CPU-Zeit: 29,8s Max Speicher: 4194304 KiB Verwendeter Speicher: 4194304 KiB Bleibend: ja Automatischer Start: deaktiviert Autostart Once: deaktiviert Verwaltete Sicherung: nein Sicherheits-Modell: none Sicherheits-DOI: 0 [axl@artix ~]$ [axl@artix ~]$ [axl@artix ~]$ [axl@artix ~]$ virsh -c qemu:///system domifaddr debian13 Name MAC-Adresse Protocol Address ------------------------------------------ [axl@artix ~]$ # => leer! [axl@artix ~]$ [axl@artix ~]$ virsh -c qemu:///system domifaddr debian13 --source lease Name MAC-Adresse Protocol Address ------------------------------------------ [axl@artix ~]$ # => leer! [axl@artix ~]$ [axl@artix ~]$ virsh -c qemu:///system domifaddr debian13 --source arp Name MAC-Adresse Protocol Address ---------------------------------------------------------- vnet1 52:54:00:09:ce:08 ipv4 192.168.122.73/0 [axl@artix ~]$ [axl@artix ~]$ [axl@artix ~]$ virsh -c qemu:///system domifaddr debian13 --source agent Name MAC-Adresse Protocol Address ----------------------------------------------------------------------- lo 00:00:00:00:00:00 ipv4 127.0.0.1/8 - - ipv6 ::1/128 enp1s0 52:54:00:09:ce:08 ipv4 192.168.122.73/24 - - ipv6 fe80::78ec:d16e:1974:e6ad/64 [axl@artix ~]$ Der Grund ist hier beschrieben: https://unix.stackexchange.com/questions/549342/cannot-guest-ip-addresses-of-guests/549474#549474 Zitat: "Try virsh domifaddr --source agent or virsh domifaddr --source arp. Since you are using macvtap for the VM, the default --source lease won't work, it only works for network type='network' configs that use dnsmasq" Alternativ gibt es aber noch diese Variante: :: [axl@artix ~]$ virsh -c qemu:///system guestinfo debian13 | grep 'addr.*addr\>' if.0.addr.0.addr : 127.0.0.1 if.0.addr.1.addr : ::1 if.1.addr.0.addr : 192.168.122.73 if.1.addr.1.addr : fe80::78ec:d16e:1974:e6ad [axl@artix ~]$ Zum Thema libvirt-Netzwerk siehe auch https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_windows_virtual_machines/configuring-virtual-machine-network-connections (u.a. ``ip link show master br0``) libvirt als Frontend für LXC ============================ Jetzt wollen wir libvirt auch zur Verwaltung klassischer Linux Container heranziehen, dazu installieren wir erst einmal die erforderlichen Pakete: :: zypper in libvirt-daemon-driver-lxc lxc Dienste starten und aktivieren ------------------------------ LXC bringt selber keinen zentralen Daemon mit, der die Container überwacht, nur für das FUSE-Dateisystem gibt es ``lxcfs``. Außerdem konfiguriert es sich mittels einfacher Textdateien. Für das Bindeglied zu libvirt wird allerdings ein spezieller Daemon benötigt. Hiermit starten und aktivieren wir beide: :: suse15:~ # systemctl start lxcfs virtlxcd suse15:~ # suse15:~ # systemctl enable lxcfs virtlxcd Created symlink /etc/systemd/system/multi-user.target.wants/lxcfs.service → /usr/lib/systemd/system/lxcfs.service. suse15:~ # suse15:~ # systemctl status virtlxcd ● virtlxcd.service - libvirt LXC daemon Loaded: loaded (/usr/lib/systemd/system/virtlxcd.service; enabled; preset: enabled) Active: active (running) since Fri 2026-05-08 15:37:36 CEST; 43s ago TriggeredBy: ● virtlxcd-ro.socket ● virtlxcd-admin.socket ● virtlxcd.socket Docs: man:virtlxcd(8) https://libvirt.org/ Main PID: 25543 (virtlxcd) Tasks: 19 (limit: 32768) CPU: 58ms CGroup: /system.slice/virtlxcd.service └─25543 /usr/sbin/virtlxcd --timeout 120 May 08 15:37:36 localhost systemd[1]: Starting libvirt LXC daemon... May 08 15:37:36 localhost systemd[1]: Started libvirt LXC daemon. suse15:~ # Netzwerk konfigurieren ---------------------- Am besten, man editiert im Vorfeld die ``/etc/lxc/default.conf``, um die Verbindung zur richtigen Bridge für alle neu zu erzeugenden Container richtig einzustellen. Unsere Bridge heißt nicht *lxcbr0*, sondern *br0*, weshalb die betreffende Zeile schließlich ``lxc.net.0.link = br0`` lautet. Nach der Erstellung des Containers *alpine-lxc* wäre dies aber in der Datei ``/var/lib/lxc/alpine-lxc/config`` ebenso noch möglich. Damit sind wir in der Lage, den Container auch auf LXC-Art zu starten, was aber für libvirt gar nicht erforderlich wäre: :: suse15:~ # lxc-start alpine-lxc suse15:~ # lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED alpine-lxc RUNNING 0 - 192.168.2.106 2003:f4:e742:a637:216:3eff:fedb:1723 false suse15:~ # Wir könnten jetzt ganz bequem ``lxc-attach alpine-lxc`` verwenden, um in den Container zu gehen und dort das root-Passwort zu setzen sowie die Consolen-Einstellung zu ändern. Falls aber der Container nicht läuft bzw. nicht gestartet werden konnte, ist ``chroot /var/lib/lxc/alpine-lxc/rootfs/ ash`` die bevorzugte Lösung (siehe nächstes Kapitel). LXC-Container erstellen ----------------------- Auf LXC-Art prüfen wir, welche Images es für Alpine gibt: :: suse15:~ # /usr/share/lxc/templates/lxc-download -l | grep alpine | head -3 alpine 3.21 amd64 default 20260507_13:00 alpine 3.21 arm64 default 20260507_13:02 alpine 3.21 armhf default 20260507_13:01 suse15:~ # Damit ist auch klar geworden, wie die Versionsbezeichnungen lauten und es kann ein Container erstellt werden: :: suse15:~ # lxc-create -t /usr/share/lxc/templates/lxc-download -n alpine-lxc -- -d alpine -r 3.21 -a amd64 Downloading the image index Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Alpinelinux 3.21 x86_64 (20260507_13:00) container. suse15:~ # Dank dem alten ``chroot`` Kommando ist es einfach, das neue Containerdateisystem zur aktuellen Wurzel zu machen, das root-Passwort zu setzen und *tty1* bis *tty2* abzuschalten, per Default kann hier nur /dev/console verwendet werden: :: suse15:~ # chroot /var/lib/lxc/alpine-lxc/rootfs/ ash / # / # passwd Changing password for root New password: Bad password: too short Retype password: passwd: password for root changed by root / # / # / # vi etc/inittab / # # Diese vier Zeilen wurden auskommentiert: / # grep ^#tty etc/inittab #tty1::respawn:/sbin/getty 38400 tty1 #tty2::respawn:/sbin/getty 38400 tty2 #tty3::respawn:/sbin/getty 38400 tty3 #tty4::respawn:/sbin/getty 38400 tty4 / # / # exit suse15:~ # LXC-Container mit libvirt erstellen ----------------------------------- Nun können wir einfach das vorhandene rootfs von *alpine-lxc* verwenden, um mittels ``virt-install`` einen libvirt-Gast zu erzeugen: :: suse15:~ # virt-install --connect lxc:/// \ --name alpineLXC \ --ram 512 --vcpu 1 \ --filesystem /var/lib/lxc/alpine-lxc/rootfs/,/ \ --noautoconsole Starting install... Creating domain... | 00:00:00 Domain creation completed. suse15:~ # suse15:~ # virsh -c lxc:/// list --all Id Name State ------------------------------ 26410 alpineLXC running suse15:~ # Nun können wir uns mit dem Container verbinden, das Ganze findet als echter Login-Vorgang statt, weswegen wir das root-Passwort setzen mussten: :: suse15:~ # virsh -c lxc:/// console alpineLXC Connected to domain 'alpineLXC' Escape character is ^] (Ctrl + ]) OpenRC 0.55.1 is starting up Linux 6.4.0-150600.23.100-default (x86_64) [LXC] * /proc is already mounted * Mounting /run ... [ ok ] * /run/openrc: creating directory * /run/lock: creating directory * /run/lock: correcting owner * Caching service dependencies ... [ ok ] * Mounting local filesystems ... [ ok ] * Creating user login records ... [ ok ] * Cleaning /tmp directory ... [ ok ] * Remounting devtmpfs on /dev ... [ ok ] * Mounting /dev/mqueue ... [ ok ] * Mounting /dev/shm ... [ ok ] * Starting busybox syslog ... [ ok ] * Starting busybox crond ... [ ok ] * Starting networking ... * lo ... [ ok ] * eth0 ...udhcpc: started, v1.37.0 udhcpc: broadcasting discover udhcpc: broadcasting discover udhcpc: broadcasting select for 192.168.104.112, server 192.168.104.1 udhcpc: lease of 192.168.104.112 obtained from 192.168.104.1, lease time 86400 [ ok ] Welcome to Alpine Linux 3.21 Kernel 6.4.0-150600.23.100-default on an x86_64 (/dev/console) alpineLXC login: root Password: Welcome to Alpine! The Alpine Wiki contains a large amount of how-to guides and general information about administrating Alpine systems. See . You can setup the system with the command: setup-alpine You may change this message by editing /etc/motd. alpineLXC:~# # => "Strg - AltGr - ]" drücken... suse15:~ # Zum Verlassen der Konsole nicht *exit* verwenden (Gast läuft ja im Hintergrund weiter, wir stünden am Login-Prompt), sondern die Strg-Taste halten sowie die schließende eckige Klammer erzeugen: ``Strg - AltGr - ]`` Weitere Hyperlinks ================== - https://doc.opensuse.org/documentation/leap/virtualization/html/book-virtualization/cha-kvm-inst.html - https://codingpackets.com/blog/libvirt-tips-and-tricks - https://rabexc.org/posts/how-to-get-started-with-libvirt-on (Umfangreiche Docu, "My first approach at sorting this mess out were chroots...") - https://linuxcontainers.org/incus-os/docs/main/getting-started/installation/virtual-libvirt/ - https://wiki.libvirt.org/FAQ.html#what-is-the-difference-between-qemu-system-and-qemu-session-which-one-should-i-use - https://gist.github.com/AsherGlick/0550b6c11a70c7755bec (Basics, Words and Descriptens)