Spielereien mit KVM (Kernelbased Virtual Machine)

[Caramon2]

Da ich mir häufiger Livesysteme ansehe und ggfs. auch testweise installiere, habe ich mir das etwas bequemer gemacht:

Falls QEMU/KVM noch nicht installiert ist, das Terminal öffnen (unbedingt als normaler Nutzer, nicht als Root!) und dort je nach Distribution folgendes ausführen:

(Es wird das System aktualisiert, um Abhängigkeitsproblemen zu vermeiden und anschließend der Paketcache bereinigt.)

# Arch und Derivate:
sudo pacman -Syu qemu espeak-ng && sudo pacman -Sc

# Solus:
sudo eopkg up && sudo eopkg it qemu espeak-ng && sudo eopkg dc

# Ubuntu und Derivate:
sudo apt update && sudo apt upgrade && sudo apt install qemu-kvm espeak-ng && sudo apt clean

Dann bei allen Distributionen:

sudo usermod -a -G kvm $USER

Dann wegen der ggfs. installierten Updates und damit die Gruppe übernommen wird rebooten: Man soll ihr angehören, damit KVM die Hardware-Virtualisierung nutzen kann.

-----

Das Video (s. u.) ist von einem AMD FX 8350 (4 GHz, TurboCore deaktiviert (spannungsoptimiert) - der wurde vorletztes Jahr für 76 € bei Amazon verscherbelt) mit 2x8 GiB DDR3L. Das BS ist Artix-Xfce-Runit mit Vertex-Skin (AUR) und QEMU 6.0

Ich nutze jeweils 3 Cores und 3 GiB RAM, da mehr eher schadet, da der Host das RAM dann nicht mehr für den Datenträger-Cache nutzen kann.

Benutzerdefinierte Funktion (in Thunar/Xfce - Zorin-Lite ist auch Xfce):

1.

Tab "Allgemein":
Name: Mit KVM booten
Befehl: qemu-system-x86_64 -sdl -enable-kvm -cpu host -smp cores=3 -m 3G -drive file=%f,if=virtio,snapshot=on

Tab "Dateizuordnung":
Dateimuster: *.iso;*.qcow2
Erscheint für: Andere Dateien

2.

Tab "Allgemein":
Name: VM-Installation
Befehl: ~/.local/bin/vmcreate.sh %f

Tab "Dateizuordnung":
Dateimuster: *.iso
Erscheint für: Andere Dateien

Die "vmcreate.sh" (in ~/.local/bin/ erstellen und als ausführbar markieren):

#!/bin/bash
i=${1%.iso}.qcow2
if [ -f $i ];then espeak-ng fail;exit;fi
qemu-img create -fqcow2 -ocompression_type=zstd $i 112G
qemu-system-x86_64 -sdl -enable-kvm -no-quit -cpu host -smp cores=3 -m 3G -drive file=$i,if=virtio -cdrom $1 -boot once=d

Da der Dateiname des ISOs für die virtuelle HD genutzt wird, sollte man das ISO vorher ggfs. umbenennen.

Bei Solus habe ich das nicht gemacht, da das ISO schon von sich aus einen "handlichen" Namen hat:

Solus4.3_VM-Installation.mkv in meinem Google-Drive

Mit 2. habe ich es installiert (reine Installationsdauer: 1:55 Min. :-) ) und anschließend mit 1. das installierte Solus gebootet und auf den hellen Skin umgestellt.

Durch "boot once=d" hätte ich nach der Installation auch "Restart now" wählen können, aber ich wollte beides zeigen.

Wer weiß, wie man benutzerdefinierte Aktionen bei anderen DEs einrichtet, Fehler findet, usw., "darf" das gerne schreiben. :-)

Gruß,

Andreas

 

[Caramon2]

Kleines Update:

Ich hatte übersehen, dass auch espeak-ng (für Fehlermeldungen) ggfs. installiert werden muss. Das habe ich jetzt nachgetragen.

Da ich die ISOs direkt auf einen Ventoy-Stick herunterlade, wurde es lästig sie für die Installation erst auf den PC kopieren zu müssen. Deshalb habe ich 2. und das Skript angepasst:

2. ("Name" und "Befehl" geändert)

Tab "Allgemein":
Name: VM in ~/VMs/ erstellen
Befehl: ~/.local/bin/vmcreate.sh %n

Tab "Dateizuordnung":
Dateimuster: *.iso
Erscheint für: Andere Dateien

Die "vmcreate.sh" (in ~/.local/bin/):

#!/bin/bash
mkdir ~/VMs 2>/dev/null
i=~/VMs/${1%.iso}.qcow2
if [ -f $i ];then espeak-ng -vde "exitstiert schon";exit;fi
qemu-img create -fqcow2 -ocompression_type=zstd $i 112G && qemu-system-x86_64 -sdl -enable-kvm -no-quit -cpu host -smp cores=3 -m 3G -drive file=$i,if=virtio -cdrom $1 -boot once=d || espeak-ng -vde "konnte nicht erstellt werden"

Dadurch wird das Platten-Image im Verzeichnis "VMs" im Benutzerordner erstellt, egal wo sich das ISO befindet. Gibt es das Verzeichnis nicht, wird es erstellt (ansonsten wird die Fehlermeldung ins Nirwana geschickt).

Durch "&&" wird die VM nur gebootet, wenn die vHD erstellt werden konnte, ansonsten gibt es eine verbale Fehlermeldung.

Wer am PC keine Lautsprecher hat, kann >espeak-ng -vde "Meldung"< z. B. durch >zenity --warning --text "Meldung"< ersetzen, was evtl. aber auch erst installiert werden muss.

 

[tukse]

Das Einbinden des Scripts und die Verknüpfungen zum ISO und QCOW2 starten funktionieren übrigens auch in KDE.
@Caramon2 Vielen Dank dafür.

 

[Caramon2]

Hi!

