bhyve und windows 10

bsd4me

Well-Known Member
Hallo,

ich möchte gerne Windows 10 mittels bhyve virtualisieren. Dazu habe ich mir ein Windwos 10 Image (und auch Prod.-key) heruntegeladen. Hier meine Randbedingungen - wo zu installeiren wäre:

user(compi,pts/0,21:13:24) win10-en > ll
total 1
-rw-r--r-- 1 root wheel 137438953472 Jun 19 20:03 os_disk.img
lrwxr-xr-x 1 root wheel 76 Jun 19 20:04 windows10.iso -> /home/xxx/path/to/iso

ich nehme als Anleitung: https://www.ateamsystems.com/tech-blog/howto-windows-10-bhyve-w-freebsd-11/ - ich selber nutzte noch version 11.2 :)

nun starte ich im Verzeichnis

bhyve -c 2 -m 4G -H -w \
-s 0,hostbridge \
-s 3,ahci-cd,windows10.iso \
-s 4,ahci-hd,os_disk.img \
-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

bekomme immer ein:

vm_create: Device not configured

kldstat sagt mir:

Id Refs Address Size Name
1 51 0xffffffff80200000 20647f8 kernel
2 2 0xffffffff82266000 a380 opensolaris.ko
3 1 0xffffffff82271000 381080 zfs.ko
4 2 0xffffffff825f3000 13509e8 nvidia.ko
5 6 0xffffffff83944000 92c0 linux_common.ko
6 3 0xffffffff8394e000 a4ab8 linux.ko
7 1 0xffffffff839f3000 6ff0 sem.ko
8 1 0xffffffff839fa000 356cd8 vmm.ko
9 1 0xffffffff83d51000 7600 if_tap.ko
10 1 0xffffffff83e21000 41f0 linprocfs.ko
11 1 0xffffffff83e26000 f4ef9 nvidia-modeset.ko
12 1 0xffffffff83f1b000 5fb8 if_bridge.ko
13 1 0xffffffff83f21000 3b78 bridgestp.ko
14 1 0xffffffff83f25000 2328 ums.ko
15 1 0xffffffff83f28000 1780 uhid.ko
16 1 0xffffffff83f2a000 31e50 linux64.ko

müsste doch alles da sein... ich weiss nicht, wo ich suchen musss...

VG Norbert
 
Note: If you opted for using a ZFS dataset as a virtual disk you’ll specify the disk as the zvols dev node, for example: /dev/zvol/zroot/vms/win10/os_disk instead of os_disk.img

Geraten...

andernfalls debug="on", das legt ein log ins Verzeichnis der vm.
 
Nur um ganz sicher zu sein: Du hast das mit Root-Rechten gestartet? Und die CPU wird von bhyve unterstützt? Letzteres müsstest Du sehen können, wenn Du den vmm.ko mal händisch lädst - da müsste sonst eine Warnmeldung kommen.
 
so Leute, danke für die Antworten - aber ich musste im BIOS nur SVM enablen - tja, darauf hätte ich früher kommen können :)
 
Ein kleiner Hinweis dazu: Auch Windows VMs laufen performanter mit "virtio-blk" statt "ahci-hd". Dazu braucht man *eigentlich* nur die virtio-Treiber für Windows, die du für dein "virtio-net" vermutlich sowieso schon hast. Eigentlich, denn mit bhyve funktioniert es nicht, aber dieser Patch in /usr/src schafft Abhilfe:
Code:
Index: usr.sbin/bhyve/block_if.h
===================================================================
--- usr.sbin/bhyve/block_if.h    (revision 340722)
+++ usr.sbin/bhyve/block_if.h    (working copy)
@@ -41,7 +41,7 @@
 #include <sys/uio.h>
 #include <sys/unistd.h>
 
