May, 2009

This blog entry describes the support in Windows 7 and Windows Server 2008 R2 for creating and managing Virtual Hard Disk (VHD) files as a native format, and booting a physical machine from a VHD file.  Native VHD support helps our enterprise customers and developer community use a common image format and common tools to manage and deploy Windows images that run either in Hyper-V virtual machines or on physical machines.

The Microsoft Virtual Hard Disk file format (VHD) is a publicly available format specification that specifies a virtual hard disk encapsulated in a single file, capable of hosting native file systems and supporting standard disk operations. VHD files are used by Microsoft Windows Server 2008 Hyper-V, Microsoft Virtual Server and Microsoft Virtual PC for virtual disks connected to a virtual machine.   VHDs are useful containers and the VHD file format is also used by Microsoft Data Protection Manager, Windows Server Backup as well as many other Microsoft and Non-Microsoft solutions.  To create a VHD on Windows Server 2008, you install the Hyper-V Server role and use the Hyper-V Manager to create a VHD file, and then install a version of Windows onto a partition in the VHD. 

Many of our data center customers are transitioning to Hyper-V virtual machines (VMs) for server consolidation and lower energy costs.  While moving an increasing number of applications to virtual machines, they still operate a significant part of the data center on physical machines. Managing the system images that are deployed to physical and virtual machines can be challenging.  IT administrators have to maintain two sets of images: one set based on the WIM format for physical machines, another set based on the VHD format for virtual machines.  What IT administrators need is a common format and toolset to make image management simpler and reduce the number of images to catalog and maintain.

Developers and testers are using virtual machines to test new system and application software.   Virtual machines provide a convenient, isolated test environment and reduce the need for dedicated test hardware.  But sometimes you need to run tests on a physical machine to access a specific hardware device, like the graphics card, or to get accurate performance profiling.   A common image format that runs on both virtual and physical machines also benefits developers and testers. 

In this blog entry we are going to look at the goals for supporting VHDs as a native format, how the core operating system supports VHDs, and the key scenarios targeted for native VHD deployment.

Goals for Native Support for VHDs in Windows Server 2008 R2 and Windows 7

1. Simplify the experience of creating, managing, and deploying Windows images across both physical and virtual machines using a single image format and common tools.
   
2. Enable systems to have multiple instances of Windows installed without using separate disk partitions for more flexibility to change server application workloads as needed.
   
3. Enable efficient development and testing for software that requires an isolated test environment using a common image that runs on either a physical or virtual machine.

Creating and managing VHDs

Windows 7 simplifies image management by adding support for virtual disks in the disk management tools.  You no longer need to install the Hyper-V Server role and use the Hyper-V Manager console to create VHDs.  The Disk Management console has an action to create a new VHD file, for either a fixed size or dynamically expanding VHD, which is uninitialized.  After creating the VHD file, the Attach VHD action makes the virtual disk available to the system as if you plugged in a hard disk drive. 

Figure 1. Creating a VHD using the Disk Management console

After attaching a new virtual disk, you create a partition and format an NTFS volume in the VHD just like a physical disk.  The VHD is ready for a Windows image to be applied to the volume and initialized for boot.

Server administrators often prefer command line tools, and you can do the same VHD operations using the diskpart command.  Diskpart also accepts a script to automate the steps to create and format a VHD. When a VHD containing a file system volume is attached, Windows automatically recognizes the volume and provides an option to explore the contents.

Figure 2.  Using the Diskpart command to create a VHD

Core Storage System Support

Access to VHD file contents is provided by a completely new mini-port driver in the storage stack for VHD files.  The VHD driver is what enables I/O requests to files in the VHD to be sent down to the host NTFS file system on the physical partition where the VHD file is located.  VHD operations can also be performed on a remote share.

With Windows Server 2008 R2, Hyper-V now uses the new native support for VHDs in the core operating system.  We have done extensive testing on a wide range of I/O test scenarios and the native VHD support is incredibly efficient.   Read and write performance for different I/O block sizes, for both sequential and random I/O is comparable with physical disk performance.  The following graphs show some of the preliminary results from performance tests comparing throughput to Fixed and Dynamic VHD files in Windows Server 2008 R2 Beta with Windows Server 2008 Hyper-V.   The “Bare Metal” columns show the maximum I/O throughput to the physical disk device without using a VHD file.   Lower write throughput to dynamic VHDs is due to multiple I/Os required to expand the file as new blocks are written to the virtual disk.

Operating system support for VHD as a native format provides opportunities for management ISVs to bring added value to their customers without introducing complexity with new image formats.  There are new Win32 APIs for VHD operations that enable image management tools to support the VHD file format in their management framework. 

Native VHD Boot