Sorry. Ich habe bei diesem bescheidenen Wetter zu nichts Lust (Noch nicht mal die 27er Bier habe ich seit vorgestern aus dem Auto geholt!), deshalb erst mal vorab die Änderungen kurz erklärt:

Benutzerdefinierte Aktion 1. (s. o.):

qemu-system-x86_64 -sdl -enable-kvm -cpu host -smp cores=2 -m 3G -vga std -hda %n

Ursprünglich hatte ich dort auch ein "snapshot=on": Das war falsch, da dann keine Änderungen geschrieben werden. Im Video kann man sehen, dass sich das Dateidatum des .qcow2 beim 2. Booten nicht ändert: Hätte ich es noch ein 3. Mal gebootet, wäre weiterhin der dunkle Skin eingestellt gewesen. Aber es schien ja alles zu funktionieren, also habe ich es gelöscht…

Außerdem habe ich aus Kompatibilitätsgründen auf 2 Kerne reduziert, da z. B. Windows XP oder Server 2003 (betrifft nur die 32 Bit Versionen) in KVM aus welchen Gründen auch immer mit mehr als 2 Kernen nicht installiert werden können und das auf die Installationsdauer allgemein keinen großen Einfluss hat.

Das Skript zu 2.:

#!/bin/bash
mkdir ~/VMs 2>/dev/null
i=~/VMs/${1%.iso}.qcow2
if [ ! -f $i ];then qemu-img create -fqcow2 $i 64G;fi
qemu-system-x86_64 -sdl -enable-kvm -cpu host -smp cores=2 -m 3G -vga std -hda $i -boot once=d -cdrom $1

Die Abfrage, ob die vHD (die Image-Datei = virtuelle HD) schon besteht, habe ich entfernt, damit man über eine bestehende Installation ggfs. vom Livesystem aus warten, oder eine neue Version drüber installieren, oder anderes BS parallel dazu installieren kann (um z. B. Multiboot auszuprobieren (s. u.) - Ansonsten wäre für jedes BS eine eigene VM natürlich sinnvoller).

Dazu muss man das .qcow2 nur wie das neue ISO benennen.

Das "-ocompression_type=zstd" habe ich auch entfernt, da das dort nur kosmetisch ist: Komprimiert wird nur beim konvertieren des Images. Im Betrieb wird ausschließlich unkomprimiert gespeichert.

Dazu habe ich eine weitere benutzerdefinierte Aktion erstellt:

Tab "Allgemein":
Name: qcow2 komprimieren
Befehl: exo-open --launch TerminalEmulator ~/.local/bin/vmconvert.sh %n

Tab "Dateizuordnung":
Dateimuster: *.qcow2
Erscheint für: Andere Dateien

vmconvert.sh (in ~/.local/bin/ erstellen und als ausführbar markieren):

#!/bin/bash
read -p "Image komprimieren? (Enter/Alt+F4)"
qemu-img convert -pcOqcow2 -ocompression_type=zstd $1 $1"b" && mv -f $1"b" $1

============================================


Außerdem habe ich mich etwas mit UEFI beschäftigt, halte aber weiterhin nichts davon. - Also Nutzung auf eigene "Gefahr" (für den Host besteht natürlich kein Risiko) und ich biete dafür keinen Support.

Für UEFI muss man OVMF installieren:

Arch+Derivate: pacman -S edk2-ovmf
Ubuntu+Derivate: apt install ovmf
Solus: eopkg it ovmf

Dann wie im ersten Beitrag die benutzerdefinierten Aktionen erstellen (ich habe an die Namen einfach ein " (UEFI)" angehängt):

qemu-system-x86_64 -sdl -enable-kvm -cpu host -smp cores=2 -m 3G -vga std -machine q35 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -hda %n

Das Skript nenne ich "vmcreate-uefi.sh":

#!/bin/bash
mkdir ~/VMs 2>/dev/null
i=~/VMs/${1%.iso}-UEFI.qcow2
cp -a /usr/share/edk2-ovmf/x64/OVMF.fd /tmp/uefi.bin
if [ ! -f $i ];then qemu-img create -fqcow2 $i 64G;fi
qemu-system-x86_64 -sdl -enable-kvm -cpu host -smp cores=2 -m 3G -vga std -machine q35 -pflash /tmp/uefi.bin -hda $i -boot once=d -cdrom $1

Das OVMF.fd kopiere ich nach /tmp/, weil man Schreibrechte darauf braucht. Sonst funktioniert das booten vom ISO nicht. Anschließend ist es besser, wieder das Original zu nutzen (kein Schreibzugriff), da bei einem Test LinuxMint parallel zu Win10 zu installieren (also erst Windows, dann Linux, damit es Win10 mit ins Bootmenü aufnimmt), es zuerst zwar zu funktionieren schien (also beides im Bootmenü), aber Windows beim anschließenden booten sich zuerst aufgehängt hat und anschließend nur noch Windows gebootet wurde: Kein Bootmenü mehr und ich konnte es auch nicht wiederherstellen.

Also habe ich die vHD und das Win10.iso gelöscht. Darüber rege ich mich nicht mehr auf.

 

[Caramon2]

Moin.

Die letzte Zeit habe ich mich mit zRAM, zSwap, usw. beschäftigt und kam dabei auf die Idee, eine VM in einer zRAM-Disk (also komprimierende RAM-Disk) zu installieren.

Gedacht ist das, die VM dort erst mal zu installieren und einzurichten und erst dann mit obigen vmconvert-Skript (man muss dann dort einen festen Ziel-Ordner einstellen) auf die Platte zu übertragen, wobei sie auch gleich komprimiert wird, um möglichst wenig Platz zu belegen und SSDs unnötige Schreibzugriffe zu ersparen.

Dazu dieses Skript als "vmcreate-zram.sh" erstellen und wie die anderen Skript (s. o.) als ausführbar markieren und einrichten:

