Spielereien mit KVM (Kernelbased Virtual Machine)

Uridium schrieb:
Vielleicht das mal vorher/nachher testen:
udisksctl info -p block_devices/sdc1
Das im Anhang ist direkt nach dem anschließen der SSD.
Dann habe ich das VM-WinXP kurz gestartet. Danach konnte Thunar sie wieder nicht öffnen, aber bei der udisksctl-Ausgabe war alles unverändert.
Dann habe ich sie kurz manuell gemountet, Thunar bekam wieder Zugriff, aber an der udisksctl-Ausgabe hatte sich wieder nichts geändert:
Code:
$ diff -s u1.txt u2.txt
Dateien u1.txt und u2.txt sind identisch.

$ diff -s u1.txt u3.txt
Dateien u1.txt und u3.txt sind identisch.
 

Anhänge

Thunarfenster mal via Terminal öffnen. Das gibt hoffentlich logs auf stderr.

Mit 'kill -HUP <dbuspid>' soll d-bus einen config reload machen. Es gibt glaube ich zwei d-bus daemons (für system und einer für die user-session).

Im syslog sollte d-bus einiges hinterlassen. Da schon nachgeguckt?
 
Uridium schrieb:
Thunarfenster mal via Terminal öffnen. Das gibt hoffentlich logs auf stderr.
Das ist eine gute Idee. - Mache ich sonst auch immer wenn was nicht funktioniert, aber bei Thunar bin ich irgendwie nicht darauf gekommen.

Werde ich machen, wenn ich das nächste Mal den PC nutze.
Uridium schrieb:
Mit 'kill -HUP <dbuspid>' soll d-bus einen config reload machen. Es gibt glaube ich zwei d-bus daemons (für system und einer für die user-session).
Ist die pid denn immer die selbe? Oder wie bekomme ich die in einem Skript raus?
Uridium schrieb:
Im syslog sollte d-bus einiges hinterlassen. Da schon nachgeguckt?
Bis jetzt nicht, da "syslog-ng" vor ca. 2 beim booten die Ausgabe mit Meldungen zugemulüllt hat: Da ich sowieso nichts damit anzufangen wusste, habe ich es rausgeschmissen (pacman -Rscn …).
 
Caramon2 schrieb:
Ist die pid denn immer die selbe? Oder wie bekomme ich die in einem Skript raus?
Sind wahrscheinlich nicht immer die selben. Für einen ersten Test soll es aber erst einmal einfacher sein, die PIDs manuell via 'ps aux |grep dbus' (oder ähnlichem) selbst raus zu suchen. Ich weiß derzeit auch nicht, wie die Prozesse genau heißen oder was das 'reload' überhaupt bewirkt. Eine gewisse Hoffnung besteht, dass d-bus danach sämtliche Verbindungen und Clients auffrischt.
 
Caramon2 schrieb:
Durch "snapshot=on" werden Schreibzugriffe nur im RAM gecached, aber nicht wirklich umgesetzt. Dadurch gibt es keine konkurrierenden Schreibzugriffe und es kann am physischen System nichts kaputt gehen.
Änderungen vom Host an der Platte die der Gast im Cache hat bekommt der Gast nicht mit.
D.h. der Gast wird irgendwann inkonsistente Filesysteme und/oder Daten haben -> BUMM!
 
@foofoobar: Richtig. Deshalb schrieb ich extra "am physischen System".

Das in der VM interessiert doch nicht: Was willst du damit groß machen, wenn es nichts dauerhaft speichern kann?

Ich nutze das, um z. B. nach einer Wiederherstellung, Neupartitionierung/-formatierung, oder wenn ich es auf ein anderes Laufwerk umgesiedelt habe, um zu testen ob es bootet, weil falls es dabei Probleme gibt, es dadurch nicht erst richtig was kaputt machen: Starten, kurz testen, wieder runterfahren, fertig.

Das eigene System sich selbst in der VM booten zu lassen war nur als Beispiel gedacht, um dem aus dem Artix-Forum zu verdeutlichen was ich meine.

Er kopiert sein Produktivsystem erst in eine VM, um dort zu testen ob die Aktualisierungen sauber funktionieren, bevor er das physikalische System aktualisiert.

Ich finde das umständlich und eine unnötige Zeit- und Platzverschwendung:

Einfach die Aktualisierungen runterladen, aber noch nicht installieren (sudo pacman -Syuw), dann das System mit "snapshot=on" in der VM booten, dort die Aktualisierungen installieren lassen (sudo pacman -Syu) - man konzentriert sich natürlich darauf und macht nicht groß was am Host - und wenn alles OK ist, die VM beenden (man kann sie einfach mit Alt+F4 abschießen) und die Aktualisierungen wirklich durchführen lassen.

Aber selbst das fände ich schon übertrieben: Ich aktualisiere mein System und fertig. - Sollte es Probleme geben (passiert nicht mal jährlich), spiele ich einfach die letzte Sicherung zurück. Genau dafür sind die doch da.
 
Zurück
Oben