OpenStack on Microsoft Windows

Stack Merge

Article from Issue 156/2013

An Italian company is making sure Microsoft doesn't sleep through the hype concerning OpenStack. Learn about the recent work on integrating OpenStack with Microsoft's Hyper-V hypervisor.

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.

About Licenses

Unlike Linux, Windows virtual machines will generally need a license key. A Windows virtual machine that does not have such a key either doesn't work, or it only works as a limited trial version The good news is that it is very much possible to use the tools described to dynamically give a VM a license key. Glance, the imaging component in OpenStack, then stores the image like a "VM without a memory" – it only becomes a full instance with the appropriate feature set after the admin enters the license key.

The bad news is that admins need a license from Microsoft for each Windows VM. What proves to be the greatest stumbling block is that the Windows volume licenses that many companies already possess are not usable in such cases, because the hypervisor is not managed by the company that owns the volume license in a cloud environment. Instead, Microsoft requires the cloud operators to obtain their own license for each virtual machine; in turn, they can bill the customers for it.

This cumbersome procedure is a big nuisance, and it is something that requires immediate attention by Microsoft. The present strategy of offering volume licenses at the hypervisor level only for those servers that are actually controlled by the company simply does not work in a cloud environment. Technically speaking, there is basically absolutely nothing to prevent giving cloud customers the option of using their existing volume licenses for their VMs. Thus, the impression arises that Microsoft just wants to dip into the customer's pockets.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More