Stack Merge

Through the years, the relationship between Microsoft and Linux has been full of misunderstanding, FUD, and emotions. Twelve years ago, CEO Steve Ballmer called Linux a cancer [1], but some time ago, Microsoft moved away from its strategy of confrontation, vociferously proclaiming a policy of "interoperability," and even making contributions to the Linux kernel.

Microsoft plays a considerable role in many open source development projects and no longer firewalls its products against open source software. This change has not been voluntary; the more flexible Linux often dominates the data center in the cloud age, and Microsoft knows it needs to catch up.

Widespread prejudice, questions about the capabilities of Windows in modern cloud environments, a belief that Windows administration and licensing are too complicated – all these factors have led to a comparatively poorly showing for Windows in Linux-dominated clouds. At the same time, anyone who has ever managed a migration will be aware: in many cases, you cannot completely do without Windows.

Windows on OpenStack

Paravirtualized systems typically work faster than their fully virtualized counterparts, but for paravirtualization to work, the guest needs specific drivers. As long as an appropriate driver is available for the guest system, everything is fine. But, the driver for the guest must be specifically designed to support the hypervisor. An existing driver for paravirtualization in KVM does not help in a Xen configuration.

If you want to use Windows as a guest on the popular Linux KVM, – whether managed by OpenStack or another virtualization environment – you'll need the necessary drivers. Fortunately, you can regard this problem as solved. Although the drivers do not come directly from Microsoft, the KVM team makes drivers available. The Fedora repository [3] even has digitally signed versions that can be easily installed in all current versions of Windows.

Windows installations are accustomed to being closely linked to the hardware on which they run; however, a cloud environment offers no guarantee that any hypervisor nodes rely on exactly the same hardware. On the contrary, the longer the cloud has been in operation, the more colorful the hardware mix is. Windows also requires some strictly machine-specific details, such as the license key that belong to a virtual machine. All this information cannot be part of the Windows image that the cloud administrator makes available to customers. The image must be a naked image that contains no specific configuration parameters. Microsoft provides a solution for exactly this problem in the form of a tool called Sysprep [4].

With Sysprep, you can more or less remove the brain from a fully installed and configured Windows. Everything that was specific to this virtual machine – and that includes the license key – is gone after a Sysprep call, and the system is plain vanilla again. At precisely this moment, the admin can grab this image and upload it to the OpenStack image store.

One peculiarity in the Windows context occasionally rears its ugly head: the size. A standard Windows image is a few gigabytes in size – incredible for Linux users. This size causes some problems when starting a new virtual machine. Without going into the hypervisor-dependent differences, the start always works in the same way: the management system, for example, OpenStack's computing component Nova, triggers a new virtual machine on a hypervisor node.

Then, the computing node loads the image from the storage manager Glance on its local disk to start the virtual machine from the local image copy in the next step. The more gigabytes the image comprises, the longer it takes, so anyone offering Windows images the OpenStack cloud would do well to have a powerful and stable network connection between their OpenStack nodes. If you want to run Windows VMs in OpenStack, you hardly need to fear technical limitations but rather the same licensing restrictions that apply to conventional virtualization setups. The box titled "About Licenses" discusses this problem.

What about Hyper-V?

The ultimate purpose of a virtual environment is to run applications. If you want to sell a comprehensive cloud computing environment, you must offer your customers the ability to run nearly any application that would run outside of the cloud environment.

Especially in the Windows environment, some large suites and even some individual programs define specific system requirements for virtualized environments, often providing the restriction that the virtual machine's entire stack has to be Windows-based from the hypervisor to the virtual machine itself. If the customer does not meet this requirement, some vendors summarily refuse support. This restriction means it isn't enough to run Windows directly in an OpenStack cloud. You need to get Microsoft's Hyper-V cloud stack running somewhere on your network. Of course, Microsoft benefits from this situation, because it means that Hyper-V hosts then start to appear in what are otherwise pure Linux environments to provide the Windows-specific stack specified by the application provider.

But, how do Hyper-V and OpenStack actually get along? Do you need separate management systems with redundant structures? The OpenStack developers actually confused this question still further in February 2012, when they completely removed support for Hyper-V from the then new version 2012.1 (Essex).

The answer is that Hyper-V and OpenStack get along much better than they used to, thanks to an Italian company known as CloudBase ([5], Figure 1). CloudBase is leading the charge for Hyper-V integration with OpenStack, so much so that rumors are circulating in the OpenStack community that CloudBase is a Microsoft-controlled zombie.

Figure 1: Italy's CloudBase has ported many of the OpenStack components to Windows.

Whatever you might think about these rumors, you can be sure that the work by CloudBase has had a very positive effect on Hyper-V support in OpenStack. As early as version 2012.2 (Folsom), support was again introduced back into OpenStack, and it worked better than ever before.

Initially, CloudBase focused on the most important OpenStack component for hypervisor support – nova-compute – giving it the ability to run on Windows with Hyper-V installed.

Based on the hypervisor code that already existed for Hyper-V, the Verona-based company has ensured that nova-compute can be used in a completely painless way on Windows. The developers even gave the software its own installer, so that a Windows computer – as strange as that may sound – can be significantly easier to transform into a compute node for Nova than a Linux system. The admin needs only one computer equipped with Hyper-V, even a desktop systems (Windows 7 or 8) will provide the necessary support (Figure 2).

Figure 2: The Hyper-V console reveals how seamlessly CloudBase has integrated nova-compute.

The Network

Cloud environments use Software Defined Networking (SDN) and degrade the switches in the data center to bare iron to control the packet flow through the cloud environment. The downside of this approach is that a component that takes care of the network needs to run on the hypervisor node. In OpenStack, the Neutron component is responsible for the network; it was officially named Quantum until recently. In its default configuration, Quantum relies on Open vSwitch [6] to establish an SDN.

CloudBase, however, could not use this approach in Windows; an Open vSwitch for Windows still does not exist today. Therefore, the Italians built their own Quantum plugin. Although this solution does not allow Hyper-V servers to run Linux and Open vSwitch in the same Quantum environment, at least the connection between Quantum and Hyper-V works satisfactorily.