Ubuntu 20.04 in bhyve?

bsd4me

Well-Known Member
Hallo,

ich habe vor kurzem versucht, Ubuntu 20.04 in eine bhyve VM zu installieren. Der Installationsvorgang ging tatsäch mit:

bhyve -c 2 -m 2048M -H -P -A -l com1,stdio \
-s 0:0,hostbridge \
-s 1:0,lpc \
-s 2:0,virtio-net,tap1 \
-s 3,ahci-cd,/home/xxx/images/ubuntu/ubuntu-20.04-live-server-amd64.iso \
-s 4,ahci-hd,/dev/zvol/zroot/ubuntu20.04 \
-s 29,fbuf,tcp=0.0.0.0:5900,wait \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
ubuntu

Aber leider das eigentliche nachher nicht:

grub-bhyve -m /local/xxx/ubuntu20.04/ubuntu.map -r hd0,msdos1 -M 4096M ubuntu

bhyve -c 4 -m 4096M -w -AI -H -P -l com1,stdio \
-s 0:0,hostbridge \
-s 1:0,lpc \
-s 2:0,virtio-net,tap1 \
-s 3,ahci-hd,/dev/zvol/zroot/ubuntu20.04 \
ubuntu

es gab immer einen Abbruch (nach dem grub-bhyve Aufruf)... ich weiss, es gibt schon Lösungen wie cbsd oder vm-bhyve - aber ich wollte es absichtlich mal so machen :) Vielleicht kann mir trotzdem jemand helfen?!

Vielen Dank! Norbert :)
 
Für mich ist das auch wieder ein "ganz klarer Fall" von einer "Errata Notice". Kürzlich habe ich in einem Bug Report (zu einem ganz anderem Thema) gelesen, dass man einen weiteren Bug Report aufmachen soll, wenn man der Meinung ist, dass es in -RELEASE einfließen soll.

Ist das die Praxis? Dann sollte man doch überlegen, jeweils einen Bug Report aufzumachen. ich glaube das würde FreeBSD echt gut tun. :)
 
Also die Installation klappt ja gut - nur wenn man es laufen lassen möchte kommt:

GNU GRUB version 2.00

Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions.
Anywhere else TAB lists possible device or file completions.


grub> exit
vm exit[0]
reason SVM
rip 0x0000000000000000
inst_length 0
exitcode 0x7f
exitinfo1 0
exitinfo2 0
Abort trap
root(host,pts/1,17:50:26) ubuntu20.04 #
root(host,pts/1,17:50:33) ubuntu20.04 #


Danke und viele Grüße, Norbert :)

PS: Den patch habe ich noch nicht inkludiert...
 
so, ein kleiner neuer Ausblick: Ubuntu 20.04 (sowohl als Desktop oder live server) lässt sich in FreeBSD 12.2 unter bhyve installieren. Vielen Dank an alle, die was beigetragen haben!!!

Das Einzige was ich gerne noch besser hätte ist der Support für: language and keyboard. Unter TigerVNC kann man arbeiten, ich habe allerdings eine deutsche Tastatur (aber der rest soll schön Englisch bleiben!! :)) Das macht die Nachkonfiguration immer ein wenig schwer, da gewisse Tasten anders belegt sind. Hat jemand eine Idee, ob man irgwndwie mit einem einem anderen vnc viewer das eleganter machen kann?

VG aus Münster - Norbert :)
 
ob man irgwndwie mit einem einem anderen vnc viewer das eleganter machen kann?
Du könntest einen VNC-Server auf ubuntu installieren und dann Dich mit dem verbinden, statt den internen von bhyve zu nehmen.
Dann sollte sich auch relativ problemlos ein anderer VNC-Client verwenden lassen.
 

Anhänge

  • remmina.png
    remmina.png
    59 KB · Aufrufe: 273
Danke Euch!! - ich probiere das mal aus :) nur leider brauche ich die Tastatursachen, damit ich das Netzwerk in Ubuntu zum Laufen bringe...
 
RDP, hat weniger overhead
Wie kommt es eigentlich zu dem geringeren Overhead bei RDP?
VNC hat ja das Problem, das BIldschirminhalte als Bitmaps übertragen werden. RDP kann da mehr und man kann halt auch sagen "Übertrage mir Linie von da nach da in der Farbe" etc. was dazu führt, das effektiv weniger Daten geschaufelt werden müssen.
Mein (möglicherweise veralteter oder gar falscher) Stand war, das dies aber nur mit Windows auf der RDP-Serverseite möglich ist und bei X11 dann VNC-like Bitmap-Schnipsel übertragen werden müssen, was einen etwaigen Vorteil gegenüber VNC natürlich marginalisieren würde.