#!/bin/bash
sz=32G # Größe von zRAM-Disk und vHD
echo -e "\nEine zRAM-Disk erstellen?"
espeak-ng -vde "Bitte Passwort."&
sudo modprobe zram # Auskommentieren, wenn zRAM sowieso schon genutzt wird.
id=$(sudo cat /sys/class/zram-control/hot_add)
echo -ne "\nKompression: ";echo lz4|sudo tee /sys/block/zram$id/comp_algorithm
echo -ne "Disk-Größe: ";echo $sz|sudo tee /sys/block/zram$id/disksize
sudo mkfs.xfs -q /dev/zram$id && mkdir /tmp/zram$id
sudo mount -o discard /dev/zram$id /tmp/zram$id/ && sudo chmod 777 /tmp/zram$id/
echo;i=/tmp/zram$id/${1%.iso}.qcow2
qemu-img create -fqcow2 $i $sz
qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=2 -m 3G -display sdl,gl=on,window-close=off -vga virtio -drive file=$i,if=virtio,aio=io_uring,discard=unmap -boot once=d -cdrom $1
exo-open --launch FileManager /tmp/zram$id/
echo -ne "\nDie zRAM-Disk löschen? (mit [Enter] bestätigen, ansonsten das Fenster schließen)";read
sudo umount -l /tmp/zram$id/ && rm -rf /tmp/zram$id
echo $id|sudo tee /sys/class/zram-control/hot_remove > /dev/null

Zur Demonstration habe ich WindowsFx mit der Win10-Optik installiert und dabei den Desktop des Host mit aufgenommen:

WinFx-10-zRAM-Install.mkv in meinem Google-Drive

Unten rechts werden (u. a.) die Belegung der zRAM-Disk und die komprimierte Größe angezeigt.

Ach ja: Bei der Installation darf man natürlich keinesfalls eine Verschlüsselung aktivieren, da es sich damit nicht komprimieren lässt.

…

Bei meiner Swap nutze ich zStd, da dort Komprimierung wichtiger als Geschwindigkeit ist (geschieht ja sowieso im Hintergrund), für die zRAM-Disk wäre mir das aber zu langsam und da einige der Daten ja schon komprimiert ist (JPG, PNG, usw.) bringt es gegenüber lz4 sowieso nicht mehr viel: zStd komprimierte beim reinen kopieren einer anderen VM ca. 15% besser (1:2,2 zu 1:1,9), brauchte aber fast 4x länger (1:54 Min. zu 31 Sek.).

 

[Caramon2]

Hi!

Aus Jux habe ich Windows 11 21H2 Pro for Workstations (vor einigen Monaten normal von MS geladen: also keine abgespeckte Version, oder sowas) auf einen 16 GB USB2-Stick (21 MB/s lesend, 9,4 MB/s schreibend) installiert:

Wichtig! (damit meine ich: WIRKLICH SEHR WICHTIG !!!)

Die zu übergebenen Laufwerke (bei meinem Beispiel /dev/sdc und /dev/sdd) DOPPELT und DREIFACH prüfen!

Erwischt ihr versehentlich euer Systemlaufwerk, wird das System entweder (höchstwahrscheinlich) irreparabel beschädigt, oder das Laufwerk ganz platt gemacht: System, Programme, Daten, Partitionierung, alles auf dem Laufwerk ist weg und muss vollständig aus der letzten Sicherung wiederhergestellt werden.

Qemu muss per "sudo" gestartet werden, damit es die angegebenen Laufwerke direkt ansteuern kann. Anschließend wechselt es automatisch auf den normalen Nutzer per "-runas $USER" ($USER ist eine Variable und muss nicht geändert werden).


Für alle, die noch nicht schreiend davongelaufen sind , so geht es weiter:

/dev/sdc ist der Ventoy-Stick (s. hier)

/dev/sdd ist das Ziellaufwerk

Unten muss das entsprechend eurem System angepasst werden: s. obige Warnung!
(Nochmal weise ich nicht darauf hin: Wer es immer noch nicht verstanden hat, ist selbst Schuld.)


Zuerst das Ziellaufwerk partitionieren und formatieren:

lw=/dev/sdd
sudo parted -s $lw mklabel msdos && sudo parted -sa none $lw mkpart primary ntfs 4kiB 100%
sudo mkntfs -QIL Windows11 $lw"1"

Die Partition lasse ich bei 4k beginnen, da Windows zum Booten nur den ersten Sektor braucht und ich bei einem 16 GB-Stick (unter Berücksichtigung des Alignments) nicht ein ganzes MiB verschwenden möchte: Immer ein Bit übrig behalten…

Wichtig: Von keinem der beiden Sticks darf eine Partition eingehängt sein!

Dann die VM mit beiden Sticks starten ("-nodefaults" bewirkt, dass es keine Internetverbinung gibt, damit Windows nicht kontrollieren kann, ob registriert ist):

sudo qemu-system-x86_64 -runas $USER -nodefaults -enable-kvm -cpu host -smp cores=2 -m 4G -display sdl,gl=on -vga virtio -drive file=/dev/sdc,if=ide,format=raw -drive file=/dev/sdd,if=ide,format=raw

Im Installer dann "Ich habe keinen Key" und die Pro4WS auswählen und auf der oben eingerichteten Windows-Partition installieren. - Die Warnung bzgl. mindestens 52 GB ist bedeutungslos: Windows braucht nicht mal 10 GB.

Nach dem ersten Reboot (bis dahin hat es bei mir 56 Min. Minuten gedauert) wird wieder Ventoy gebootet: Das dann per F5/Power/Halt herunterfahren und dann nur den Win11-Stick booten:

sudo qemu-system-x86_64 -runas $USER -nodefaults -enable-kvm -cpu host -smp cores=2 -m 4G -display sdl,gl=on -vga virtio -drive file=/dev/sdd,if=ide,format=raw

Wer es mit Internetverbindung testen will, kann "-nodefaults" entfernen. Aber euren Key (falls vorhanden) solltet ihr dort besser nicht eingeben: Wer weiß, was das für euer "richtiges" Windows für Folgen haben kann…

Der zweite Schritt der Installation (schwarzer Hintergrund mit Win-Logo und rotierendem Kringel) hat bis zum 2. Reboot 73 Min. gebraucht.