Native VHD boot enables the seamless transition to virtualization using a single image format that boots on both physical and virtual machines.  Native VHD boot means that the Windows image in a VHD file can boot on a physical machine without starting a Hyper-V virtual machine. VHD image files make it easy for a single physical machine to have multiple instances of the operating system available to boot at any time.   Multiple boot support has been available in Windows for many releases, but required a separate disk partition for each installed operating system.  Native VHD boot supports all three types of VHD files: fixed, dynamic, and differencing disks.  

Developers and testers can use native VHD boot to run test versions of new device drivers or other software for Windows with full access to the hardware devices connected to the system.  A differencing VHD file provides a convenient way of initializing a test environment, performing tests and reverting back to a clean or baseline state after testing is complete.  Executing tests will result in updates being made only to the differencing disk. Once the testing is complete you can revert back to the clean state in the parent VHD by simply throwing away the differencing file and creating a new one. 

Native VHD boot enables IT Administrators to quickly repurpose a machine for different roles.  Servers can have multiple application workloads in separate VHD files available and switch between workloads to adjust to demand.   The flexibility of multiple boot using VHD files also makes it easy to keep a previous Windows image available to use as a fall-back in the event of a problem with a new image. 

Native VHD boot depends on enhancements to the Boot Configuration Data (BCD) to represent the VHD file as a boot device rather than a physical disk partition.  The following image shows an example of a multiple boot configuration with a VHD boot entry.

Figure 3. Multiple boot configuration with VHD boot entry

The Windows 7 boot manager and loader can now read the files required to start the operating system from the Windows image inside a VHD file.  When Windows boots from a VHD file, all the ‘disk I/O’ to load the kernel device drivers, start system services, and run applications is translated to I/O to the VHD file initially, and then to I/O to the NTFS volume and the physical disk.    On shutdown, all outstanding write operations flush to the VHD file and underlying physical partition in the proper order before the storage stack shuts down the disk device.  Because of these enhancements to core parts of the system, native VHD boot only works for VHDs containing Windows 7 or Windows Server 2008 R2 and not earlier versions of Windows.  Native VHD boot in this release does not support BitLocker, or hibernation (which includes resuming from hibernate).

Deploying Images

To put a Windows 7 or Windows Server 2008 R2 operating system image in the VHD file, you have to apply an image to the partition in the VHD file. Running Setup from the install DVD and selecting a partition in a VHD file for installation is not supported. Here are two ways you can apply a WIM image to a VHD:

1. Use the Install-WindowsImage Powershell script from the MSDN Code Gallery.
   
2. Or use the Imagex deployment tool from the Windows Automated Installation Kit (WAIK).

The Install-WindowsImage Powershell script uses the wimgapi.dll in Windows 7 to apply a WIM to a VHD. Use the script if you are not familiar with the WAIK and Imagex.exe tool, or do not have the WAIK available.

See the document Using Install-WindowsImage, on the Install-WindowsImage site for step-by-step instructions on how to create a VHD and apply a WIM image for VHD boot.

IT professionals will be interested in using the WAIK deployment tools to customize and capture a reference Windows image and deploy the image in VHD format to either physical or virtual machines. The basic deployment steps for the IT Administrator to prepare a custom Windows image includes the following:

• Install Windows to a partition on a physical machine first as a reference.
• Customize the reference image settings and installing the applications you want.
• Run the sysprep command on the reference system to generalize the image, which resets some of the system state and device configuration in Windows specific to that machine and shuts down.
• Capture the reference image from the physical partition into a Windows image file that you copy to a server share.
• Apply the Windows image to a VHD file and initialize the VHD boot environment.

The VHD file with a generalized image can be copied to and used on multiple physical or virtual machines. A generalized image is required to avoid system startup issues because the hardware on the new system is different, and to avoid having multiple copies of Windows with the same machine identity (name and security identities), on the network. During the first boot of Windows from the VHD file on a different physical or virtual machine, Windows will specialize the image for the new machine, configure devices, and prepare for first use. Copying the reference VHD file is quick way to get a new Windows 7 or Windows Server 2008 R2 image to a machine for development, testing, or staging for servers.

If you want to deploy Windows images to many machines, you can leverage the Windows Deployment Service (WDS) feature of Windows Server 2008 R2. WDS is enhanced with the ability to add VHD image files to the WDS image catalog. The WDS administrator creates image groups for VHD files that are ready to deploy to machines that use network boot, or “PXE boot”. When WDS deploys a VHD image, the client agent copies the VHD file locally and configures the boot environment to boot from the VHD. All the applications and system settings are configured in the master reference image in the VHD file. When Windows boots from the VHD file for the first time, the system is specialized as mentioned above, for the physical devices on the target machine and then is ready for use. That’s pretty convenient and goes a long way toward rapid deployment.