-#define BLOCKIF_IOV_MAX        33    /* not practical to be IOV_MAX */
+#define BLOCKIF_IOV_MAX        128    /* not practical to be IOV_MAX */
 
 struct blockif_req {
     struct iovec    br_iov[BLOCKIF_IOV_MAX];
Ich hatte den mal in einer Mailingliste gefunden und staune eigentlich, dass er nie seinen Weg in die offiziellen FreeBSD sources gefunden hat...
 
Ich hatte den mal in einer Mailingliste gefunden und staune eigentlich, dass er nie seinen Weg in die offiziellen FreeBSD sources gefunden hat...
Inzwischen ist er angekommen: https://svnweb.freebsd.org/base?view=revision&revision=347033 Und ich würde dann auch gleich noch den hier mit reinpatchen: https://svnweb.freebsd.org/base?view=revision&revision=347960 Sonst bleibt Windows ab und an hängen.

Bhyve hatte eine etwas tote Phase, nachdem Peter Grehan zu Apple gewechselt ist. Inzwischen gibt es aber neue Entwickler, die dran arbeiten und sich nun erstmal durch das Backlog der letzten zwei Jahre baggern.
 
nun läuft fast alles - mir fehler noch eine funktionierende Internet Verbindung :( Ich habe mich an die oben genannte Anleitung gehalten - Der virtio Treiber ist da... Aber ich habe immer "No Internet access". Mein ifconfig auf dem host sieht so aus:

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:93:d9:4a:00:00
nd6 options=9<PERFORMNUD,IFDISABLED>
groups: bridge
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
tap10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:8d:14:f7:0a
hwaddr 00:bd:8d:14:f7:0a
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
groups: tap
Opened by PID 1783

Danke für Hilfe... Norbert :)
 
Nachtrag, da übersehen: Auf jeden Fall fehlt die Host-NIC in der Bridge. Ohne die kann es nicht gehen, außer du kleisterst ein NAT dazwischen. Was du wahrscheinlich nicht willst.

Die IP-Adresse des Hosts muss auf der Bridge und nicht einem ihrer Member-Interfaces liegen, denn sonst passieren seltsame Sachen. Empfangende und sendende NIC stimmen dann nicht überein, was den Switch aus dem Tritt bringt. Es empfiehlt sich auch der Bridge eine MAC-Adresse zu setzen, da die zufällig generieren MACs nur auf einem Host garantiert eindeutig sind. Ich habe daher schon MAC-Kollissionen gesehen, was nicht allzu schön zu debuggen war... Bei mir sieht es in der rc.conf so aus, das Kabel steckt in em0:

Code:
ifconfig_em0="up"
cloned_interfaces="bridge0"
ifconfig_bridge0="ether 02:bc:79:92:85:00 addm em0 stp em0 up"
ifconfig_bridge0_alias0="inet 192.168.142.10/24"
ifconfig_bridge0_ipv6="inet6 auto_linklocal accept_rtadv"


Wenn es danach nicht geht, würde vielleicht ein ipconfig /all aus dem Windows Gast helfen.
 
so, ich hab's!!!

oh menno, waren die Tomaten auf meinen Augen gross heute... Ich muss ja das richtige network interface angeben - nämlich re0 und nicht em0

cloned_interfaces="bridge0 tap10"
ifconfig_bridge0="addm re0 addm tap10"

so, nun bin ich wieder klüger, entspannter und neu bereit für weitere "Schandtaten" ... ;-)

Danke Euch!!! VG aus Münster, Norbert
 
Tut nichts zur Sache, aber dennoch: Ich nutze inzwischen auch -S (Wire guest memory), da es Voraussetzung für pcipassthru ist. Ebenfalls pinne ich die an den Gast durchgereichten vcpus auf ausgewählte Hostcpus, damit ich am CPU-Monitor von Xfce erkennen kann, ob die Last vom Host oder vom Guest kommt. :)

Noch ein tut nichts zur Sache: Ich bin seit 12.0 deutlich glücklicher mit bhyve als noch mit 11.2. Du kannst ab 12.0 mit -c nicht nur cpus sondern auch sockets, cores oder Threads durchreichen. Vielleicht möchtest du dir 12.0 mal ansehen :)

Alle guten tut nichts zur Sache sind 3: Wenn du zfs nutzt, lege ich dir ein Zvol als Guest-Platte ans Herz. Was ich noch nicht getestet habe, mich aber reizt: nvme statt ahci-hd.
 
Oh ... das ist ja ein sehr interessanter Thread - und motiviert auf jeden Fall sich mit bhyve nochmals neu zu befassen

Grüße Walter
 
Tut nichts zur Sache, aber dennoch: Ich nutze inzwischen auch -S (Wire guest memory), da es Voraussetzung für pcipassthru ist. Ebenfalls pinne ich die an den Gast durchgereichten vcpus auf ausgewählte Hostcpus, damit ich am CPU-Monitor von Xfce erkennen kann, ob die Last vom Host oder vom Guest kommt. :)

Noch ein tut nichts zur Sache: Ich bin seit 12.0 deutlich glücklicher mit bhyve als noch mit 11.2. Du kannst ab 12.0 mit -c nicht nur cpus sondern auch sockets, cores oder Threads durchreichen. Vielleicht möchtest du dir 12.0 mal ansehen :)

Alle guten tut nichts zur Sache sind 3: Wenn du zfs nutzt, lege ich dir ein Zvol als Guest-Platte ans Herz. Was ich noch nicht getestet habe, mich aber reizt: nvme statt ahci-hd.

super danke für die Tipps - aber "tut nichts zur Sache" :) Nun, Windows 10 läuft, es gibt eignetlich nur noch 2 Punkte die noch zu lösen sind: (1) Es gibt masigs logs das Register nicht zu lesen oder schreiben sind und (2) hätte ich auch gerne Sound durchgereicht... Das erste ist aber unkritisch, aber auch unschön. Die Sache mit ZFS/ZVOL habe ich schon umgesetzt - leider noch nicht virtio an die Platte zu "greifen"... Naja, lieber kleine schritte als dauernd hinfallen :)

