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.

Cinder

In OpenStack, Cinder is the component that provides the VMs with persistent block storage. Again, this software was not capable of running on Windows before CloudBase. Cinder was given a graphical installer (Figure 3) and can be installed on Windows Server systems now, with the cinder-volume component doing most of the work.

Figure 3: The Cinder installer for Windows allows administrators to provide storage via I-SCSI on a Windows server in the cloud.

Now the administrator can mount the storage volume on the Cinder host directly on the active virtual machines without any problems in the form of block devices, regardless of whether the virtual machines run Linux or Windows. It simply users I-SCSI, which Windows servers can share natively.

CloudBase Init

Cloud computing commentators love to use the following animal metaphor: conventional IT setups consist of systems, which need to be cherished and maintained like kittens. Systems in an OpenStack cloud, however, are basically cattle, whose failure no longer fazes the owner emotionally. After all, the failed system can always be replaced with another, perhaps even automatically. The devil is in the details, however: Even if a virtual machine is arbitrarily replaceable, you need to know a few specific bits of data. This data includes the host name or the SSH key, which must be stored on the system for remote login to work. For Linux guests, a simple and reliable way to resolve this problem is in OpenStack clouds: cloud-init. The shell script that calls a Linux guest when starting uses a predefined URL http://169.254.169.254:80/.

In the background, OpenStack ensures that the request ends up with the Nova metadata server, where an appropriate reply is sent subsequently (Figures 4 and 5). The virtual machine thus discovers who it is. The whole principle seems to be shamelessly stolen from Amazon AWS, where the process basically works the same way.

Figure 4: The metadata service tells virtual machines all about themselves, for example, their hostnames.

Figure 5: When launched, most cloud images retrieve their information from the metadata server.

The only problem with this process is that cloud-init is Linux-specific; a port to Windows does not make sense technically for the open source community. CloudBase, however, has bitten the bullet and written a re-implementation for Windows, by the name of cloudbase-init (Figure 6) [7]. On a Windows system, it basically serves the same purpose as cloud-init on Linux systems. In the meantime cloudbase-init almost has more features than its Linux ancestor, and it has evolved into a reliable tool.

Figure 6: Cloudbase-init starts after the Windows VMs boot and implements on Windows the same features that cloud-init provides for Linux.

Big Announcements

Windows systems with Hyper-V can already be very neatly integrated into an OpenStack environment; only the network issue is still problematic. CloudBase, however, is not resting on its laurels: as a speaker at the OpenStack CEE Day 2013 in Budapest, CEO Alessandro Pilotti made a stir in June with an ambitious plan: CloudBase is working on making Open vSwitch run natively on Windows (Figure 7).

Figure 7: Network in OpenStack: Neutron with Open vSwitch is the standard; CloudBase is currently porting Open vSwitch to Windows.

A Windows port would certainly benefit all applications that rely on Open vSwitch, but in the OpenStack context, the benefits would be most evident. Once Open vSwitch works for Windows, it would be possible to completely and seamlessly integrate Hyper-V systems in existing clouds with OpenStack and manage them in the same interface using a browser.

Only live migration between individual servers remains a problem; live migration of KVM to Hyper-V or any other virtualization technology is currently not supported and unlikely to be in the foreseeable future. In OpenStack, however, this problem could possibly be mitigated by putting the Linux systems and the Hyper-V server in their own zones. OpenStack thus has the option of distinguishing between the servers.

Guest and Hypervisor

It might surprise some Linux users, but Windows systems do not only live as guest VMs in OpenStack. Windows can also be used as a hypervisor in OpenStack, and the credit for this goes to CloudBase. In fact, with just a few mouse clicks, you can convert a Hyper-V system into an OpenStack node, and support for storage (Cinder) and the software-defined network (neutron) is already included.

The fact that the company is now even taking it upon itself to launch Open vSwitch in a version for Windows is great news for anyone who would like to add Hyper-V systems as hypervisors in their clouds. Thus, users can hope that CloudBase is making good progress with the porting work.

If you want to test the capabilities of Windows in OpenStack, check the CloudBase site [5] for all the required OpenStack components, as well as a prebuilt image that demonstrates the abilities of Windows guests in OpenStack. The image is a trial version, but you can convert it into a normal version by entering a serial number.

The OpenStack project documentation archive has useful HowTos on setting up a Windows image for use in OpenStack [8].