qemu IP Adresse unbekannt

yamaharacer

Lt. Junior Grade
Registriert
Jan. 2008
Beiträge
485
Hallo zusammen,

ich versuche gerade qemu irgendwie auf meinem Manjaro System zum laufen zu bekommen. Aktuell habe ich nämlich drei Festplatten eingebaut, auf einer ist Manjaro, die zweite hat Windows und die dritte hat OSX (opencore).

Da mir das alles mittlerweile etwas zu viel wird, und ich OSX und Windows mittlerweile echt nur noch für Spielereien oder Software brauche, die es nur dort gibt (meistens ganz alte Software), würde ich gerne die Festplatten anderweitig verwenden und alles mit qemu oder ähnlicher Software virtualisieren.

Leider stehe ich bei qemu bereits zu beginn vor dem Problem, dass ich keine Netzwerkverbindung in die VM erhalte.
Ich bin nach dieser Anleitung vorgegangen:
https://www.howtoforge.de/anleitung/wie-man-kvm-qemu-auf-manjaro-archlinux-installiert/


Leider bleibt meine IP Adresse auch nach aktuallisieren auf unbekannt stehen.
Auf meinem Host System habe ich eine feste IP hinterlegt.

Hat jemand Rat?
 

Anhänge

  • 2022-10-02_09-41.png
    2022-10-02_09-41.png
    86 KB · Aufrufe: 290
  • 2022-10-02_09-42.png
    2022-10-02_09-42.png
    32,3 KB · Aufrufe: 276
  • 2022-10-02_09-43.png
    2022-10-02_09-43.png
    26,4 KB · Aufrufe: 271
Am aller einfachsten ist es, wenn die Bridge im gleichen Netzwerk wie der Rest des Netzwerkes und auch dein Router ist. Also z.B. 192.168.1.0/24 Kommt aber darauf an was im Router eingestellt ist. Dem Host gibst du eine feste IP im gleichen Netz. NAT brauchst du dann nicht mehr. Alle VM holen sich ihre IP dann vom DHCP Server im Router.
Ergänzung ()

Noch mal ein paar Anmerkungen:
  • Ich bin mir nicht sicher, ob man ein installiertes OS, so einfach in einer VM booten kann. Ich habe immer neu installiert.
  • Wenn Du viel mit VM machen willst, schau dir Proxmox an, das geht auch ohne subscription
  • Bevor du komplett umsteigst, probiere erst mal aus, ob dir die "VDI Experience" überhaupt zusagt.
Also gerade für virtuelle Desktops (VDI) ist Virtualierung problematisch, da die GPU Hersteller keine Consumer Grafikkarten unterstützen (NUC9 ist die Ausnahme), und alles andere (z.B. GPU passthrough) ist sehr experimentell, d.h. es geht mal, bis zum nächsten update.
 
Zuletzt bearbeitet:
qemu/kvm mit virt-manager auf dem desktop ist angenehmer zu nutzen, wenn du statt der "system" verbindung eine user session nimmst. dazu einfach eine neue verbindung anlegen (file -> add connection):

1664699676655.png


das hat einerseits den vorteil, dass man sich beim "usermode networking" keine gedanken machen muss und andererseits dass man die hdd-images und isos bei sich im home-directory speichern kann.

bei der "system" verbindung liegt das alles unter "/var/lib/libvirt/images", wo man als user standardmässig keinen zugriff hat und auf isos im home will libvirtd aufgrund mangelnder berechtigungen auch nicht zugreifen.
 

Anhänge

  • 1664699469916.png
    1664699469916.png
    136,2 KB · Aufrufe: 201
  • 1664700292637.png
    1664700292637.png
    35,6 KB · Aufrufe: 201
Stell das Netzwerk von deinem Host auf eine Bridge um und da die VMs dranhängen, dann wird sich das so verhalten wie du es vermutlich erwartest.
 
Besser als der Netzwerktyp "bridge" wäre "network". "Using a virtual network is particularly indicated if the host has dynamic networking (e.g. NetworkManager), or using wireless." – Quelle.

In meinem Dokument "Arch Linux [Setup]" wird bspw. auch beschrieben, wie man Virt-Manager auf Systemebene mit "default NAT/DHCP networking" einrichtet.
@0x8100 Die Passwortabfrage wird auch umgangen. Die ISOs kann man auch vom HOME-Verzeichnis einbinden. Was ist denn so schlecht daran, dass die qcow2-Dateien in /var/lib/libvirt/images/ liegen?

