Today I've played around with Bhyve and vm-bhyve for the first time and I like it very much.
I've used QEMU/KVM for everything until now, but I'm thinkering with switching completely to Bhyve.
The first VM is already up and will be the base for the Dark Blue Raven website.
#bhyve #vmbhyve #freebsd #darkblueraven #hypervisor #virtualization
Today I've played around with Bhyve and vm-bhyve for the first time and I like it very much.
I've used QEMU/KVM for everything until now, but I'm thinkering with switching completely to Bhyve.
The first VM is already up and will be the base for the Dark Blue Raven website.
#bhyve #vmbhyve #freebsd #darkblueraven #hypervisor #virtualization
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.