Viele Grüße an alle, Norbert
 
Es gibt masigs logs das Register nicht zu lesen oder schreiben sind
Die Meldungen kannst du unterdrücken, indem du Bhyve mit -w startest.

hätte ich auch gerne Sound durchgereicht
Dafür gibt es Patches, die nun, wo Bhyve wieder mehr Aufmerksamkeit bekommt, vielleicht auch mal eingehen werden: https://reviews.freebsd.org/D12419

Aber noch mal ganz allgemein: Ich habe das Problem, dass Windows 10 schon seit 1809 auf all meinen Maschinen in Bhyve sehr "zäh" ist. Das betrifft auch das neuere 1903. Es ist, zumindest bei Intel bzw. VT-x als Backend, unabhängig von der CPU, egal ob mein i7-2600k, der i7-6700k oder das Ivy Bridge Ding im Büro. Und auch unabhängig von der Größe der VM, es tritt auch noch mit 4 Kernen und 8GB RAM im Gast auf. Symptome sind Gedenksekunden, also: Doppelklick auf "Computer" -> CPU-Last auf dem Host schießt auf 100% -> 2 Sekunden warten -> Explorer öffnet sich. Diese CPU-Spikes mit der Wartezeit gibt es bei fast alles Interaktionen, was das Windows unbenutzbar macht. Das passiert auch wirklich nur unter den beiden Windows Versionen, nicht unter älteren Windowsen oder anderen Systemen.

Ich habe diverse Dinge ausprobiert, aber den Fehler bisher nicht gefunden. Verschiedene Bhyve-Optionen quergetestet, CPI Bug Mitigations auf dem Host und im Gast abgeschaltet, Power Management abgeschaltet, virtio-blk und NVMe statt ahci-hd... Ich wäre sehr interessiert daran, ob auch jemand anders solche Probleme hat. Und wenn nicht, welche CPU der Host hat und, wenn möglich, das Bhyve-Kommando, mit dem die VM gestartet wird.
 
super danke für die Tipps - aber "tut nichts zur Sache" :) Nun, Windows 10 läuft, es gibt eignetlich nur noch 2 Punkte die noch zu lösen sind: (1) Es gibt masigs logs das Register nicht zu lesen oder schreiben sind

Ich möchte hier Yamagi widersprechen. Die Meldungen - soweit du die in der Konsole meinst - bekomme ich auch, obwohl ich mit -w starte. Am Rande: Ohne -w läuft Windows hier überhaupt nicht. Weil mich die Meldungen extrem nerven, starte ich den Gast einfach aus einer tmux-Sitzung, welche ich dann schließe (also nicht komplett sondern nur das eine "Terminal" davon).

und (2) hätte ich auch gerne Sound durchgereicht... Das erste ist aber unkritisch, aber auch unschön. Die Sache mit ZFS/ZVOL habe ich schon umgesetzt - leider noch nicht virtio an die Platte zu "greifen"... Naja, lieber kleine schritte als dauernd hinfallen :)

Viele Grüße an alle, Norbert
Das hängt jetzt ganz davon ab, wofür du den Gast brauchst. Ich greife per rdp auf den Gast zu. Wenn dir das reicht, hast du auch Sound ohne den von Yamagi genannten Patch.

Die von Yamagi genannten Probleme kenne ich - wie er aber schon weiß - nicht. Ich achte aber mal darauf. Für den Fall, dass es hilft.. Ich starte bhyve mit:

bhyve -S
-c threads=8
-m 16G
-H
-w
-s 0,amd_hostbridge
-s 4,ahci-hd,/dev/zvol/zroot/win10disk0
-s 7,passthru,1/0/0
-s 10,virtio-net,tap0
-s11,fbuf,tcp=0.0.0.0:5900,w=1600,h=900
-s 30,xhci,tablet
-s31,lpc -lbootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -p0:1 -p1:2 -p2:3 -p3:4 -p4:5 -p5:6 -p6:7 -p7:8 win10 &

Und habe einen AMD Threadripper.

HTH
 
Ich möchte hier Yamagi widersprechen. Die Meldungen - soweit du die in der Konsole meinst - bekomme ich auch, obwohl ich mit -w starte. Am Rande: Ohne -w läuft Windows hier überhaupt nicht. Weil mich die Meldungen extrem nerven, starte ich den Gast einfach aus einer tmux-Sitzung, welche ich dann schließe (also nicht komplett sondern nur das eine "Terminal" davon).
Könntest das ein AMD vs. Intel Problem sein? Bei mir geht es definitiv auch ohne -w, nur sehe ich dann die Meldungen.
 
Zurück
Oben