Microsoft Loves Linux Deep Dive #2: Linux and FreeBSD Integration Services Core Features

This post was written by Michael Kelley, Principal PM Manager, Cloud + Enterprise team

Introduction

This blog post is #2 in a series of technical posts about running and managing Linux and FreeBSD in your on-premises datacenter.  Previous posts in the series are here:

Overview
• Microsoft Loves Linux

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

I encourage you to check back weekly as I add to this series.

Hyper-V Functionality for Linux and FreeBSD

The full range of functionality available to Linux and FreeBSD guests running on Hyper-V fits into two broad categories.  The first category is functionality outside the guest, while the second category is functionality requiring guest cooperation.  Let’s briefly look at each category.

Hyper-V functionality outside the guest doesn’t depend on the operating system running in guest virtual machines, so it works for Windows guests, Linux guests, and FreeBSD guests.  This category is by far the larger of the two and represents the majority of the investment that Microsoft is making in enabling great functionality and performance for guest VMs.  The salient point is that this work accrues to Linux and FreeBSD VMs just like it does to Windows VMs.  Examples of this functionality include:

  • Super-fast live migration of virtual machines to another Hyper-V host using RDMA
  • Storage Quality-of-Service (QoS) controls
  • Software Defined Networking

These feature examples, along with a large list of other features, provide the same benefits to Linux and FreeBSD guests as they do to Windows guests.  They are described in other blogs posts outside this Linux/FreeBSD series, so I won’t be covering them in more detail here.

The second category, functionality requiring guest cooperation, includes:

  • Enhanced guest operations
  • Direct guest-host communication
  • Dynamic memory
  • Live backup

The guest cooperation is implemented via the Linux and FreeBSD Integration Services described in last week’s blog post.  Since this functionality has attributes specific to Linux and FreeBSD, this blog post series will focus on this functionality.

Enhanced Guest Operations

Operations on Linux and FreeBSD guests are performed using the same tools as for Windows guests.  These tools include:

  • Hyper-V Manager:  Basic graphical user interface for operating a modest number of Hyper-V hosts and guest virtual machines.
  • PowerShell:  Command line interface on Windows for performing basic virtual machine operations.  Even though PowerShell runs on Windows, it can perform operations on virtual machines running Linux or FreeBSD just like it does on VMs running Windows.
  • System Center Virtual Machine Manager:  Graphical user interface for operating a full scale private cloud.  VMM operates on Linux VMs just like it operates on Windows VMs.  (VMM cannot operate on FreeBSD VMs.)

As you would expect, guest operations include the ability to start and stop guest VMs, as well as to suspend and resume VMs.  The “stop” operation has two variants:  “turn off” and “shutdown”.  From outside the VMs, it’s easy for Hyper-V to just turn off the VM – equivalent to turning off a physical computer.  But this approach results in an unclean shutdown, with attendant problems such as file system inconsistency.   So Hyper-V also implements “shutdown”, which uses the LIS/BIS code in the guest to perform the equivalent of the Linux “shutdown” command within the VM itself.  This approach allows the operating system to go through normal shutdown procedures so that, for example, file systems are left in a consistent state.   Hyper-V implements shutdown without having to login to the Linux or FreeBSD guest VM, so anyone with permissions to Hyper-V can perform the shutdown.

Time Synchronization and Time Keeping

When a Linux or FreeBSD virtual machine is started or resumed, its time-of-day clock is set to match the time-of-day on the Hyper-V host.  From there on, the guest does its own time keeping using counters provided by the Hyper-V host.  However, accurate time keeping in a guest VM is extremely challenging, and some clock drift is inevitable unless an external time synchronization mechanism is used.   Windows guests are typically domain-joined and benefit from ongoing time synchronization performed by the Active Directory Domain Controller.  For Linux and FreeBSD guests, we recommend using an NTP service in each guest to perform ongoing time synchronization and ensure that clock drift does not accumulate.

Direct Guest-Host Communication

Hyper-V provides two mechanisms for direct communication between the host hypervisor and its guest VMs.  In this context, “direct” means communication that does not require a network connection between the host and the guest.  Such network connections may be difficult or impossible to achieve in some environments where the host and guest networks are completely separate for security purposes.

The first mechanism is Data Exchange, also called Key/Value Pairs or just KVP.  Key-value pairs consist of a “key” and a “value”. Both the key and the value are strings, with the “value” string being up to 1024 characters long.  When a key-value pair is created or changed, it is visible to the guest and the host.  Key-value pairs can be created and read on both the host and the guest, so information flow is bi-directional – from the host to the guest, or vice versa.  This TechNet article provides an overview of key/value pairs, as well as the details on how your applications can make use of key-value pairs within the Hyper-V host and within Linux or FreeBSD guests.

Some key-value pairs are automatically created in the guest and host to transmit basic information.  For example, a KVP is created in the host with the name of the host itself, so the guest can find out what host it is running on.  Similarly, the guest creates a KVP with its IP address so the host can know the IP address of the guest.

The second mechanism is “file copy”.  File copy moves a file from the Hyper-V host into a guest VM, and is much more efficient for bulk data transfer than key/value pairs.  The data transfer is uni-directional -- from the host to the guest only.  The file copy feature is invoked via the Copy-VMFile PowerShell cmdlet.  Within the Linux guest, make sure the hv_fcopy_daemon process (which is part of LIS) is running.

Other Functionality

Recent Linux distros (but not FreeBSD) have support for booting from UEFI and can run in Hyper-V Generation 2 virtual machines.   Generation 2 VMs are slimmed down VMs that don’t provide most legacy PC devices, and can also do things like PXE boot from a synthetic network adapter.  The “Secure Boot” option on Generation 2 VMs must be disabled in order to run Linux on Hyper-V 2012 R2, but in the Windows Server 2016 Technical Preview 2 and later versions of Hyper-V, Linux distros also work with Secure Boot, provided you specify the Microsoft UEFI Certificate Authority via Hyper-V Manager UI, PowerShell, or the System Center VMM UI.

Hyper-V gives you the ability to change the size of a virtual hard disk (VHD or VHDX) used by a guest VM, even while the guest VM is running, so that you don’t incur any downtime.  In a Linux or FreeBSD guest, the new size of the virtual hard disk is immediately visible with commands such as df –k.  You can then use partitioning and file system commands to take advantage of additional space, or adjust to reduced space.

Summary

Hyper-V provides an important set of core features that make it easy to run Linux and FreeBSD as a guest operating system.  Most of the functionality of Hyper-V is independent of the guest OS, and so the functionality “just works” with Linux and FreeBSD.  But the functionality that requires guest cooperation also “just works” via the Linux and FreeBSD Integration Services.

In my next post I’ll give details on two additional important features:  dynamic memory, for achieving higher VM densities, and live backup, for eliminating downtime due to backing up your virtual machines.