MX Linux Forum

Posted: **Sun Mar 24, 2024 12:26 pm**

Hallo, Forum.

Beim benutzen von Virt-manager will es mir einfach nicht gelingen, einen gemeinsamen Ordner zum Austausch zwischen Wirt und Gast zu nutzen.

Ich versuche mein Glück immer wieder mit gebooteten ISOs als Gast.
Und vielleicht ist das auch schon die Krux, weil ich so einen ISO-Gast ja nicht rebooten kann, wenn ich vermutete, notwendige Virt-Pakete nachinstalliert oder Gruppenberechtigungen geändert habe.

Mein bisheriges Vorgehen war:
Vor dem Hochfahren des Gastes im Wirt habe ich einen Austausch-Ordner ausgewählt über Info-Seiten-Panel -> "+Gerät hinzufügen" -> "Dateisystem".
In der dazugehörigen Konfigurationsmaske war vor ausgewählt
Typ=mount ( im dropdown war nichts weiter auszuwählen, obwohl 9P auf dem Wirt installiert ist.)
Modus stand auf "mapped" und habe ich so belassen.

Als Quelle hatte ich mir den extra im Home des Wirts angelegten "Austausch-Ordner" herausgesucht.
Als Ziel habe ich eingetragen /share

Nach dem Booten des Gastes habe ich dort das Terminal genutzt und ...

Code: Select all

mkdir /tmp/share

Dann

Code: Select all

sudo mount -t 9p -o trans=virtio,version=9p2000.L /share /tmp/share

Und das hat funktioniert.
Obwohl auf dem Gast nix von 9P installiert ist.

Ich konnte auf den share-Ordner im Gast zugreifen und Dateien, die ich zuvor im Wirt dort angelegt hatte ansehen, öffnen, kopieren.
Aber nix schreiben oder dort vom Gast aus Platzieren.
Das änderte sich, nach dem ich vom Gast aus in der Rechtevergabe allen alles erlaubt hatte und ausführbar machte.
( Was sicherlich nicht Sinn der Sache ist )
Aber so konnte ich nun auch vom Gast aus etwas in diesem Austauschordner Platzieren.
Nur, dass das das dann wiederum im Wirt nicht zu öffnen war, weil gesperrt.
Ausser für Root.
Im Wirt, zu diesem Ordner allen alles erlauben, hatte nur ganz selektiv etwas geändert.

Anstrengend.

Wenn es um den Trasfare von Dateien vom Wirt zu Gast geht, wäre das ja dank SPICE alles gar nicht nötig.
Einfach die Datei im Wirt anpacken, festhalten und auf den Desktop des Gastes ziehe und Loslassen.
Fertig.
Mit ganzen Ordnern geht das natürlich nicht, wenn sie nicht zuvor in einen Kompressionskontainer gestopft wurden.

Ich hoffe, ich bekomme von euch eine Anleitung, einen ordentliche, bidirektional benutzbaren Austausch-Ordener auch in/für ISO-Live-Systemen erstellen zu können.

Derweil behelfe ich mich mit dem Ein- und Ausbinden eines USB-Sticks.
Das geht ja bei Virt-Manager ebenso gut wie bei VirtualBox. ( bei Aqemu ging das gar nicht. War zwar vorgesehen, aber funktionierte nicht )

Posted: **Sun Mar 24, 2024 1:16 pm**

Zwei Nachträge:

Das System mit dem ich es gerade versuchte, als ich vorheriges schrieb, war
Wirt = MX-21.3-64bit-xfce

Gast = MX-23.2-64bit-xfce
hier funktionierte das Mounten im Gast, wie geschrieben, auch ohne 9p.

Gast = MX-21.3-64bit-xfce
hier funktionierte das Mounten im Gast weder ohne 9p noch mit den Nachinstallierten Paketen 9p.

Auch das Nachträgliche Anlegen ( und zuordnen ) von Gruppen ( libvirt, libwirt-clients, libvirt-qemu ) im Gast MX-21.3-64bit-xfce, half nicht. ( erstellt mit dem MX-Benutzer-Manager )
Aber, wie schon geschrieben, konnte ich keinen Neustart des Gast-Systemes durchführen, weil ja ISO.

Posted: **Sun Mar 24, 2024 5:03 pm**

Hallo loik,

loik wrote: Sun Mar 24, 2024 12:26 pm ich bekomme von euch eine Anleitung, einen ordentliche, bidirektional benutzbaren Austausch-Ordener auch in/für ISO-Live-Systemen erstellen zu können

naja, kommt drauf an. Ich bevorzuge externe USB-FP zum Datenaustausch (USB-Einheit weiterleiten). Aber Du kannst auch sftp im Dateimanager benutzen, das ist direkter. Z.B. im Thunar in die Adresszeile

Code: Select all

sftp://IP-ADRESSE/PFAD/ZUM/ORDNER

eintragen, Fragen zu Username und Passwort beantworten und schon kannst Du die Dateien mit der Maus hin- und herschubsen. Natürlich gelten die üblichen Linux-Rechte, also eine Datei oder ein Verzeichnis das nur root gehört kannst Du als normaler User nicht bearbeiten.
Da sich sowohl Host und Gast in einem Netzwerk befinden, funktionieren aber auch die gängigen Austauschmechanismen wie NFS oder Samba.
https://itsfoss.community/t/communicati ... ager/10841
Dass ist alles Geschmacksfrage, aber mir scheint die sftp/ssh-Methode am einfachsten zu sein. Statt Thunar kannst Du auch sowas wie Filezilla benutzen, aber Thunar (oder anderer Dateimanager) ist schon vorhanden, Filezilla & Co. müsstest Du erst nachinstallieren.

viele Grüsse gosia

PS.
in meinem jugendlichen Ungestüm

habe habe ich vergessen zu erwähnen, dass für die ssh/sftp-Methode natürlich auch ssh laufen muss. Aber das war bei mir unter MX eigentlich immer der Fall, zu anderen Distris kann ich nichts sagen.
Und ab MX-23 läuft wohl per default eine Firewall, die ssh blockiert. Also bei Problemen dort nachsehen, Stichwort gufw, bzw. einfach

Code: Select all

sudo ufw status

Posted: **Mon Mar 25, 2024 10:54 am**

Hallo, Gosia.

Danke für die Tipps und Anregungen.

Mein grundsätzlicher Wunsch ist es VirtualBox zu ersetzen.

Darin läuft Win10 mit meinen Buchhaltungsprogamm.
Dieses Konstrukt muss leider sein.

Und Virt-Manager scheint sehr wohl VB ersetzen zu können.

Nur anscheinend nicht so einfach das Wesentliche, nämlich den gemeinsamen Ordner.
In VB suche ich mir in den Einstellungen dafür meinen Home-Ordner des Wirtes und den Media-Ordner des Wirtes heraus und gewähre Vollzugriff.
So kann ich von beiden Systeme gleichermaßen auf dieselben Dateien zugreifen.

Das klappt so mit Virt-Manager nicht.

Außer eben vielleicht mit

Code: Select all

sftp://IP-ADRESSE/PFAD/ZUM/ORDNER

Aber das ist Netzwerk und da scheitere ich schon als erstes an der IP-Adresse und als nächstes an ssh.
( Wirt und Gast waren in meinem Versuch Linux 21.3-64bit-xfce. Firewall jeweils aus. )

Ich wollte vom Gast auf den Wirt zugreifen, über den Dateimanager.
Die vermutetet IP vom Wirth habe ich mir aus dessen Conky abgelesen, Wireless ( na wenn das mal stimmt. Glaube ich ja nicht. )

Dann in den Dateimanager nach der Befehlsvorgabe eingegeben:

Code: Select all

"sftp://IP-ADRESSE/PFAD/ZUM/ORDNER" konnte nicht angezeigt werden.
Fehler: Verbindung wurde vom Server Verweigert.
Bitte wählen sie einen anderen Betrachter und versuchen Sie es erneut

Natürlich hatte ich einen realen Pfad eingetragen und eben unbedarft jene IP

Ich hatte es in der Vergangenheit auch gemacht, dass ich ein USB-Laufwerk an den Router gehängt hatte, um Austausch zwischen all meinen Geräten zu ermöglichen.
Aber, obwohl scheinbar der Königsweg für alle, hat mich daran irgend etwas so genervt, dass ich doch lieber wieder mit dem USB-Stick von A nach B gelaufen bin.

Aber ja, für den Austausch einzelner Dateien ist das sicherlich das Sinnvollste.
Nur für die Büroarbeit eben eher nicht.

Klar, dass mit mit USB ist schon eine große Erleichterung.
Und für die ein oder andere Sache auch genau richtig.
Aber für Büroarbeit ein wenig umständlich, ständig virtuell an und abzukoppeln.
Oder gibt es eine Einstellung bei der Wirt und Gast Zeitgleich auf das USB-Laufwerk zugreifen können ?

Bei USB-FP kommt problematisch hinzu, das sich Wirt und Gast und die Büro-Dateien auf ein und demselben USB-Datenträger befinden.
Zwar auf unterschiedlichen Partitionen aber auf dem selben USB-Gerät.
Da ist es mir wohl kaum möglich, diesen USB-Datenträger durchzureichen.
Der Wirt würde ja gleich mitgereicht werden.

Posted: **Mon Mar 25, 2024 6:36 pm**

Hallo loik,
oha, das ist ja nun doch eine etwas andere Ausgangslage, als ich sie mir nach diesem Satz vorgestellt hatte

loik wrote: Sun Mar 24, 2024 12:26 pm eine Anleitung, einen ordentliche, bidirektional benutzbaren Austausch-Ordener auch in/für ISO-Live-Systemen

An Windows habe ich dabei nun gar nicht gedacht, mein Fehler. Windows in einer VM kann ich im Moment nicht testen, also erstmal nur Theorie.
sftp könnte schon funktionieren, aber da müsste in Windows ein openssh-Server/Client laufen und eingerichtet sein. Ab Win10 sollte der auf jeden Fall dabei sein, habe ich mir sagen lassen, vor Win10 käme sowas wie putty in Betracht.
https://the.earth.li/~sgtatham/putty/0.80/htmldoc/
Aber "Verbindung verweigert" klingt für mich doch sehr nach Firewall, ist ja in Windows auch eingeschaltet.
Was die IP-Adresse des Gastes betrifft, so wird die in "Details" -> "NIC" angezeigt, sicher auch irgendwo in Windows.

Aber letztendlich sollte der Weg mit "Gerät hinzufügen" -> "Dateisystem" auch funktionieren, aber das müsste dann ein Dateisystem das auch Windows lesen/schreiben kann, ext4 & Co. fällt da schon mal weg, bliebe letztendlich dann doch wieder was mit externer USB-FP. Kann ich aber im Moment nichts dazu sagen, vielleicht meldet sich mal jemand, der ähnliches schon mal gemacht hat.
Bleibt nur die Frage, ein Dualsystem mit Windows und Linux möchtest Du nicht?

viele Grüsse gosia

Posted: **Tue Mar 26, 2024 4:13 am**

Hallo, Gosia.

Oha, jetzt habe ich mit der Erwähnung meines langfristigen Zieles ( win10 in Virt-Manager ) es doch wieder geschafft, für Verwirrung zu sorgen.
Deine Infos zu win10 gehen im Moment noch ins Leere.
Soweit bin ich noch gar nicht.
Meint ich habe noch gar kein Win10 in Virt-Manager laufen.

Aber ich dachte mir schon, dass dieses Projekt zusätzliche Hürden haben würde.
Deshalb bin ich froh, von dir schon mal die ersten konkreten Hinweise darauf erhalten zu haben. Danke.

Ähm, Dateisystem, ja, ich habe alle meine Dateien auf NTFS, damit ich von jedem System darauf zugreifen kann.
Home auf ext4 nutze ich nur als temporären Zwischenspeicher.

Zum entstandenen Missverständnis:

eine Anleitung, einen ordentliche, bidirektional benutzbaren Austausch-Ordener auch in/für ISO-Live-Systemen

Das hattest du richtig verstanden.
Es geht zur Zeit um Linux in Linux bzw von Linux zu Linux.

Bei meinen Versuchen, wo ich am Verbindungsaufbau über das Netzwerk scheiterte,
war Wirt = MX-21.3-64bit-xfce
und Gast = MX-21.3-64bit-xfce ( ein MX-Snapshot )
In beiden ist die Firewall aus.

Ich hatte es auch über Samba Versucht
( Damit hatte ich in der Vergangenheit Erfolg, das USB-Laufwerk am Router zu erreichen.
Aber Nach einem Routerwechsel habe ich dieses Laufwerk noch nicht neu installiert und somit fällt dieses vorläufig aus, um zu Testen, ob ich das denn erreichen würde. )

Mit Samba sah mein Eintrag für die Adresszeile so aus:

Code: Select all

smb://IP-Adresse-des-Wirtes/HOME/USER/AUSTAUSCH_ORDNER/

Darauf hin öffnete sich das Passwort-Abfragefenster.
Als Domöne war "WORKGROUP" eingetragen, was schon der Fehler sein kann.
Denn die Verbindung scheiterte, weil das Ziel nicht erreichbar sei.

Dann fiel mir ein, dass dies in der Vergangenheit bereits manchmal der Fall war, wenn ich das USB-Laufwerk am Router erreichen wollte.
Das lag dabei an einem Samba-Update, welches wohl negativ auf die Verbindung zu alter Router-Software wirkt.
Da muss dann die Datei
/etc/samba/ smb.conf
bearbeitet werden.
Es braucht die NT1-Zusatzzeile, damit es wieder Verbindet:

Code: Select all

# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = Workgroup
   client min protocol = NT1

Das habe ich im Gast-system also nachgetragen.
Aber die Verbindung zum Wirt hat trotzdem nicht funktioniert.

Ich vermute, das "WORKGROUP" falsch ist.

Posted: **Tue Mar 26, 2024 4:49 am**

Ich habe jetzt mal den alten Router herausgesucht, in s Netzwerk eingebunden, mir vom Hauprouter aus dessen aktuelle IP geholt, den USB-Speicher an den alten Router.

Dann habe ich Ihn mit der Adresszeile des Dateimanagers ( des Wirtes ) angewählt
smb://usbbox@http://IP-ADRESSE/fritz.nas/

Dann bei der Passwortabfrage
bei Domäne usbbox eingetragen
Und bei Passwort natürlich dass passwort.

Zugriff erfolgt.
Prima.

Das selbe habe ich dann im Gast versucht.
Aber Zugriff wegen FehlenderWindows-Freigabe verweigert.

Samba wie beschrieben Korrigiert.
Ab- und Angemeldet.

Es bleibt dabei, Zugriff wegen fehlender Windowsfreigabe verweigert.

Über den Browser des Gastes ist der alte Router aber per IP zu erreichen.
( wie schon geschrieben, Gast ist MX-21.3-64bit )

Ob die Manipulation der Samba-Datei Wirkungslos blieb, weil ich nicht Neustarten konnte, da Gast ja ein ISO ist ?

Oder hat Virt-Manager eine eigene Firewall ?

Nachtrag:

Folgendes hatte im Gast auch nicht geholfen

Code: Select all

sudo service network-manager restart

Code: Select all

sudo service smbd restart

Code: Select all

sudo /etc/init.d/smbd restart

Code: Select all

sudo service nmbd restart

Posted: **Tue Mar 26, 2024 5:50 am**

O.K.
Ich habe das ganze Prozedere, den Netzwerkspeicher aus dem Gast heraus zu erreichen, nachgestellt mit Aqemu.
Selber Wirt, wie zuvor.
Selber Gast., wie zuvor.

Auch hier war es notwendig, erstmal die smb.conf anzupassen und danach
smbd und nmbd per Terminal neustarten.

Danach konnte ich in Aqemu auch vom Gast aus das Netlaufwerk am Router erreichen.

Demnach liegt das Problem beim Virt-Manager

Meinen Austausch-Ordner im Home-Verzeichnis des Wirtes konnte ich aber auch aus Aqemu heraus auf keinste Weise erreichen.

Posted: **Tue Mar 26, 2024 9:34 am**

Hallo loik,
ich muss schon sagen, dass ich etwas die Stirn runzle

