• bhyve
• OfficeHours
• 27January2021

Agenda

• Intro to bhyve office hours
• Notable commits in the past month
  • bvmconsole and bvmdebug removed
  • Fix issues with various VNC clients
  • additional serial ports (COM 3/4)
• Upcoming work
  • VNC non-US keyboard support

  • Warm migration D28270

• Short talks - (Please upload your talks to your FreeBSD space and modify the example link below)
  • (none this session)
• Demos
  • CentOS 7/8 installs via GUI and CLI

• Q & A

Video

• YouTube video of bhyve Office Hours Meeting

Meeting Notes

• Notable commits in the past month
  • bvmconsole and bvmdebug removed. This has been unused over recent times and is no longer needed. The code has been cleaned up like other code in the src tree.
  • Fix issues with various VNC clients. bhyve has a minimal VNC server built in but has struggled with client compatibility. These issues have largely now been fixed. Notable fixes are performance improvements at idle with consumption now down to 1.9%, fixed chopping/tearing of display output, more stable mouse tracking and screen refreshing has been fixed.
  • COM3/4 now been added for additional ports for people to use (for example - in debugging).
• Upcoming work
  • Warm migration work update by jhb@. This work is more of a steppingstone to the live migration phase. Fixes still being working on for suspend and resume, but these are not mandatory/pre-requisite for the warm migration work, they are more orthogonal in the migration work. However, suspend and resume is required for live migration.
  • VNC non-US keyboard support. This has been coming for a while but had several pre-requisites to make it happen. A VNC server typically removes a lot of data coming in from a keyboard that is then being sent through to a guest. The initial goal was to get a limited functionality working first by using PS/2 codes. This now allows foreign keys to be render correctly. A more complex implementation would be to have translation tables for every language loaded into the VNC server which would require a significant amount of work.
  • UEFI update. The current EDK2 version is quite an old implementation (circa 2014). We have been missing out on bug fixes and changes from upstream during this time. The current version used by FreeBSD in ports is built on python 2.7 (with this version of Python being deprecated/unsupported), which is not ideal moving forwards. EDK2 work by Rebecca Cran to merge requirements for FreeBSD/bhyve has been up streamed so the FreeBSD project can take advantage of the latest upstream build and bug fixes moving forward. CSM is the most difficult part of this and will be a problem to upstream.

  • ARMv8 support. There is a large review to add bhyve support for use on ARMv8 hardware, such as the EspressoBin ARM board. Typical SoC boards like Raspberry Pi 4 won’t work because of the GIC2 interrupt controller. ARMv8.1 has virtual host connection which would improve things.

• Short talks
  • (none this session)
• Demos
  • CentOS 7/8 installs

• Q & A

  • Which block device model is best to use (virtio-blk, ahci, nvme, virtio-scsi)?

    • virtio-blk, was the first block device and has good support in the BSDs and Linux operating systems. There are drivers for Windows maintained by RedHat but are not available in the standard Microsoft installer.

    • AHCI for compatibility. virtio-blk is not available in the Windows or Linux (at the time) installers, so this was coded in to improve installation for the above operating systems and allowed CD access via local ISO files. AHCI performance is horrible and it is suggested to switch to one of the other block models once the operating system has been installed.
    • NVMe is the solution for Windows. Has been written for parallelism in mind. This is supported across all guest operating systems that are currently supported and would be the preferred block device. No matter the underlying storage, this will give you the best performance for guests. Only available for FreeBSD hosts version 12.2 and above.
    • virtio-SCSI solves a problem for storage fan-out. It also gives you the option to do SCSI pass-through.
  • How far along is the virtio 9p support in bhyve and FreeBSD?
    • There is support for 9p that will ship in FreeBSD 13.0 (due at the end of March 2021). This will allow the passing of a file system from the host, directly to the guest.

    • virtioFS that is being push by RedHat does contain UEFI support and would be the better direction to eventually move to.

  • Any interest in allowing bhyve to use the memory_size/is_wired_memory settings that bhyveload/grub-bhyve was called with? It would allow the '-m' and '-S' flags to be optional to bhyve (when not using uefi).
    • grub-bhyve was a hack to get things working. It is not the recommended way of moving forward for booting guests, partially for this reason.
    • grub-bhyve caused issues for other guests such as OpenBSD at each upgrade cycle because of absolute paths. When OpenBSD gained supported UEFI support, there was no longer a need to use grub-bhyve.
    • The majority of operating systems now boot UEFI so the purpose of grub-bhyve has greatly diminished.
    • There has been no reasonable work/maintenance on grub-bhyve.
  • Device models support hot plug?
    • virtio-SCSI might.
    • There is work in providing a socket into bhyve that is currently in progress which could allow bhyvectl to send commands through to the guest for example, to change CDs, adjust disk capacities on the fly or add additional disks. At this time, there has been no work to provide these features.