Und der letzte Schritt (mit den ganzen Nerv-Abfragen - bei der Passworteingabe habe ich einfach Enter gedrückt, damit es anschließend ohne Passwortabfrage direkt bootet) dauerte bis zum vollständig geladenen Desktop (bis auch alle Tray-Icons da waren) nochmal 28 Min.

Ich habe es dann noch ca. 15 Min. laufen lassen, damit es sich fertig einrichten kann (es macht noch eine ganze Weile irgendwas, der CPU-Last nach), dann "powercfg -h off" + Swap deaktivieren, reboot, wieder ein paar Minuten warten und anschließend herunterfahren (die Schnellstartfunktion hatte ich oben mit "powercfg -h off" deaktiviert, also es wurde vollständig heruntergefahren).

Dann den Stick kurz entfernt, damit nichts mehr im Cache ist, die VM wieder gestartet und das erste "richtige" booten:

Nach 2:33 Min. erschien der Desktop, aber noch mit vollkommen leerer Tastleiste (einfach nur ein hellgrauer Balken), nach insges. 3:40 Min. waren plötzlich Startmenü, Icons, Tray und Uhr da und bei 4:15 erschien dann auch noch die Benachrichtigungsanzeige.

Ich habe ca. 10 Minuten gewartet, den Screenshot gemacht:

und anschließend Windows runtergefahren: Das dauerte dann nochmal 2:17 Min.

…

P. S.: Ich habe natürlich nicht die ganze Zeit vorm PC gehockt und dabei zugesehen: Es reicht beim lesen den Bildschirm im Augenwinkel zu halten, man hat genügend Zeit, sich zwischendurch ein zweites Frühstück zu machen, usw.

 

[Caramon2]

Da ich auf dem Ventoy-Stick auch noch ein Zorin 15.3 Xfce hatte, habe ich das gleiche damit auf den selben Ziel-Stick (auch im Voraus partitioniert (ab 64k, da Grub nach dem MBR ca. 56k belegt) und formatiert: ext4) wiederholt:

Vom starten der VM, über boote des Ventoy-Sticks, booten des Livesystems, starten und durchführen der Installation, bis sie abgeschlossen war: 28 Min.

Das System dann gebootet, 15 Min. gewartet, damit alle Cronjobs (daily, weekly, monthly) ausgeführt wurden, dann runtergefahren und den Stick kurz entfernt.

Das "richtige" booten dauerte 45 Sek., dann einige Minuten warten, dabei das Hintergrundbild gewechselt, den Screenshot gemacht und anschließend runtergefahren, in 8 Sek.

Der "Witz" an der Sache:

Da ich das aus der VM heraus direkt auf den Stick installiert habe (nicht in eine Image-Datei), lässt es sich auch direkt an einem PC booten: Also nicht nur in der VM.

Das so installierte Zorin (oder auch jede andere Linux-Distribution, außer Solus: das zerschießt sich schon nach ein paar Aktualisierungen, wenn ich es auf einem USB-Datenträger, an verschiedenen PCs nutze) kann man an jedem PC booten, das von USB booten kann: Das ist ein richtig installiertes System, das man aktualisieren kann (einschließlich des Kernels - anders als bei einem Livesystem), Programme installieren, deinstallieren, usw.

Trotz des lahmen Sticks kann man sogar halbwegs vernünftig damit arbeiten (besser als gar nichts), solange man dem System nach jedem größeren Arbeitsschritt genug Zeit lässt, die Änderungen zu schreiben. - LinuxMint hatte ich damals eine längere Zeit auf einen nur etwas schnelleren 16 GB USB2 Stick genutzt, wenn Bekannte Probleme mit ihrem PC hatten, usw.

xfs hat sich dafür übrigens weit besser bewährt als ext4, weshalb ich seit dem xfs standardmäßig für alles nutze, wo es sich einsetzen lässt: Es ist nicht nur schneller, sondern auch robuster und das Verhältnis zwischen Flash- und Host-Writes (meine erste SSD, eine BX100, zeigte beides an) verbesserte sich nach der Umstellung ext4->xfs auch deutlich (jeweils über mehr als ein Jahr gemittelt). Es ist also auch schonender für SSDs.

Noch einen schönen Sonntag.

Andreas

 

[Caramon2]

Hi!

Ich wollte mal testen, wie schnell sich Windows 11 installieren lässt.

Deshalb habe ich die vHDs in einer optimierten RAM-Disk erstellt (mein PC hat 32 GiB RAM):

Da ich Win11 dazu per Ventoy installieren muss, habe ich mir dort zuerst ein 6 GB Ventoy-Stick-Image erstellt:

qemu-img create Win11-Ventoy.raw $((6*10**9))

sudo qemu-system-x86_64 -runas $USER -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -display sdl,gl=on -vga virtio -drive file=/dev/sdc,if=ide,aio=io_uring,snapshot=on,format=raw -drive file=Win11-Ventoy.raw,if=ide,aio=io_uring,discard=unmap,format=raw -drive file=/dev/sdd,if=ide,aio=io_uring,snapshot=on,format=raw

- "sudo" benötigt man, um die Laufwerke sdc und sdd direkt einzubinden (WICHTIG: Sie dürfen auf keien Fall eingehängt sein!!!) - das passiert gleich beim starten der VM, anschließend läuft Qemu durch "-runas $USER" wieder mit normalen Benutzerrechten: $USER ist eine Variable und muss nicht angepasst werden - s. "echo $USER"

- sdc ist eine bootfähige 1:1 Kopie meines Produktivsystems auf einer ext. SSD (damit ich es überall booten kann und meine gewohnten Tools und Arbeitsumgebung habe)

- sdd ein 64 GB Ventoy-Stick u. a. mit dem Win11-ISO, das ich dann auf den virtuellen Stick kopiert habe:

Nachdem ich die VM wieder runter gefahren habe, habe ich ein 120 GB Festplatten-Image erstellt *) und zusammen mit dem dem virtuellen Ventory-Stick gebootet:

qemu-img create Win11.raw $((120*10**9))

qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -display sdl,gl=on -vga virtio -drive file=Win11.raw,if=ide,aio=io_uring,discard=unmap,format=raw -drive file=Win11-Ventoy.raw,if=ide,aio=io_uring,snapshot=on,format=raw -boot menu=on

"-boot menu=on" weil der Ventoy-Stick das 2. Laufwerk ist: Um davon zu booten, ruft man das Bootmenü gleich nach dem Start der VM mit [Esc] auf und wählt das 2. Laufwerk. - Diese Reihenfolge ist notwendig, da Windows während der Installation 2x rebootet und ansonsten wieder der Ventoy-Stick gebootet würde, wäre er das 1. Laufwerk.

*) auch in der RAM-Disk: da sparse, belegt es nur das, was wirklich belegt ist: selbst mit dem fertig installierten Win11 sind das zuletzt nur ca. 9,5 GiB

Komplett hat das ca. 10,5 Min. gedauert und die reine Installation **) knapp über 8 Min.: s. Anhang

Noch schneller wäre es vermutlich mit "if=virtio", aber dafür hat Windows keinen Treiber und es war mit zu aufwändig erst zu testen, ob man den einpflegen kann (wie bei der XP-Installation mit Treiberdiskette und F6 zum richtigen Zeitpunkt).

**) den 15 Sek. Zählrunter vor dem esten Reboot und den Teil mit Benutzernamen, wer spionieren darf, usw. habe ich Bildgenau entfernt

Btw:

Countdown To Windows 10 EOL

 

[Caramon2]

Noch schneller wäre es vermutlich mit "if=virtio", aber dafür hat Windows keinen Treiber und es war mit zu aufwändig erst zu testen, ob man den einpflegen kann

Hab's jetzt doch getestet:

Hier die letzte Treiberversion auf Diskettenimage geladen und damit die VM gestartet:

qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -display sdl,gl=on -vga virtio -fda virtio-win-0.1.190_amd64.vfd  -drive file=Win11.raw,if=virtio,aio=io_uring,discard=unmap,format=raw -drive file=Win11-Ventoy.raw,if=virtio,aio=io_uring,snapshot=on,format=raw -boot menu=on

Obwohl noch für Win10, wurde er akzeptiert:

und die Installation war (netto) ca. 20 Sek. schneller: s. Anhang

Ich habe es dann auch noch vorpartitioniert und mit 16k Cluster formatiert getestet und obwohl die Quelle (das ISO) das Nadelöhr ist und die vHD sogar in einer optimierten RAM-Disk lag, war die Installation nochmal einige Sekunden schneller: s. Anhang

Wenn 16k Cluster selbst unter diesen Umständen messbare Vorteile bringen, dürften sich die auf großen Datenträgern mit entsprechend großen Datenmengen erst recht lohnen.

 

[7vor10]

Mit Qemu/KVM habe ich vor ein paar Monaten auch ein bißchen herumgespielt.
Allerdings innerhalb des GUI-Frontends von VirtManager.
Mir ging es darum, mal auszuloten, ob das Ganze eine echte Alternative zu VirtualBox und VMware in Sachen VM-Performance sein könnte.

Was Linux-VMs betrifft durchaus!
Mithilfe der VirGL-Erweiterung laufen auch Games wie der Klassiker Supertuxkart absolut flüssig.
Einzig gefundener Haken: die Grafikkarte des Hosts darf nicht von Nvidia sein. Intel aber funktioniert (vermutlich auch AMD).
VirGL geht quasi einen Mittelweg zwischen konventioneller virtueller Grafikkarte und GPU-Passthrough.

Bei Windows-VMs allerdings sieht es mau aus. Windows 7 schleppt sich so dahin und es ist nicht möglich, Aero zu aktivieren. VirGL hatte mal vor mittlerweile längerer Zeit versprochen in ähnlicher Weise, auch Windows auf die Sprünge zu helfen. Aber da ist bis jetzt anscheinend nichts draus geworden (und wird es vermutlich auch nie).

Vorläufiges Schlußfazit meines Ausflugs: keine wirkliche Konkurrenz für Virtualbox und VMware, in punkto was sich so das "einfache Volk" von Virtualisierern erhofft. Und das obwohl das Bedienkonzept des VirtManagers nach ein bißchen Einarbeitung als sehr überzeugend zu bezeichnen ist.

 

[andy_m4]

Virtualbox

VirtualBox wird irgendwie von Version zu Version schlechter. Das war mal ein solides Produkt. Dann fiel es irgendwie Oracle in die Hände. Das hatte zunächst keine wirklich großen Auswirkungen aber so in den letzten Jahren hat man irgendwie immer mit Zipperlein zu tun, die es früher nicht gab und zudem wurde die GUI verschlimmbessert.

Und ja. Bei KVM/QEMU steht Desktop-Virtualisierung (insb. Windows) nicht so sehr im Vordergrund. Es geht auch, aber ist nicht deren Paradedisziplin, ums mal vorsichtig auszudrücken. :-)

 

[LochinSocke]

Vorläufiges Schlußfazit meines Ausflugs: keine wirkliche Konkurrenz für Virtualbox und VMware, in punkto was sich so das "einfache Volk" von Virtualisierern erhofft. Und das obwohl das Bedienkonzept des VirtManagers nach ein bißchen Einarbeitung als sehr überzeugend zu bezeichnen ist.

Du willst also sagen, dass das "einfache Volk", der ungebildete Pöbel und Bewohner der Unterschicht des gesellschaftlichen Bodensatzes stets dabei ist Windows aus dem Hause Microsoft zu Virtualisieren?

Ich stimme dir voll zu!

 

[7vor10]

Du willst also sagen, dass das "einfache Volk", der ungebildete Pöbel und Bewohner der Unterschicht des gesellschaftlichen Bodensatzes stets dabei ist Windows aus dem Hause Microsoft zu Virtualisieren?