Zum ersten, wo willst Du denn nun tatsächlich hin? Windows oder doch nicht Windows, oder eben Linux, aber eben nur als ISO-Live-System, wie am Anfang der Startpunkt war?
Netzwerkspeicher (=USB-Stick am Router) oder doch kein Netzwerkspeicher? Hattest Du mal für deine Bürozwecke als "ungünstig bzw. umständlich" verworfen, wenn ich mich recht erinnere.
Mein dritter Stirnrunzler ist subjektiv und betrifft Samba. Mit Samba zwischen Linux Daten austauschen, kann man machen, fällt aber in die Kategorie "warum einfach, wenn es auch umständlich geht". Samba ist nett, um auf Windowsfreigaben zuzugreifen, aber für "von Linux - nach Linux"? Naja, deine Entscheidung.

loik wrote: Tue Mar 26, 2024 5:50 am Demnach liegt das Problem beim Virt-Manager

Habe das jetzt nur überflogen, aber ziehst Du da nicht zu schnell Schlüsse? Mein Verdacht ist eher, das alte aqemu kann leider das alte SMB1-Protokoll noch, während virt-manager sich zu Recht weigert, solch ein altes und unsicheres Protokoll ohne Zwang anzuwenden?
Aber gut, werde mir das heute abend mal ansehen und nachspielen, um nicht bloss zu spekulieren.
Wäre aber trotzdem nett (und eigentlich auch notwendig), wenn Du genau sagst, was und wie Du es zum Schluss gern hättest (s. meine Fragen am Anfang). Sonst springen wir hier im Kreis rum, verzetteln uns und verlieren das Ziel aus den Augen. Von mir aus auch Samba, wenn es dir lieber ist ("der Kunde ist König"

), aber Klarheit wäre schon wichtig.

viele Grüsse gosia

Posted: **Tue Mar 26, 2024 10:19 am**

loik wrote: Sun Mar 24, 2024 12:26 pm Beim benutzen von Virt-manager will es mir einfach nicht gelingen, einen gemeinsamen Ordner zum Austausch zwischen Wirt und Gast zu nutzen.

Nun vielleicht solltest Du mal etwas stöbern
und nach virtio-fs "Treibern" in Qemu/KVM ausschau halten:
9p is alt aber geht noch gut, virtiofs/virtio-fs ist neu und sollte angeblich 10 mal schneller sein.

z.B. hier:
Share folder between Windows guest and Linux host using KVM
https://www.debugpoint.com/kvm-share-fo ... ows-guest/
und hier wie man das in WIndows einrchtet
https://virtio-fs.gitlab.io/howto-windows.html
hier auch was von den Leuten, die es wissen solten:
Sharing files with Virtiofs
https://libvirt.org/kbase/virtiofs.html

Kann Dir dabei selber nicht weiter helfen, weil ich Virtmanager nicht benutze.
Und meine qemu-Kommandzeile immer noch 9p-treiber enthält.
Müsste mir dann selber erstmal meinen Qemu-Starter nach diesen Hinweisen.
Running with virtiofs
https://virtio-fs.gitlab.io/howto-qemu.html
anpassen.
Glück Auf

Posted: **Tue Mar 26, 2024 10:57 am**

Moin,

also ich weiß, dass ich deinen Plan letztes Jahr oder so bei mir mal hinbekommen habe. Aber auch nur irgendwie mit Glück und viel herumgooglen. Und wegen diverser anderer Hakeleien mit Qemu/KVM und virt-manager habe ich mir auch dann keine gründlichen Notizen mehr gemacht.

Was ich noch weiß ist das Anlegen einer zusätzlichen Netzwerkbrücke, irgendeine manuelle Eingabe in virt-manager und ja, natürlich virtio als Netzwerktreiber nutzen.

Alles wenig intuitiv und in VirtualBox soviel einfacher gelöst, daher meine Frage:

loik wrote: Mon Mar 25, 2024 10:54 am Mein grundsätzlicher Wunsch ist es VirtualBox zu ersetzen.

Warum?

Posted: **Tue Mar 26, 2024 4:21 pm**

Hallo loik,
habe mich entschieden, doch erstmal eine kleine Schritt-für-Schritt-Anleitung für das anlegen von gemeinsamen Ordnern im virt-manager zu schreiben (für Host u. Gast beide Linux).
1. Gast darf nicht laufen.
2. In "Details" -> "Speicher auswählen" und rechts Häkchen bei "gemeinsamen Speicher aktivieren" setzen.
3. Klick auf "Gerät hinzufügen"
4. im neuen Fenster "Dateisystem" auswählen
5. als Treiber "virtiofs" wählen
6. mit "Quellpfad" den gewünschten Ordner auswählen, z.B. /home/USER/musik
7. "Zielpfad" (der Name ist etwas irreführend) einen beliebigen sprechenden Namen eintragen. Könnte bei meinem Beispiel einfach musik sein, aber auch "shared_music" o.ä. Der Name wird dann nur zum mounten benutzt.
8. Gast starten und darin einen passenden Ordner anlegen, z.B.

Code: Select all

 mkdir /home/USER/musik

9. zum Testen von Hand mounten:

Code: Select all

sudo mount -t virtiofs musik /home/USER/musik

der erste Name ist der in Punkt 7. gewählte Name für "Zielpfad", der zweite "Name" (mount-Pfad) das in 8. ngelegte Mount-Verzeichnis
im Dateimanager oder mit ls sollte jetzt das gemeinsame Verzeichnis musik im mount-Pfad auftauchen.
10. Um nicht jedesmal das mounten von Hand durchzuführen, im Gast einen entsprechenden Eintrag in der /etc/fstab vornehmen:

Code: Select all

musik  /home/USER/musik  virtiofs  defaults  0 0

oder allgemeiner zum anpassen:

Code: Select all

ZIELPFAD     /PFAD/ZUM/MOUNTPOINT   virtiofs   defaults    0 0

von jetzt an erscheint alles was im /PFAD/ZUM/MOUNTPOINT (Gast) oder Quellpfad (Host) editiert, angelegt, verändert, kurz gesagt, bearbeitet wurde, so verändert sowohl im Host als auch im Gast.

viele Grüsse gosia

Posted: **Wed Mar 27, 2024 4:55 pm**

Hallo loik,
hier die unverbindlichen Ergebnisse meiner versprochenen Verbindungsversuche zwischen Host und Gast mittels Samba:

Variante 1:
Ordner "Downloads" freigegeben mit vollem Zugriff, d.h. "andere Benutzer dürfen in diesem Ordner schreiben" + "Gastzugang erlauben".
Thunar sagt, dass dazu die Ordnerrechte geändert werden müssen und ob ich das möchte?
Antwort "ja", da dies verständlich ist -> Rechte vom Ordner werden auf 777 gesetzt -> voller Zugriff vom Host auf Gast-Ordner "Downloads" ist möglich, nach Eingabe des Userpasswortes.

Variante 2:
ditto mit Freigabe u. nur "andere Benutzer dürfen in diesem Ordner schreiben" (ohne "Gastzugang erlauben")

bei Variante 1 u. 2 sind die Dateien des freigegebenen Gast-Ordners im Host problemlos les- und schreibbar.

Variante 3:
diesmal nur "diesen Ordner freigeben" ->
hier wird es notwendig entweder die smb.conf zu bearbeiten oder (einfacher), das MX-Werkzeug "MX Samba Konfiguration" zu benutzen und dort im Tab "Benutzer" einen passenden User samt Passwort einzutragen.

Die Dateien im Ordner sind dann im Host lesbar, dort editierbar aber nur, wenn sie im Gast mindestens das Recht 666 (rw-rw-rw-) besitzen, was ich aber für kein Problem halte. Möglich, dass dies durch entsprechende Einträge in der fstab unnötig wird, dem bin ich aber nicht weiter nachgegangen.

Mein Fazit: wie ich schon sagte, ich halte smb für Linux -> Linux nach wie vor für überflüssig, finde aber dass die Benutzung (Freigabe/Rechte) mit Dateimanager und/oder "MX Samba Konfiguration" schnell und auch eingängig ist. Wer smb benutzen möchte (auch für die Kommunikation zwischen Host und Gast), dem empfehle ich Variante 2.

viele Grüsse gosia

Posted: **Wed Mar 27, 2024 5:37 pm**

Hallo Dennis-TW,
ehrlich gesagt halte ich die von dir verlinkte "Anleitung" für schrecklich. Wenn ich die am Anfang meiner Versuche mit virt-manager gelesen hätte wäre ich auch schreiend davongelaufen und hätte die Finger vom virt-manager gelassen.
Schrecklich auch deshalb, weil diese "Anleitung" den virt-manager (die GUI für QEMU/KVM), virsh (die Kommandozeile) und das manuelle Editieren der xml-Datei ohne nähere Erklärung und ohne Begründung durcheinander wirft.
Man kann die xml-Datei von Hand editieren wenn man möchte und vor allem nur, wenn man genau weiss, was man da tut (und wirklich nur dann). Ist aber bei Benutzung von virt-manager überflüssig (es wird dort auch davon abgeraten), weil der virt-manager diese Editierarbeit sozusagen unter der Haube selbst vornimmt.
Man kann auch virsh benutzen, wenn man sich gut damit auskennt, um eine VM zu starten oder sonstwie zu bearbeiten. Ein mächtiges Werkzeug, oder besser gesagt, ein sehr mächtiges Werkzeug, aber wozu die Kommandozeile bemühen, wenn es die GUI (=virt-manager) in 99,9% aller Fälle auch tut. Auch für das Anlegen eines neuen Network Bridge Devices (wenn man es denn tatsächlich braucht) würde der virt-manager ausreichen.

Damit Du mich nicht falsch verstehst, ich will dich oder andere keinesfalls vom benutzen des virt-managers überzeugen, sondern dem IMHO völlig abschreckenden Eindruck entgegentreten, dem man nach dem Lesen dieser schrecklichen "Anleitung" vom virt-manager bekommt.

viele Grüsse gosia

Posted: **Wed Mar 27, 2024 8:59 pm**

Keine Sorge, mir ist vollkommen bewusst, dass ich Qemu/KVM/virt-manager in all seinen Einzelheiten in keinster Weise verstanden habe.

Am Ende zählt aber das Ergebnis, oder?

Funktioniert hatte die Anleitung insofern, dass Windows 10 in virt-manager inkl. gemeinsamem Ordner lief. Also genau das, was loik wohl letztlich haben möchte. Mir fällt allerdings gerade auf, dass ich das auf meinem Arch System umgesetzt hatte, daher wahrscheinlich auch die "schreckliche" Anleitung und Rumrühren in Konfigdateien.

Nun war aber das Problem, dass ich für meine Arbeit in einer Windows 10 VM nicht nur einen, sondern drei gemeinsame Ordner brauche. In VirtualBox problemlos in der GUI möglich, in virt-manager auch?

Seis drum, letztlich kommt es drauf an, ob loik hier nochmal antwortet und seine Pläne umsetzen kann. Es ging mir halt nur darum, ob ein Wechsel von VirtualBox zu virt-manager z.B. wegen besserer Performance angedacht ist oder einfach nur so. Für meine Anforderungen sehe ich in der Performance zwischen VirtualBox und Qemu/KVM nämlich keinen Unterschied (auf schneller Hardware), daher gibt bei mir halt die Bedienung den Ausschlag.

Posted: **Thu Mar 28, 2024 4:45 am**

Hallo, Leute.

Vielen Dank für eure Unterstüzung.

Fehlix Links werden mir für mein zukünftiges Virt-Manager-Windows-Propjekt sicherlich hilfreich sein, ebenso wie Dennis Tips.