While native VHD format support and specifically native VHD boot opens up a lot of usage scenarios, our goals with this technology are fairly specific: simplify image management for enterprise customers migrating server workloads to virtual machines, and enable efficient development and testing of software in an isolated environment on either physical or virtual machines. The support for VHD as a native format targets key scenarios in the enterprise where the IT staff is well versed with different imaging technologies and tools to manage their client and servers. A managed enterprise environment also employs technologies like folder redirection and roaming profiles to manage the user’s data outside the deployed VHD images.  Developers will appreciate the ability to quickly update or replace a private VHD image during development. Test environments can use multiple VHD images and differencing disks for more efficient use of test machines.

Hopefully this blog posting gives you an idea of how Windows 7 and Windows Server 2008 R2 supports VHD files as a native format and why the common image format for physical and virtual machines will be interesting for many customer environments.

Mike Kolitz
Software Design Engineer in Test
Hyper-V Test Tools and Infrastructure

Update: A few people have asked me whether this information applies to Microsoft Hyper-V Server 2008 R2 as well.  Yes, it does.

Virtualization Nation,

Greetings from Tech Ed in Los Angeles! It's been a busy couple of days and you've probably heard the big news by now, Windows 7 and Windows Server 2008 R2 will be shipping for the holidays!

On the Hyper-V R2 front, we're pleased to announce a few surprises of our own. :-) Let's start with scalability.

64 logical processor support. This is a 4x improvement over Hyper-V R1 and means that Hyper-V can take advantage of larger scale-up systems with greater amount of compute resources. As our friends at AMD and Intel drive up core counts, we want you to know that Hyper-V is ready to take advantage of the compute resources in your server today and those you're buying tomorrow.

