Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
03.12.2021, 07:41:19

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 26109
  • Letzte: khr37
Statistiken
  • Beiträge insgesamt: 765717
  • Themen insgesamt: 61432
  • Heute online: 466
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  qemu + kvm  (Gelesen 11801 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Re: qemu + kvm
« Antwort #45 am: 08.08.2016, 11:28:31 »
Ja, ich lebe noch ;)

Bin mittlerweile auf Mint-Mate 18 umgestiegen. In erster Linie nur weil das Repo aktueller ist, aber das ist auch nur relativ.
Die Qemu-versionen 2.5 und auch 2.6 haben einen Installationsbug der bei einigen Usern auftreten kann. Klar, ich gehöre natürlich zu denen. Hat mich etliche Stunden gekostet um das in Erfahrung zu bringen.
Da war ich gezwungen die aktuellste GIT-Version zu kompilieren, und das ohne Ahnung. Eines der grauenhaftesten Dinge unter Linux. Diese ganzen verdammten Abhängigkeiten und deren Abhängigkeiten usw. herauszufinden, gefühlte 100 Pakete zu installieren, da möchte man gleich wieder zu Windows zurückgehen. Aber ich bin ja belastbar und Rentner haben Zeit ;)

Hab also momentan qemu 2.6.92 kompiliert und installiert. Die Windows 7 Installation (nur per Script) funktionierte problemlos. Grafikkarte, Maus und Tastatur durchreichen, alle NTFS Laufwerke einbinden (Virtio), mit smb auf die Host-Freigaben zugreifen usw., damit hab ich mittlerweile Routine. Aber die Optimierung des Scripts um in der Nähe von "NATIV" zu gelangen, ist auch ein gewisser Horror. Gefühlt gibt es für mich kaum eine schlechtere Dokumentation als für qemu. Klar gibt es haufenweise Infos über qemu, aber die sind rudimentär gehalten ohne verständliche Beispiele, UND meistens in englisch. Mit dem Googletranslater hab ich oft Spaß gehabt.

Ok, die Win7-VM läuft nun ziemlich gut. Die 3D-Performance ist fast nativ, die SSD-Performance hinkt u.a. etwas zurück. Ich kann das gut beurteilen weil hier auch eine "echte" Win7 Installation vorhanden ist. Beide, die "Echte" und die "Virtuelle" sind ähnlich installiert und konfiguriert worden. Und zum Performancevergleich sind auch identische Benchmarkprogramme (3D-Mark11,Cinebench R15,RealBench,PerformanceTest8 und CrystalDiskMark 5) installiert.

Es gibt aber noch ein Problem das mich ordentlich nervt. Und zwar die Laufwerkszuordnung unter Windows 7 (VM).

Im Qemuscript sieht das u.a. folgendermaßen aus.

[...]
-device virtio-scsi-pci,id=scsi \
-drive file=/media/user/disk/VM/win7.raw,id=boot0,format=raw,if=none,aio=native,cache=none,index=0 -device scsi-hd,drive=boot0 \
-drive file=/dev/sda2,id=disk1,format=raw,if=none,aio=native,cache=none,index=1 -device scsi-hd,drive=disk1 \
-drive file=/dev/sdb3,id=disk2,format=raw,if=none,aio=native,cache=none,index=2 -device scsi-hd,drive=disk2 \
-drive file=/dev/sdb4,id=disk3,format=raw,if=none,aio=native,cache=none,index=3 -device scsi-hd,drive=disk3 \
[...]

In diesem Fall werden normalerweile folgende Laufwerksbuchstaben (Windows) vergeben:

win7p.raw C:
sda2 D:
sdb3 E:
sdb4 F:

Wunderbar ! Das funktioniert aber nur bei ersten Windowsstart. Bei jedem Neustart werden abwechselnd D: und E: vertauscht. Echt lustig und nervig.
Also, ich boote den Computer, Mint ist aktiv. Die Win7-VM wird gestartet, die Laufwerkszuordnung ist ok.

win7p.raw C:
sda2 D:
sdb3 E:
sdb4 F:

Die VM wird neugestartet:

win7p.raw C:
sda2 E:
sdb3 D:
sdb4 F:

Die VM wird neugestartet:

win7p.raw C:
sda2 D:
sdb3 E:
sdb4 F:

usw.

Hat dafür irgendjemand eine Erklärung. Ich kann das mittlerweile auf 3 verschiedenen Computern reproduzieren. Die Zuordnung läßt sich ebensowenig unter Win7 zuverlässig ändern (Datenträgerverwaltung), wenn überhaupt.

Wer einen Tipp oder eine Idee hat, her damit :)