Und oha, Gosia, da warst du nun viel schneller als ich überhaupt lesen konnte.
Ich hatte gestern aber auch keine Zeit und heute nur begrenzt.
Reicht gerade mal zum Antworten, auf deinen Post #12.
( Kann sein, das etwas aus meiner Antwort durch deinen Post #13 obsolet ist.
Mir fehlt nun aber gerade Zeit und Konzentration, meinen Vorgeschriebenen Text abzugleichen und anzupassen.
Jedenfalls schon mal Dank und Respekt vor deiner umfangreichen Mühe.

Also zu Post #12
Gosia, deine Frage ( "... was ich denn nue igentlich will") , ist durch die Dokumentation meiner verzweifelten Versuche ( Pos #4, #6, #7, # 8 ) aufgekommen,
in denen ich probiert habe überhaupt eine Austauschmöglichkeit ( außer über USB ) von Gast zu Wirt hinzubekommen.

Aber nun habe ich von dir genau dass bekommen, was ich brauche:
Eine Schritt für Schritt Anleitung für Dullis, mit der sich des Themas "Geteilter Ordner" annähern lässt.

Bevor ich dieses Thema eröffnete, hatte ich ja bereits unzufriedenstellenden Erfolg mit einem geteilten Ordner.
Ich konnte ihn Erstellen, und im Gast einhängen.
( Zu diesem Zeitpunkt hatte ich die Option von Samba noch gar nicht in Erwägung gezogen und deshalb auch nicht versucht. Das kam für mich erst im Laufe dieses Themas auf. )

Ich konnte in diesem Verzeichnis vom Wirt aus Dateien und Ordner Platzieren.
Ich hatte es auch hinbekommen, vom Gast aus auf diese zuzugreifen.
Sogar in einem Ordner, der vom Wirt im Austausch-Verzeichnis angelegt wurde, konnte ich vom Gast aus wiederum einen Ordner oder eine Datei erstellen.
Nur eine vom Wirt erstellte Datei konnte ich vom Gast aus nicht bearbeiten.

Damit das soweit funktionieren konnte musste ich aber in beiden Systemen für das Austausch-Verzeichnis Allen Alles erlauben.

Trotzdem funktionierte der Austausch in umgekehrter Richtung vom Gast zum Wirt nicht.
Zwar konnte ich wie schon geschrieben vom Gast aus im Austausch-Verzeichnis Orner und Dateien Platzieren, auf diese aber vom Wit aus nicht zugreifen, weill sie gesperrt waren.
Nur dem Root vom Wirt war es möglich diese Dateien und Ordner zu öffnen.

Wenn ich mir zu diesen gesperrten Dateien und Ordner im Wirt die Berechtigungen anschaute, war zu sehen:
Besitzer = libvirt-qemu
Gruppe = libvirt-qemu

Aber Lesen Schreiben und Ausführen waren nur dem Benutzer erlaubt.
Für Gruppe und Andere waren gar keine Rechte vergeben.

Sowohl Gast als auch Wirt sind Jeweils eingetragen in den Gruppen kvm, libvirt, libvirt-clients, libvirt-qemu.

Wirt und Gast sind jeweil MX-21.3-64bit-xfce.

Jetzt hoffe ich, dass ich mit deiner Anleitung mehr Erfolg haben werde.

Ich vermute aber, dass ich heute nicht mehr dazu kommen werde, dass durchzuspielen.

Zumal ich bereits an den ersten Punkten deiner Anleitung im Wirt MX-21.3 scheitere.

2. In "Details" -> "Speicher auswählen" und rechts Häkchen bei "gemeinsamen Speicher aktivieren" setzen.
Das finde ich offensichtlich erstmal nicht:

Oder ist das gemeint ?

Tja, und wenn ich auf "Dateisystem Hinzufügen gehe, dann sieht das letztlich so aus:

In den Dropdowns der Optionen taucht kein Virtiofs auf.

Ist das vielleicht schon die Crux ?

Denn in den Paketquellen finde ich auch kein virtiofs.

Einzig ein Paket guestfsd wurde angeboten.

Obwohl guest schon vielversprechend klingt, war die Beschreibeung so "kann, muss aber nicht" dass ich es bisher noch nicht installiert habe.

Ist es das was fehlt.

Posted: **Thu Mar 28, 2024 10:54 am**

Only able to reply in English. Please run through your favorite translator.

loik wrote: Thu Mar 28, 2024 4:45 am Fehlix Links werden mir für mein zukünftiges Virt-Manager-Windows-Propjekt sicherlich hilfreich sein, ebenso wie Dennis Tips.

Don't put off trying the solution @fehlix proposes. virtiofs is the current procedure. I'm in the process of transitioning from VirtualBox to Virt-Manager (for Linux VMs, anyway) and shared folders was very high on my "must have" list. Turned out to be the easiest advanced feature to replicate. Moreover, Virt-Manager has the advantage over VBox that folders can be symlinked from a virtiofs mount into the VM's file system.

For what it's worth, here are my notes on how to set up the share:

Click Show Virtual Hardware (or View > Details). Memory > tick box to enable shared memory. Apply.
Click Add hardware (bottom-lef). Select Filesystem. Leave driver as virtiofs.
Browse to desired folder, in my case /data/files. Wouldn't work until I created a pool for /data (label = host-data).
Assign a label for target. I used data-files (the label of the partition mounted at /data/files).
Boot VM. Create folder in Home = Data. Run sudo mount -t virtiofs data-files $HOME/Data.
Check File Manager. Folders appear as expected. Able to click through to files, which open read-write (should, same uid).
Automount at boot. echo "data-files /home/pbear/Data virtiofs defaults,noatime,nofail 0 0" | sudo tee -a /etc/fstab

Hope that helps. Caveat: I'm new at Virt-Manager, so what I've come up might benefit from fine tuning. Does work as written, though.

References: GitLab, Debug blog, Debug WinVM, Biggs blog, Reddit, Heiko Sieger, OSTechNix, Device Tests, libvirt.org, kernel.org.

Edited to improve formatting and clarify a few points.

Posted: **Thu Mar 28, 2024 12:28 pm**

Hallo loik,
ganz kurz, stecke auch voll in den Ostervorbereitungen.
ich meine das hier:
Dateisystem + Treiber virtiofs

viele Grüsse gosia

Posted: **Fri Mar 29, 2024 8:33 am**

Hallo, pbear.
Hallo Gosia.

Eure Schritt für Schritt Anleitungen sind ja am Anfang absolut gleich.

Und so treffen sie auch zu, auf einen Wirt in MX-23.2.

Aber bei einem Wirt MX-21.3 gibt es weder die Option "gemeinsamen Speicher aktivieren",
noch gibt es in MX-21.3 die, auf Gosias Screenshot zu sehende, Auswahl zwischen virtofs oder virto-9p.

Man kann hier keine Treiber auswählen.
Es gibt nur die Option "Typ" aber da muss man sich begnügen mit dem default-Eintrag "mount".

Dafür gibt es hier aber zusätzlich eine Auswahl zu dem Punkt "Modus".
Hier steht zur Auswahl: "mapped", "squash" und "Hypervisor-Standard".

Ich habe mich bisher mit dem voreingestellten mapped versucht, da ich ohnehin nicht weiß, was was ist.

siehe meinen letzten Screenshot in Post #16

Posted: **Fri Mar 29, 2024 9:16 am**

Ihr erster Screenshot in Beitrag Nr. 16 ist der richtige Ort, um die Shared-Memory-Einstellung zu finden. Vielleicht war Virtiofs zum Zeitpunkt von MX-21 noch nicht vollständig implementiert. Das sehe ich in Debian 12 (Codebasis für MX-23).

Hinweis: Übersetzt von Herrn Google.
.

VirtMan Memory Shareing.png

Posted: **Fri Mar 29, 2024 9:24 am**

Hallo, pbear

Leider ist es genau so in MX-21.3 nicht der Fall.

Posted: **Fri Mar 29, 2024 10:34 am**

Hallo, Gosia.

Ich habe jetzt noch mal einen MX-snapshot von meinem Wirt-System MX-21.3-64bit-xfce erstellt.
Zuvor hatte ich alles mögliche an libvirt, qemu und Spice installiert und die entsprechenden Gruppen erstellt und eingetragen.
( nur guestfsd habe ich immer noch nicht installiert um herauszufinden, ob bei den bisherigen Versuchen der fehlende Neustart das Problem war. Ich kann bereits sagen, das es daran nicht lag. )

So habe ich nun also einen identisches ISO, welches keines Neustartes bedarf, als Gast.

Ich bin jetzt mal deiner Anleitung gefolgt.
Noch mal Angemerkt: die Option "gGemeinsamer Speicher" gibt es in MX-23 nicht.

Ich habe mein Ziel genannt "share"
( Danke für die Aufklärung. Ja eine Beschreibung wie "bitte vergeben Sie einen Namen für den zu erstellenden Ziel-Ordner im Gast" wäre vielleicht etwas eindeutiger )

Beim Mounten im Gast ging das so erst mal nicht:

Code: Select all

sudo mount -t virtiofs share /home/loik/share

wohl weil es kein virtiofs in MX-23 gibt.

Ich habe es abgewandelt.

Code: Select all

sudo mount -t 9p share /home/loik/share

Das hatte funktioniert.
Die schlichtheit deines Befehls gefällt mir besser, als alle, die ich zuvor versucht.

Dennoch war ich mit dieser Aktion exakt genau so weit, wie bevor ich dieses Thema eröffnete.

Was immer ich nun im Gast oder Wirt in diesem Ordner mache, ist synchron, auch im jeweils anderen System zu erkennen.
Aber das nützt mir nix, weil ich nicht einfach so auf die Einträge zugreifen darf, obwohl in den Rechteeinstellungen ( mit xfe vorgenommen ) allen alles erlaubt ist.

Platziere ich vom Gast aus einen neuen Ordner im Austauschverzeichnis, so ist es für den Wirt gesperrt, ausser für root usw. dass hatte ich ja alles schon mal versucht zu beschreiben.

Jedenfalls war diese nervige Enschränkung der Anlass zu diesem Thema.
Ich dachte, ich hätte etwas grundsätzlich falsch gemacht und wollte mich gerne zum Richtigen anleiten lassen.

Aber anscheinend liegt es gar nicht an mir, weil wohl etwas grundsätzlich falsch ist.

Leider konnte ich weder in den Test-Repos noch in den Backports eine aktuellere Version finden, als diese problematische 3.2.0

Posted: **Fri Mar 29, 2024 11:19 am**

Hallo loik,
oh, tut mir leid. Wenn man nicht alles doppelt und dreifach kontrolliert

In MX-21.3 funktioniert das bei mir auch nicht. Dort hat der virt-manager die Version 3.2.0 und in MX-23.2 ist er schon bei Version 4.1.0.
Die "shared memory"-Memory scheint es erst ab Version 4.0.0 zu geben:

Release 4.0.0 (March 02, 2022)
...
Add 'Enable shared memory' UI checkbox (Lin Ma)

https://github.com/virt-manager/virt-ma ... in/NEWS.md

vielleicht mal beim Maintainer nachfragen, ob ein Update auf Version >= 4.0.0 geplant ist.

viele Grüsse gosia

PS. Das mit deinen fehlenden Rechten ist mir im Moment unklar. komme aber leider gerade nicht dazu, dem nachzugehen.

Posted: **Fri Mar 29, 2024 12:49 pm**

Hallo, Gosia.

Danke für die Bestätigung.

Ich hatte derweil schon mal hier heruntergeladen
https://packages.debian.org/sid/virt-manager

https://packages.debian.org/sid/all/virtinst/download

das sind ja schön all-deb-Pakete für Version 4.1.0-3

virtinst musste zuerst installiert werden und hat dann gleich mal den alten installierten Virt-Manager deinstalliert.
Danach konnte ich den neuen Virt-Manager installieren.
Das lief alles ohne Probleme.

Jedenfalls sah das im Virt-Manager danach so aus, wie von euch beschrieben.
Aber "gemeinsamer Speicher" war zwar als Option angezeigt, aber leider ausgegraut.
Konnte ich keinen Haken setzen.

Da ich es in einem gebooteten MX-Snapshot testete, war natürlich kein Reboot möglich.
Ob das der Grund für die Optionssperre war.

Jedenfalls war die Nutzung eines gemensamen Ordners nun noch blödsinniger als mit dem alten Virt-Manager, weil der Gast nun noch nichteinmal Ordner und Dateien erstellen darf.
Auf vom Wirt erstellte Ordner oder Dateien kann der Gast auch nicht zugreifen. Alles verboten.

Bei der Installatin wurde das Paket python3-guestfs vorgeschlagen.

Das verlangt aber eine ganze Menge zusätzlichen Kladdaradatsch an Paketen.
Ich habe es bisher noch nicht installiert.

Code: Select all

$ sudo apt install python3-guestfs
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  attr db-util db5.3-util debootstrap kpartx ldmtool libafflib0v5 libdate-manip-perl libewf2
  libguestfs0 libhivex0 libldm-1.0-0 libtsk19 libvhdi1 libvmdk1 libyara4 lsscsi lzop scrub
  sleuthkit supermin uuid-runtime zerofree
Vorgeschlagene Pakete:
  ubuntu-archive-keyring squid-deb-proxy-client libguestfs-gfs2 libguestfs-jfs libguestfs-nilfs
  libguestfs-rescue libguestfs-rsync libguestfs-zfs autopsy mac-robber
Empfohlene Pakete:
  arch-test libguestfs-hfsplus libguestfs-reiserfs libguestfs-xfs
Die folgenden NEUEN Pakete werden installiert:
  attr db-util db5.3-util debootstrap kpartx ldmtool libafflib0v5 libdate-manip-perl libewf2
  libguestfs0 libhivex0 libldm-1.0-0 libtsk19 libvhdi1 libvmdk1 libyara4 lsscsi lzop
  python3-guestfs scrub sleuthkit supermin uuid-runtime zerofree
0 aktualisiert, 24 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
Es müssen 10,3 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 32,7 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]

EDIT:
Ich habe es dann mal gemacht.
Habe python3-guestfs und alles was vorgeschlagen und empfohlen wurde installiert ( bis auf ubuntu-keyring )

Hat nichts verändert.
Gemeinsamer-Speicher-Option blieb gesperrt.

dann habe ich mir noch mal die Abhängigkeiten zum heruntergeladenen Virt-Manager-Paket angeschaut.
https://packages.debian.org/sid/virt-manager

Zum Beispiel

Andere Pakete mit Bezug zu virt-manager
dep: dconf-gsettings-backend
Einfaches Konfigurations-Speichersystem - GSettings-Backend

Konfigurations-Speichersystem
Das klingt doch nach dem, was fehlt.

Vielleicht ......
Aber es verlangte weitere Abhängigkeiten und die wiederum weitere usw.
Ich wollte es aber wissen.

Nach Stunden VersuchUndIrrtum hatte ich endlich alles beisammen, das nichts weiter an Abhängigkeiten verlangt wurde und die Installation möglich war.

Sah dann aber so aus:

Code: Select all

sudo apt install ./gcc-14-base_14-20240315-1_amd64.deb ./libgcc-s1_14-20240315-1_amd64.deb ./libc6_2.37-15.1_amd64.deb ./libffi8_3.4.6-1_amd64.deb ./libdconf1_0.40.0-4+b2_amd64.deb ./libglib2.0-0_2.78.4-6_amd64.deb ./libglib2.0-0t64_2.78.4-6_amd64.deb ./dconf-gsettings-backend_0.40.0-4+b2_amd64.deb ./dconf-service_0.40.0-4+b2_amd64.deb
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Hinweis: »gcc-14-base« wird an Stelle von »./gcc-14-base_14-20240315-1_amd64.deb« gewählt.
Hinweis: »libgcc-s1« wird an Stelle von »./libgcc-s1_14-20240315-1_amd64.deb« gewählt.
Hinweis: »libc6« wird an Stelle von »./libc6_2.37-15.1_amd64.deb« gewählt.
Hinweis: »libffi8« wird an Stelle von »./libffi8_3.4.6-1_amd64.deb« gewählt.
Hinweis: »libdconf1« wird an Stelle von »./libdconf1_0.40.0-4+b2_amd64.deb« gewählt.
Hinweis: »libglib2.0-0« wird an Stelle von »./libglib2.0-0_2.78.4-6_amd64.deb« gewählt.
Hinweis: »libglib2.0-0t64« wird an Stelle von »./libglib2.0-0t64_2.78.4-6_amd64.deb« gewählt.
Hinweis: »dconf-gsettings-backend« wird an Stelle von »./dconf-gsettings-backend_0.40.0-4+b2_amd64.deb« gewählt.
Hinweis: »dconf-service« wird an Stelle von »./dconf-service_0.40.0-4+b2_amd64.deb« gewählt.
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  caja-common dh-strip-nondeterminism dwz featherpad-l10n galternatives gdebi-core gir1.2-caja-2.0
  gir1.2-keybinder-3.0 gir1.2-nm-1.0 gparted-common hwdata icoutils icu-devtools intltool-debian
  iw jq libarchive-zip-perl libavahi-common-data:i386 libbabeltrace1 libboost-regex1.74.0
  libbrotli-dev libcairo-script-interpreter2 libcapi20-3 libcolorhug2 libcrypt-dev libdatrie-dev
  libdbus-1-dev libdebhelper-perl libegl-dev libegl1-mesa-dev libepoxy-dev libept1.6.0 libffi-dev
  libfile-stripnondeterminism-perl libfm-qt-l10n libfreerdp2-2 libfribidi-dev libgail-3-0
  libgl-dev libgles-dev libgles1 libglvnd-dev libglx-dev libgraphite2-dev libhandy-0.0-0
  libharfbuzz-gobject0 libice-dev libiptcdata0 libjq1 libkf5screen-bin libkf5screen7
  liblxqt-globalkeys0 liblxqt-l10n libmbim-glib4 libmbim-proxy libmediainfo0v5 libmm-glib0 libndp0
  libnm0 libnma-common libnma0 libnsl-dev libonig5 libopengl-dev libosinfo-bin libpango1.0-0
  libpcre16-3 libpcre2-posix2 libpcre32-3 libpixman-1-dev libpthread-stubs0-dev libqmi-glib5
  libqmi-proxy libqt5xdgiconloader3 libqwt-qt5-6 libsepol1-dev libsm-dev libsub-override-perl
  libteamdctl0 libthai-dev libtinyxml2-8 libtirpc-dev libvirt-daemon-config-network
  libvirt-daemon-config-nwfilter libwayland-bin libwayland-dev libwinpr2-2 libx11-dev libxau-dev
  libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev
  libxdmcp-dev libxext-dev libxfixes-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev
  libxrender-dev libxtst-dev libzen0v5 linux-headers-5.10.0-10-common
  linux-headers-5.10.0-11-common linux-headers-5.10.0-12-common linux-headers-5.10.0-13-common
  linux-headers-5.10.0-14-common linux-headers-5.10.0-15-common linux-headers-5.10.0-16-common
  linux-headers-5.10.0-17-common linux-headers-5.10.0-18-common linux-headers-5.10.0-19-common
  linux-headers-5.10.0-20-common linux-headers-5.10.0-21-common linux-headers-5.10.0-22-common
  linux-headers-5.10.0-23-common linux-headers-5.10.0-25-common linux-headers-5.10.0-26-amd64
  linux-headers-5.10.0-26-common linux-headers-5.10.0-27-amd64 linux-headers-5.10.0-27-common
  linux-image-5.10.0-26-amd64 linux-image-5.10.0-27-amd64 lximage-qt-l10n lxqt-config-l10n
  lxqt-notificationd-l10n lxqt-policykit-l10n lxqt-powermanagement-l10n lxqt-session-l10n
  lxqt-sudo-l10n lxqt-system-theme lxqt-themes mate-desktop pango1.0-tools po-debconf pptp-linux
  python-caja-common python3-caja python3-mediainfodll python3-natsort qlipper vhba-dkms
  wayland-protocols wine-gecko2.47.2 wine-gecko2.47.2:i386 wine-mono7.0.0 wine-staging-amd64
  wpasupplicant x11proto-dev x11proto-input-dev x11proto-randr-dev x11proto-record-dev
  x11proto-xext-dev x11proto-xinerama-dev xorg-sgml-doctools xsettingsd xtrans-dev
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert:
  systemd-sysv
Vorgeschlagene Pakete:
  glibc-doc locales libnss-nis libnss-nisplus low-memory-monitor
Empfohlene Pakete:
  libnss-systemd
Die folgenden Pakete werden ENTFERNT:
  alien blueman build-essential caja caja-admin caja-mediainfo caja-rename cdemu-client
  cdemu-daemon cgmanager colord dbus-user-session dconf-cli debhelper dh-autoreconf featherpad g++
  g++-10 gcdemu gdebi gnome-boxes gnome-keyring gparted gufw gvfs-bin hardinfo
  kde-servicemenu-rootactions lib32gcc-s1 lib32stdc++6 libaom0:i386 libasound2:i386
  libasound2-plugins:i386 libasyncns0:i386 libatk-bridge2.0-dev libatk1.0-dev libatspi2.0-dev
  libavahi-client3:i386 libavahi-common3:i386 libavcodec58:i386 libavresample4:i386
  libavutil56:i386 libblkid-dev libblkid1:i386 libbrotli1:i386 libbsd0:i386 libburner-media3-dev
  libbz2-1.0:i386 libc-bin libc-dev-bin libc6:i386 libc6-dev libc6-i386 libcairo-gobject2:i386
  libcairo2:i386 libcairo2-dev libcap2:i386 libcapi20-3:i386 libcgmanager0 libcodec2-0.9:i386
  libcom-err2:i386 libcrypt1:i386 libcurl3-gnutls:i386 libcurl4:i386 libdatrie1:i386
  libdav1d4:i386 libdb5.3:i386 libdbus-1-3:i386 libdeflate0:i386 libdrm2:i386 libdw1:i386
  libelf-dev libelf1:i386 libexif12:i386 libexpat1:i386 libexpat1-dev libffi7:i386 libflac8:i386
  libfm-qt8 libfontconfig-dev libfontconfig1:i386 libfontconfig1-dev libfreetype-dev
  libfreetype6:i386 libfreetype6-dev libfribidi0:i386 libgcc-s1:i386 libgcrypt20:i386 libgd3:i386
  libgdbm-compat4:i386 libgdbm6:i386 libgdk-pixbuf-2.0-0:i386 libgdk-pixbuf-2.0-dev
  libglib2.0-0:i386 libglib2.0-bin libglib2.0-dev libglib2.0-dev-bin libgmp10:i386
  libgnutls30:i386 libgomp1:i386 libgpg-error0:i386 libgphoto2-6:i386 libgphoto2-port12:i386
  libgraphite2-3:i386 libgsm1:i386 libgssapi-krb5-2:i386 libgstreamer-plugins-base1.0-0:i386
  libgstreamer1.0-0:i386 libgtk-3-dev libharfbuzz-dev libharfbuzz0b:i386 libhogweed6:i386
  libicu-dev libicu67:i386 libid3-3.8.3-dev libid3tag0-dev libidn2-0:i386 libieee1284-3:i386
  libjack-jackd2-0:i386 libjbig0:i386 libjpeg62-turbo:i386 libk5crypto3:i386 libkeyutils1:i386
  libkrb5-3:i386 libkrb5support0:i386 liblcms2-2:i386 libldap-2.4-2:i386 libltdl7:i386 liblxqt0
  liblz4-1:i386 liblzma5:i386 libmd0:i386 libmount-dev libmount1:i386 libmp3lame0:i386
  libncurses6:i386 libnettle8:i386 libnghttp2-14:i386 libnih-dbus1 libnih1 libnsl2:i386
  libnspr4:i386 libnss3:i386 libnuma1:i386 libogg0:i386 libopenal1:i386 libopenjp2-7:i386
  libopus0:i386 liborc-0.4-0:i386 libp11-kit0:i386 libpango-1.0-0:i386 libpango1.0-dev
  libpangocairo-1.0-0:i386 libpangoft2-1.0-0:i386 libpcap0.8:i386 libpci3:i386 libpcre2-8-0:i386
  libpcre2-dev libpcre3:i386 libpcre3-dev libperl5.32:i386 libpixman-1-0:i386 libpng-dev
  libpng16-16:i386 libpoppler-glib8:i386 libpoppler102:i386 libpsl5:i386 libpulse0:i386 libqt5xdg3
  libreoffice-l10n-de librsvg2-2:i386 librtmp1:i386 libsamplerate0:i386 libsane1:i386
  libsasl2-2:i386 libsasl2-modules-db:i386 libselinux1:i386 libselinux1-dev libsensors5:i386
  libshine3:i386 libsnappy1v5:i386 libsndfile1:i386 libsndio7.0:i386 libsnmp40:i386 libsoxr0:i386
  libspeex1:i386 libsqlite3-0:i386 libssh2-1:i386 libssl1.1:i386 libstdc++-10-dev libstdc++6:i386
  libswresample3:i386 libsystemd0:i386 libtasn1-6:i386 libthai0:i386 libtheora0:i386 libtiff5:i386
  libtinfo6:i386 libtirpc3:i386 libtool libtwolame0:i386 libtxc-dxtn0:i386 libudev1:i386
  libunistring2:i386 libunwind8:i386 libusb-1.0-0:i386 libuuid1:i386 libva-drm2:i386
  libva-x11-2:i386 libva2:i386 libvdpau1:i386 libvirt-daemon-system libvorbis0a:i386
  libvorbisenc2:i386 libvpx6:i386 libwavpack1:i386 libwebp6:i386 libwebpmux3:i386 libwrap0:i386
  libx11-6:i386 libx264-160:i386 libx265-192:i386 libxau6:i386 libxcb-render0:i386
  libxcb-shm0:i386 libxcb1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxft-dev
  libxml2:i386 libxpm4:i386 libxrender1:i386 libxvidcore4:i386 libzstd1:i386 libzvbi0:i386 linssid
  linux-headers-5.16.0-18.1-liquorix-amd64 linux-headers-liquorix-amd64 locales lximage-qt
  lxqt-config lxqt-notificationd lxqt-policykit lxqt-powermanagement lxqt-qtplugin lxqt-session
  lxqt-sudo modemmanager mx-apps mx-locale mx-pkexec mx-usb-unmounter network-manager
  network-manager-gnome network-manager-openconnect network-manager-openconnect-gnome
  network-manager-openvpn network-manager-openvpn-gnome network-manager-pptp network-manager-vpnc
  ocl-icd-libopencl1:i386 pcmanfm-qt pithos playonlinux policykit-1 policykit-1-gnome q4wine qps
  seahorse skypeforlinux synaptic systemd-shim sysvinit-core teamviewer tlp tlp-rdw tracker
  tracker-extract tracker-miner-fs uuid-dev wine-staging wine-staging-i386:i386 winehq-staging
  winetricks zlib1g:i386 zlib1g-dev
Die folgenden NEUEN Pakete werden installiert:
  gcc-14-base libffi8 libglib2.0-0t64 systemd-sysv
Die folgenden Pakete werden aktualisiert (Upgrade):
  dconf-gsettings-backend dconf-service libc6 libdconf1 libgcc-s1 libglib2.0-0
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
  libc-bin libcrypt1:i386 libc6:i386 (wegen libcrypt1:i386) libgcc-s1:i386
6 aktualisiert, 4 neu installiert, 286 zu entfernen und 3 nicht aktualisiert.
Es müssen noch 112 kB von 4.602 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 1.651 MB Plattenplatz freigegeben.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
 ?]