Nee, nicht ganz
Mit "einfachen Volk" (wohlwollend ironisiert) meine ich Leute, die Virtualisierungsprogramme nicht mit den Augen von Systemadministratoren bzw. IT-Fachleuten betrachten, sondern einfach bloß wollen, dass ihre VM (was für eine auch immer) möglichst einfach aufzusetzen und leicht zu bedienen ist. Und natürlich performt und stabil läuft.

 

[Caramon2]

Ups, habe gar nicht mitbekommen, dass es hier was neue gibt.

Vorläufiges Schlußfazit meines Ausflugs: keine wirkliche Konkurrenz für Virtualbox und VMware, in punkto was sich so das "einfache Volk" von Virtualisierern erhofft. Und das obwohl das Bedienkonzept des VirtManagers nach ein bißchen Einarbeitung als sehr überzeugend zu bezeichnen ist.

Der Vorteil von KVM ist, dass man damit Laufwerke direkt einbinden kann, so dass man z. B. Windows (und natürlich erst recht Linux) aus der VM heraus "richtig" installieren und anschließend native booten kann. - Man kann sogar beliebig wechseln: Wenn ich nur kurz was nachsehen will, boote ich es in der VM, wenn ich etwas aufwändigeres testen will, boote ich es direkt.

VirtualBox hat auch den Nachteil, dass man nicht eine vHD in mehrere VMs einbinden kann. - Nicht mal, wenn man nur immer eine davon nutzen will.

Mein VM-XP kann ich dagegen beliebig oft parallel booten und mit gesetzter snapshot-Option kommen die sich auch nicht ins Gehege (insbes. als ich KSM mal richtig ausgetestet habe, war das sehr praktisch: Bei 16 GiB RAM 20 VM-XPs mit jeweils 4 GiB RAM nacheinander parallel starten und dann dabei zusehen, wie der Speicherbedarf immer weniger wird ). - Schön fand ich dagegen den Nahtlos-Modus, als ich noch mehr mit dem VM-XP gemacht habe. - Mit KVM soll das zwar auch möglich sein (irgendwie mit dem Spice-Protokoll, oder so), aber damit habe ich mich noch nicht beschäftigt.

Mit VirtManager habe ich noch nie was gemacht, da ich lieber alles schön übersichtlich in einer Befehlszeile habe, anstatt mich erst durch irgendwelche GUIs durchklicken zu müssen. - Da kann man als Neuling schnell was übersehen oder falsch verstehen und wer weiß von welchen Möglichkeiten man nichts mitbekommt, weil es in der GUI nicht vorgesehen ist.

…

Was neues:

Ich habe es mir einfacher gemacht, Windows testweise zu installieren, indem ich mir ein Image eines Ventory-Sticks mit dem Win-ISO erstellt habe und es automatisch booten lasse.

Das habe ich eben durchgespielt und mitgeschnitten: s. Anhang (stark komprimpiert)

Zum Host:

Ich nutze Artix-Xfce-Runit und lasse Fenster beim verschieben/skalieren 20% transparent anzeigen (um sie besser überlappend positionieren zu können) und inaktive Fenster 10%, damit mir auffällt, dass das Fenster gar nicht den Fokus hat, bevor ich versuche dort etwas einzugeben.

Letzeres passiert mir zwar immer noch gelegentlich, aber weit weniger als früher, bevor ich diese Idee hatte. - 20% wäre zwar besser (damit passierte das fast nie), aber das stört dann schon, wenn ich z. B. zwei Fenster miteinander vergleiche.

Unten rechts kann man u. a. sehen, wie sich die zRAM-Disk mit der vHD langsam füll und wie stark es komprimiert wird.

Die Fan-Anzeige der GraKa (AMD 560D) ist übrigens falsch: Der Lüfter dreht nur beim booten kurz hoch und wird dann abgeschaltet. Statt dass die Drehlzahlanzeige auf 0 rpm fällt, friert sie beim letzten Stand ein.

Im Skript (s. u.) nutze ich "if=virtio" und habe deshalb eine Treiber-Disk mit eingebunden: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/
(eine etwas ältere Version, da die aktuellen nicht mehr als Diskettenimage angeboten werden)

Das ab 10:30 Min. erst nichts passiert, liegt daran, dass ich noch in der Küche war: Nach dem ersten Reboot hatte ich mir gedacht, die Zeit reicht, um mir einen Cappuccino zu machen. - Tja, nichts ganz…

Die Abfragen habe ich komplett per Tastatur beantwortet: Mit Shift+Tab zu "kein Internet" und die restlichen mit wiederholt Cursor runter + 2x Enter: So geht's am schnellsten.

Nachdem es "fertig" installiert war, habe ich schnell meine Grundkonfiguration durchgeführt (weder Fastboot noch Swap usw.) und rebootet.

Während ich dann darauf wartet, bis es "wirklich" fertig installiert ist (im Hintergrund macht es ja noch eine ganze Weile was), habe ich dann die Ventoy-Konfiguration gezeigt, mit der das Win-ISO sofort gebootet wird.

Btw:

Wieso gibt es für den Papierkorb keine generelle Einstellmöglichkeit mehr?

Ich möchte, dass bei RMB/"Löschen" genau das gemacht wird. Den Papierkorb habe ich noch nie genutzt.

Bei Windows XP war das kein Problem:

#!/bin/bash
echo "Passwort zum erstellen der zRAM-Disk:"
sudo modprobe zram
id=$(sudo cat /sys/class/zram-control/hot_add)

# Für langsamere, dafür bessere Kompression, hier "lz4" durch "zstd" ersetzen:
echo -ne "\nKompression:   "; echo lz4|sudo tee /sys/block/zram$id/comp_algorithm

# Eine frische Win11-22H2-Pro-4-WS-Installation belegt ca. 9,5 GiB, das zstd auf 5,3 GiB
# und lz4 auf 6,5 GiB komprimiert: Das ist der effektive RAM-Bedarf.