Support for up to 384 Concurrently Running Virtual Machines & 512 Virtual Processors PER SERVER. (No, that's not a typo.) Going hand in hand with our support for 64 logical processors, we're upping the maximum number of concurrently running virtual machines to 384 per server and the maximum number of virtual processors to 512 for the highest virtual machine density on the market. Here are a few examples. You could run:

1. 384 single virtual processor vms OR
2. 256 dual virtual processor vms (512 Virtual Processors) OR
3. 128 quad virtual processor vms (512 Virtual Processors) OR
4. any combination so long as you're running up to 384 VMs and up to 512 Virtual Processors

Live Migration & Processors.

With the addition of Live Migration in Hyper-V R2, one of the immediate questions we're asked is: "Do the physical processors have to be exactly the same?"

Scenario 1: Suppose you bought three servers for live migration and created a three node cluster. Everything's working well and a 6-12 months down the road you want to add another couple of nodes to increase the compute resources in your cluster. In the meantime, your OEM has upgraded their server hardware line with new processors, now what do you do?

Scenario 2: You work in a small/medium business or K-12 education and you need to squeeze every nickel you can out of your budget. You want to use virtualization and would love to use Live Migration, but you have a mix of different servers ranging from Pentium 4, Core 2 and maybe next year you'll get budget to purchase a new Core i7 server.

Wouldn't it be great if you could Live Migrate virtual machines across different processor generations?

We think so too.

Introducing: Processor Compatibility

With Hyper-V R2, we include a new Processor Compatibility feature. Processor compatibility allows you to move a virtual machine up and down multiple processor generations from the same vendor. Here's how it works.

When a Virtual Machine (VM) is started on a host, the hypervisor exposes the set of supported processor features available on the underlying hardware to the VM. This set of processor features are called guest visible processor features and are available to the VM until the VM is restarted.

When a VM is started with processor compatibility mode enabled, Hyper-V normalizes the processor feature set and only exposes guest visible processor features that are available on all Hyper-V enabled processors of the same processor architecture, i.e. AMD or Intel.  This allows the VM to be migrated to any hardware platform of the same processor architecture. Processor features are "hidden" by the hypervisor by intercepting a VM's CPUID instruction and clearing the returned bits corresponding to the hidden features.

Just so we're clear: this still means AMD<->AMD and Intel<->Intel. It does not mean you can Live Migrate between different processor vendors AMD<->Intel or vice versa.

In addition, you may be aware that both AMD and Intel have provided similar capabilities in hardware, Extended Migration and Flex Migration respectively. Extended and Flex Migration are cool technologies available on relatively recent processors, but this is a case where providing the solution in software allows us to be more flexible and provide this capability to older systems too. Processor Compatibility also makes it easier to upgrade to the newest server hardware. In addition, Hyper-V Processor Compatibility can be done on a per VM basis (it's a checkbox) and doesn't require any BIOS changes.

Processor Compatibility In Action

Here's an example of a cluster we've been testing. This is a 4 node cluster using 4 generations of Intel Processors with VT all attached to a small iSCSI SAN over 1 Gb/E. We have a script that continuously Live Migrates VMs from one node to the next every 15 seconds. We've been running this test for about a week and have successfully completed over 110,000 Live Migrations. Looks kinda like this.

Time To Get Uber-Geeky

Now that I've explained what processor compatibility mode does and the flexibility provides, I'm guessing there are a few propeller heads who want to go further and know exactly what a "normalized processor" means from a processor feature standpoint. Happy to oblige. When a VM in processor compatibility mode is started, the following processor features are hidden from the VM:

FAQ

Q: What happens if a vendor has written an application that uses one of these features that isn't visible with processor compatibility enabled?

A: Since the feature isn't exposed to the virtual machine, the application won't "see it" and it's up to the application to determine how to proceed; however, there are two likely paths.

Path 1: The application will check to see if a specific processor feature is available and use it if it's available. If the processor features isn't available, it will use a different code path. Remember that applications that make use of these advanced processor features are generally written in a flexible fashion to accommodate the servers in market today and there are still thousands of older Xeons and Opterons on the market that don't have some of the latest processor features.

Path 2: The application requires a specific processor feature and refuses to launch. At this point in time, we haven't found any application that fall into this category. It's possible they exist, but we haven't hit one yet. Since we can't test every application out there, processor compatibility is defaulted off. (We're conservative by nature.).

BTW, if there were issues with Hyper-V Processor Compatibility, you'd also see it with other virtualization products which rely on underlying hardware capabilities to mitigate this problem as well.

Q: Does processor compatibility have a hardware requirement? Does it require Intel Flex Migration or AMD Extended Migration?

A: Hyper-V processor compatibility mode has no dependencies on these technologies.

Q: Does Hyper-V processor compatibility allow you to migrate a VM from an AMD host to an Intel host and vice versa?

A: No. Processor compatibility allows you to move a virtual machine up and down multiple processor generations from the same vendor. It does not allow migrating a VM (with or without processor compatibility mode) from AMD based hosts to Intel based hosts, and vice versa.

Cheers,

Jeff Woolsey

Principal Group Program Manager

Windows Server, Hyper-V

You'll want to read Isaac's blog post about the RC milestone of Windows Server 2008 R2. His post focuses on 64 LP support and processor compatibility mode for live migration. Read the post here.

Here's an excerpt:

64LP Support

We have seen processors grow from 1, 2, 4, and now 6 cores on a single processor, soon to hit 8.  Within the Windows Server 2008 R2 lifecycle, 64 logical processor servers will become commonplace (8 processors x 8 cores).  Virtualization is the natural fit for these next-gen servers, allowing them to consolidate a greater number of virtual machines on a single host. Hyper-V is in line with these hardware trends all with an eye towards bringing you greater VM density. The dev team has done a fantastic job in building and testing a platform that can scale.

Let's take a quick look at the history of logical processor support for Hyper-V:

• Server 2008 Hyper-V                                         16 LP Support
• Server 2008 Hyper-V +update (KB95670)      24 LP Support
• Server 2008 R2 Hyper-V Original POR           32 LP Support
• Server 2008 R2 Hyper-V RC/RTM                   64 LP Support!

Processor Compatibility Mode for Live Migration 

Live Migration is the killer-feature in Windows Server 2008 R2!  Previous to the RC build of Windows Server 2008 R2, identical CPUs were needed across every node in the cluster in order to perform a live migration.  As we came closer to the RC milestone we got feedback from customers and partners asking, "What if I deploy additional nodes that contain newer processors with features not contained in the original nodes?"  Well, we've solved that problem due to tremendous effort by the Hyper-V development team.

Processor compatibility mode is very straightforward. It enables live migration across different CPU versions within the same processor family (i.e. Intel-to-Intel and AMD-to-AMD). However, it does NOT enable cross platform from Intel to AMD or vice versa. It works by abstracting the VM down to the lowest common denominator, in terms of instruction sets, which enables live migrations across a broader range of Hyper-V host hardware.

There are a few things to note: Processor compatibility mode is disabled by default but you can configure it on a per-VM basis. There are no specific hardware requirements other than the CPUs must support hardware assisted virtualization (i.e. Intel's IVT and AMD's AMD-V).

Patrick

Virtualization Nation,

I thought we were done with this topic yesterday. I really did. If you missed my last article and aren't sure what I'm talking about, it's here.

Scott Drummonds, VMware Product Marketing, apparently saw my response and attempted to respond. I say attempted because if you're looking for facts Scott still doesn't provide many.

I've taken the text below verbatim from his blog and will again provide the facts.

Scott's Sort Of Blog Response

Since I posted the YouTube video showing Hyper-V blue screens last Friday I've received a lot of comments, questions, compliments and complaints. The video and descriptive text have raised more questions than answers, so here are a few details to help fill out the story.

• The workload was not technically VMmark. There are two reasons for this:

VMmark's run rules specify that the VMs must be configured with a single virtual disk. Because this configuration can't make use of Hyper-V's paravirtualized SCSI driver, which requires a second virtual disk, the run rules were violated to make Hyper-V produce its best results.

Jeff Woolsey: I have no idea what he's talking about. Hyper-V VMs support 4 virtual IDE disks, 4 virtual SCSI controllers and each virtual SCSI controller supports up to 64 virtual hard disks. That's 4 times more than ESX. If you want to run a virtual machine with a single virtual disk just do it. My best guess is this: Hyper-V only boots from virtual IDE, not virtual SCSI, and whoever ran this test thinks that the test must be run from virtual SCSI for the best performance.

That's not the case with Hyper-V.

Once you install the Integration Components in the guest OS it doesn't matter. Our virtual IDE performs just as well as our virtual SCSI because we provide an optimized enlightened (para-virtualized) IDE path. This ensures our customers always get the best possible disk performance.

The only limitations here are:

1. ESX needs virtual SCSI to get better performance because their virtual IDE doesn't perform as well
2. The person(s) running these test don't understand what they're testing

The vendors that provided requirements for VMmark included use of SMP Linux guests. Hyper-V's lack of support for these configurations means that it is unable to run VMmark according to the rules. Those rules were ignored by the test team and the ESX and Hyper-V tests were run with uniprocessor Linux guests so that Hyper-V was able to produce some number.

Jeff Woolsey: I see no mention of the specific guest operating system version (Red Hat, SUSE, ???) or if the Linux Integration Components were installed. I'm going to assume by the stellar test methodology so far that's a "No."

• The server ran 15 tiles* when ESX was installed. So, the hardware is good.

Jeff Woolsey: As I pointed out in my last blog, of the 750,000 downloads of Hyper-V gold code, we've had 3 reports of crashes under stress and with the same error code as seen in the video bugcheck (0x00020001). The solution in all three cases was to upgrade the server BIOS which solved the problem. This can happen as hypervisors interact very closely with the hardware and BIOS updates generally include updated microcode for processors oftentimes to address errata.

As you still haven't answered some of the most basic questions about this "test" (and I use the word test in the broadest sense as a test implies a methodology) you'll have to excuse me if I disagree with the assertion that the hardware is properly configured and up-to-date.

Methodology, Heard Of It?

Even with this new information, Scott is still missing the most basic of information. What version of Hyper-V was this? Was this the version included with Windows Server 2008? If so, that's the beta. Did you apply the RTM update? Did you use the final shipping Integration Components in the guests? Did you include the Linux Integration Components for the Linux guests?

The way this information is dribbling out indicates a lack of methodology and systematic testing. Apparently, VMware has no problem ignoring these precepts when it suits them.

Here's what I mean.

The Hypocrisy of VMWare's Benchmark Restrictions

Ever wonder why there are almost no public competitive benchmarks of VMware, Hyper-V and/or Xen?

Simple, VMware doesn't permit it without their approval. No, I'm not kidding. Here's the exact language: http://www.vmware.com/download/eula/esx_server.html

3.3 Restrictions. You may not (i) sell, lease, license, sublicense, distribute or otherwise transfer in whole or in part the Software or the Software License Key to another party; (ii) provide, disclose, divulge or make available to, or permit use of the Software in whole or in part by, any third party (except Designated Administrative Access) without VMware's prior written consent; or (iii) modify or create derivative works based upon the Software. Except to the extent expressly permitted by applicable law, and to the extent that VMware is not permitted by that applicable law to exclude or limit the following rights, you may not decompile, disassemble, reverse engineer, or otherwise attempt to derive source code from the Software, in whole or in part. You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware to request such review.

If you ask them why, their answer is:

"Benchmarking is a difficult process fraught with error and complexity at every turn. It's important for those attempting to analyze performance of systems to understand what they're doing to avoid drawing the wrong conclusions or allowing their readers to do so." (from HERE)

So, what does that mean when VMware royally screws up?

Apparently, that's OK as the video is still posted even after Scott is struggling to come up with the most basic of facts.

Scott Goes On To Say

I'm hoping to convince the people responsible for the test to shed their anonymity and come out with an official paper. I'll provide those details as soon as I can get them.

Gosh, that's awfully swell of you Scott.

In the meantime, I'm guessing you're going to leave that defamatory video posted which has no merit or value except to a VMware salesman. This looks great for your credibility, VMware's credibility and EMC's.

Your management chain must be proud.

Jeff Woolsey

Principal Group Program Manager

Windows Server, Hyper-V

Virtualization Nation,

I prefer to spend my time talking about the great things we're doing with Hyper-V and Microsoft virtualization. We have a lot of very happy customers today with Hyper-V R1 and the upcoming R2 release delivers even more in terms of scalability, performance and new features like Live Migration and much, much more. Unfortunately, I need to take a moment to respond to some VMware FUD circulating the web.

Out on the web, there's an "anonymous" video purporting to show a Hyper-V crash. When I heard, I was surprised and immediately wanted to know more. I haven't heard of any such incidents with Hyper-V and the Hyper-V R1 release has been incredibly stable and reliable. So, what did I find?

The Video: No Facts Just FUD.

Not much. Where are the details? There are no facts provided. What Hyper-V build was this? The beta? What was the configuration being tested? Who posted this? Why didn't they contact Microsoft support? I mean there's literally no data other than a defamatory statement at the beginning of the video implying that Hyper-V had something to do with some downtime at TechNet/MSDN. The SQL team and Operations responded to this days ago. In short, Hyper-V had nothing to do with the outage.

So, why would someone create such a video? Let's dig a little deeper.

The Poster.

The poster, who doesn't appear on the video, doesn't state what company he works for or provide any context. Gee, I wonder where he works?

<drum roll please>

Introducing Scott Drummonds, VMware Product Marketing.

Gosh, I wonder why Scott didn't mention he works for VMware?

Very professional Scott.

No signs of desperation there at all.

Looks like I'll need to provide the facts here.

What I Do Know.

1. In the first 7 months of Hyper-V RTM availability, we've had over 750,000 downloads of Hyper-V gold bits.
2. Hyper-V is the fastest growing x86/x64 hypervisor in history. We are laser focused on our customers and providing high performance, high quality virtualization for everyone from small business to Fortune 500 customers.
3. We have hundreds of Hyper-V case studies from customers worldwide and we're winning new customers daily.
4. Hyper-V continues to power MSDN, TechNet and Microsoft.com as well as numerous other MS properties. Microsoft.com continues to receive over a BILLION hits per month and there has been no downtime to any of these internet properties running atop Hyper-V. Period.
5. Of those 750,000+ downloads, the number of support calls we have received on Hyper-V is less than .02%. (Yes, a minimal fraction of a percent.)

So, in terms of reliability, stability and support, not bad. (It's not like we released any patches resulting in days of downtime. HERE, HERE, HERE, HERE, HERE, & HERE)

Hmm. Still Want To Know More.

All said, I still wasn't satisfied. On the Hyper-V team, we run thousands of stress tests per week and the stress tests we run are far more invasive than the test in this video. So, I consulted our Hyper-V Supportability Program Manager and dug deeper. I wanted to know if we've had any Hyper-V crashes reported. Here's what I found out.

Of the 750,000 downloads, we've had 3 reports of crashes under stress and with the same error code as seen in the video bugcheck (0x00020001). The solution in all three cases was to upgrade the server BIOS which solved the problem. This can happen as hypervisors interact very closely with the hardware and BIOS updates generally include updated microcode for processors oftentimes to address errata.

In case you're wondering, VMware has had similar crashes with older BIOSes as well. Here.

Those are the facts. Now back to our regularly scheduled Hyper-V goodness.

TechEd Next Week!

Next week is TechEd in Los Angeles and a number of us from the virtualization team will be there in Los Angeles. We've got numerous sessions covering Hyper-V R2, Virtual Machine Manager and more. Hope to see you there!

Jeff Woolsey

Principal Group Program Manager

Windows Server, Hyper-V

P.S. It appears Keith Ward has seen through this veneer of FUD and blogged as well. HERE.

Virtualization Nation,

The Virtualization team is pleased to announce the availability of the Microsoft Hyper-V Server 2008 R2 Release Candidate for download. Hyper-V Server 2008 R2, our free standalone hypervisor, represents our continued commitment to providing high performance, hypervisor based virtualization for everyone, especially small and mid-market customers. This release underscores our customer focus by adding key new capabilities such as Live Migration and High Availability (and more.). The Microsoft Hyper-V Server 2008 Release Candidate is available here:

http://www.microsoft.com/hyper-v-server/en/us/default.aspx

Free Live Migration and High Availability? Really?

A couple weeks ago, Zane Adam first blogged the news that Hyper-V Server 2008 R2 would include Live Migration and High Availability at no charge. The response from our customers was "AWESOME!! When is the final release?" :-) Understandably, the phone's been ringing off the hook, my inbox has been on overdrive and some folks in the blogosphere have been trying to imply <cough, cough, FUD> that there are some strings attached. So, I wanted to take a moment to provide more details about the upcoming Hyper-V Server 2008 R2 release and free Live Migration & High Availability.

Hyper-V Server 2008 R2 Availability

When Hyper-V Server 2008 R2 goes gold and is released to manufacturing (RTM) the bits will be available as a free download here:

http://www.microsoft.com/hyper-v-server/en/us/default.aspx

Hyper-V Server 2008 R2 will be available worldwide in 11 languages.

Microsoft Hyper-V Server 2008 R2 includes Live Migration and High Availability. Period. No Strings Attached.

Live Migration is a great solution for planned downtime such as servicing the underlying hardware like adding more memory, storage or applying a BIOS update. Simply Live Migrate the virtual machines to another server (without downtime) shutdown the physical server and perform the maintenance. When the maintenance is complete, Live Migrate the virtual machines back and your done.

High Availability is a great solution for unplanned downtime. For example, suppose someone accidentally unplugs the wrong power cable on a server. The virtual machine on the server that just unexpectedly went down will automatically restart on another node without any user intervention.

Hyper-V Server 2008 R2 includes both these capabilities as well as our new Cluster Shared Volumes (CSV) capabilities to simplify storage management and run multiple virtual machines from a single LUN.

Managing Hyper-V Server 2008 R2

Hyper-V Server 2008 R2 Live Migration and High Availability can be managed in a few different ways:

1. Failover Cluster Manager/Hyper-V Manager from a Windows Server 2008 R2 Server OR,
2. System Center Virtual Machine Manager 2008 R2 OR,
3. Using the FREELY (there's that word again) available Failover Cluster Manager/Hyper-V Manager for Windows 7.

So, as you can see, there are a few different options depending on your needs and option three gives you Live Migration and High Availability at zero cost.

BTW: If you decide to go with option #2 System Center Virtual Machine Manager 2008 R2, you certainly can do a lot more such as:

• Heterogeneous Virtualization Management
• Rich PowerShell Support for Datacenter Automation
• Maintenance mode
• Virtual Machine Library Support
• Templates, Clones, Sysprep Integration
• Performance Resource Optimization (PRO)

.and a lot, lot more. But, I digress.

$$$ Comparison

Let's take a look at a few cluster configurations and compare costs for Live Migration and High Availability functionality.

You may be wondering, "Did he choose the most expensive VMware configuration?" On the contrary, I chose the least expensive configuration ($2245 per processor) that offers both Live Migration and High Availability.

You may be wondering, "Why isn't System Center management represented here?"

In this example, I simply wanted to compare the lowest cost for Live Migration and High Availability functionality from Microsoft and VMware with some real world configurations that a small/medium business may use. I will post a follow-up blog that adds management for small/medium businesses. As for enterprise customers, they typically have larger server farms with more sophisticated management requirements. That's another blog for another time.

You may also be wondering, "Why isn't the cost of guest operating systems included here?"

Simple, neither Microsoft Hyper-V Server 2008 R2 nor VMware include any guest operating system licenses so if you need to run 4 copies of Windows Server, you need to purchase the appropriate license. That cost is the same whether you're running Hyper-V Server 2008 R2 or VMware so I didn't bother to include it.

While VMware claims to be more affordable the facts are clear and the value of Microsoft Hyper-V Server 2008 R2 is undeniable. Microsoft offers exceptional value especially for small and mid-market customers who have told us for years how they would like Live Migration/High Availability functionality and simply can't afford it.

Those days are over.

At this point you may be thinking we're crazy to provide virtualization live migration and high availability at no cost. Well, I wish we could say we were first, but the folks at Xen have been providing free Live Migration and HA for a few months. In fact, the only one still charging for Live Migration and High Availability ($2245+ per socket) is VMware.

Now that's crazy.

Jeff Woolsey

Principal Group Program Manager

Windows Server, Hyper-V

Admittedly this post is a stew and not a meal (if that metaphor works). But you might be interested in the following items. I'll keep it short:

• John Kelbley will host a webcast on Friday, May 8 at 8:00am PDT titled, "Running Linux on Hyper-V." The session will discuss install, configure, run, backup and monitor non-Windows systems. See here.
• On May 14, 8am-noon PDT, Edwin Yuen will host a live chat on TechTarget. He'll answer questions about our virt products, be it datacenter, desktop or managemment. See more here.
• Wondering what to read when you're flying to TechEd, or your next trip? The Windows Server 2008 Hyper-V Resource Kit book is it. One of the authors, Robert Larson, architect in MS Services and TechNet blogger, told me that the book is in final formatting and some sample chapters are available to download (here). The book will be available via Amazon and Barnes and Noble in June. Read more from one of the authors here.
• Finally

Enjoy.

Patrick

Hi, I'm Edwin Yuen, a Senior Technical Product Manager at Microsoft's Integrated Virtualization team.  This past week, there were two key announcements made, one by Microsoft and one by VMware, that have an impact on how we compare Microsoft and VMware pricing. 

The first announcement was actually off this blog, made by Zane Adam, announcing that with the upcoming release of our free, standalone hypervisor, Microsoft Hyper-V Server 2008 R2, features like clustering, high availability (HA), and live migration would be included.  This was a very important announcement, as many customers are currently paying a significant amount of money for those features, and as we'll see below, will potentially continue to pay for them.  With Microsoft Hyper-V Server 2008 R2, you can now implement HA and live migration without having to buy a premium management SKU, which could save you thousands of dollars.

The second announcement was VMware's announcement of vSphere, the next version of VMware's hypervisor.  I spend a lot of time working and speaking with customers, both Microsoft and VMware users.  The one theme repeated in those conversations is that everyone understands VMware is not a low cost solution and many have been re-evaluating how much they spend to implement virtualization.  I think that everyone, including those of us at Microsoft, were wondering if VMware would drop their prices in the new version of vSphere.  When the announcement came out, it had a bullet point on reduced costs and new SKUs for customers.  When I sat down to actually figure out the pricing, it was pretty clear that the pricing really didn't change for many customers and the prices still don't compare to the offerings from Microsoft.

One of the key things I noticed is that for the SKU that most people bought, VI Enterprise or vSphere Enterprise, the price didn't actually change.  It went from $5,750 for a two processors host to $2,875 per processor, which is the same thing.  Thus, for many VMware customers, there is no cost savings in vSphere.  Another interesting issue about vSphere can be seen on the version comparisons page off VMware's website.  Many of the touted new features of vSphere, such as 8-way vSMP, >256GB of memory on the host, the vNetwork Switch, and Host Profiles, are only available if you buy new Enterprise Plus SKU, which is 18% more expensive than Enterprise and a cost increase for existing customers.  This means, for those customers who want these new vSphere features, there is a net increase in their cost.  Even when we compare just vSphere Enterprise SKU, the cost of vSphere Enterprise is five times that of buying the Microsoft solution with the Server Manage Suite Enterprise.

On the small and medium business side, VMware changed the name of their VI Foundation SKU to vSphere Essentials and added a new vSphere Essentials Plus SKU.  Essentials is just like VI Foundation, but without consolidated backup.  Essentials Plus is like Foundation, but with HA added.  Essentials is priced at $995 for three two processors hosts and Essentials Plus is priced at $2995 for three two processor hosts.  In contrast, a customer using Microsoft Hyper-V Server 2008 R2 with System Center Virtual Machine Manager 2008 (VMM) Workgroup Edition (WGE) will only have to pay $499 for five hosts.  Thus, the Essentials SKU is four times more expensive compared to the Microsoft Solution, which also includes HA, clustering, and live migration.  The Essentials Plus SKU is 12 times more expensive than the Microsoft solution, while still missing live migration.  In fact, for customers who need live migration, they must purchase the vSphere Advanced SKU, which starts at $4490 for a single, two processor host.  When we look at the chart below, we can easily how the costs add up on the VMware side. 

Finally, VMware has also argued on evaluating price per VM, based on a white paper and calculator they published recently.  We recently published a white paper that reviews why this model and the cost calculator associated with it are not applicable to most customers.  One of the key issues to the price per VM model, especially with how VMware has been promoting it, is that it doesn't take into account the applications being run. The number of VMs that can be run on a host depends on how the applications inside the VMs run. Don't believe VMware marketing about low consolidation ratios on Hyper-V. For example, this case study about Kroll Factual Data shows them running 30 VMs on a single Hyper-V host.

The consolidation ratio can vary depending on what you are running and how you run them. Because of this, you can't just plug consolidation ratios into a calculator and try to apply this across your entire deployment. The best way to compare Hypervisors is to compare Hypervisors, running your applications and VMs. When you do that, it will be easy to see why Microsoft is still less expensive then VMware. You can read about other companies that have made the switch to Microsoft here.

Still, in the end, the big question to ask yourself is the following: Is it worth all this expense for VMware, when the Microsoft solution offers a comparable or even better feature set for much less cost?  Is it worth the extra line item on the invoice, the extra line in the budget, to use VMware virtualization when it's built into Windows?  That is a question I think many customers will be asking themselves in the coming months and that is just another reason that you should start using Microsoft Virtualization solutions.