Ich hätte es auch ohne die lobenswert, ausdrückliche Warnung von APT nicht gemacht.
Also brav abgebrochen.

Erfolgreich gescheitert

Posted: **Fri Mar 29, 2024 3:32 pm**

Irgendwie muss der Feiertag ja rumzukriegen sein .....

Jetzt habe ich mal ein vollinstalliertes MX-23.2-64bit-xfce als Wirt hochgefahren.

Ja, hier sind alle Einstellungen wie in der Anleitung beschrieben zu finden.
Ich kann den Haken setzen für gemeinsamer Speicher.

Ich kann auswählen zwischen virtiofs und virtio-9p, wie auf Gosias screenshot zusehen.
Theoretisch, geht das.

Bei der Wahl von von Virtiofs bekomme ich beim Starten der Maschine die Meldung, dass kein zufriedenstellender virtiofsd zu finden sei. Startet also nicht.
Fehlt wohl ein Paket.
Welches ?

Also doch wieder 9p.

Damit habe ich dann anschließend jedenfalls wieder dasselbe Rechteproblem wie zuvor mit der alten Virt-Manager-Version von MX-21.3.

Harrrgh ....

Warum ist das bei euch nicht so ?

Posted: **Fri Mar 29, 2024 6:27 pm**

Hallo loik,
ja, warum ist das bei dir so?
Da fällt mir nichts dazu ein. Ich wüsste nicht, dass ich für virtiofs was spezielles gemacht hätte. Bin auf den gemeinsamen Speicher auch erst durch deine Anfrage gekommen, vorher habe ich das nicht gebraucht.
Ich weiss nur, dass bei mir virtiofsd hier liegt:

Code: Select all

/usr/lib/qemu/virtiofsd

aber woher das kommt, ist mir unklar.

viele Grüsse gosia

Posted: **Fri Mar 29, 2024 7:24 pm**

Hallo loik,
ist qemu-system-common installiert?

viele Grüsse gosia

Posted: **Sat Mar 30, 2024 3:11 am**

Hallo, Gosia.

ist qemu-system-common installiert?

Ja, ist installiert.

Ich weiss nur, dass bei mir virtiofsd hier liegt:

/usr/lib/qemu/virtiofsd

Bei mir ist /usr/lib/qemu/ nur zu finden:
qemu-bridge-helper
vhost-user-gpu
virtfs-proxy-helper

Kein virtiofsd.

Ist bei dir installiert, guestfsd ?

Mir fiel dann ein , dass du ja nur mit SysVenit arbeitest.

Ich hatte aber für die Festinstallierten Wirte MX-21.3 und MX-23.2 SystemD laufen, wegen meiner USB-Monitore.

Habe es dann bei Wirt MX-23.2 mal mit SysVenit versucht.
Das machte gar keinen Unterschied.

Weil virtiofsd ja nun mal nicht vorhanden ist.

Ach ja, und bei dir Klappt der Austausch uneingeschränkt ?

Wenn du im Gast, bzw. vom Gast aus, Dateien Und Ordner im Austausch-Verzeichnis platzierst, dann kannst du auf diese vom Wirt aus Zugreifen, bearbeiten, ergänzen, erweitern ?

Bzw. auch umgekehrt ?

Auch wenn du Virtio-9p als Treiber wählst ?

Hier habe ich anscheinend eine mögliche Lösung gefunden, wie ich mit dem veralteten Virt-Manager in MX-21.3 mit 9p die Rechteprobleme behen kann.
Für die mögliche Lösung bis mindestens Seiten-Mitte scrollen.
https://askubuntu.com/questions/548208/ ... ion-denied

Aber ich bin erschöpft.
Das nachzustellen, muss ich verschieben.

Anbei.
Wie setzt man die Rechte per Terminal auf 777.

Bzw. wie kontrolliere ich, welchen Wert ein Verzeichnis hat.

Ich kann es ja nur über die Datei-Manager, und die sind aber nur rudimentär.

Außer XFE.
Trotzdem kann ich nicht erkennen, welchen Wert meine Einstellungen ergeben, hilflos, geratenen in XFE gemacht habe.

Posted: **Sat Mar 30, 2024 6:55 am**

Hallo loik,
komme erst nach Ostern dazu, dass alles zu testen und auch zu beantworten. Nur kurz:
guestfsd -> nicht installiert
mit virtio-9p -> deine Rechteprobleme
virtiofs -> lesen u. schreiben in beide Richtungen möglich (Host <-> Guest), d.h. Datei im Gast erstellt, kann im Host bearbeitet werden und erscheint so bearbeitet im Gast u. umgekehrt. Habe ich aber nur zweimal mit einer Datei getest. Ausführliche Tests nach Ostern.

Rechte:
https://www.stationx.net/linux-file-per ... eat-sheet/
https://www.ionos.de/digitalguide/serve ... mit-chmod/

viele Grüsse gosia

Posted: **Sat Mar 30, 2024 11:54 pm**

Aus Neugier habe ich den Virt-Manager in meiner MX-23-Testbox installiert, der sonst größtenteils so installiert ist (bis auf Updates). Wenn es dich tröstet, ich bin auf ein Problem nach dem anderen gestoßen, was nicht meine Erfahrung mit Debian war. Die meisten davon wurden gelöst, bis auf eines, das Sie nicht erwähnt haben: „Namespace SpiceClientGtk nicht verfügbar“, das das Öffnen der VM verhinderte. Also habe ich es noch einmal versucht, einschließlich --install-recommends, was in Debian, aber nicht in MX die Standardeinstellung ist. Das hat gut funktioniert (die anderen Probleme wurden bereits gelöst), die VM wurde gestartet und ich hatte keine Probleme, den freigegebenen Ordner gemäß den zuvor veröffentlichten Anweisungen zu aktivieren. Wenn Sie ausprobieren möchten, was bei mir funktioniert hat, war dies der Installationsbefehl:

Code: Select all

sudo apt install --install-recommends virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system

Als Referenz sehen Sie hier den Unterschied zwischen ohne und mit Empfehlungen:

Code: Select all

pbear@mx-23-xfce:~
$ sudo apt install virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system
[sudo] password for pbear:         
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libpango1.0-0
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-vte-2.91 ipxe-qemu libcacard0 libcapstone4 libdaxctl1 libexecs0 libfdt1 libgtk-vnc-2.0-0
  libgvnc-1.0-0 libibverbs1 libndctl6 libosinfo-1.0-0 libosinfo-l10n libpmem1 librdmacm1 libslirp0 libspice-server1 libssh-4 libusbredirparser1 libvdeplug2
  libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-system-sysv libvirt-glib-1.0-0
  libvirt0 osinfo-db python3-charset-normalizer python3-libvirt python3-libxml2 python3-requests qemu-system-common qemu-system-data seabios usb.ids virtinst
Suggested packages:
  libvirt-clients-qemu libvirt-login-shell libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-iscsi-direct libvirt-daemon-driver-storage-rbd
  libvirt-daemon-driver-storage-zfs numad apparmor auditd open-iscsi systemtap zfsutils python3-cryptography python3-openssl python3-socks python-requests-doc vde2
  gir1.2-secret-1 python3-guestfs virt-viewer python3-argcomplete
Recommended packages:
  ibverbs-providers libvirt-daemon-driver-lxc libvirt-daemon-driver-vbox libvirt-daemon-driver-xen libxml2-utils netcat-openbsd swtpm swtpm-tools mdevctl
  libvirt-glib-1.0-data libvirt-l10n qemu-system-gui ovmf qemu-block-extra gir1.2-ayatanaappindicator3-0.1 | gir1.2-appindicator3-0.1 gir1.2-spiceclientglib-2.0
  gir1.2-spiceclientgtk-3.0 virt-viewer
The following NEW packages will be installed:
  gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-vte-2.91 ipxe-qemu libcacard0 libcapstone4 libdaxctl1 libexecs0 libfdt1 libgtk-vnc-2.0-0
  libgvnc-1.0-0 libibverbs1 libndctl6 libosinfo-1.0-0 libosinfo-l10n libpmem1 librdmacm1 libslirp0 libspice-server1 libssh-4 libusbredirparser1 libvdeplug2
  libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-sysv
  libvirt-glib-1.0-0 libvirt0 osinfo-db python3-charset-normalizer python3-libvirt python3-libxml2 python3-requests qemu-system-common qemu-system-data qemu-system-x86
  qemu-utils seabios usb.ids virt-manager virtinst
0 upgraded, 45 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.0 MB of archives.
After this operation, 115 MB of additional disk space will be used.

pbear@mx-23-xfce:~
$ sudo apt install --install-recommends virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libpango1.0-0
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  gir1.2-ayatanaappindicator3-0.1 gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 gir1.2-vte-2.91
  gnutls-bin ibverbs-providers ipxe-qemu libcacard0 libcapstone4 libdaxctl1 libexecs0 libfdt1 libfmt9 libgfapi0 libgfrpc0 libgfxdr0 libglusterfs0 libgnutls-dane0
  libgtk-vnc-2.0-0 libgvnc-1.0-0 libibverbs1 libiscsi7 libndctl6 libosinfo-1.0-0 libosinfo-l10n libphodav-3.0-0 libphodav-3.0-common libpmem1 librados2 librbd1 librdmacm1
  libslirp0 libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libspice-server1 libssh-4 libtpms0 libunbound8 libusbredirhost1 libusbredirparser1 libvdeplug2
  libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-lxc libvirt-daemon-driver-qemu
  libvirt-daemon-driver-vbox libvirt-daemon-driver-xen libvirt-daemon-system-sysv libvirt-glib-1.0-0 libvirt-glib-1.0-data libvirt-l10n libvirt0 libxencall1
  libxendevicemodel1 libxenevtchn1 libxenforeignmemory1 libxengnttab1 libxenhypfs1 libxenmisc4.17 libxenstore4 libxentoolcore1 libxentoollog1 libxml2-utils mdevctl
  netcat-openbsd osinfo-db ovmf python3-charset-normalizer python3-libvirt python3-libxml2 python3-requests qemu-block-extra qemu-system-common qemu-system-data
  qemu-system-gui seabios spice-client-glib-usb-acl-helper swtpm swtpm-libs swtpm-tools usb.ids virt-viewer virtinst
Suggested packages:
  libvirt-clients-qemu libvirt-login-shell libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-iscsi-direct libvirt-daemon-driver-storage-rbd
  libvirt-daemon-driver-storage-zfs numad apparmor auditd open-iscsi systemtap zfsutils python3-cryptography python3-openssl python3-socks python-requests-doc vde2
  trousers gir1.2-secret-1 python3-guestfs python3-argcomplete