# Größe der zRAM-Disk (die unkomprimierte Größe: kann mehr als das RAM des Hosts sein - s. o.):
echo -ne "zRAM-Disk-Größe: "; echo 20G|sudo tee /sys/block/zram$id/disksize

# Da selbst Win11-Pro4WS komprimiert keine 7 GiB belegt, reichen mit "lz4" 16 GiB RAM locker und mit "zstd"
# kann man es sogar mit nur 8 GiB RAM in der zRAM-Disk installieren: Dazu unten auf "-m 2G" ändern.

sudo mkfs.xfs -q /dev/zram$id && mkdir /tmp/zram$id
sudo mount -o discard /dev/zram$id /tmp/zram$id/ && sudo chmod 777 /tmp/zram$id/
vhd=/tmp/zram$id/vHD.raw;qemu-img create $vhd $((240*10**9))

# Die vHD wird sparse erstellt und kann deshalb weit größer als RAM und zRAM sein: Relevant ist nur
# was tatsächlich geschrieben wird (zRAM-Größe) und wie viel es komprimiert ist (RAM des Hosts).

# VM mit UEFI booten:
echo -e "\nHinweis:\n\nBeim Reboot kommt man mit [Esc] ins UEFI. (um z. B. von einem anderen Laufwerk zu booten)\n"
qemu-system-x86_64 -nodefaults -machine q35 -enable-kvm -cpu host -smp cores=4 -m 4G -display sdl,gl=on -vga virtio -drive file=/usr/share/edk2-ovmf/x64/OVMF.fd,if=pflash,snapshot=on,format=raw -drive file=Win11-VirtIO.vfd,if=floppy,aio=io_uring,snapshot=on,format=raw -drive file=$vhd,if=virtio,aio=io_uring,discard=unmap,format=raw -drive file=Win11-Ventoy.qcow2,if=virtio,aio=io_uring,snapshot=on || read -p [Fehler\!]

 

[7vor10]

Mit VirtManager habe ich noch nie was gemacht, da ich lieber alles schön übersichtlich in einer Befehlszeile habe, anstatt mich erst durch irgendwelche GUIs durchklicken zu müssen. - Da kann man als Neuling schnell was übersehen oder falsch verstehen und wer weiß von welchen Möglichkeiten man nichts mitbekommt, weil es in der GUI nicht vorgesehen ist.

Für Leute wie mich ist der VirtManager die einzige Chance, auch mal alternativ etwas unter Qemu/KVM zu probieren. Zumal dir der Manager die zugrundeliegenden Qemu-Kommandosequenzen auf Wunsch auch anzeigt und du ggf. noch nacheditieren kannst. (Hatte ich im Fall der NVidia-Macke sogar nach Anleitung aus dem Web probiert - jedoch ohne Erfolg.)

Wo die Virtualisierungsalternative allerdings auch keine Wunder bewirkt, ist die Performance (von Windows-VMs). Da sind VirtualBox und vor allem der VMware Player einfach besser. Es fehlt halt eine virtuelle Grafikkarte, die stärker ist als VMSVGA.

Ich liebe auch eher das Einfache. Im Sinne von unkompliziert, aber nichtsdestotrotz mächtig in seiner Leistung. Zum Beispiel den Simple Screen Recorder, den Du im Anhang-Video nutzt. Dieses Tool hatte ich erst vor rund einem halben Jahr entdeckt und ist für mich seitdem nicht mehr wegzudenken.

 

[Caramon2]

Für Leute wie mich ist der VirtManager die einzige Chance, auch mal alternativ etwas unter Qemu/KVM zu probieren.

Ich habe ihn mir gar nicht erst angesehen, da ich das "reine" KVM nutzen wollte. - Sozusagen als von der vBox-GUI "gebrannten" Kind: Mit sowas wollte ich nicht mehr zu tun haben.

Der Einstieg war ziemlich schwer, da ich überhaupt keinen Plan davon hatte, aber als ich dann auf die Beschreibungen bei Redhat gestoßen bin und langsam realisierte, wie viel mächtiger KVM gegenüber vBox doch ist, war es für mich ganz klar, dass ich auf keinen Fall wieder zurück will.

Ursprünglich wollte ich hauptsächlich wechseln, weil ich nicht mehr eine großes Softwarepaket (+ den Umstand mit dem zu jeder neuen Version passend nachzuinstallierenden Erweiterungspaket und dann in jeder VM zu aktualisierenden Gasterweiterung) installieren wollte: Für etwas, dass der Kernel schon von sich aus kann.

Nachdem ich endlich die erste funktionierende Befehlzeile zusammen hatte und das Prinzip verstand, war der Rest ein Klacks, da ich ja darauf aufbauend konnte.

Ich erstelle sie ja nicht immer wieder neu auf, sondern brauche meine Skripte ja nur kopieren und entsprechend anzupassen.

Zumal dir der Manager die zugrundeliegenden Qemu-Kommandosequenzen auf Wunsch auch anzeigt und du ggf. noch nacheditieren kannst.

Also eine der besseren GUIs, bei der man sich nicht blind auf das verlassen muss, was der/die Macher sich dabei "gedacht" haben.

Auch soll es gut zur Verwaltung mehrerer VMs sein. Aber bei mir gibt es nichts zu verwalten, da ich die nur bei Bedarf nutze und eher kurzfristig, um was auszuprobieren.

Btw:

Mit bei "-drive" hinzugefügten ",snapshot=on" werden Schreibzugriffe nicht wirklich umgesetzt, sondern nur im RAM gepuffert: Ideal um etwas auszuprobieren, da man ja nichts kaputt machen kann.

z. B. kann eine Linux-Installation sich damit selbst in der VM booten und man kann dort z. B. "sudo rm -rf /" ausprobieren, ohne dass es (außer natürlich in der VM) beschädigt wird.