Vielleicht funktioniert es ja dann bei dir.
 
agon schrieb:
Die ISOs kann man auch vom HOME-Verzeichnis einbinden. Was ist denn so schlecht daran, dass die qcow2-Dateien in /var/lib/libvirt/images/ liegen?
mit der "system" verbindung kann libvirtd nicht auf isos im home verzeichnis zugreifen, da der prozess keine zugriffberechtigungen auf die dateien dort hat. ebenso kann ich aus dem gleichen grund als user nicht mal eben die imagedateien unter /var/lib/libvirt/images/ anfassen, um die z.b. auf eine andere maschine zu kopieren, ein backup zu machen oder eine iso dahin zu kopieren. ein weiterer nachteil ist, wenn man home separat gemountet hat und das root-fs relativ klein ist, dann ist da kein platz für vm-images. kann man natürlich alles ändern, aber bei einem single-user desktopsystem ist es einfacher, alle seine daten einfach in seinem home zu haben.

mit der user session habe ich das gleiche verhalten wie mit virtualbox, wo man alles im "Virtualbox VMs" verzeichnis in seinem home hat. ist einfach bequemer :)
 
0x8100 schrieb:
mit der "system" verbindung kann libvirtd nicht auf isos im home verzeichnis zugreifen, da der prozess keine zugriffberechtigungen auf die dateien dort hat.
Sollte eigentlich funktionieren. Create a new virtual maschine > Local install media > Browse > Add pool "+":
  • Name: ISO
  • Target Path: ~/Downloads/ISO (dort hausen dann die ISO-Dateien)
qemu:///session hat halt eine schlechte Netzwerk-Leistung, siehe bspw.:
"On the other hand it can’t access system resources that well, which includes network setup that is known to be hard with qemu:///session. It falls back to slirp networking which is functional but slow and makes it impossible to be reached from other systems." – Quelle.

Das "default NAT/DHCP networking" funktioniert im Usermode nicht.

Es gibt doch bestimmt Wege, den default pool ('/var/lib/libvirt/images/') zu sichern. Einige Konfigurationsdateien sind halt auch im /etc/-Verzeichnis. Die möchte man doch auch "einfach" gesichert bekommen.
 
Danke für die ganzen Infos, aber mittlerweile verstehe ich nur noch Bahnhof. Das waren irgendwie zu viele "man könnte" oder "das wäre besser".

Was ich jetzt versucht habe:
0x8100 schrieb:
qemu/kvm mit virt-manager auf dem desktop ist angenehmer zu nutzen, wenn du statt der "system" verbindung eine user session nimmst. dazu einfach eine neue verbindung anlegen (file -> add connection):

das hat einerseits den vorteil, dass man sich beim "usermode networking" keine gedanken machen muss und andererseits dass man die hdd-images und isos bei sich im home-directory speichern kann.

bei der "system" verbindung liegt das alles unter "/var/lib/libvirt/images", wo man als user standardmässig keinen zugriff hat und auf isos im home will libvirtd aufgrund mangelnder berechtigungen auch nicht zugreifen.
Habe ich probiert siehe Bilder im Anhang, erhalte natürlich sofort das nächste Problem dass ich keine Berechtigung habe um ein virtuelles Netzwerk zu erstellen.



agon schrieb:
Was ist denn so schlecht daran, dass die qcow2-Dateien in /var/lib/libvirt/images/ liegen?

Vielleicht funktioniert es ja dann bei dir.
Ich habe es auch bereits mit dem Standardverzeichnis /var/lib/libvirt/images/ probiert aber da hat sich leider auch nichts geändert.
 

Anhänge

  • 2022-10-02_16-41.png
    2022-10-02_16-41.png
    72,2 KB · Aufrufe: 184
  • 2022-10-02_16-42.png
    2022-10-02_16-42.png
    38,9 KB · Aufrufe: 168
  • 2022-10-02_16-42_1.png
    2022-10-02_16-42_1.png
    83,5 KB · Aufrufe: 180
agon schrieb:
Sollte eigentlich funktionieren. Create a new virtual maschine > Local install media > Browse > Add pool "+":
1664724196181.png

