This post was written by Jason M. Anderson, Principal PM Manager, Cloud + Enterprise
This blog post is #5 in a series of technical posts about running and managing Linux and FreeBSD in your on-premises datacenter. Other posts in the series are here:
Running Linux and FreeBSD as a guest operating system on Hyper-V
- Microsoft Loves Linux Deep Dive #1: Introduction to Linux and FreeBSD on Hyper-V
- Microsoft Loves Linux Deep Dive #2: Linux and FreeBSD Integration Services Core Features
- Microsoft Loves Linux Deep Dive #3: Linux Dynamic Memory and Live Backup
- Microsoft Loves Linux Deep Dive #4: Linux Network Features and Performance
- Microsoft Loves Linux Deep Dive #5: FreeBSD Overview and Status
Managing Linux and UNIX using System Center and PowerShell DSC
- Microsoft Loves Linux Deep Dive #6: Linux and UNIX Systems Management Overview
- Microsoft Loves Linux Deep Dive #7: Managing Linux in System Center Virtual Machine Manager
- Microsoft Loves Linux Deep Dive #8: Linux and UNIX Monitoring with Operations Manager
- Microsoft Loves Linux Deep Dive #9: Monitoring Open Source Middleware
- Microsoft Loves Linux Deep Dive #10: Managing the Software Configuration on Linux and UNIX Servers
- Microsoft Loves Linux Deep Dive #11: Linux Configuration Management with PowerShell DSC
- Microsoft Loves Linux Deep Dive #12: Summary of Running and Managing Linux and FreeBSD in Your Datacenter
In the last 4 blog posts in the “Microsoft ♥ Linux” series, Michael Kelley has been going into detail on the work Microsoft has been doing to make sure that Linux runs great on Hyper-V. Today, I’m going to shift gears a little bit and talk about FreeBSD on Hyper-V. Yes, Microsoft ♥ FreeBSD, too!
FreeBSD serves as the base operating system for many popular storage, network and security appliances popular in datacenters today. As the trend of virtualization of server workloads continues to grow, the trend of appliances moving to a virtual model is also accelerating rapidly. These virtual appliances need to run on a variety of hypervisors, including Hyper-V. The work Microsoft is doing to support FreeBSD on Hyper-V is primarily targeted towards our appliance vendor partners in ensuring that their products can run in a virtualized manner both in on premises environments as well as Microsoft Azure, which leverages Hyper-V as the virtualization layer. Ensuring that you can deploy your virtualized workloads on-premises, in public or hybrid environments is a core priority for us at Microsoft.
FreeBSD Integration Services
Like Linux, FreeBSD needs to have integration services (drivers and corresponding daemons) in order to work on the Hyper-V platform. The concept of integration services is the same whether you’re running Linux, FreeBSD, or even Windows for that matter, on Hyper-V. For more detail on Integration Services in general, peek back at Michael Kelley’s first blog post where he describes “Guest Operating Systems and Integration Services”.
How Integration Services are developed and distributed for FreeBSD is a little different than it is for Linux. Unlike Linux, where there is a main kernel that all Linux distributions are subsequently built from, there is only one FreeBSD. The FreeBSD Foundation is responsible for not only the kernel of the operating system itself, but also the associated drivers and libraries which make-up a full operating system, there are no subsequent “distributions” as there are for Linux. This means that Microsoft can deliver the Integration Services components directly to the FreeBSD community and upon acceptance, are included directly into the latest release of the FreeBSD operating system. Linux, on the other hand, has a much more complex distribution method as there are various Linux distributions, based on different Linux kernel versions, so an installable package is necessary in some cases for certain Linux distribution versions to have the proper Linux Integration Services.
But what if you’re running an older version of FreeBSD that does not have Integration Services built-in? Well you’re not completely out of luck in this case. We do provide ports for versions of FreeBSD that go back as far as 8.4, so if you are building or maintaining a product based on an older version of FreeBSD, you can include these ports as installable drivers and corresponding daemons to get the needed functionality to run on Hyper-V. If you are running a newer version of FreeBSD, specifically 10.1 or later, you’ll have the latest integration services built-in directly. For a detailed list of what Hyper-V features are supported in the various versions of FreeBSD, either built-in or as ports, you can find that information here.
What about other BSD operating systems like OpenBSD, NetBSD or FreeNAS? Unfortunately, like FreeBSD, these are complete operating systems maintained separately from FreeBSD and as such the FreeBSD Integration Services will not work on these operating systems.
FreeBSD Features and Optimizations on Hyper-V
Now that we’ve talked about how FreeBSD runs on Hyper-V with Integration Services, let’s dive a little deeper into some of the areas of focus we’ve worked-on to ensure that FreeBSD not only runs on Hyper-V, but runs GREAT on Hyper-V
- Key-Value Pair (KVP) – One of the first investments we made in optimizing FreeBSD for Hyper-V was in KVP (Key-Value Pair). KVP allows administrators to store custom metadata, for example guest static IP addresses. In the event that the FreeBSD guest has failed over from one Hyper-V host to another, KVP can be used from the host to set the IP address of the guest to ensure continued availability. Prior to FreeBSD 10.1, the KVP driver and associated daemon were provided as ports only, however with 10.1 and above, it is built-in as an integrated driver and daemon.
- VMBus Improvements – VMBus is the communication plane in which the Hyper-V host channels all communication to the guest, including all drivers. All I/O between the host and the guest must communicate through VMBus, so ensuring that all core drivers are optimized for VMBus is crucial for top performance.
o Multi-Channel Support – VMBus on Hyper-V has the ability to utilize multiple channels bound to multiple vCPUs to parallelize I/O between the guest and host, however prior to FreeBSD 10.2 each device driver could only bind to one channel and all channels were bound to vCPU0. Now each device driver can have one dedicated channel on one vCPU. This significantly increases the performance primarily for storage and networking drivers if they are multi-channel optimized.
o Signal Optimization – Signal optimization reduces the number of interrupts needed to transfer I/O packets between the virtual machine and the host. This is done by combining multiple read and write activities in the VMBus layer into a single read and write, resulting in improved VM network and storage I/O performance.
- Storage – Storage performance and resiliency is a core investment we’ve made in FreeBSD Integration Services over the past year. Without performant storage, you simply can’t have a product-class workload, so we’ve done a bunch of work here to ensure you can get the highest IOPs possible when running FreeBSD on Hyper-V.
o Multi-Channel – As described above in Multi-Channel support for VMBus, we have optimized the storage driver stack to take advantage of multi-channel to overcome the single channel limitation. Not only does this mean that storage devices have their own dedicated channel bound to a vCPU, but in addition, for FreeBSD virtual machines that have more than 5 vCPUs, and additional sub-channel is made available to the storage driver.
o Scatter/Gather List Support – In addition to this, we have also enabled scatter/gather list support which enables immediate handing of I/O requests in the storage driver which is particularly useful for non-page-aligned reads and writes.
- Networking Performance – Like storage, networking performance is critical for production workloads of any type. In the last Linux Deep Dive blog posting, Michael talked in depth about the goals for networking performance for Linux on Hyper-V. We have the same goals for FreeBSD as we do for Linux, namely that if you have a 10G Ethernet adapter in the host, the FreeBSD guest should be able to utilize nearly all of the available 10G bandwidth capability of that adapter. Below are some of the recent investments made in networking for FreeBSD guests on Hyper-V.
o Multi-Channel – Just like we’ve done for storage, described above, we have enabled multi-channel for the networking stack in FreeBSD to take advantage of more than one channel per vCPU in FreeBSD virtual machines.
o TCP Segment Offload – TCP Offload is another Hyper-V feature that transfers segmentation and checksum work from the guest CPU to the host virtual switch or NIC.
o Common Address Redundancy Protocol (CARP) – CARP is a popular feature in FreeBSD which allows multiple hosts to share the same IP address and Virtual Host ID (VHID). This enables high availability in the event that a single host becomes unavailable, the requesting application or service does not need to be aware of a new IP address.
- Live virtual machine backup – Another Hyper-V feature, live virtual machine backup facilitates zero down time during the backup of a virtual machine as the virtual machine can continue to run during the backup operation. This is achieved by freezing the state and operations of the virtual machine for short periods of time during backup.
- Hot Add/Remove SCSI Disk – As the name implies, the ability to add or remove a disk in a running virtual machine rather than having to shut it down to do so.
A little bit about running FreeBSD in Microsoft Azure
As I mentioned earlier in the blog post, we see as much opportunity for FreeBSD based virtual appliances running in Microsoft Azure as we do in on premises environments that run on Hyper-V. However, if you go to the Microsoft Azure portal, you won’t find FreeBSD as a general-purpose operating system to spin-up as a virtual machine. Again, this is primarily because most solutions based on FreeBSD are packaged and provided as a complete system as a virtual appliance, not as a baseline operating system.
However, if you do want to spin-up a virtual machine quickly based on FreeBSD, we do have an option to do so through the VM Depot website run by Microsoft Open Technologies. Simply go to https://vmdepot.msopentech.com and navigate to the “platforms” pane on the right and you can select FreeBSD as an operating system. You’ll see a bunch of offerings here, including releases from the FreeBSD release engineering team, which are “ready to provision” images for Microsoft Azure. No prepping, no configuring, simply click and deploy!
So… What’s next?
As you can see, we’ve done a bunch of work to make FreeBSD run great on Hyper-V, and subsequently in Microsoft Azure as well. But we’re not done – there’s always more work to do to tune performance, increase reliability and of course, add more support for Hyper-V and Azure specific features. Stay tuned to our TechNet page here as we add more features and FreeBSD version support over the coming months!