nur leider brauche ich die Tastatursachen, damit ich das Netzwerk in Ubuntu zum Laufen bringe...
Nimm notfalls den Konsolenzugriff von bhyve:
https://www.freebsd.org/doc/de/book...ion-host-bhyve.html#virtualization-bhyve-nmdm
 
Wie kommt es eigentlich zu dem geringeren Overhead bei RDP? VNC hat ja das Problem, das BIldschirminhalte als Bitmaps übertragen werden.
Richtig, es wird (in Standardeinstellung) unkomprimiert und Vollbild für Vollbild übertragen. Da kannst du Bandbreite ohne Ende draufwerfen, es bleibt laggy, wenn du nicht gerade ein 320x240-Briefmarkenfensterchen akzeptierst. Es gibt zwar Möglichkeiten zur Komprimierung, da wird aber trotzdem jedes komprimierte Vollbild übertragen (man möge mich hier berichtigen, alter Stand ;) ).
Diese Kompression knechtet die CPU und bei alten Singlecores war das wiederum der Flaschenhals.

Der bessere Ansatz war es dann, nur die Veränderung zu übertragen. Dein Client hat ja bereits das Bild geladen z.B. 1024x768px und der Rahmen um den Cursor hat dann z.B. 10x10px und nur das muss übertragen werden.
Bei Videocodecs hat man das mit steigernder CPU-Power auch immer verfeinern können, aber im Prinzip geht das da genau so.
Stell dir eine Szene aus Tom & Jerry vor. Die Maus rennt analog dem Cursor quer durchs Bild. Der Hintergrund bleibt gleich, nur die klitzekleine Veränderung wird abgespeichert. Cartoons lassen sich darüber hinaus wegen den vielen statischen Hintergründen und einfarbigen Flächen sehr effizient codieren. :)

Mein (möglicherweise veralteter oder gar falscher) Stand war, das dies aber nur mit Windows auf der RDP-Serverseite möglich ist und bei X11 dann VNC-like Bitmap-Schnipsel übertragen werden müssen, was einen etwaigen Vorteil gegenüber VNC natürlich marginalisieren würde.
Die unterschiedlichen Versionen von rdp bekamen immer mehr Features, Nachbauten hinken dann immer etwas hinterher. Ich glaube, was du in Erinnerung hast, war die Zertifikatsvoraussetzung zur Verbindung. Das hat oft Schaum am Maul gegeben. :p
https://de.wikipedia.org/wiki/Remote_Desktop_Protocol

Bestätigen kann ich das selber nicht, bin nicht so tief in der Materie:
https://www.javaer101.com/de/article/11070870.html
 
Es gibt zwar Möglichkeiten zur Komprimierung, da wird aber trotzdem jedes komprimierte Vollbild übertragen (man möge mich hier berichtigen, alter Stand ;) ).
Auch VNC überträgt nur Änderungen und es kennt auch die Möglichkeit der Komprimierung:
https://tools.ietf.org/html/rfc6143

TightVNC beherrscht dann sogar noch verlustbehaftete Kompression (JPEG) und macht noch ein paar andere Optimierungen in der Kodierung der Daten.

Ich glaube, was du in Erinnerung hast, war die Zertifikatsvoraussetzung zur Verbindung.
Keine Ahnung. Ich meinte eher die technische Ebene.
Und das RDP prinzipiell halt mehr kennt als nur Bitmaps bzw. Bitmap-Schnipsel.
 
Ah, ok. man lernt nie aus. :)

Und das RDP prinzipiell halt mehr kennt als nur Bitmaps bzw. Bitmap-Schnipsel.
Jep. Mich hat das nun doch genauer interessiert.
Im Wesentlichen ist VNC so designed, dass es 'dumm' Bilder schicken soll. Das ergibt den Vorteil, dass der Empfänger quasi nichts machen oder wissen muss. Bildaufbereitung auf Senderseite.
RDP schickt vereinfacht gesagt nur Instruktionen, Bildaufbereitung auf Empfängerseite.
 
Ich sage mal ungeschützt ja. Zu einer VM mit xrdp kann ich mit max. in remmina betitelter Farbtiefe von GFX RFX (32 bpp) connecten. Das dürfte noch ein Level über RemoteFX sein. Ob das jetzt wirklich auch greift, weiß ich nicht. Wüßte auch nicht, wie ich das gegenprüfen sollte.

Aber vllt. weiß ja jemand noch etwas mehr. :)
 
Danke Euch für die rege Unterstützung, aber eigentlich brauche ich den vnc/rdp zugang bei ubuntu nur für die server version. Gui etc. ist "nebenläufig" für mich, ich brauche halt nur einen Zugang zu Anfang um alles einzustellen :) :) Daher ist mir auch eine 16 bit Farbauflösung mehr als genung :)
 