The following NEW packages will be installed:
  gir1.2-ayatanaappindicator3-0.1 gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 gir1.2-vte-2.91
  gnutls-bin ibverbs-providers ipxe-qemu libcacard0 libcapstone4 libdaxctl1 libexecs0 libfdt1 libfmt9 libgfapi0 libgfrpc0 libgfxdr0 libglusterfs0 libgnutls-dane0
  libgtk-vnc-2.0-0 libgvnc-1.0-0 libibverbs1 libiscsi7 libndctl6 libosinfo-1.0-0 libosinfo-l10n libphodav-3.0-0 libphodav-3.0-common libpmem1 librados2 librbd1 librdmacm1
  libslirp0 libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libspice-server1 libssh-4 libtpms0 libunbound8 libusbredirhost1 libusbredirparser1 libvdeplug2
  libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-lxc libvirt-daemon-driver-qemu
  libvirt-daemon-driver-vbox libvirt-daemon-driver-xen libvirt-daemon-system libvirt-daemon-system-sysv libvirt-glib-1.0-0 libvirt-glib-1.0-data libvirt-l10n libvirt0
  libxencall1 libxendevicemodel1 libxenevtchn1 libxenforeignmemory1 libxengnttab1 libxenhypfs1 libxenmisc4.17 libxenstore4 libxentoolcore1 libxentoollog1 libxml2-utils
  mdevctl netcat-openbsd osinfo-db ovmf python3-charset-normalizer python3-libvirt python3-libxml2 python3-requests qemu-block-extra qemu-system-common qemu-system-data
  qemu-system-gui qemu-system-x86 qemu-utils seabios spice-client-glib-usb-acl-helper swtpm swtpm-libs swtpm-tools usb.ids virt-manager virt-viewer virtinst
0 upgraded, 92 newly installed, 0 to remove and 0 not upgraded.
Need to get 58.7 MB of archives.
After this operation, 204 MB of additional disk space will be used.

Ich kann nicht versprechen, dass die Installation der Empfehlungen das Problem lösen wird, aber es ist logisch, es zu versuchen. Viel Glück.

Posted: **Sun Mar 31, 2024 2:52 am**

Hallo, Gosia.

Danke für die Bestätigungen zu guestfsd und zu den Rechteproblemen mit 9p.

Also, ist mein Hauptproblem in MX-23 das Fehlen von virtiofsd und die Frage, wieso ? und wie zu korrigieren ?

Rechte:
Lehre einem Menschen das Fischen.
Finde ich gut und richtig.
Ist für mich aber so komplex, das ich aus all den Informationen gar nicht herausfinde, wie rum ich die Angel halten muss.

Gefunden habe ich

Code: Select all

ls -l

Habe mit Thunar den entsprechenden Ordner geöffnet und dann in die Fensterfläche geklickt und gewählt "Terminal hier öffnen".
Dann habe ich dort eingegeben

Code: Select all

ls -l

und die Kryptischen rwx-Auskünfte erhalten, die ich trotz der Anleitungen erst mal noch nicht in der Lage bin zuzuordnen bzw mir in den Zahlenkode zu übersetzen.
( Das ich weiß, dass r für Lesen, w für Schreiben und x für Ausführen steht, ist eine Grundvorraussetzung, ja, hilft mir aber bisher noch nicht beim entschlüsseln bzw übersetzen in Zahlenwerte )
Einen Befehl, der die bestehenden Rechte im Zahlenwert ausgibt, konnte ich nicht finden.

Erst mal ein schöne und entspannte Ostertage.

Hallo, pbear.
Dir ebenfalls danke für deine Tests.

Ja, das ist nicht nur bei Virt-Manager eine Qual, für den User, herauszufinden, welche Pakete relevant sind und welche unnötiger Ballast.

Synaptic scheint ja schon mal grundsätzlich zwingende Abhängigkeiten zu berücksichtigen und installiert die dann auf Zustimmung mit.

In MxPi kann man einen Haken setzen "Auch empfohlene Pakete installieren".

Und in MX-Tweak kann man unter "Sonstiges" per Hakensetzen festlegen "apt installiert zusätzlich empfohlene Pakete als Abhängigkeiten"

Und wenn man sich in MxPi eine Anwendung aus den "Beliebten" heraussucht, habe ich den Eindruck, dass automatisch immer der ganze Wust an Abhängigkeiten mitgeliefert wird.
Meisten passt das.
Aber manchmal ist es wohl doch auch unvollständig.

Aus deinen Installationsauflistungen hätte ich gerne heraus gelesen, was welches das speziell fehlende Paket für virtiofsd sein könnte.
Ist mir aber nicht gelungen.

Ich war natürlich sofort gewillt trotzdem einfach

Code: Select all

sudo apt install --install-recommends virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system

laufen zu lassen.

ABER

Code: Select all

$ sudo apt install --install-recommends virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
virt-manager ist schon die neueste Version (1:4.1.0-2).
qemu-system-x86 ist schon die neueste Version (1:8.2.1+ds-1~bpo12+1).
qemu-utils ist schon die neueste Version (1:8.2.1+ds-1~bpo12+1).
libvirt-daemon-system ist schon die neueste Version (9.0.0-4+mx23+1).
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  libpango1.0-0 linux-headers-6.1.0-17-amd64 linux-headers-6.1.0-17-common
  linux-image-6.1.0-17-amd64
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Es fehlt anscheinend nichts.

Warum nur existiert bei mir virtiofsd nicht ?
( jedenfalls nicht in /usr/lib/qemu )

Posted: **Sun Mar 31, 2024 7:39 am**

Hallo, Dennis-TW.

Ich bin bisher noch gar nicht dazu gekommen, mich mit deinen beiden Posts genauer zu befassen.

Seis drum, letztlich kommt es drauf an, ob loik hier nochmal antwortet und seine Pläne umsetzen kann. Es ging mir halt nur darum, ob ein Wechsel von VirtualBox zu virt-manager z.B. wegen besserer Performance angedacht ist oder einfach nur so. Für meine Anforderungen sehe ich in der Performance zwischen VirtualBox und Qemu/KVM nämlich keinen Unterschied (auf schneller Hardware), daher gibt bei mir halt die Bedienung den Ausschlag.

Da stimme ich zu.
Wenn es keine Leistungseinschränkungen gibt, dann braucht man nicht den Komfort von VB zu verschmähen.
Ich habe aber auch Einiges an Hardware, wo VB gar nicht mehr will oder gar 32bit-Wirt-Systeme.
Da brauche ich es jeweils auch nicht mit win10 als Gast versuchen, auch nicht in Virt-Manager. Ist klar.
Aber da würde ich sehr wohl auch mal das ein oder andere Linux-ISO starten wollen.

Deshalb brauche ich Austausch-Verzeichnisse, die für bzw. in/mit jedem System funktionieren.

Virt-Manager macht einen derart ausgereiften Eindruck, dass es doch auch hier entsprechend möglich sein sollte.
Mehrere Austausch-Ordner scheint mir nicht das Problem zu sein, soweit von mir zu erkennen.
Mein Problem bleibt die Rechtevergabe bei 9p bzw. das Fehlen von virtiofsd.

Mit Windows als Gast im Virt-Manager werde ich mich befassen, wenn Austausch-Verzeichnisse in Kombination aus Linux in Linux problemlos zu händeln sind.

Zu deinem Link:
Auch ohne Gosias Kritik, hätte ich mich nicht daran versucht.
Zu komplex für mein schlichtes Gemüt.

Aber trotzdem danke, für diese Option.

Posted: **Sun Mar 31, 2024 11:54 am**

loik wrote: Sun Mar 31, 2024 2:52 am Warum nur existiert bei mir virtiofsd nicht ?

Ich weiß es nicht. Dir ist klar, dass virtiosd eine Datei ist, oder? Die Frage wäre also: Welches Paket bringt diese Datei mit?

Ihr Frust ist verständlich. Ich habe das Erlernen von QEMU viele Jahre lang aufgeschoben, da ich aus der Lektüre von Tutorials wusste, dass es schwierig sein würde. OTOH, sobald es installiert und ausgeführt ist, ist es meiner Meinung nach einfacher zu verwenden und zu warten als VirtualBox. Tatsächlich habe ich, wie in meinem ersten Beitrag erwähnt, beschlossen, darauf als mein Hauptvirtualisierungstool umzusteigen, mit Ausnahme der Beibehaltung von VBox für für eine Win10-VM (bessere Grafikunterstützung, wenn man keine separate GPU zum Durchleiten hat) und älteren VMs (nicht). eine Konvertierung lohnt sich, wenn ich VBox installieren möchte). Allerdings ist es eine Ihrer Optionen, „Macht nichts“ zu sagen und bei VBox zu bleiben. Nur Sie können sagen, ob sich die Weiterentwicklung mit Virt-Manager lohnt.

Bitte bedenken Sie, dass es für uns nicht möglich ist, dies aus der Ferne zu diagnostizieren, was für mich doppelt schwierig ist, da ich alles (in beide Richtungen) durch einen Übersetzer laufen lassen muss. Fehler, die Sie erhalten). Ich möchte erwähnen, dass apt Sie in diesem Fall möglicherweise im Stich gelassen hat. Manchmal stolpert es über die Neuinstallation von Paketen mit sehr vielen Abhängigkeiten; Ich habe oft gesehen, dass dies Leuten in Foren mit Wine (dem Windows-Emulator) hilft. Nachdem mein erster Versuch fehlgeschlagen war (ohne „empfohlen“), habe ich versucht, „mit“ neu zu installieren. Angeblich läuft es, aber apt hat die „Empfehlungen“ tatsächlich nicht installiert; Virt-Manager gelöscht und von Grund auf neu installiert; „Empfehlungen“ wurde immer noch nicht installiert. Das Einzige, was funktionierte, war das Zurücksetzen des Systems mit Timeshift. Die „mit Empfehlungen“-Installation verlief sauber, der Virt-Manager funktionierte wie erwartet und der freigegebene Ordner funktionierte. Um zu bestätigen, dass ich beim ersten Mal keinen Fehler gemacht hatte, kehrte ich zu Timeshift zurück und installierte virt-manager ohne „Empfehlungen“. ging schnell, genauso wie die anderen Probleme, aber das gleiche Ergebnis („SpiceClientGtk nicht verfügbar“).

Wenn Sie Timeshift nicht installiert haben, empfehle ich Ihnen, eine Neuinstallation des Systems durchzuführen. Das dauert weniger lange als der Versuch, den Status Ihres Paketuniversums herauszufinden und festzustellen, ob die „Empfehlungen“ von VirtMan vorhanden sind. Installieren Sie entweder Timeshift oder sichern Sie das System mit einer anderen Methode. Versuchen Sie dann erneut, virt-manager zu installieren, und zwar mit meiner Befehlsform (eigentlich nicht meiner, da ich sie von einem erfahrenen QEMU-KVM-Benutzer im Debian-Forum erhalten habe).

------------

Don't know. You realize virtiosd is a file, right? So the question would be, which package brings in that file?

Your frustration is understandable. I put off learning QEMU for many years, as I knew from reading tutorials that it would be difficult. OTOH, once installed and running, I find it's easier to use and maintain than VirtualBox. Indeed, as mentioned in my first post, I've decided to switch to it as my main virtualization tool, except retaining VBox for a Win10 VM (better graphics support if one doesn't have a separate GPU to pass through) and legacy VMs (not worth converting if I'm going to have VBox installed). That said, saying "never mind" and staying with VBox is one of your options. Only you can say whether pushing forward with Virt-Manager is worth the effort.

Please bear in mind, it's not feasible for us to diagnose this at a distance, for me doubly difficult as I have to run everything (both ways) through a translator. Will mention, apt may have failed you in this case. It sometimes stumbles over reinstalling packages with very-many dependencies; I've seen this often helping people on forums with Wine (the Windows emulator). After my first trial failed (without 'recommends'), I tried reinstalling 'with'. Claimed to run, but apt didn't in fact install the 'recommends'; purged virt-manager and reinstalled from scratch; still didn't install 'recommends'. Only thing that worked was reverting the system with Timeshift. With a clean slate, the 'with recommends' installation went through cleanly, Virt-Manager performed as expected, and shared folder worked. To confirm I hadn't made an error the first time, reverted with Timeshift and installed virt-manager without 'recommends'; went quickly, as had figured out the other issues, but same result ("SpiceClientGtk not available").

If you don't have Timeshift installed, I recommend you do a clean system install. Takes less time than trying to figure out the state of your package universe and whether VirtMan's 'recommends' are present. Either install Timeshift or backup the system by some other method. Then try again installing virt-manager, using my form of command (not mine actually, as I got it from an experienced QEMU-KVM user on Debian forum).

Posted: **Sun Mar 31, 2024 2:31 pm**

Hallo loik,
habe nochmal kurz nachgesehen. virtiofsd ist Bestandteil von qemu-system-common. Deshalb hatte ich gefragt, ob Du das installiert hast. Keine Ahnung, warum es bei dir nicht auftaucht. Hast du einen anderen Kernel (vielleicht nur 32-bit), oder was ist da los?
Poste mal die Ausgabe von

Code: Select all

dpkg --search visiofs

Bei mir sieht das so aus:

Code: Select all

dpkg --search virtiofs
qemu-system-common: /usr/share/man/man1/virtiofsd.1.gz
qemu-system-common: /usr/lib/qemu/virtiofsd
qemu-system-common: /usr/share/qemu/vhost-user/50-qemu-virtiofsd.json
linux-image-6.1.0-18-amd64: /lib/modules/6.1.0-18-amd64/kernel/fs/fuse/virtiofs.ko

die restlichen Fragen lasse ich erstmal aus Zeitmangel und wegen nicht so bedeutenden Nebenschauplätzen aussen vor.
Aber wenn Du unbedingt die Oktaldarstellung der Dateirechte sehen willst, benutze

Code: Select all

stat DATEINAME

Aber ich finde, wenn man sich noch nicht so auskennt, die ls -l Ausgabe von z.B. rw-r----- intuitiver als die entsprechende Oktalausgabe 640. Das ist allerdings ein anderes Thema.

viele Grüsse gosia

Posted: **Sun Mar 31, 2024 3:30 pm**

Hallo, Gosia.

Aber ich finde, wenn man sich noch nicht so auskennt, die ls -l Ausgabe von z.B. rw-r----- intuitiver als die entsprechende Oktalausgabe 640

Wenn es nicht graühisch ist, ist für mich gar nix intuitiv.

Ich wollte nur gerne kontrollieren, ob meine, für den Austausch-Ordner, graphisch erteilten Rechte denn auch real 777 entsprechen.
Dem ist wohl so:

Code: Select all

$ stat AUSTAUSCH_mit_VMs
 Datei: AUSTAUSCH_mit_VMs
 Größe: 4096      	Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 8/38	Inode: 57292       Verknüpfungen: 5
Zugriff: (0777/drwxrwxrwx)  Uid: ( 1000/user-mx23-64)   Gid: (64055/libvirt-qemu)
Zugriff: 2024-03-20 18:52:27.632682483 +0100
Modifiziert: 2024-03-31 07:40:35.080415364 +0200
Geändert: 2024-03-31 07:40:35.080415364 +0200
Geburt: 2024-03-17 15:14:30.795807770 +0100

Hast du einen anderen Kernel (vielleicht nur 32-bit), oder was ist da los?

Hast Recht, eine QSI ist überfällig:

Code: Select all

