Well, the week is over so I thought I would quickly share some links.

Vijay has posted a great article on how to install the SP1 beta on our standalone Hyper-V Server product.  So now you really have no excuse to not be looking at dynamic memory / RemoteFX (both of which are supported on Hyper-V Server).

Meanwhile – the Virtualization launch page on TechNet (http://technet.microsoft.com/en-us/bb802511.aspx) has been updated with a “Hyper-V Tools” section that gives you pointers to a number of home grown tools from Microsoft for working with Hyper-V:

Cheers,
Ben

If you are thinking about trying out dynamic memory in the Windows Server 2008 R2 SP1 beta release – here are some handy resources to read before you get going:

Dynamic Memory Technical Overview whitepaper

This paper talks about what dynamic memory is, what it does and how it does it.  It is a good read for those curious to understand what is happening under the covers.

http://download.microsoft.com/download/E/0/5/E05DF049-8220-4AEE-818B-786ADD9B434E/Implementing_and_Configuring_Dynamic_Memory.docx

Hyper-V Dynamic Memory Evaluation Guide

This article steps you through the process of setting up SP1 and enabling dynamic memory.  It also gives you some good tips on configuration and troubleshooting.

http://technet.microsoft.com/en-us/library/ff817651(WS.10).aspx

Windows Server 2008 R2 Service Pack 1 – TechNet Center

For all things “Windows Server 2008 R2 Service Pack 1” related – the TechNet Center has you covered.

http://technet.microsoft.com/en-us/library/ff817647(WS.10).aspx

Hyper-V: Dynamic Memory Survival Guide

The TechNet Wiki also has a “Dynamic Memory Survival Guide” article with some extra links.

http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-dynamic-memory-survival-guide.aspx

Cheers,
Ben

At TechEd this year we announced that dynamic memory would be supported for virtual machines that were running the following guest operating systems:

• Windows Server 2003 Web, Standard, Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2003 R2 Web, Standard, Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2008 Web, Standard, Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2008 R2 Web, Standard, Enterprise & Datacenter (64-bit)
• Windows Vista Enterprise & Ultimate (32-bit and 64-bit)
• Windows 7 Enterprise & Ultimate (32-bit and 64-bit)

But not all of these operating systems will support dynamic memory with the beta release.  Only the following operating systems are supported with the beta release:

• Windows Server 2003 Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2003 R2 Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2008 Enterprise & Datacenter (32-bit and 64-bit)
• Windows Server 2008 R2 Enterprise & Datacenter (64-bit)
• Windows Vista Enterprise & Ultimate (32-bit and 64-bit)
• Windows 7 Enterprise & Ultimate (32-bit and 64-bit)

The following guest operating systems will be supported after the beta release:

• Windows Server 2003 Web & Standard (32-bit and 64-bit)
• Windows Server 2003 R2 Web & Standard (32-bit and 64-bit)
• Windows Server 2008 Web & Standard (32-bit and 64-bit)
• Windows Server 2008 R2 Web & Standard (64-bit)

Cheers,
Ben

Starting today you can download the Windows Server 2008 R2 SP1 beta release.  For Hyper-V this specifically means that you can start evaluating the following new Hyper-V features:

• Dynamic Memory – the new feature that allows Hyper-V to dynamically change the amount of memory assigned to a virtual machine at run time, to get higher consolidation ratios.  I spoke about this at TechEd US 2010 – and you can watch the movie here.
• RemoteFX – provides support for rich graphics (Silverlight, 3D, etc…) when using Hyper-V to host desktop virtual machines.

You can register to download the beta here: http://www.microsoft.com/windowsserver2008/en/us/sp1.aspx

Note that while registration is required, there is no approval process and you will get immediate access to the bits.

Cheers,
Ben

Here is a good question:

If you are using iSCSI for all of your storage needs; should you use a software iSCSI initiator inside the virtual machine to connect the iSCSI storage directly to the virtual machine, or should you connect the iSCSI storage to the management operating system (in the parent partition) and then store virtual hard disks / use pass through disks?

The answer is (as usual) not that simple.  Generally speaking – you should always connect the iSCSI storage to the management operating system.  The reason for this is that virtual machines can only connect to iSCSI devices with a software iSCSI initiator, where as the management operating system will be able to use hardware host-bus adapters (HBAs).

That said, there is a time when you will want to use a software iSCSI initiator inside the virtual machine and connect the storage directly to the virtual machine.  You will want to do this if you are trying to cluster the guest operating system inside the virtual machine (as opposed to clustering Hyper-V itself).  In this scenario; having iSCSI storage connected directly to the guest operating system is the only option that works.

Some common questions that I have heard around these recommendations include:

• What if I am just using a software iSCSI initiator inside the management operating system?  Does it really make any difference then?
  
  Yes, it still matters.  At very least a software iSCSI initiator in the management operating system will be able to take full advantage of all of the network offload / acceleration technologies supported by your physical network adapter.  If you run the software iSCSI initiator in the guest operating system, you will only be able to access the subset of network offload functionality that is exposed on our virtual network adapters.
  
  Furthermore, in the management operating system it is easier to utilize dedicated storage network adapters and network teaming in order to increase your performance.
  
  
• If I connect the iSCSI storage to the management operating system, should I then pass-through the physical disks to the virtual machines – or should I use virtual hard disks (VHDs) stored on the iSCSI device?
  
  I have discussed this issue in the past – and I strongly believe that everyone should default to using fixed size virtual hard disks over using physical disks directly connected to virtual machines.  The only exception that I would make with iSCSI storage is if you have some external process (e.g. backup software) that will be manipulating the iSCSI storage directly and is not aware of virtual hard disks.
  
  
• How bad is it to use iSCSI connected a software iSCSI initiator inside the virtual machine?
  
  Not that bad really.  Chances are that if you are running on gigabit networking you will not really notice much of a performance difference between a software iSCSI initiator in the virtual machine and one in the management operating system.  That said, a software iSCSI initiator in the virtual machine will use a lot more CPU power to achieve the same results as a hardware (or software) iSCSI initiator in the management operating system.  This will eventually cause performance problems if / when your physical computer comes under high load.

Cheers,
Ben

When we released Windows Server 2008 R2 we stated that we would support up to 384 virtual machines running on a single instance of Hyper-V – but only up to 64 virtual machines running on a node of a cluster.

Last week we announced that we now support up to 384 virtual machines running on a node of a cluster – as long as the total number of running virtual machines in the cluster does not exceed 1000.

You can read more about this on the “Requirements and Limits” page on TechNet: http://technet.microsoft.com/en-us/library/ee405267(WS.10).aspx

Cheers,
Ben

A while ago I made an open offer to people to contact me if they had experienced issues using Hyper-V backup.  A number of you contacted me with reports of large registry files in the parent partition – that would slow down system boot over time.

Well, after a lot of investigation we have figured out the cause and a hotfix is now available.  You can download it from here:

http://support.microsoft.com/kb/982210

I recommend that if you are using backup regularly on Hyper-V that you install this hotfix.

Note – that despite the title of the KB article, this fix applies to Windows Server 2008 R2 (not Windows Server 2008).

So what was the cause of the problem?

A short description is as follows:

Whenever we backup a virtual machine using VSS, we momentarily connect the backup copy of the virtual machines virtual hard disks to the parent partition in order to clean them up after backup.  Unfortunately with Windows Server 2008 R2 a new plug-and-play entry would get created in the Windows registry each time that we did this.  Over time this would cause the registry to get larger and larger, which would in turn slow down the Windows boot process.

Cheers,
Ben

Our documentation team has done a great job of putting together a detailed Windows Server 2008 R2: Hyper-V Component Architecture Poster.  They were nice enough to give us on the development team some physical copies – but you can download the .PDF to create your own:

The poster provides details on the inner workings of things like:

• Virtual Networking
• Virtual Storage
• Live Migration
• Virtual Machine Snapshots
• Virtual Machine File Management

Cheers,
Ben

I have a blogged about this before - but we maintain a list of all updates / hotfixes that have been released for Hyper-V on Windows Server 2008 R2.  We update this list regularly - and have just rolled out the latest updates.  You can review the list here:

http://technet.microsoft.com/en-us/library/ff394763(WS.10).aspx

You should make sure to check this article regularly as we are always updating it.

We also have a similar list that we provide for Hyper-V on Windows Server 2008:

http://technet.microsoft.com/en-us/library/dd430893(WS.10).aspx

Cheers,
Ben 

While not strictly virtualization related – I did stumble upon something interesting while working on my international WMI blog post yesterday.  In that post I showed some examples of using PowerShell on a German system.  I had originally intended to use Chinese for this post – but I encountered a problematic limitation with PowerShell on Chinese systems.  When I ran this command:

gwmi MSVM_ComputerSystem -namespace root\virtualization

At the PowerShell command line on a Chinese system – all the properties were returned in English instead:

But when I ran the same command in the PowerShell Integrated Scripting Environment (ISE):

I was able to get correctly localized properties.  After a brief mail exchange with the PowerShell team I discovered that this was all working “as expected”.  Because they cannot display the Chinese characters on the text mode command line interface – they fall back to English.

The problem here is – as I demonstrated in my post yesterday – this means that you could write a script that would run correctly in the command line interface on a Chinese system, but would fail in the Integrated Scripting Environment.

Just wanted to pass this along – if you are ever scripting on a Chinese system – so you are not caught off guard by this change in behavior.

Cheers,
Ben