• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

FreeBSD 12.1 / vm-bhyve / Windows 10

PaulAtreides

Well-Known Member
Themenstarter #1
Ich habe Probleme Windows 10 mit bhyve zu installieren. Nachdem die Installation beendet wurde und das System neustartet stürzt bhyve mit der Fehlermeldung "Status 134" ab. Bhyve scheint ein Problem mit einem OP Code zu haben.

Die Installation habe ich nach dieser Anleitung durchgeführt:
https://github.com/churchers/vm-bhyve

CPU: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz (3000.10-MHz K8-class CPU)

Kennt jemand das Problem?
 

Andy_m4

Well-Known Member
#2
Kenn ich nicht. Bei mir funktioniert alles. Aber ich verwende vm-bhyve auch nicht, sondern rufe die VM direkt mit dem bhyve-Befehl auf:
Bash:
bhyve -c 2 -m 4G -H -w \
  -s 4,ahci-hd,/dev/zvol/softraid/VMs/win10-disk \
  -s 5,virtio-net,tap10 \
  -s 29,fbuf,tcp=0.0.0.0:5900,wait \
  -s 30,xhci,tablet \
  -s 31,lpc \
  -l com1,stdio \
  -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
  win10
Kann man vielleicht irgendwie rauskriegen, was da vm-bhyve im Hintergrund macht bzw. wie die die Maschine konfigurieren und starten?
 

datasmurf

Well-Known Member
#3
Ich nutze gelegentlich ebenfalls vm-bhyve und es gibt die Möglichkeit

Code:
debug="yes
in die Startconfig einzufügen. Ein ausführlicheres Log wird dann in die Datei bhyve.log geschrieben im vm-bhyve katalog/verzeichnis der vm.

Code:
#Beispiel(!)
/usr/vm/win10/bhyve.log
Soweit ich weiß (bitte korrigieren wenn nötig) ist exit code 134 der Syscall SYS_shutdown 134[1]

Du scheinst ja auch nicht der erste zu sein der diese Fehlermeldung/Exitcode bekommt[2]. Im FreeBSD Forum gibt es ebenfalls einen Thread[3] dazu.

[1] http://fxr.watson.org/fxr/source/sys/syscall.h#L139
[2] https://github.com/churchers/vm-bhyve/issues?q=is:issue+is:open+134
[3] https://forums.freebsd.org/threads/bhyve-error-134.58821/
 

mr44er

moderater Moderator
Mitarbeiter
#4
Code:
loader="uefi"
cpu="2"
cpu_cores="2"
memory=4G
wired_memory="no"
debug="on"
disk0_name="disk0"
disk0_dev="sparse-zvol"
disk0_type="virtio-blk"
network0_type="virtio-net"
network0_switch="public"
graphics="yes"
graphics_port="6000"
graphics_listen="x.x.x.x"
xhci_mouse="yes"
utctime="no"
Damit zuletzt erfolgreich die 2004er ISO installiert.
 

PaulAtreides

Well-Known Member
Themenstarter #5
Heute hat das starten geklappt. Ich habe nur die Debug Option hinzugefügt. Versteh ich nicht.

Läuft Windows und bhyve sonst stabil?

Bisher habe ich den Eindruck das ich mit VirtualBox ohne VM aktivität weniger CPU Auslastung hatte.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#7
Bevor du irgendwas weiter machst, aktualisiere erstmal auf FreeBSD 12.2. Alles andere ist verschwendete Zeit. Es kommt diese Woche (im Code ist es bereits fertig) und bringt eine ganze Reihe Bhyve-Verbesserungen. Unter anderem auch Performance- und Stabilitätsverbesserungen für Windows auf Intel Desktop CPUs. Die betreffen auch die Xeon E3 Serie, da ihnen die "großen" Virtualisierungsfunktionen fehlen.
 

Columbo0815

Kaffeemann
Mitarbeiter
#8
Heute hat das starten geklappt. Ich habe nur die Debug Option hinzugefügt. Versteh ich nicht.

Läuft Windows und bhyve sonst stabil?

Bisher habe ich den Eindruck das ich mit VirtualBox ohne VM aktivität weniger CPU Auslastung hatte.
Bei meiner AMD-CPU muss ich auch mit Debug starten, sonst läuft das nicht. Windows läuft hier sehr stabil. Ansonsten hätte ich ein Problem, da ich das Windows beruflich brauche.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#9
Bei meiner AMD-CPU muss ich auch mit Debug starten, sonst läuft das nicht.
Kann es sein, dass die Debug-Option dafür sorgt, dass Bhyve mit -w gestartet wird? Ich finde, dass die Option falsch herum ist. Ohne -w ist der Zugriff auf ein nicht implementiertes MSR tödlich, die VM bricht sofort ab. Das will man eigentlich nur zu Debugzwecken. Mit -w wird dem Gast die MSR als nixhtexistent zurückgegeben und die VM läuft weiter. Windows braucht zwingend -w, da es diverse MSR zu lesen versucht.
 

Columbo0815

Kaffeemann
Mitarbeiter
#10
Dann ist das ein Missverständnis meinerseits. Mit Debug meinte ich die -w Option. Allerdings habe ich gelesen, dass das nur bei AMD-CPUs (oder eben bei alten Intel-CPUs) notwendig ist...
 

PaulAtreides

Well-Known Member
Themenstarter #11
Bevor du irgendwas weiter machst, aktualisiere erstmal auf FreeBSD 12.2. Alles andere ist verschwendete Zeit. Es kommt diese Woche (im Code ist es bereits fertig) und bringt eine ganze Reihe Bhyve-Verbesserungen. Unter anderem auch Performance- und Stabilitätsverbesserungen für Windows auf Intel Desktop CPUs. Die betreffen auch die Xeon E3 Serie, da ihnen die "großen" Virtualisierungsfunktionen fehlen.
Hab heute das Update auf 12.2 durchgeführt und es läuft tatsächlich schneller.

Bringt es etwas wenn man disk0_type="virtio-blk" verwendet? Leider bootet das System nicht mehr wenn ich das umstelle.
Treiber habe ich installiert. Bei der Netzwerkkarte funktioniert das mit network0_type="virtio-net"
 

mr44er

moderater Moderator
Mitarbeiter
#12
Bringt es etwas wenn man disk0_type="virtio-blk" verwendet?
Ja, alles andere kann man als lahm bezeichnen.

Leider bootet das System nicht mehr wenn ich das umstelle.
Richtig. Man muss es so gesetzt installieren und bereits im setup den virtio-Treiber übergeben. Also Laufwerk1 win.iso, Laufwerk2 treiber.iso

Kann sein, dass man es in einer bestehenden Installation friemeln kann, mir ist da aber nichts bekannt.
 

mr44er

moderater Moderator
Mitarbeiter
#14
Du musst den Ordner viostor statts vioscsi nehmen, fällt man gerne mal drauf rein.

Statts abstürzen sollte es maximal meckern.
 

mr44er

moderater Moderator
Mitarbeiter
#16
Da fällt mir nicht viel ein. Du könntest eine 2004er .iso probieren.
Evtl. ist eine der beiden ISOs beim Downloaden fehlerhaft übertragen worden.

Oder es ist was mit der Architektur, was mich nicht betraf, weil das bei mir auf AMDs läuft.