Tech Broiler

Jason Perlow and Scott Raymond
Home / News & Blogs / Tech Broiler

Geek Sheet: Virtualizing Free Linux Distributions in Windows Server 2008 R2

By | August 9, 2009, 12:01pm PDT

Summary: It’s been a while since we’ve had a hardcore Geek Sheet installment, and I promise that this one will be a real winner. Some of you may be aware that the updated Hyper-V bare-metal hypervisor virtualization layer in Microsoft’s upcoming Windows Server 2008 R2 (Which is due to be released August 14th to MSDN and Technet [...]

It’s been a while since we’ve had a hardcore Geek Sheet installment, and I promise that this one will be a real winner.

Some of you may be aware that the updated Hyper-V bare-metal hypervisor virtualization layer in Microsoft’s upcoming Windows Server 2008 R2 (Which is due to be released August 14th to MSDN and Technet customers) now has support for SUSE Linux Enterprise Server 11 (SLES) and Red Hat Enterprise Linux 5.3 (RHEL). Additionally, Linux support and performance has greatly improved over the initial Hyper-V release. Microsoft also recently released it’s Hyper-V Linux Integration Components (LinuxIC) under the GPLv2 Open Source License.

The LinuxICs for Hyper-V, which are in Release Candidate status and are available for download from Microsoft’s Connect site, provide synthetic device drivers that enhance I/O and networking performance when Linux OSes are virtualized under Hyper-V. The source code for the LinuxIC’s were accepted into the Linux Driver Project and should become part of the Linux Kernel within two subsequent releases and code merges — 2.6.32 is expected to be when they will be integrated, and all Linux distributions using that kernel code base going forward should be Hyper-V enabled out of the box. Yes, you heard that correctly, Microsoft is now an official Linux Kernel contributor.

Download: Windows Server 2008 R2 with Hyper-V Release Candidate

Download: Hyper-V Server 2008 R2 Release Candidate

Podcast: Frugal Friday with Jeff Woolsey, Product Manager for Microsoft Virtualization

However, until that code merge occurs, only Red Hat Enterprise and SUSE Linux Enterprise Linux distributions are officially supported by Microsoft as Hyper-V for Server 2008 R2 ready. Both RHEL and SLES are commercial Linux distributions and cost money for updates and maintenance. However, that does not mean that free Linux distributions will not work fully optimized with synthetic driver support in Hyper-V now. They most certainly do, and you can definitely take advantage of VMs running on free Linux distributions on Hyper-V right away.

Over the last week or so, I’ve been putting the release code of Windows Server 2008 R2 as well as the free Hyper-V Server 2008 R2 release candidate through their paces and running a combination of both Windows and Linux virtual machines on them. The free Linux distributions I have had most success with running the Hyper-V LinuxICs on are CentOS 5.3, Scientific Linux 5.3, and OpenSUSE 11.1.  In my limited testing, I only used 64-bit versions, because Windows Server 2008 R2 is 64-Bit only and I wanted to fully take advantage of the processing capability and native 64-bit virtualization of Hyper-V. However, the LinuxIC’s should also install fine on the 32-bit versions of these systems.

CentOS 5.3 (foreground) and Scientific Linux (background) running fully paravirtualized in Hyper-V in Windows Server 2008 R2.

CentOS 5.3 and Scientific Linux 5.3 are both source code clones of Red Hat Enterprise Linux, so there are only minor differences in how the LinuxIC’s are installed on them compared to how it is done in RHEL. OpenSUSE 11.1’s installation procedure is also very similar to SLES, but like the other two there are some minor changes. However, these small differences were learned through a good number of hours of troubleshooting, so as long as you follow these steps, you won’t run into the pitfalls I ran into.

Building your Linux VM in Hyper-V

First you’ll want to build your VM. Using the Hyper-V Manager, select New > Virtual Machine from the “Actions” menu on the right. You’ll be presented with this initial dialog wizard:

Here you’ll specify the name of your Virtual Machine and where you’d like it stored on your server. I created a new volume specifically for storing my virtual machines and my ISO files, the V: drive.

After clicking “Next” you’ll be asked for the amount of memory to assign. For a basic Linux server VM, 512-768MB of RAM is certainly plenty, but if you’re going to use the GUI features, 1GB or more is recommended. On the following screen, you’ll be asked to configure networking and to pick a network interface to bridge to. During the setup of the Hyper-V role, at least one network adapter should be bridged to the LAN for the virtual network switch.

Following the Network screen, you’ll be asked how large your virtual hard disk (VHD file) should be. For CentOS, Scientifc Linux and openSUSE server use, I’d recommend 8GB-20GB of space for the VHD depending on the usage role (Apache/MySQL/PhP, Java, Ruby on Rails applications, etc.)

On the final configuration screen you’ll be asked to point to your install media. You can either install from a physical CD or DVD, or from an ISO file. Once you’ve chosen your desired install media, click on Finish to create the VM.

Next –>

More from “Tech Broiler”

Topics

Red Hat Enterprise Linux, Linux Distribution, Mouse, Network, Microsoft Windows Server, Microsoft Windows, Microsoft Windows Server 2008, Microsoft Windows Server Hyper-V, SLES, LinuxIC, OpenSUSE 11.1, ENTER, Linux, UNIX, Open Source, Operating Systems, Servers, Software, Hardware, Jason Perlow

Jason Perlow, Sr. Technology Editor at ZDNet, is a technologist with over two decades of experience integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies.

Disclosure

Jason Perlow

My Full-Time Employer is IBM. I write as a freelancer for ZDNet.

Disclaimer: The postings and opinions on this blog are my own and don't necessarily represent IBM's positions, strategies or opinions.

I own no investments or direct financial instruments in the companies I write about.

Biography

Jason Perlow

Jason Perlow, Sr. Technology Editor at ZDNet is a technologist with over two decades of experience with integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies. A long-time computer enthusiast starting the age of 13 with his first Apple ][ personal computer, he began his freelance writing career starting at ZD Sm@rt Reseller in 1996 and has since authored numerous guest columns for ZDNet Enterprise and Ziff-Davis Internet. Jason was previously Senior Technology Editor for Linux Magazine, where he wrote about Open Source issues from 1999 to 2008.

In his spare time, Jason is an avid amateur chef and food writer, where his work reviewing New Jersey restaurants has appeared in The New York Times. He is also the founder of the popular food web site eGullet and blogs about restaurants and cooking at OffTheBroiler.com.

Talkback Most Recent of 46 Talkback(s)

  • cool.......:)
    nt
    ZDNet Gravatar
    straycat5678
    9th Aug 2009

  • ZDNet Blogger

    For the same reasons...
    You'd do it in VMWare. The difference is that this
    solution is free. You want live migration or
    anything else VMWare does you'll have to pay for
    it. Hyper-V is an excellent hypervisor.
    ZDNet Gravatar
    jperlow
    9th Aug 2009
  • Well having Windows as a guest on a Linux host maybe...
    but the other way around...no thank you!
    ZDNet Gravatar
    ­ 
    9th Aug 2009

  • ZDNet Blogger

    Would you run Linux on a Xen host? Or VMWare ESX?
    Because this isn't any different. You aren't
    "running" under Windows. You're running on a bare
    metal hypervisor. Windows is just the "priveleged
    guest" under the hypervisor, it runs in Domain 0
    paravirtualized. Research the architecture before
    making statements like that.
    ZDNet Gravatar
    jperlow
    9th Aug 2009

  • ZDNet Blogger

    Not better technology
    Hyper-V was designed to share similar features
    of Xen's architecture.

    Compared with Xen's management tools Hyper-V's
    are
    much more robust. Xen may be open source but
    giving it to an IT staff to manage without
    additional tools -- such as Xen's commercial
    offerings for XenServer you'll still need to
    spend
    money, open source or not.
    ZDNet Gravatar
    jperlow
    10th Aug 2009
  • Haven't you learned...
    not to argue with people that have the mind set that proprietary software is lacking because it is proprietary or FOSS is lacking because it is FOSS. Anyone with this mind set is truly half of the IT person they could be and can't possibly carry on an intelligent discussion because they have killed part of the possible scenarios without even considering them. 08/08/09 is making a decision based on nothing factual. Both flavors can be quality software and both have their place in a top notch IT environment.

    I personally would chose to run SuSE and Xen and Windows in the virtualized environment. But in no way because I think MS's proprietary offering is lacking and especially not simply because it is proprietary.
    ZDNet Gravatar
    bjbrock
    9th Aug 2009
  • Is it necessary to spend money?
    I would think most IT people could get off to a good start on Xen without buying tools. Provided they are prepared to read some basics.
    And, could you add some ideas as to how or why Hyper-V tools are "more robust"?
    ZDNet Gravatar
    peter_erskine@...
    10th Aug 2009
  • Are you suggesting....
    That you can install Xen with no O/S installed and THEN install guests?
    ZDNet Gravatar
    handydan918
    9th Aug 2009

  • ZDNet Blogger

    Xen's architecture
    and Hyper-V's architecture are the same. You
    are using a bare metal hypervisor with a
    priveleged "parent" guest OS to act as the
    driver passthru for storage and networking. But
    you are still not running guests on that OS.

    In the case of XenServer from Citrix, which is
    also a free product, you are using a heavily
    stripped-down Linux as the parent domain. So
    you are in effect installing it with almost no
    OS. Hyper-V server can be installed the same
    way, with no GUI. The Windows Server kernel is
    being used as a driver passthru privileged
    guest.

    All of this is well documented on both the Xen
    and Hyper-V sides.
    ZDNet Gravatar
    jperlow
    9th Aug 2009
  • @jperlow
    If I understand you correctly, then MS is using the Windows Server kernel as the backbone of Hyper-V. If so, then has MS solved the problem with the heavy resource penalty when spawning processes in their latest kernel? Or is it still better to spawn threads with the Windows Kernel?
    If it's still better to spawn threads, then with MS current method for spawning threads with shared processes should make anybody pause and rethink using Hyper-V. Because it will never be as stable as Linux.
    ZDNet Gravatar
    Axsimulate
    10th Aug 2009
  • @axsimulate: You have misunderstood both Windows kernel and hypervisor
    1) An operating system running under a type 1 hypervisor does not use the host operating system kernel at all. If you run Linux under Hyper-V, creating a Linux process does not create a process or thread in the host Windows system.

    2) Windows makes a distinction between processes and threads. A Windows process is not a unit of execution and is not subject to scheduling as in Linux. A Windows process provides boundaries such as memory, handles, security etc. But it *never* executes *anything*. Instead all processes own at least one thread. The responsibility is simply more "modularized" if you will: Boundaries are the responsibility of processes (merely a data structure), execution is the responsibility of threads. In Linux these are mixed in with eachother.

    You are correct that processes are considered "expensive" in Windows. However this is not a problem as you claim, it is merely a design decision. Threads are considered lightweight and comparatively cheap to create.

    Windows system libraries are all guaranteed thread-safe, and in general also 3rd party DLLs can be assumed to be thread-safe, unless otherwise stated.

    This is not the story on Linux where the "thread-safeness" of even many system libraries are unknown. This is the reason why e.g. PHP can execute threaded under Windows but you are (strongly) advised to execute PHP under the Apache MPM dispatcher if you are using LAMP.

    Either way, the Windows kernel threading/process model has absolutely no bearing on the "guest" operating system. That is a misunderstanding. The guest's processes are not mapped to processes/threads in the host OS.
    ZDNet Gravatar
    honeymonster
    10th Aug 2009
  • @honeymonster
    "1) An operating system running under a type 1 hypervisor does not use the host operating system kernel at all. If you run Linux under Hyper-V, creating a Linux process does not create a process or thread in the host Windows system."

    I guess I'm not understanding how Hyper-V works. Doesn't it need some sort of kernel to provide a foundation for the virtual machines?

    Don't vmware use a trimmed down Linux kernel as a foundation?

    "2) Windows makes a distinction between processes and threads. A Windows process is not a unit of execution and is not subject to scheduling as in Linux. A Windows process provides boundaries such as memory, handles, security etc. But it *never* executes *anything*. Instead all processes own at least one thread. The responsibility is simply more "modularized" if you will: Boundaries are the responsibility of processes (merely a data structure), execution is the responsibility of threads. In Linux these are mixed in with eachother."

    Yes, I know that processes in Windows are different than Linux/Unix. What I'm saying is, take svchost.exe for example, many different apps piggyback on this process such as networking. When they do this, this negates the whole purpose of memory protection as each thread shares the same memory space as the host process and can encroach on another threads. If one thread goes down, it can bring other threads down until the entire system goes down. Not only can this happen, the way Windows handles threads, there is no easy way to identify an errant thread and restart it. And if the errant thread has a memory leak, restarting it don't free up the memory it has consumed, which ultimately requires a system restart to free the memory. Hence less stability.
    ZDNet Gravatar
    Axsimulate
    10th Aug 2009
  • @axsimulate: You are incorrect
    once the process hosting the thread is ended, all memory that may have been leaked is released back to the os. No os restart is needed.
    Also, one thread terminating unexpectedly generally has no effect on the system as a whole.
    svchost is a special process, designed to be a surrogate container for services. It's supposed to host services. No "Apps" piggyback onto this, only services.
    ZDNet Gravatar
    ITLeader
    10th Aug 2009
  • @ITLeader
    "once the process hosting the thread is ended, all memory that may have been leaked is released back to the os. No os restart is needed."

    Yes, that is what is suppose to happen. What happens when an errant thread gobbles up memory? Killing the offending thread don't always free up the memory it took.

    "Also, one thread terminating unexpectedly generally has no effect on the system as a whole."

    Yes, that is the way it is suppose to work. However what happens when an errant thread starts to stomp all over the other threads? Because each process may have it's own protected memory space, threads don't. Piggybacking defeats the sole purpose of protected memory.


    "svchost is a special process, designed to be a surrogate container for services. It's supposed to host services. No "Apps" piggyback onto this, only services."

    Yes, I understand that. However MS's own programming guidelines encourage the use of piggybacking on processes. svchost was nothing more than an example. And yes, svchost can, will and has brought the entire system down.
    ZDNet Gravatar
    Axsimulate
    17th Aug 2009
  • Bare Metal? I think not.
    Jason-

    Calling Hyper-V a "bare-metal" hypervisor is a stretch, at best. By
    definition, a bare-metal hypervisor does not contain a general
    purpose operating system. All drivers are fully contained and
    optimized in the kernel itself. This has important implications for
    performance and security, among other things.

    Note that the Wikipedia article that you referenced does not call
    Hyper-V a "bare-metal" hypervisor once. This is because it is not.
    http://en.wikipedia.org/wiki/Hyper-V

    Jason, I think you need to "Research the Architecture" a bit more
    yourself. You were rather rude in response to a simple question, "Why
    would anybody want to trust their virtualized infrastructure to
    Windows?" While Hyper-V is Microsoft's first true hypervisor, it is a
    first generation product and still highly dependent on Windows. If the
    "privileged guest" dies, so does your ability to access your VMs.

    Hyper-V is comparable to VMware ESX v1 which was released in 2001.
    This ESX release used RedHat as a privileged guest in a fashion similar
    to Hyper-V. When/if Microsoft manages to untangle Hyper-V from
    the Windows driver stack, but still leaves Windows to manage the
    kernel then it will have progressed to match VMware ESX v2 which was
    released in 2003.

    If Microsoft ever removes Windows altogether and simply ships a true
    "bare-metal" hypervisor then they will match what VMware completed
    in 2007 with ESXi v3. This is highly unlikely considering that
    Microsoft's stated virtualization strategy is to sell virtualization as a
    feature of the OS. This stands in stark opposition to the concept of an
    OS-free bare-metal hypervisor.

    The point is that Microsoft's hypervisor still lags 8 years behind
    VMware and is additionally dragged down by its reliance on Windows.
    I will agree that Microsoft's management tools are doing better than
    their hypervisor as the "live migration" feature that will ship this fall
    finally is in the same ballpark as VMware's VMotion. However, VMware
    shipped VMotion way back in 2003, so Microsoft is still way behind in
    this area as well.

    So, back to the original question, with Windows' long history of
    unreliability and with thousands of companies virtualizing their
    systems with non-Microsoft products to protect themselves from the
    risks that Windows poses, "Why would anybody want to trust their
    virtualized infrastructure to Windows?"
    ZDNet Gravatar
    A/UX
    10th Aug 2009
View More Comments

Talkback - Tell Us What You Think

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

Blog Roll

Blog Archive

White Papers, Webcasts, & Resources