Snapshot created on: 20231222_1428
System:
  Kernel: 6.1.0-18-amd64 [6.1.76-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-18-amd64 root=UUID=<filter> ro quiet splash
    init=/lib/systemd/systemd
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7
    dm: LightDM v: 1.26.0 Distro: MX-23.2_x64 Libretto Dezember 22  2023 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Desktop System: Hewlett-Packard product: HP Compaq Elite 8300 USDT v: N/A
    serial: <superuser required> Chassis: type: 3 serial: <superuser required>
  Mobo: Hewlett-Packard model: 3398 serial: <superuser required> BIOS: Hewlett-Packard
    v: K01 v02.05 date: 05/07/2012
Battery:
  Device-1: hidpp_battery_0 model: Logitech Wireless Touch Keyboard K400 serial: <filter>
    charge: 55% (should be ignored) rechargeable: yes status: discharging
CPU:
  Info: model: Intel Core i5-3470S bits: 64 type: MCP arch: Ivy Bridge gen: core 3 level: v2
    built: 2012-15 process: Intel 22nm family: 6 model-id: 0x3A (58) stepping: 9 microcode: 0x21
  Topology: cpus: 1x cores: 4 smt: <unsupported> cache: L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB
    L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 1772 high: 1789 min/max: 1600/2900 scaling: driver: intel_cpufreq
    governor: ondemand cores: 1: 1789 2: 1788 3: 1747 4: 1767 bogomips: 23147
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB
    filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Vulnerable: No microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics vendor: Hewlett-Packard
    driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports:
    active: DP-1,HDMI-A-2 empty: DP-2,HDMI-A-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0152
    class-ID: 0300
  Device-2: DisplayLink USB3.0 Dual Video Dock type: USB driver: cdc_ncm,snd-usb-audio,usbfs
    bus-ID: 4-2.1:4 chip-ID: 17e9:4307 class-ID: 0a00 serial: <filter>
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.18.0 driver: X:
    loaded: modesetting dri: crocus gpu: evdi,i915 display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 6720x1080 s-dpi: 96 s-size: 1778x286mm (70.00x11.26") s-diag: 1801mm (70.9")
  Monitor-1: DP-1 pos: 1-4 model: BenQ FP92Wa serial: <filter> built: 2007 res: 1440x900 hz: 60
    dpi: 90 gamma: 1.2 size: 408x255mm (16.06x10.04") diag: 472mm (18.6") ratio: 16:10 modes:
    max: 1440x900 min: 640x350
  Monitor-2: DVI-I-1 mapped: DVI-I-1-1 pos: 1-2 model: Acer K242HL serial: <filter> built: 2020
    res: 1920x1080 hz: 60 dpi: 92 gamma: 1.2 size: 531x299mm (20.91x11.77") diag: 609mm (24")
    ratio: 16:9 modes: max: 1920x1080 min: 720x400
  Monitor-3: DVI-I-2 mapped: DVI-I-2-2 pos: 2-1 model-id: AGO 0x0001 serial: <filter> built: 2013
    res: 1440x900 hz: 75 dpi: 143 gamma: 0.97 size: 256x192mm (10.08x7.56") diag: 378mm (14.9")
    ratio: 4:3, 5:4 modes: max: 1024x768 min: 720x480
  Monitor-4: HDMI-A-2 mapped: HDMI-2 pos: primary,1-3 model: Acer SB241Y A serial: <filter>
    built: 2022 res: 1920x1080 hz: 60 dpi: 93 gamma: 1.2 size: 527x296mm (20.75x11.65")
    diag: 604mm (23.8") ratio: 16:9 modes: max: 1920x1080 min: 720x400
  API: OpenGL v: 4.2 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 2500 (IVB GT1)
    direct-render: Yes
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard 7
    driver: snd_hda_intel bus-ID: 1-1.5:6 v: kernel bus-ID: 00:1b.0 chip-ID: 041e:3010 class-ID: 0300
    chip-ID: 8086:1e20 class-ID: 0403
  Device-2: Creative SoundBlaster MP3+ type: USB driver: hid-generic,snd-usb-audio,usbhid
  Device-3: DisplayLink USB3.0 Dual Video Dock type: USB driver: cdc_ncm,snd-usb-audio,usbfs
    bus-ID: 4-2.1:4 chip-ID: 17e9:4307 class-ID: 0a00 serial: <filter>
  API: ALSA v: k6.1.0-18-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pw-cat,pw-cli,wpctl
  Server-2: PulseAudio v: N/A status: off (using pipewire-pulse) tools: pacat,pactl,pavucontrol
Network:
  Device-1: Intel 82579LM Gigabit Network vendor: Hewlett-Packard driver: e1000e v: kernel
    port: f060 bus-ID: 00:19.0 chip-ID: 8086:1502 class-ID: 0200
  IF: eth0 state: down mac: <filter>
  Device-2: Realtek 802.11ac NIC type: USB driver: rtl8821cu bus-ID: 2-3:3 chip-ID: 0bda:c811
    class-ID: 0000 serial: <filter>
  IF: wlan0 state: up mac: <filter>
  IF-ID-1: eth1 state: down mac: <filter>
  IF-ID-2: virbr0 state: down mac: <filter>
Drives:
  Local Storage: total: 792.51 GiB used: 400.83 GiB (50.6%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: Fujitsu model: MHZ2320BH G2 size: 298.09 GiB block-size:
    physical: 512 B logical: 512 B speed: 3.0 Gb/s type: N/A serial: <filter> rev: 0009 scheme: MBR
  ID-2: /dev/sdc maj-min: 8:32 type: USB vendor: SanDisk model: Cruzer Spark size: 28.65 GiB
    block-size: physical: 512 B logical: 512 B type: N/A serial: <filter> rev: 1.00 scheme: MBR
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
  ID-3: /dev/sdd maj-min: 8:48 type: USB vendor: Realtek model: RTL9210B-CG size: 465.76 GiB
    block-size: physical: 512 B logical: 512 B type: N/A serial: <filter> rev: 1.00 scheme: GPT
Partition:
  ID-1: / raw-size: 17.53 GiB size: 17.15 GiB (97.82%) used: 15.76 GiB (91.9%) fs: ext4
    dev: /dev/sdc6 maj-min: 8:38
Swap:
  Kernel: swappiness: 60 (default) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 3.82 GiB used: 0 KiB (0.0%) priority: 100 dev: /dev/zram0
  ID-2: swap-2 type: partition size: 3.03 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/sdc7
    maj-min: 8:39
Sensors:
  System Temperatures: cpu: 34.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 2659 libs: 1372 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm main non-free
  Active apt repos in: /etc/apt/sources.list.d/signal-xenial-added-by-mxpi.list
    1: deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main
Info:
  Processes: 265 Uptime: 14m wakeups: 2 Memory: 7.63 GiB used: 2.55 GiB (33.4%) Init: systemd
  v: 252 target: graphical (5) default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: BIOS (legacy, CSM, MBR)

Kernel dürfte wohl o.k. sein.
Nur halt SystemD

Code: Select all

$ dpkg --search virtiofs
linux-image-5.10.197-antix.1-amd64-smp: /lib/modules/5.10.197-antix.1-amd64-smp/kernel/fs/fuse/virtiofs.ko
linux-image-6.1.0-17-amd64: /lib/modules/6.1.0-17-amd64/kernel/fs/fuse/virtiofs.ko
linux-image-6.7.4-1-liquorix-amd64: /lib/modules/6.7.4-1-liquorix-amd64/kernel/fs/fuse/virtiofs.ko.xz
linux-image-6.1.0-18-amd64: /lib/modules/6.1.0-18-amd64/kernel/fs/fuse/virtiofs.ko

Hmm.

Ich starte gleich noch mal in SysVenit und wiederhole die Installation von Virt-Manager.
Mal schauen, was dann geschieht.

Hallo, pbear.

Bitte bedenken Sie, dass es für uns nicht möglich ist, dies aus der Ferne zu diagnostizieren, was für mich doppelt schwierig ist, da ich alles (in beide Richtungen) durch einen Übersetzer laufen lassen muss. Fehler, die Sie erhalten)

Ich bin immer wieder Beeindruckt, wie gering die Rate an Fehlern und Missverständnissen ist und freue mich sehr über die Sprachübergreifenden Hilfen.

Ihr Frust ist verständlich. Ich habe das Erlernen von QEMU viele Jahre lang aufgeschoben, da ich aus der Lektüre von Tutorials wusste, dass es schwierig sein würde. OTOH, sobald es installiert und ausgeführt ist, ist es meiner Meinung nach einfacher zu verwenden und zu warten als VirtualBox. Tatsächlich habe ich, wie in meinem ersten Beitrag erwähnt, beschlossen, darauf als mein Hauptvirtualisierungstool umzusteigen, mit Ausnahme der Beibehaltung von VBox für für eine Win10-VM (bessere Grafikunterstützung, wenn man keine separate GPU zum Durchleiten hat) und älteren VMs (nicht). eine Konvertierung lohnt sich, wenn ich VBox installieren möchte). Allerdings ist es eine Ihrer Optionen, „Macht nichts“ zu sagen und bei VBox zu bleiben. Nur Sie können sagen, ob sich die Weiterentwicklung mit Virt-Manager lohnt.

Ja, dem stimme ich voll zu. Genau so geht es es mir, genau so sehe ich dass und dank deines Hinweises werde ich mich wohl gar nicht erst daran Versuchne, Windows zu konvertieren und in Virt-Manager nutzbar zu machen.

Aber für Linux möchte ich wohl gerne Virt-Manager voll nutzen können.
Allein schon, weil ich drei VMs gleichzeitig laufen haben konnte.
Das hatte bei VB nie geklappt.
Wenn eine lief, war alles andere Blockiert.

Ich weiß es nicht. Dir ist klar, dass virtiosd eine Datei ist, oder? Die Frage wäre also: Welches Paket bringt diese Datei mit?

Doch, ja. Und das war von mir auch als Fragestellung gemeint.
Bzw. auch:
Warum fehlt bei mir diese Datei ?
Wodurch wird sie normalerweise Angelegt ?
Durch die Installation von Virt-Manager ?
Oder durch den ersten Start von Virt-Manager ?
Wie kann ich diese Datei Nachträglich erstellen ?

Ich möchte erwähnen, dass apt Sie in diesem Fall möglicherweise im Stich gelassen hat. Manchmal stolpert es .....

Das ist ja schon ein Teil der Antwort.

.... eine Neuinstallation des Systems durchzuführen

Die Installation ist natürlich ruckzuck gemacht.

Aber ein System optisch und funktional nach meinen Bedürfnissen einzurichten zieht sich über Wochen bis Monate. Davon werde ich vorerst noch Abstand nehmen.
Timeshift habe ich nicht.

Posted: **Sun Mar 31, 2024 3:58 pm**

Hallo loik,

loik wrote: Sun Mar 31, 2024 3:30 pm und wiederhole die Installation von Virt-Manager.

dann installiere auf jeden Fall qemu-system-common auch neu

Code: Select all

sudo apt install qemu-system-common

denn das beinhaltet virtiofsd
und wahrscheinlich auch wichtig, fahre vorher mit diesem Kernel hoch:
linux-image-6.1.0-18-amd64
alles grösser als 6.1 sollte eigentlich funktionieren, aber der ist mit meinem Kernel identisch, was für einen Vergleich und die Fehlereingrenzung ja ganz praktisch sein kann.

viele Grüsse gosia

Posted: **Sun Mar 31, 2024 4:19 pm**

Ja, das sollte auch aus genau dem Grund meine Vorgehensweise sein.

Ich habe mich also auf qemu-system-common konzentriert.

Aha!
Sehr interessant.

Ich habe mit Synaptic das bereits installierte qemu-system-common deinstalliert.

Dabei vermeldete Synaptic, dass aber dann auch folgende Pakete deinstalliert werden müssen:
aqemu
qemu-system-x86
qemu-system-gui
qemu-system-modules-opengl
qemu-system-modules-spice

Nach dem ich mir das notiert hatte, habe ich der Deinstallation zugestimmt.

Dann habe ich das System neu gestartet und in SysVenit ( vermitlich wäre SystemD genauso gut gewesen ) gebootet.

Dann wieder Synaptic und die Pakete
aqemu
qemu-system-x86
qemu-system-gui
mit den von Synaptic empfohlenen Abhängigkeiten neu installiert.
Und qemu-utils bei der Gelegenheit auch nochmal "erneut" installiert.

qemu-system-modules-opengl
qemu-system-modules-spice
waren nicht verfügbar.

Danach sah es dann so aus:

Code: Select all

$ dpkg --search virtiofs
linux-image-5.10.197-antix.1-amd64-smp: /lib/modules/5.10.197-antix.1-amd64-smp/kernel/fs/fuse/virtiofs.ko
linux-image-6.1.0-17-amd64: /lib/modules/6.1.0-17-amd64/kernel/fs/fuse/virtiofs.ko
linux-image-6.7.4-1-liquorix-amd64: /lib/modules/6.7.4-1-liquorix-amd64/kernel/fs/fuse/virtiofs.ko.xz
qemu-system-common: /usr/share/man/man1/virtiofsd.1.gz
qemu-system-common: /usr/lib/qemu/virtiofsd
qemu-system-common: /usr/share/qemu/vhost-user/50-qemu-virtiofsd.json
linux-image-6.1.0-18-amd64: /lib/modules/6.1.0-18-amd64/kernel/fs/fuse/virtiofs.ko

JuHu.

Aber was ist mit den zwei anderen Paketen?
MxPi geöffnet und danach gesucht.
In den Backports pfündig geworden.

Erstmal qemu-system-modules-spice zur installation aufgerufen und den Haken bei Plus empfohlenen Abhängikeiten gesetzt.
Dabei wurde qemu-system-modules-opengl gleich mit aufgelistet.
Aber auch Upgrades für

Code: Select all

2024-03-31  21:55:49  upgrade  qemu-utils                                amd64  1:7.2+dfsg-7+deb12u5             1:8.2.1+ds-1~bpo12+1
2024-03-31  21:55:48  upgrade  qemu-system-common                        amd64  1:7.2+dfsg-7+deb12u5             1:8.2.1+ds-1~bpo12+1
2024-03-31  21:55:44  upgrade  qemu-system-x86                           amd64  1:7.2+dfsg-7+deb12u5             1:8.2.1+ds-1~bpo12+1
2024-03-31  21:55:44  upgrade  qemu-system-gui                           amd64  1:7.2+dfsg-7+deb12u5             1:8.2.1+ds-1~bpo12+1

Ja, klar. Warum auch nicht ?
Installiert.
Danach sah es dann so aus:

Code: Select all

$ dpkg --search virtiofs
linux-image-5.10.197-antix.1-amd64-smp: /lib/modules/5.10.197-antix.1-amd64-smp/kernel/fs/fuse/virtiofs.ko
linux-image-6.1.0-17-amd64: /lib/modules/6.1.0-17-amd64/kernel/fs/fuse/virtiofs.ko
linux-image-6.7.4-1-liquorix-amd64: /lib/modules/6.7.4-1-liquorix-amd64/kernel/fs/fuse/virtiofs.ko.xz
linux-image-6.1.0-18-amd64: /lib/modules/6.1.0-18-amd64/kernel/fs/fuse/virtiofs.ko

Oh, Nein!

Aber vielleicht die Lösung.
Ich wiederhole das jetzt mal ....

Posted: **Sun Mar 31, 2024 4:49 pm**

Code: Select all

sudo mount -t virtiofs VM-Austausch /home/loik/VM-Austausch
mount: /home/loik/VM-Austausch: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /home/loik/VM-Austausch ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

Menno ....

Posted: **Sun Mar 31, 2024 5:13 pm**

Hallo loik,

loik wrote: Sun Mar 31, 2024 4:19 pm was ist mit den zwei anderen Paketen?

bin wohl zu müde. welche zwei andere Pakete meinst Du?
oha, diese Updates sind bei mir noch nicht angekommen. Ich habe jetzt nur qemu-system-common verglichen, und da habe ich als neueste Version immer noch 1:7.2+dfsg-7+deb12u5. Aber ich benutze auch keine Backports und auch nicht den MX Linux Package Installer. Mal sehen, was passiert, wenn diese Updates bei mir ankommen.

loik wrote: Sun Mar 31, 2024 4:49 pm
Code: Select all
mount: /home/loik/VM-Austausch: Falscher Dateisystemtyp

hm, welchen Dateisystemtyp benutzt Du denn da, ext4, btrfs oder was?
Aber erwarte für heute keine Antworten mehr von mir, Ostern und die Zeitumstellung ziehen mich unweigerlich ins Bett...

viele Grüsse gosia

Posted: **Sun Mar 31, 2024 5:27 pm**

Alles gut, Gosia.
War überrrascht, dir heute überhaupt noch zu begegnen.
Ich dachte, du wärst ab Dienstag erst wieder am Start.

Ich meine diese Zwei Pakete, die es nur über die Backports gibt.
qemu-system-modules-opengl
qemu-system-modules-spice

ich weiß nicht, warum die bei mir installiert waren.
Ich weiß nur, dass sie installiert waren, weil Synaptic sie in Folge wieder deinstalliert hat.
Deshalb dachte ich auch dass ich sie wieder besorgen müsste und fand sie in den Backports.
Aber die und die dazugehörigen Updates verhindern, dass virtiofsd in /usr/lib/qemu auftaucht.

Jedenfalls habe ich diese zwei Pakete nun, aktuell, nicht installiert, damit ich endlich virtiofsd habe.

Trotzdem aber der Mount-Fehler im Gast.
Wirt und Gast benutzen jeweils ext4.

qemu-system-modules-opengl ?
( Auf die Auflösungsoptionen im Gast hat es jedenfalls Auswirkungen. Die sind ohne dieses Paket beschränkter )

Oder muss eben doch erst in der XML rungekritzelt werden ?
https://libvirt.org/kbase/virtiofs.html

Posted: **Mon Apr 01, 2024 9:11 am**

Hallo loik,

loik wrote: Sun Mar 31, 2024 5:27 pm War überrrascht, dir heute überhaupt noch zu begegnen.

tja, wenn Du solch spannende Fragen stellst schaufle ich mir gern 5 Minuten frei, schon aus Neugierde und um was zu lernen

Aber so richtig intensiv und gründlich wird es wirklich erst nach Ostern.

loik wrote: Sun Mar 31, 2024 4:49 pm

Code: Select all

mount: /home/loik/VM-Austausch: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /home/loik/VM-Austausch ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

Du hast Fehlermeldungen... Hm, da kann ich nur sagen, kontrolliere nochmals alles von vorn:
-> dpkg --search virtiofs
-> virtiofs ist tatsächlich in /usr/lib/qemu/ vorhanden?
-> Du hast auch den betreffenden Kernel gestartet linux-image-6.1.0-18-amd64?
-> im virt-manager ist im Menupunkt "Speicher" gemeinsamer Speicher aktiviert + in "Dateisystem" Treiber virtiofs, Quellpfad "/home/loik/VM-Austausch" (Gross- Kleinschreibung ist korrekt?) und Zielpfad "VM-Austausch" angegeben?
-> der mount-Befehl wurde im Gast und nicht etwa im Host angegeben?
-> der Dienst virtiofsd läuft? Das kannst Du nur kontrollieren, wenn die virtuelle Maschine (Gast) auch läuft und Du im Host das eingibst:

Code: Select all

ps ax | grep virtiofsd

im Zweifelsfall poste einfach die Ausgabe dieses Kommandos
-> das Verzeichnis "/home/loik/VM-Austausch" existiert so im Host?
-> Dein Filesystem ist ok? Als Minimum kannst Du ja mal einen vorhandenen USB-Stick/FP normal nach /home/loik/VM-Austausch mounten.

mehr fällt mir im Moment nicht ein.

loik wrote: Sun Mar 31, 2024 5:27 pm Oder muss eben doch erst in der XML rungekritzelt werden ?

ich rate dir, lass die Finger davon. Kann man machen, kannst aber viel mehr Schaden anrichten, wenn Du dich nicht auskennst. Ich lasse jedenfalls den virt-manager diese Arbeit erledigen.

loik wrote: Sun Mar 31, 2024 5:27 pm qemu-system-modules-opengl
qemu-system-modules-spice

Nur soviel: Ich habe diese Pakete bei mir auch nicht, könnte aber die Auflösung des Gastes trotzdem so hoch einstellen, dass alles sehr winzig wird. Da gibt es Auflösungen bis zu 5120x2160, würde wahrscheinlich mein kleiner Monitor explodieren

viele Grüsse gosia

Posted: **Tue Apr 02, 2024 3:30 am**

Hallo, Gosia.

Teilerfolg und neue Erkenntnis.

Die Fehlermeldung, dass es sich um einen falschen Dateityp handele, bekomme ich nicht, wenn ich es mit 9p versuche.
Da Klappt das Mounten einfach. ( das ist noch nicht der angekündigteTeilerfolg ).
Nur das bei 9p das mit den Dateirechten nervt.

Präzise Checkliste. Danke.
Ja, Stimmt alles.

Du hast auch den betreffenden Kernel gestartet linux-image-6.1.0-18-amd64?

Im Wirt, Ja.
Der Gast ist MX-21.3-64bit-MX-snapshot.
Der hat keinen 6er Kernel, weil ich mit dem in MX-21.3 eine superschlechte Performance hatte.

Code: Select all

Kernel: 5.10.188-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 10.2.1 
           parameters: lang=de_DE quiet splash 
           Desktop: Xfce 4.18.1 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.18.0 vt: 7 
           dm: LightDM 1.26.0 Distro: MX-21.3_x64 Wildflower October 20  2021 
           base: Debian GNU/Linux 11 (bullseye)

Und wegen dem:
https://libvirt.org/kbase/virtiofs.html

Boot the guest and mount the filesyste
guest# mount -t virtiofs ...........
Note: this requires virtiofs support in the guest kernel (Linux v5.4 or later)

hatte ich vorgestern schon eine Frage formuliert, sie aber wieder verworfen, weil ich dachte, dass mein Gast-Kernel 5.10.188 die Kriterien doch wohl erfüllt.

Aber, nun die Erkenntnis:
Eben doch nicht.

Wegen dieser und deiner Kenel-Frage habe ich mal MX-23.1-64bit mit Kernel 6.1.0-17 als Gat geladen.
In dem ist noch überhaupt gar nix installiert von qemu, virt, spice, kvm oder 9p.

In diesem Gast ließ sich der Austausch-Ordner mit mkdir erstellen und klaglos mounten.

Ich konnte nun in diesem Gast-Verzeichnis, so wie in dem darauf verweisenden Wirt-Verzeichnis ohne jegliche Rechte-Probleme oder speziellen Einstellungen auf die jeweiligen Dateien und Ordner über Kreuz zugreifen und weiter bearbeiten.
Sogar das synchrone Arbeiten in einer Datei war möglich.
Eine Featherpad-Datei kann in beiden Systemen zeitgleich geöffnet sein und von beiden Systemen aus, kann in ihr geschrieben werden.
Das Geschriebene taucht auf dem Dokument im anderen System dann auf, sobald es im System wo es bearbeitet wurde gespeichert ist und im anderen System auf aktualisieren des Dokumentes geklickt wurde.
So soll das. JA!
So gar einem Symlink, den ich im Wirt in dem Austauschordner gezogen hatte, konnte ich vom Gast aus bedingt folgen und auf Dateien Zugreifen, diese aber eben doch auch nur bedingt direkt bearbeiten.
Ich konnte beispielsweise, wenn ich vom Gast aus, einen solchen Symlink-Pfad folgte, in diesem eine neue Datei erstellen. Auch bearbeiten.
Aber diese Datei ist, wenn ich dem Pfad vom Wirt aus folge, dort nicht vorhanden. Das n büschn spuki.
Grundsätzlich aber alles schon mal sehr schön so.

Doch eben nur Teilerfolg, weil es ja in älteren Gast-Systemen nicht funktioniert.
Für weitere Kernel-Versuche hatte bisher noch keine Zeit, folgt aber noch.

Trotzdem die Frage, wie diese Kernel-Macke zu überwinden ist.
Meinetwegen auch durch ausweichen auf 9p.
Aber da müsste es dann eine Lösung für das Rechteproblem geben.

Wie ist denn das deiner Erfahrung nach mit dem USB-Speicher.
Ich hatte es bisher ja so verstanden, wie ich es auch von VB kenne.
Auf so einen Speicher ist nicht zeitgleich von Gast und Wirt aus zuzugreifen, sondern immer nur abwechselnd, je nach dem ob er gerade im Gast eingehängt ist oder nicht.
Ist das so richtig ?
Oder gibt hier auch eine Möglichkeit für die synchrone Nutzung ?

Da gibt es Auflösungen bis zu 5120x2160,

Gibt es bei mir auch.
So hoch hinaus wollte ich aber gar nicht.

Als qemu-system-modules-opengl noch installiert war, konnte ich auch die Auflösung 1600x900 wählen.
Diese Auflösung wird nun, da qemu-system-modules-opengl deinstalliert ist, nicht mehr angeboten.
Das nur am Rande. Nicht wirklich wichtig.

.... schaufle ich mir gern 5 Minuten frei, schon aus Neugierde und um was zu lernen ....

Das ist doch wohl das Forums-Kredo par Excellence.
Sollte es jedenfalls sein.
Sehr schön auf den Punkt gebracht.

Danke.

Posted: **Tue Apr 02, 2024 4:19 am**

Ich habe als Gast versucht:
MX-21.3-32bit-FluxBox, Kernel 5.10.0-23-686pae.

Mounten des Austausch-Ordners ebenfalls gescheitert.
Auch die Fehlermeldung über ein angeblich beschädigtes Dateisystem erhalten.

Posted: **Tue Apr 02, 2024 5:36 pm**

Hallo loik,
naja, jetzt wird es schwierig. Wie Du schon selbst gelesen hast
"this requires virtiofs support in the guest kernel (Linux v5.4 or later)"
muss virtiofs auch vom Kernel unterstützt werden, was eigentlich ab 5.4 der Fall sein sollte. Aber irgendwas ist da faul dran, denn in meinem alten MX-21.3 (Kernel 5.10) bekomme ich im virt-manager auch keine Einstellung "gemeinsamen Speicher nutzen".
Für ältere Gäste bleibt dann wohl nur der gemeinsame Zugriff über eine übliche Netzwerkmethode (ssh, Samba, NFS), da wären wir dann dort, wo wir schon am Anfang mal waren. Ich bevorzuge ssh, aber für Samba gibt es ja das nette Helferlein "MX Samba Konfiguration". Damit funktioniert bei mir auch die Benutzung von gemeinsamen Ordnern. Die müssen eben nur in der "MX Samba Konfiguration" freigegeben werden und der User muss dort "vollständigen Zugriff" erhalten. Dann sind sie im Dateimanager erreichbar und editierbar. Im Host "normal" und im Gast über Netzwerk durchsuchen.
USB wird nur wechselweise unterstützt (wie Du geschrieben hast), im Gast einhängen, dann aushängen um es im Host wieder mounten zu können. Wüsste keinen Weg, das zu ändern.
Was 9p betrifft, so habe ich ich irgendwo gelesen, dass es eh nicht mehr empfohlen wird. Ich bin dem nicht weiter nachgegangen.

viele Grüsse gosia

Posted: **Wed Apr 03, 2024 1:24 am**

Hallo, Gosia.

Damit wäre dann dieses Thema nicht gelöst, aber beendet.
Unbefriedigend, könnte man meinen.
Aber ich bin froh, über die eindeutige Bestätigung, dass ich nicht zu ungeschickt war, sondern die Softwares fehlerhaft, unausgereift oder ungepflegt sind.

Ich danke dir für die Hilfe und Mühe des Nachstellens und allen anderen, die mit ihreren Erfahrungen oder Überlegungen mitgewirkt hatten, dieses Thema zu ergründen.

Also werde ich noch mal die drei Netzwerk-Möglichkeiten versuchen und für eventuelle Hilfe dazu ein neues Thema eröffnen.

Posted: **Wed Apr 03, 2024 6:09 am**

Hallo loik,

loik wrote: Wed Apr 03, 2024 1:24 am Softwares fehlerhaft, unausgereift oder ungepflegt sind.

das sehe ich nun nicht so hart. Wenn der Kernel die notwendigen Module (noch) nicht mitbringt, weil er z.B, zu alt ist, dann kann das ja nicht auf diesem Wege funktionieren. Und nicht umsonst existiert in solchen Systemen beim virt-manager dann dieses Auswahlkästchen "gemeinsamer Speicher" nicht. Wenn man aber den passenden Kernel hat, wie in MX-23, dann funktioniert es doch wunderbar.
Aber gut, darüber müssen wir nicht diskutieren und auch von meiner Seite ist das Thema erstmal abgeschlossen, einfach deshalb, weil mir nichts gescheites mehr dazu einfällt

loik wrote: Wed Apr 03, 2024 1:24 am Also werde ich noch mal die drei Netzwerk-Möglichkeiten versuchen

Ein guter Ansatz. Das lohnt sich auf jeden Fall, nicht nur für virtuelle Maschinen.

viele Grüsse gosia

Posted: **Wed Apr 03, 2024 1:01 pm**

Naja, das war jetzt nicht als speziell, empörte Schimpfe gegen Virt-Manager gemeint.

Ich finde das schon ganz schön, das einfach so, ohne weiteres die gemeinsame Kopierablage funktioniert und das sich USB-Datenträger unproblematisch einbinden lassen.
Da kann man mit arbeiten.
Das ging mit Aqemu so einfach nicht.
Das war eher ein geschlossener Betrachter.

Ich finde es nur doch eben auch recht frustrierend, wenn man an Software scheitert, wenn sie eben auch nur eines der drei von mir angeführten Punkte aufweist.

Und ja, wie wir festgestellt haben, sind die Auskünfte von Virt-Manager für den Gast, Kernel 5.4 oder höher, was doch wohl auf 5.10 zutreffen sollte.
Da finde ich ein verärgertes Kopfschütteln nicht überzogen, wenn man sich über Tage vergeblich die Zähne daran ausbeißt, bis man feststellt, das diese Aussage gar nicht zutreffend ist.

Aber, Hey.
Das wirklich Gute an tiefgründiger Fehler-Überwindungs-Versuchen ist, dass man die Sache an sich viel besser versteht.

So gesehen alles gut.

Posted: **Fri Apr 05, 2024 5:04 pm**

Hallo loik,
ich habe nochmal recherchiert und gefunden wie man per Kommandozeile den gemeinsamen Ordner auch mit Host-Kernel >= 5.4 einrichten kann, wenn im virt-manager diese Option nivht angezeigt wird.
Dazu brauchst Du nur drei Variable, die ich hier kurz erläutere:
* Name der virtuellen Maschine: steht im virt-manager, wird aber auch mit

Code: Select all

 sudo virsh list --all

ausgegeben.
* source.dir: zu teilendes Verzeichnis (Host)
* target.dir: ein beliebiger passender Name, der dann im Gast für den mount Befehl benutzt wird

für die Beispielkommandos benutze ich jetzt mal folgende symbolischen Namen, in Klammern mögliche Beispiele:
Name der virtuellen Maschine: VM_NAME (mx21)
source.dir: HOSTDIR (/home/loik/musik)
target.dir: MOUNTNAME (musik)

Code: Select all

sudo virt-xml VM_NAME --edit --memorybacking source.type=memfd,access.mode=shared
sudo virt-xml VM_NAME --add-device --filesystem driver.type=virtiofs,accessmode="passthrough",source.dir=HOSTDIR,target.dir=MOUNTNAME

dann den Gast starten und dort einmal den Rest eingeben (kennst Du ja eigentlich schon)

Code: Select all

 mkdir -v VERZEICHNIS

# Name und Ort des Verzeichnisses ist beliebig, sollte aber der Einfachheit halber in deinem Homeverzeichnis liegen

Code: Select all

sudo mount -v -t virtiofs MOUNTNAME VERZEICHNIS

dann hast Du in VERZEICHNIS wie gewünscht wechselseitigen Zugriff. Um das dauerhaft zu machen kannst Du dann in der /etc/fstab des Gastes diese Zeile einfügen:

Code: Select all

MOUNTNAME	VERZEICHNIS	virtiofs  defaults  0  0

hier ist ein möglicher Fallstrick, dass VERZEICHNIS in der fstab der volle Dateiname sein muss, also nicht nur musik, sondern /home/loik/musik

viele Grüsse gosia

PS.
Quelle für die etwas angepasste Anleitung ist hier:
https://sysguides.com/share-files-betwe ... g-virtiofs
Und auch wichtig, die Methode mit virtiofs funktioniert wie gesagt nur bei Kerneln ab 5.4, weil nur dort die Unterstützung für virtiofs im Kernel vorhanden ist. Wie es mit Gästen Kernel >= 5.4 aber 32-bit musst Du selbst testen. Habe gerade keine 32-bit-Distro zur Hand.

Posted: **Sat Apr 06, 2024 3:41 am**

Hallo, Gosia.

Das nenne ich sportlichen Ehrgeiz.
Sehr erfreut.

Die Quelle deiner neuen Tipps scheint ja genau zeitgleich entstanden zu sein, als wir uns an diesen Thema versuchten.

Die angebotene Vorgehensweise bringt Teil-Erfolg.

Denn die Anleitung hat laut Quelle ein Manko,

Debian 12 guest virtual machine

welches nicht, die hier zuletzt beklagten Probleme berücksichtigt.
Nämlich das Mounten in einem Gast der einen Kernel unter 6.1 hat, nicht geht. ( weiß nicht ob 6.0 ginge. Habe keinen solchen Gast. Nur 5.8 oder 5.10 ).
Das wird ja mit der bereits geposteten Fehlermeldung verweigert.

Und das bleibt auch so.
Das ist also weiterhin ungelöst.

Aber, immerhin, kann ich nun, mit dieser Anleitung, in einen Wirt mit 5.10er Kernel ( MX-21.3 ), virtiofs anwenden.
Damit kann ich dann in einen Gast, sofern er einen 6.1er Kernel hat ( MX-23 ), den Austausch-Ordner mounten und so einfach, komfortable und unbeschränkt nutzen, wie gewünscht.

Mit einem Gast MX-21.3 geht es wie schon geschrieben nicht. Unabhängig vom Wirt.

Was ich nun noch nicht getestete habe, ( weil in der Erstellung etwas Aufwendig, da ich erstmal so ein entsprechendes ISO produzieren müsste,) ist ein MX-21.3 mit irgendeinem 6.1er Kernel.
Sollte es in diesem Gast dann ebenfalls scheitern, hätte es überhaupt nix mit dem Kernel zu tun sondern hinge davon ab, ob man als Gast Debian12 oder 11 oder 10 benutzt.

Obwohl es mich juckt, werde ich die nächsten 10 Tage wohl keine Zeit haben das zu testen.
Bin schon froh, dass ich dir diese Rückmeldung erstellen konnte.

Posted: **Sat Apr 06, 2024 6:57 am**

Hallo loik,

loik wrote: Sat Apr 06, 2024 3:41 am Mit einem Gast MX-21.3 geht es wie schon geschrieben nicht.

das bedarf der Klärung. Ich habe hier als Host ein MX-21.3 (Kernel 5.10.0-28-amd64), in dem ein Gast MX-21.3 (Kernel 5.10.0-28-amd64) läuft und beide teilen sich wunderbar ein Verzeichnis.
Ist natürlich etwas gaga, Host und Gast das gleiche System, aber was anderes habe ich im Moment nicht zur Hand.

viele Grüsse gosia

Posted: **Sat Apr 06, 2024 1:04 pm**

das bedarf der Klärung

Ja, unbedingt gerne.

Da es bei dir mit beidem funktioniert hat, sollte es bei mir auch möglich sein.

ist in deinem gast irgend was spezielles installiert, als Voraussetzung ?

Wenn das bei dir, dann müsste doch auch bei dir die Kombination Wirt 23.2 Gast 21.3 funktionieren.

Oder hattest du gemeint " ...habe nix anderes" auch keinen 23.2-Wirt?

Posted: **Sat Apr 06, 2024 3:33 pm**

Hallo loik,
habe mich unklar ausgedrückt. Auf meinem Zweitrechner läuft MX-23.2 (Kernel 6.1.0-18-amd64) auch als Wirt. Aber damit habe ich keinerlei Probleme, weil dort im virt-manager die Option "gemeinsamen Speicher aktivieren" immer anwählbar ist und auch funktioniert, sofern der Gastkernel >= 5.4 ist.
Deshalb habe ich mich auf den Rechner mit MX-21.3_x64 (5.10.0-28-amd64) konzentriert. Dort erscheint diese Option "gemeinsamer Speicher" nicht im virt-manager und deshalb wollte ich testen, ob man trotzdem auf der Kommandozeile virtiofs benutzen kann, um den gemeinsamen Speicher zu erhalten. Und siehe da, z.B. mit den beiden Kommandozeilen
sudo virt-xml MX-21 --edit --memorybacking source.type=memfd,access.mode=shared
sudo virt-xml MX-21 --add-device --filesystem driver.type=virtiofs,accessmode="passthrough",source.dir=/home/gn,target.dir=host_home
habe ich im Gast vollen Zugriff auf mein Homeverzeichnis /home/gn im Wirt.
Mit

gosia wrote: Sat Apr 06, 2024 6:57 am was anderes habe ich im Moment nicht zur Hand.

meinte ich nur, dass ich es gern mit einem Gast Kernel 5.4, also der Mindestanforderung testen wollte. Da muss ich noch in meinen alten ISOs rumsuchen, aber dummerweise steht da immer nur die Distri (MX-19) aber den damals benutzten Kernel muss man selbst erst raussuchen. Da ich aber eigentlich kaum Zweifel habe, dass es auch mit einem Gast Kernel 5.4 funktionieren würde, hat sich meine Energie in dieser Richtung bis jetzt in Grenzen gehalten.

loik wrote: Sat Apr 06, 2024 3:41 am Das wird ja mit der bereits geposteten Fehlermeldung verweigert.

äh, Du meinst diese Fehlermeldung

mount: /home/loik/VM-Austausch: Falscher Dateisystemtyp...

Und redest Du jetzt von einem Versuch mit den Kommandozeilen

Code: Select all

sudo virt-xml...

?
Verstehe ich nicht, kommt bei mir nicht. Und mein Gast hat ja auch nur Kernel 5.10
Und was meinen Versuchsgast betrifft, nein, das ist nichts besonderes dabei. Einfach eine ISO, die ich vor einem Wechsel auf MX-23 als Backup mit MX-Snapshot gemacht habe. Aber wie gesagt, ich kann es auch mit irgendeiner passenden älteren Distri probieren.

viele Grüsse gosia

Posted: **Sun Apr 07, 2024 3:02 am**

Hallo, Gosia.

Doch, ich hatte alles so verstanden und nachvollzogen, wie du es hier beschrieben hast.

Auf meinem Zweitrechner läuft MX-23.2 (Kernel 6.1.0-18-amd64) auch als Wirt. Aber damit habe ich keinerlei Probleme, weil dort im virt-manager die Option "gemeinsamen Speicher aktivieren" immer anwählbar ist und auch funktioniert, sofern der Gastkernel >= 5.4 ist.
Deshalb habe ich mich auf den Rechner mit MX-21.3_x64 (5.10.0-28-amd64) konzentriert. Dort erscheint diese Option "gemeinsamer Speicher" nicht im virt-manager und deshalb wollte ich testen, ob man trotzdem auf der Kommandozeile virtiofs benutzen kann, um den gemeinsamen Speicher zu erhalten. Und siehe da, z.B. mit den beiden Kommandozeilen
sudo virt-xml MX-21 --edit --memorybacking source.type=memfd,access.mode=shared
sudo virt-xml MX-21 --add-device --filesystem driver.type=virtiofs,accessmode="passthrough",source.dir=/home/gn,target.dir=host_home
habe ich im Gast vollen Zugriff auf mein Homeverzeichnis /home/gn im Wirt.

Ich war nur kurz irritiert, weil ich davon ausging, das am Anfang dieses Themas, du 23.2 als Wirt-System benutztes, es aber plötzlich schien, dass es eben doch die ganze Zeit 21.3 war.
Das hast du ja nun aufgeklärt.
Und ich kann sagen, es ist bei mir absolut die selbe Konstellation.

An ein und der selben Hardware entscheide ich beim Einschalten, ob ich 21.3 oder 23.2 hochfahre und als Wirt nutzen werde.
Und, genau wie du es beschreibst, ist in Wirt 23.2 Das Terminal nicht nötig, um die entsprechenden Einstellungen für den geteilten Ordner vorzunehmen.
Bei der Konstellation
Wirt 23.2 Kernel 6.1 / Gast 23.2 Kernel 6.1, funktioniert die Sache mit dem Austausch-Ordner wie gewünscht.
Bei
Wirt 23.2 Kernel 6.1 / Gast 21.3 Kernel 5.10, kommt diese Fehlermeldung:

mount: /home/loik/share: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /home/loik/share ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

("share" ist korrekt ! Vorher in den Virt-Manager-Einstellungen so festgelegt und mit mkdir im Gast, den dazugehörigen Ordner share, im Homeverzeichnis angelegt.)

Wenn der Wirt 21.3 ist, muss das Austauschverzeichnis sowie "shared memory" und die Verwendung von "virtiofs", so wie von dir und der verlinkten Anleitung beschrieben, angelegt werden bzw vorbereitet werden.
Bei der Konstellation
Wirt 21.3 Kernel 5.10 / Gast 23.2 Kernel 6.1, funktioniert der Austausch über diesen Ordner, wegen des nun Verfügbaren "virtiofs" und dem "shared memory" ebenfalls wie gewünscht.
Aber bei
Wirt 21.3 Kernel 5.10 / Gast 21.3 Kernel 5.10 erhalte ich wieder diese Fehlermeldung:

mount: /home/loik/share: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /home/loik/share ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

Immer wieder kommt in mir der Verdacht auf, dass es etwas ausmachen könnte, ob der Wirt SystemD oder SysVenit ist.
Ich benutze überwiegend SystemD.
Aber wenn ich zum Vergewissern SysVenit nehme, bleibt das negative Ergebnis das gleiche.

Was passiert bei dir, wenn du es testhalber mit einem SystemD-Wirt versuchst?

Ich habe in meinem Fundus an heruntergeladenen ISOs gestöbert und habe entdeckt, ein LinuxMint 20 "Una" mit Kernel 5.4.0-9

Als Wirt hatte ich MX-23.2 genommen.
Auch in diesem Versuch scheiterte das Mounten im Gast mit jener Fehlermeldung, dass das Dateisystem defekt sei.
Grundsätzlich war dieser Versuch noch entsetzlicher, weil hier noch nicht einmal die gemeinsame Zwischenablage funktionierte.
Ob das nun eine Eigenart dieser Distri ist oder nur daran liegt, weil hier noch Pakete fehlen, die ich in MX bereits "unbewusst" installiert habe, weiß ich nicht.

Posted: **Sun Apr 07, 2024 5:11 am**

Ebenfalls herausgesucht, als Gast, ein heruntergeladenes MX-21.1-64bit xfce, Kernel 5.10.0-16 von Juli 2022.

Wirt MX-23.2-64bit-xfce, kernel 6.1.0-18 / Gast MX-21.1-64bit xfce, Kernel 5.10.0-16

Code: Select all

$ mkdir ~/share
$ sudo mount -t virtiofs share ~/share

[sudo] Passwort für demo: 
mount: /home/demo/share: wrong fs type, bad option, bad superblock on /home/demo/share, missing codepage or helper program, or other error.

Also, kein Snapshot, an dem ich zuvor etwas verbastelt haben könnte.
Gemeinsame Zwischenablage funktioniert auf Anhieb tadellos ( also ist ML-20 keine gute Wahl als Gast ).

Dann als Gast versucht, ebenfalls ein heruntergeladenes ISO von Juli 2022,
MX-21.1-64bit-AHS-xfce, Kernel 5.16.0-5mx

Das Mounten funktioniert hier ebenso wenig.

Dann habe ich mir als Gast ein MX-19-64bit-xfxe kernel 19.4.0-6, von Oktober 2019, geschnappt.

Wie zu erwarten ging das Mounten auch hier im Gast nicht.
Zu der bekannten Fehlermeldung kam es aber nicht, weil zuvor vermeldet wurde:

Code: Select all

[sudo] Passwort für demo: 
mount: /home/demo/share: unknown filesystem type 'virtiofs'.

Nicht überraschend, eher bestätigend.

Aber auch hier funktionierte die gemeinsame Zwischenablage sofort, uneingeschränkt gut.
Ein Hoch auf MX.
( Mit MX-18.3-64bit-xfce, Kernel 4.19.0-5 vom Mai 2019 funktionierte die gemeinsame Zwischenablage aber nicht. )

Um das ganze abzurunden habe ich als Gast auch noch ein MX-Snapshot von Oktober 2021 herausgesucht.
MX-21-64bit-xfce kernel 5.14.0-4mx.

Auch hier beim Mounten die bereits gewohnte Fehlermeldung erhalten.

Posted: **Sun Apr 07, 2024 11:37 am**

Um diese Testreihe abzurunden, habe ich mir in eines meiner MX-21.3-64bit-xfce über MxPi den Kernel 6.1.0-17mx AHS installiert.

Der ist für mich in MX21 überhaupt nicht brauchbar, weil er weder displayLink kompatibel ist, noch erkennt er den USB-Wlan-Dongel mit 5 Ghz.
Mit den 5.10er Kerneln läuft das alles super.
In MX-23 geht es auch mit dem 6.1er Kerneln.

Jedenfalls, auch mit dem einem Gast MX-21.3-64bit-xfce Kernel 6.1.0-17mx AHS, die bekannte Fehlermeldung beim Mounten.

Ach ja, in diesem Fall war der Wirt ( zufällig ) MX-21.3-64bit-xfce Kernel 5.10.188-antix SytemD.

Um sicher zugehen, dass ich hier keinen Fehler in der Vorbereitung in der Konsole gemacht habe, habe ich die VM-MX.21.3 heruntergefahren.
Habe dann nichts weiter verändert, als das ISO ausgetauscht. MX-21.3 mit 6.1er Kernel gegen MX-23.1 mit 6.1er Kernel.
VM MX-23.1 hochgefahren.
Austauschordner in Home angelegt.
dann, wie heute zuvor schon x-mal vergeblich

Code: Select all

sudo mount -t virtiofs share ~/share

Dieses mal aber mit dem erwarteten Erfolg.
Und alles wunderbar.
Austausch funktioniert, wie es soll.

Wo ist nur der Unterschied, dass es bei dir mit Gast MX-21.3 geht und bei mir nicht ?

Posted: **Sun Apr 07, 2024 4:35 pm**

Hallo loik,

loik wrote: Sun Apr 07, 2024 11:37 am Wo ist nur der Unterschied, dass es bei dir mit Gast MX-21.3 geht und bei mir nicht ?

Das bin ich gerade auch am Überlegen. Nur dass mir heute gerade nichts gescheites einfällt. Aber morgen ist auch noch ein Tag...

viele Grüsse gosia

Posted: **Mon Apr 08, 2024 3:56 pm**

Hallo loik,
habe jetzt mal Ubuntu 22.04 (Kernel 5.15.0-25) als Gast probiert. Dummerweise wurde der Kernel während der Installation ohne mich zu fragen auf 6.5.0-27 angehoben, grummel.
dann die üblichen Schritte auf dem Wirt (5.10.0-28-amd64) mit

Code: Select all

sudo virt-xml...

und im Gast

Code: Select all

mkdir...
mount -t virtiofs...

funktioniert, aber eigentlich wollte ich ja einen Gast mit Kernel >= 5.4 testen.
Aber wie auch immer, ich glaube, das führt uns nicht besonders weiter. Das eine funktioniert bei mir, oder auch nicht, und bei dir kann es dann anders aussehen. Aber warum dem so ist, sehe ich auf diese Weise nicht. Und nur diese bis jetzt nicht sichtbaren Hintergründe würden helfen, so meine Meinung. Deshalb werde ich mich mal intensiver mit diesen Hintergründen beschäftigen, Sourcen studieren, das Internet durchforsten usw. Das geht natürlich nicht von heute auf morgen und der Erfolg ist ungewiss. Deshalb werde ich wohl in diesem Thread auch etwas pausieren (aber nicht aufhören). Zum Glück gibt es aber ja noch andere schlaue und noch schlauere Leute hier.

viele Grüsse gosia

PS. starten mit systemd bringt keinen Unterschied.

Posted: **Tue Apr 09, 2024 1:46 am**

Hallo, Gosia.
Danke für die intensiven Bemühungen.

Ich gehe davon aus, dass ich bei mir im MX-21.3-Gast, auch die gesamten, in MxPi angebotenen, 6er kernel installieren kann, ohne dass bei mir im Gast das Mounten des Austausch-Verzeichisses gelingen würde.

Hingegen hätte bei dir sicherlich auch der Ubuntu-Gast mit dem 5.15er kernel funktioniert.

Ich vermute deshalb, dass in deinen Wirten, ein oder mehrere Pakete installiert sind, die es ermöglichen und in meinen Wirten fehlen diese.
Denn es betrifft bei mir ja all meine Debian11 Gäste, egal ob sie im MX-21.3-Wirt oder im MX-23.2-Wirt laufen.

Grundsätzlich ist mal festzustellen, dass genau wegen deiner Bemühungen in diesem langen Thema, schon Klärungen und Fortschritte erreicht wurden.
Immerhin, lässt sich nun auch bei mir ein gemeinsamer Ordner, eines Wirtes mit 5.10er Kernel und einem Debian12-Gast einrichten und benutzen.

Grundsätzlich hängt mein Leben nicht davon ab.
Und die Option über USB besteht ja zur Not auch.

Dennoch, geht es uns wohl ähnlich, dass es ab irgendwann wichtiger wird, den Fehler zu ergründen, als die Funktion zu erlangen.

Und manchmal kommen die Erkenntnisse zugeflogen, wenn man, wie du es vor hast, die Sache mal ruhen lässt, aber nicht begräbt.

Schauen wir mal, was sich in den nächsten Monaten, bei Gelegenheit an möglichen Lösungen so anbietet.

Danke für dein intensives Interesse und Wirken an diesem Thema.

MX Linux Forum

virt-Manager - gemeinsamer bzw. geteilter Ordner

virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner

Re: virt-Manager - gemeinsamer bzw. geteilter Ordner