agon schrieb:
qemu:///session hat halt eine schlechte Netzwerk-Leistung,
schlecht ist relativ. auf jeden fall ausreichend. knapp 2Gb/s im user mode hier reichen locker. wie gesagt, das ist für den desktop use-case.
1664725280965.png

Ergänzung ()

yamaharacer schrieb:
keine Berechtigung habe um ein virtuelles Netzwerk zu erstellen.
brauchst du doch auch gar nicht...
 
Zuletzt bearbeitet:
@0x8100 Die Meldung konnte ich ignorieren. Da steht "may not have search permissions". Sonst siehe hier.
2Gb/s im user mode klingen gut! Hättest du auch Ping-Vergleiche o.ä.?
Ginge denn "PCI passthrough via OVMF" gut in der user session?

@yamaharacer
Für user-session: Evtl. # systemctl disable --now libvirtd.service; ausführen und alles mit "QEMU/KVM" deaktivieren.
 
@agon ignorieren konnte ich die warnung auch, aber es hilft dann später nicht :) der link hilft auch nur bedingt, ich möchte mein home-dir ja nicht dem libvirtd user bzw. der gruppe zugänglich machen.

1664728162332.png


agon schrieb:
Hättest du auch Ping-Vergleiche o.ä.?
da gibt es keine auffälligkeiten. habe gerade nur windows in einer vm, mehr als "<1ms" kann ich gerade nicht anbieten :)
agon schrieb:
Ginge denn "PCI passthrough via OVMF" gut in der user session?
nein, das geht nicht. eine der einschränkungen in der user session.
 
  • Gefällt mir
Reaktionen: agon
@agon ich weiss ja warum es nicht geht :) ich müsste nur den kompletten pfad bis zur iso für libvirtd lesbar machen. da würde aber z.b. bedeuten, mein home-dir world-readable zu machen oder libvirtd mit in meine gruppe aufzunehmen oder sowas. man könnte auch ein verzeichnis ausserhalb meines home anlegen, auf das mein user und libvirtd gemeinsam zugreifen können. aber ich kann mir das auch sparen und die user-session nehmen :)

im vergleich zu der system-session ist das netzwerk in der user-session schon lahm. auf meinem proxmox ist der test mit iperf zwischen vm und host um ein vielfaches schneller. allerdings ist das usermode-networking eben schnell genug für ab und zu mal windows starten. für irgendwas performance-kritisches würde man das nicht nehmen.
 
0x8100 schrieb:
mit der user session habe ich das gleiche verhalten wie mit virtualbox, wo man alles im "Virtualbox VMs" verzeichnis in seinem home hat. ist einfach bequemer :)



Bei mir funktioniert damit aber nicht virtiofs ( https://virtio-fs.gitlab.io/ ). Das ist für mich das Äquivalent zu "shared Folder". Wie machst du das in der user session?
 
Zuletzt bearbeitet:
oh man, scheinbar hat das die ganze Zeit bereits funktioniert, bei der Windows Installation fehlen allerdings die Treiber für die virtuelle Netzwerkschnittstelle.

Weiß jemand wo man die her bekommt?

habs im arch wiki gefunden. funktioniert aber weiterhin nicht. die schnittstelle wird einfach nicht durchgereicht.


Edit2: Als Session Benutzer habe ich es nun hinbekommen durch neuinstallation der virtio Netzwerktreiber. In der System Session funktioniert diese herangehensweise zwar auch, aber es wird dann kein Netzwerk identifiziert. Einstellungen sind bei beiden gleich.
 

Anhänge

  • 2022-10-03_12-04.png
    2022-10-03_12-04.png
    179 KB · Aufrufe: 167
Zuletzt bearbeitet:
hab ich schon probiert, dann erhalte ich wieder den Fehler 56 und den Treiber kann ich aufgrund der automatischen Treiber installation nicht aktualisieren. Ist irgendwie verzwickt.
 
Was hast du schon probiert mit welchem Treiber?

Deinstalliere den vorhandenen Treiber mal, dann wähle bei der Treibersuche den spezifischen Ordner in der VirtIO iso aus.
 
LochinSocke schrieb:
Wie machst du das in der user session?
wenn ich dateien zwischen host und vm austauschen will, dann nehme ich einfach ssh. wenn man das in der windows-vm als laufwerk haben will, kann man das mit sshfs-win machen. anonsten reicht auch filezilla/winscp oder einfach das gute alte ssh kommando in der console :)
 
Zurück
Oben