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.
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:///sessionweggelassen 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 <boot dev='cdrom'/> auf <boot dev='hd'/>. 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
<name>suse15.6</name>
<libosinfo:os id="http://opensuse.org/opensuse/15.6"/>
<source file='/home/axl/.local/share/libvirt/images/suse15.6.qcow2'/>
<source file='/home/axl/Downloads/openSUSE-Leap-15.6-DVD-x86_64-Build710.3-Media.iso'/>
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
<domain type='kvm'>
<name>deb13-01</name>
<uuid>3116a247-e2d2-4500-8b88-8813c3b5391b</uuid>
<metadata>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://debian.org/debian/13"/>
</libosinfo:libosinfo>
</metadata>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
<boot dev='cdrom'/>
</os>
<features>
...
=> Geändert auf: <boot dev='hd'/>
=> 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…
wget https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-standard-3.21.0-x86_64.iso
Als root:
mv /home/tux/alpine-standard-3.21.0-x86_64.iso /var/lib/libvirt/boot/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 <VM> --name <SNAPSHOTNAME> "<COMMENT>" 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
<description>before nfs install</description>
tux@suse15:~>
tux@suse15:~> # Variante 2 mittels 'snapshot-current':
tux@suse15:~> virsh -c qemu:///system snapshot-current alpine321 | grep description
<description>before big install actions</description>
tux@suse15:~>
Netzwerk
Im grafischen virt-manager sind über Edit / Connection Details / Virtual Networks / Hinzufügen[+] fünf Netzwerkmodi zu finden:
NAT (übliches NAT-Routing mit DHCP und cache-only DNS)
Routed (ein virtueller Router sitzt dazwischen, kein NAT, Isolation durch Subnetze)
Isolated (Keine Verbindung zum Host und anderen Netzwerken)
Open (Ähnlich wie „routed“, es werden keine Firewallregeln hinzugefügt)
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:
<network>
<name>default</name>
<forward mode='nat'/>
<bridge name='virbr0' stp='on' delay='0'/>
<ip address='192.168.122.1' netmask='255.255.255.0'/>
</network>
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.102Jetzt 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 <https://wiki.alpinelinux.org/>.
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://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://gist.github.com/AsherGlick/0550b6c11a70c7755bec (Basics, Words and Descriptens)