Lessons learned when using #bhyve in general and -k configfile: everyone hates whitespace at the end of a line and so does bhyve; to successfully configure PCI and LPC devices you have to follow the man pages to the letter; bhyve(8) slightly deviates from bhyve_config(5) it seems; contents of man pages may change, depending on the #freebsd version (surprise!); I’m probably not experienced enough to understand why there is a difference between “normal” PCI devices and LPC devices and why this is reflected in the config syntax and there are very good reasons why (if I remember correctly when I had a look) #vmbhyve chose to use bhyve command line options rather than -k configfile in their source code; the man pages do not always make clear that some bhyve features are experimental (and not compiled in) and reading the FreeBSD handbook is always worthwhile; my system was not unusable due to active ZFS deduplication during my experiments; bhyve appeared to excel in terms of performance, I did not expect that my VM runs so smoothly on a 15+ year old laptop (SSD upgrade only), didn’t try Windows yet though. And after all this I’m still not sure why I’m supposed to bhyvectl —destroy my VMs, like does that free up some resources somewhere? I did note that this makes the device node of the VM in /dev/vmm disappear though.

There reason why my bhyve guest running slow: vm-bhyve runs the vm with its default cpu configuration (which is 2 cores) and e1000. Read, edit and test are the best way to tune up things. #vmbhyve #bhyve

Just started reading about #bastilleBSD. Correct me if I’m wrong but this is (at the very basic level of course) for #jails what #vmbhyve is for #bhyve? Way easier interface to use these underlying technologies, right?