Ohne ",snapshot=on" reicht dagegen schon das parallele booten von sich selbst, um sich irreparabel zu beschäftigen: Zumindest bei btrfs schrottet das sofort das das komplette Dateisystem der Systempartition (dabei hatte ich nur bis zur Passwort-Abfrage der LUKS-verschlüsselen Home-Partition gebootet, als mir aufgefallen ist, dass ich das falsche Laufwerk erwischt hatte und die VM sofort beendete und den Host sofort ruter fuhr), während xfs das gleiche offenbar locker wegsteckt: Sicherheitshalber habe ich es trotzdem nicht weiter genutzt, sondern die Partition neu formatiert und die Sicherung wiederhergestellt.

Das war noch unter LinuxMint: Nach einem reboot hatte sich eine USB-HD "vorgedrängelt" und war sda, wodurch das Systemlaufwerk zu sdb wurde, statt der 2. int. SSD, die ich eigentlich in der VM booten wollte. - Im "Eifer des Gefechts" hatte ich nicht mehr daran gedacht…

Dieses "Vordrängeln" passiert übrigens nur bei Ubuntu und Derivaten: Mit keiner anderen Distribution konnte ich das reproduzieren: Auch nicht mit LMDE!

Das hat also eindeutig Ubuntu vermurkst und nichts daran geändert, da sich das auch mit aktuellen Versionen reproduzieren lässt: Bei allen PCs, auf die ich Zugriff hatte und habe. Also es liegt nicht nur an meinem.

Das passiert aber nicht immer, sondern manchmal (sehr selten) bleiben bei einem Reboot die USB-Laufwerke hinten. - Man kann sich also nicht mal darauf verlassen.

Nicht nur deswegen rate ich inzwischen von Ubuntu und aller Derivate ausdrücklich ab.

Ich habe LinuxMint 17.1-18.3 genutzt, da LM 19 für mich schon unbrauchbar war: Was ich mit anderen auf Ubuntu 18.04 basierenden Distributionen reproduzieren konnte (ich hatte Zorin und Elementary getestet).

Für den Einstieg scheinen mir LMDE oder MX-Linux die bessere Wahl, obwohl sie etwas anspruchsvoller als Ubuntu & Co. sind.

Wenn einem die zu Langweilig werden, wäre m. E. Manjaro ein guter nächster Schritt und später kann man zu einem "richtigen" Arch-Derivat wechseln: Z. B. E-dingsbums-OS (ich kann mir den Namen - und erst recht die Schreibweise - nicht merken.

 

[7vor10]

Ich bin ja ein eingefleischter 'GUIler'. Aber keine Regel ohne Ausnahme. Als ich vor rund einem halben Jahr mit meinem Experiment unter Qemu-KVM begann, war das erste Tool, welches ich ausprobierte, ein Snap-Paket unter Ubuntu 22 LTS namens 'Qemu-Virgil'. Das Teil ist aber ein reines CLI-Programm. Ohne die erstklassige Einführung hätte ich mit dem Teil wenig anfangen können. So aber ermöglichte es mir, die 3D-Beschleunigung via VirGL in einer Kubuntu-VM nachempfinden zu können. VirGL liefert die beste mir bekannte Performance für Linux-VMs.

Der Erfolg mit dem CLI-Tool veranlasste mich, dasselbe nochmal unter dem VirtManager zu probieren. Obwohl der VirtManager das VirGL-Feature zu integrieren vermag, klappte es auf diesem Wege nicht. Die Nvidia-Grafikkarte stand im Weg. Denn auf einem anderen Rechner, aber mit Intel-Graka, funktionierte es anstandslos. Erstaunlich halt nur, dass das CLI-Tool 'Qemu-Virgil' das auch unter der Nvidia-Karte zuwege brachte.

Danach war meine Neugierde aber erst mal gestillt. Denn was ich eigentlich suchte, war sowas wie VirGL, bloß für ältere Windows-Versionen (XP, 7). Hier steht man nämlich vor dem Problem, dass man selbst mit GPU-Passthrough nicht weiter käme, da es (jetzt oder irgendwann) keine nativen Treiber mehr für alte Windows-Versionen gibt. Was man für solche Fälle braucht, ist stattdessen eine verbesserte virtuelle Grafikkarte wie VirGL, die es aber leider nicht in gleicher Weise für Windows-Systeme gibt.

 

[Caramon2]

So aber ermöglichte es mir, die 3D-Beschleunigung via VirGL in einer Kubuntu-VM nachempfinden zu können.

Mit 3D Beschleunigung in KVM habe ich mich noch nicht beschäftigt. Ich nutze es hauptsächlich, um gerade mal Livesysteme zu booten oder zu installieren und um nach Basteleien am System, Ventoy-Stick, usw., schon mal zu testen, ob es bootet (mit gesetzter Snapshot-Option, damit nichts geschrieben werden kann), bevor ich es "richtig" boote und wenn alles okay, sichere.

Für Win X|XI nutze ich es nur für solche Testinstallationen, wo die Installation länger dauert, als die anschließende "Nutzung". Dauerhaft nutze ich nur mein altes VM-XP, was ich gelegentlich für den Schnitt von DVB-S-Aufnahmen brauche und da habe ich bzgl. Vorschau-Bild die beste Leistung mit QXL. Dafür gibt es bei Fedora aber offenbar nur Treiber bis 32bit XP. Jedenfalls konnte ich keine für XP x64 finden und für neuere Versionen habe ich den auch noch nicht gesehen.

3D hatte ich nur mal mit vBox und AeroFly Pro Deluxe 1.9 getestet. Das lief zwar flüssig, aber schon nach 2-3 Min. war immer wieder der Ton weg und ich musste die VM runterfahren und neu starten (auch schon unter XP x64, wo ich ein 32-bit VM-XP für den Canoscan 1220 U brauchte, da es für den schon 5 Jahre nach dem Kauf keinen Treibersupport mehr gab: Nie wieder Canon!).

Per Wine lief es dagegen von Anfang an (Wine 0.99.irgendwas unter LinuxMint 17.1) problemlos. Auch mit meiner damaligen, passiv gekühlten GeForce 710 GT und deren proprietären Treiber.