Ich hab mich jetzt auch mal etwas mit bhyve befasst, um meinen Server (FreeBSD 12.2) um Pi-Hole zu erweitern. Hab aber direkt vm-bhyve verwendet. Ich hab dann noch das uefi-edk2-bhyve Paket installiert und folgende vm-bhyve-config für eine Debian Installation gewählt:

Code:
loader="uefi"
cpu=2
memory="1G"
network0_type="virtio-net"
network0_switch="public"
zfs_zvol_opts="volblocksize=4096"
disk0_type="virtio-blk"
disk0_name="disk0"
disk0_dev="sparse-zvol"
disk0_size="100G"

Dann letztendlich nur grob das Vorgehen von der github Seite vom vm-bhyve Projekt:
Code:
pkg install vm-bhyve
zfs create pool/vm
sysrc vm_enable="YES"
sysrc vm_dir="zfs:pool/vm"
vm init
<hier die /pool/vm/.templates/default.conf wie oben anpassen>
vm switch create public
vm switch add public <netdev>
<debian iso runterladen und nach /pool/vm/.iso kopieren
vm create pihole
vm install pihole <debian-iso-name>

Dann via tigervnc auf Port 5900 des Servers verbinden und da wartete auch schon das Debian Boot-Menü auf mich. Normal installiert und fertig war die Sache. Hilft vielleicht dem einen oder anderen. Was vm-byve dann so für bhyve Aufrufe macht sieht man dann im vm-bhyve-log im Ordner der VM:

Code:
Nov. 23 09:19:10:  [bhyve options: -c 2 -m 1G -Hwl bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -U 578ef378-2cf6-11eb-93ad-001e67aadb23 -u]
Nov. 23 09:19:10:  [bhyve devices: -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/dev/zvol/datatank/vm/pihole/disk0 -s 5:0,virtio-net,tap0,mac=58:9c:fc:0f:70:87 -s 6:0,fbuf,tcp=0.0.0.0:5900]
Nov. 23 09:19:10:  [bhyve console: -l com1,/dev/nmdm-pihole.1A]
Nov. 23 09:19:10:  [bhyve iso device: -s 3:0,ahci-cd,/datatank/vm/.config/null.iso]
Nov. 23 09:19:10: starting bhyve (run 6)

Kein externes Grub oder sonst was nötig. Einfach via UEFI booten lief gut.
 
PI-Hole macht ja nix anderes als DNS-basierte Filterung. Was spricht für Pi-Hole anstatt einfach DNS-basierte Filterung zum Beispiel mit nem unbound-DNS-Server zu machen?
Und warum der Umweg über bhyve, wo es doch gerade unter FreeBSD 12.2 super einfach geworden ist ein Linux-Jail einzurichten?

Ich verwende Pi-Hole nicht nur als DNS, sondern auch als DHCP. Und ob ich nun eine Linux-Jail einrichte oder eine VM... da nehme ich das was 100% Support vom Projekt hat, statt mich mit irgendwas zu befassen was gerade heiß aus dem Ofen kommt. Und das ganze Projekt manuell nachbauen, damit das nativ unter FreeBSD läuft -> weder Zeit noch Lust dazu.
 
Ah Ok. Ich dachte es gibt irgendwelche rationalen Gründe. :-)

Bei mir hab ich eine ähnliche Aufgabenstellung fürs LAN. Ich möchte DHCP haben und auch DNS. Und wenn ich eh schon DNS hab, kann ich natürlich auch gleich Filterung darüber machen. Ich hab mir dann dnsmasq dafür genommen. Da hat man dann gleich DHCP und DNS in einem und er ist auch relativ leicht zu konfigurieren. Ich hab dann aber noch "chained" eine unbound-Instanz für DNS. Ich glaub, das hab ich damals gemacht, da dnsmasq kein DNS-over-TLS kann. unbound übernimmt dann auch die Filterung, indem halt analog zu Pi-Hole entsprechende DNS-Listen zur Filterung eingesetzt werden.

Das Setup ist eigentlich nicht schwierig und ist relativ schnell gemacht. Daher war ich etwas verwundert über den Umweg mit bhyve, Debian etc. Weil das Aufwand ist und man dann halt sich noch mehr Kram ins System reinzieht (wo ja dann auch mal potentiell etwas Haken kann). Abgesehen von dem Ressourcenverbrauch.

Ich will das auch gar nicht bewerten. Es hatte mich nur gewundert. Deshalb hab ich gefragt. Hätte ja sein können, das es einen (für mich) interessanten Grund gibt das so zu tun.
 
Zuletzt bearbeitet:
Zurück
Oben