Dario IT Solutions Blog

Cluster Shared Volumes (CSV) is a new feature that was introduced in Windows 2008 R2.

If you want to read more about it, how it works, and how you can enable it. There is a lot of material out there that you can refer to:

• Windows 2008 R2 NLB & Failover Clustering
• http://technet.microsoft.com/en-us/library/dd759255.aspx
• http://technet.microsoft.com/en-us/library/dd630633(WS.10).aspx
• http://blogs.msdn.com/clustering/archive/2009/03/02/9453288.aspx
• http://blogs.msdn.com/clustering/archive/2009/02/19/9433146.aspx

Well, after you’ve setup your cluster, enabled CSV, and added clustered disks to CSV, it is now time to copy your VHD files to those CSV disk. The big question is, which cluster node should you perform this operation on?

We’ll, to make a long story short – Copy it to the node that owns the CSV disk!

The reason this is important is that if you are running the copy on the coordinator node (the node which owns the CSV volume of interest), the writes are all local writes. If you are running the copy on any other node, the writes are actually redirected over the network (because they are extending writes to the file) and not done directly to the volume.

Hope this will save you some much needed time

I had the opportunity today (16.9.08) to participate in Microsoft’s getVIRTUALnow event, and to present the session “Physical and Virtual Server Management”

I presented my take on data center management, which involves automating management tasks in response to system\application states.

It was impressive to see the number of vendors that were present in the event. Microsoft seem to be quick in building the required ecosystem of partners that will push it’s Virtualization offerings greatly in my opinion.

The main point in my presentation was that when looking at the data center (or IT environment) as a whole, tools like Systems Center Operations Manger and Systems Center Virtual Machine Manager (that has integration built into them from the grounds up) really stand out in the crowd in comparison to tools that are built for a specific environment (like managing only virtual machines).

One of the demonstrations involved Performance Resource Optimization (PRO) which is one of VMM’s top features, as it allows administrators to automate practically any type of response to a given condition, including responding to application, virtualization, system, storage, or network events.

For more demonstrations, take a look at Liran’s post – “Get Virtual Now with Hyper-V Technology“.

Also, You are more then invited to check out a bunch of pictures we took at the event – http://www.facebook.com/album.php?aid=55996&id=15415483905&ref=mf

Microsoft has published an interesting article about their official support for installing Exchange on Hyper-V\Virtual Server 2005 virtual machines.

To make a long story short, here are the support policies for both Exchange 2007 and Exchange 2003:

Support Policy and Recommendations for Exchange Server 2007

Microsoft supports Exchange Server 2007 in production on hardware virtualization software only when all the following conditions are true:

• The hardware virtualization software is Windows Server 2008 with Hyper-V technology, Microsoft Hyper-V Server, or any third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program.
• The Exchange Server guest virtual machine:
  • Is running Microsoft Exchange Server 2007 with Service Pack 1 (SP1) or later.
  • Is deployed on the Windows Server 2008 operating system.
  • Does not have the Unified Messaging server role installed. All Exchange 2007 server roles, except for the Unified Messaging role, are supported in a virtualization environment.
• The storage used by the Exchange Server guest machine can be virtual storage of a fixed size (for example, fixed virtual hard drives (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that is configured at the host level and dedicated to one guest machine.

  Note:

  In a Hyper-V environment, each fixed VHD must be less than 2,040 gigabytes (GB). For supported third-party hypervisors, check with the manufacturer to see if any disk size limitations exist.

  • Virtual disks that dynamically expand are not supported by Exchange.
  • Virtual disks that use differencing or delta mechanisms (such as Hyper-V’s differencing VHDs or snapshots) are not supported.
• No other server-based applications, other than management software (for example, antivirus software, backup software, virtual machine management software, etc.) can be deployed on the physical root machine. The root machine should be dedicated to running guest virtual machines.
• Microsoft does not support combining Exchange clustering solutions (namely, cluster continuous replication (CCR) and single copy clusters (SCC)) with hypervisor-based availability or migration solutions (for example, Hyper-V’s quick migration). Both CCR and SCC are supported in hardware virtualization environments provided that the virtualization environment does not employ clustered virtualization servers.
• Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it is running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots are not application-aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange Server. As a result, making virtual machine snapshots of an Exchange guest virtual machine is not supported.
• Many hardware virtualization products allow you to specify the number of virtual processors that should be allocated to each guest virtual machine. The virtual processors located in the guest virtual machine share a fixed number of logical processors in the physical system. Exchange supports a virtual processor-to-logical processor ratio no greater than 2:1. For example, a dual processor system using quad core processors contains a total of 8 logical processors in the host system. On a system with this configuration, do not allocate more than a total of 16 virtual processors to all guest virtual machines combined.

Support Policy and Recommendations for Exchange Server 2003

Microsoft supports Exchange Server 2003 in production on hardware virtualization software (virtual machines) only when all the following conditions are true:

• The hardware virtualization software is Microsoft Virtual Server 2005 R2 or any later version of Microsoft Virtual Server.
• The version of Exchange Server that is running on the virtual machine is Microsoft Exchange Server 2003 with Service Pack 2 (SP2) or later.
• The Microsoft Virtual Server 2005 R2 Virtual Machine Additions are installed on the guest operating system.
• Exchange Server 2003 is configured as a stand-alone server and not as part of a Windows failover cluster.
• The SCSI driver that is installed on the guest operating system is the Microsoft Virtual Machine PCI SCSI Controller driver.
• The virtual hard disk Undo feature is not enabled for the Exchange virtual machine.

  Note:

  When a Microsoft Virtual Server SCSI adaptor is added to a virtual machine after the Virtual Machine Additions have been installed, the guest operating system detects and installs a generic Adaptec SCSI driver. In this case, the Virtual Machine Additions must be removed and then reinstalled for the correct SCSI driver to be installed on the guest operating system.

Rest of the recommendations are at source.

One of the best new features in 2008 clusters is the ability to have cluster nodes on different subnets.

This is done by introducing a new OR dependency option for resources. In 2008 clusters, you have two options when making a resource depend on more than one resource:

• AND – Both the resource in this line and one or more previously listed resources must be online before the dependent resource is brought online.
• OR – Either the resource listed in this line or another previously listed resource must be online before the dependent resource is brought online.

So with the OR dependency, you can set up your cluster Network Name resources using an IP address from multiple subnets.

When you create your cluster or an application group, you are prompted to provide an IP address for each subnet. For example:

Here, you would enter a valid IP address for each subnet. Once this is complete, the cluster will automatically setup these dependencies properly for you and only one of the IP resources will be online at a time as the other IP address is not valid for the active node.

Some important notes:

1. Failover Cluster Quorum Type
   1. Node and File Share Majority is the best quorum type for geo-clusters
   2. Especialy if your file share will be located on a third site (that has no cluster members in it)
   3. Just remember, File Share Witness:
      1. Need to be on a File Server in the same forest
      2. No need to use shared storage – just a normal share
      3. Can’t be a node in the cluster
      4. Used as a decision making point for majority
      5. Can be used for multiple clusters (each cluster has a different share)
2. DNS Considerations
   1. Upon failover to the other node, DNS records will be updated to point to the new IP address. While this is occurring, clients may not be able to connect to the cluster workload even though it is online
   2. Use “RegisterAllProvidersIP” to control which dependent IP address are registered
   3. Use “HostRecordTTL” to control time-to-live on cluster network name resources (For ex. – 5 minutes is recommended for Exchange 2007)

Microsoft has some great Webcasts related to Windows 2008 Failover Clustering. 

You can view these recording on-demand and/or get the PPT files here:

Building High Availability Infrastructures with Windows Server 2008 Failover Clustering
Webcast – http://go.microsoft.com/?linkid=8131531
PPT – http://go.microsoft.com/?linkid=7933793

Failover Clustering 101
Webcast – http://go.microsoft.com/?linkid=8146346
PPT – http://go.microsoft.com/?linkid=7933794

Failover Cluster Validation and Troubleshooting with Windows Server 2008
Webcast – http://go.microsoft.com/?linkid=8173778
PPT – http://go.microsoft.com/?linkid=7933795

Geographically Dispersed Failover Clustering in Windows Server 2008 Enterprise
Webcast – http://go.microsoft.com/?linkid=8187007
PPT – http://go.microsoft.com/?linkid=7933796

Deep Dive on Failover Clustering in Windows Server 2008 Enterprise Storage and Understanding Quorum
Webcast – http://go.microsoft.com/?linkid=8213972
PPT – http://go.microsoft.com/?linkid=7933798

Hyper-V have an option to use CIFS/SMB file server share as your option for Failover Clustering storage.

This solution can enable you to use Quick Migration and but only be truly highly available if you file share is also highly available.

Important performance issue – Windows Server 2008 file server does increased performance for this type of workload. However, this is no way near FC\iSCSI configurations and should be used only after throughout utilization tests.

Before and After Diagrams

Lets describe the scenario using two diagrams. First, here is a diagram describing the scenario before a failure:

Now, here’s a diagram describing the scenario after a failure in SPTNODE1:

As you can see, we use a file server (called SPTSERVER1) for storing the Hyper-V files. The idea is to store the configuration files, the VHD itself and the VHD snapshots in the \\SPTSERVER1\VMSHARE\VM1 folder. As we do when using a SAN for shared storage, the surviving node will take over and start the VM in case of a failure. We can also use the very same scenario for Quick Migration, making the VM move orderly from one node to another by saving the state to the file share and instructing to other node to take over and restore the VM.

Pre-requisites

Before you move forward, you want to make sure you have at least two physical computers running Hyper-V. In our scenario, STPNODE1 and STPNODE2 are running Windows Server 2008 Enterprise (Full or Core installs work fine).

Add the Hyper-V role to STPNODE1 and STPNODE2.

Add the Failover Clustering feature to STPNODE1 and STPNODE2.

You will need to use a general purpose server to act as a file server or a NAS box compatible with CIFS/SMB. You probably want to run Windows Server 2008 for improved performance (new TCP/IP stack and SMBv2 protocol). In our scenario, STPSERVER1 is the file server running Windows Server 2008 Enterprise Edition  (Full or Core installs work fine).

Grant the required permissions for \\SPTSERVER1\VMSHARE\ to the computer accounts for STPNODE1 and STPNODE2, as described at http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx.

You might also want to have a management client which could be your desktop (running Windows Vista SP1) or another server (running a Full install of Windows Server 2008). In our scenario, SPTCLIENT1 is the management client.

Install the Windows Server Hyper-V RTM patch.

You will need to have a domain infrastructure (Windows Server Failover Clustering requires a domain). The domain controller is not shown in the diagrams.

Steps

You start the process by creating a cluster with the two Hyper-V nodes. To do this, you will use the Failover Cluster Management MMC from either node. In that tool, you will:

1. Validate the configuration
2. Create the cluster
3. Adjust the quorum configuration
4. Create the virtual machine in one of the nodes
5. Make the VM highly available

Running Validation

Here’s the initial screen of the Failover Cluster Management MMC, when first loaded.

Before you create the cluster, you must Validate your Configuration. Be sure to run *all* Validation tests, since solutions are only supported if you do so.

Since we are not using shared storage, the storage tests will generate a warning.  Completing validation with a warning is acceptable.

If you run into any errors during Validation, you must fix those before you proceed.

Creating the Cluster

After you run validation, click the option to “Create a Cluster”. First, you must specify the nodes. In this case we’re using SPTNODE1 and SPTNODE2.

Second, you specify the name of the cluster.

After confirming the data entered, the cluster is created, as shown below:

Note that we end up with a warning (yellow triangle). If you click the “View Report” button, you find what the issue is:

No appropriate disk could be found for the quorum disk.

This is expected. With only two nodes with no shared storage, you don’t have a valid quorum configuration and a single node failure will cause the cluster to fail.

You can see that in the cluster information below:

Typically, in a shared storage configuration, you would get that third vote from a shared witness disk (also know as a quorum disk).

We will overcome that in the next step.

Configuring the Cluster Quorum Settings

To get our third vote for the cluster without using shared storage, we will use the new option in Windows Server 2008 Failover Clustering to use a file server witness.

First, you need to add permission for the cluster computer account to the file share. The cluster computer account was created when we created the cluster.

As you did when granting permissions to SPTNODE1 and SPTNODE2, add full control permissions for the SPTDEMO\SPTCLUSTER$ account in the share and in the file system at SPTSERVER1.

Next, use the Failover Cluster Management tool to change the Quorum Configuration.

You will find this option by right-clicking the cluster name, then selecting “More Actions”, as shown below:

The wizard will guide you through the process. You will select the option for “Node and File Share Majority”, as shown below:

In the next screen, you will specify the actual shared folder path for the file share witness resource. We will use \\SPTSERVER1\VMSHARE\WITNESS. See below:

After you confirm the operation, you will see the update in the quorum configuration, now showing no warning signs.

I would recommend that you also check the status of the storage in the cluster.

You do this by clicking on the “Storage” node under the cluster name in the Failover Cluster Management tool. Here’s what you should see at this point:

As you can see, this is one of the cases where you have a healthy cluster with no shared storage. Exchange Server 2007 CCR clusters also do that.

Creating a regular Virtual Machine on a cluster node

At this point, if you check the Hyper-V Manager tool, you will see no virtual machines:

Now we will use the Hyper-V Manager to create a new VM in SPTNODE1 using only a file share for storage. If you’re doing this from SPTNODE1, you should have no issues. If you’re doing this from any other computer (like the management client SPTCLIENT1), be sure to check this post on how to configure Constrained Delegation to allow remote management of Hyper-V when using file shares: http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx

Again, this is done through a wizard. This is a regular VM creation, except for the fact that we’re using UNC paths (file share paths) for the storage, instead of regular folders on a local disk. In my specific case, we’re storing this new VM at \\SPTSERVER1\VMSHARE\VM1.

Here you see the virtual machine configuration folder:

Then the location of the new VHD file for the VM:

And even the ISO file we’re mounting will also come from that file server:

Once all is confirmed, we have a new VM, which you should keep in an “off” state for now:

Making the Virtual Machine Highly Available

Now we go back to the Failover Cluster Management tool to make the newly created VM highly available.

Click on the “Services and Applications” node under the cluster name and select the option to “Configure a Service or Application”. Again, it’s a wizard:

After selecting “Virtual Machine” as the type of service, you will select from a list of existing VMs. In our case, there’s only VM1:

After confirming your settings, the VM is made highly available, with a warning:

Again, if you click on the “View Report” button, you find the issues

The path ‘\\SPTSERVER1\VMSHARE\VM1′ where the virtual machine configuration is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine configuration on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1′ where the virtual machine snapshots are stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine snapshots on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1\VM1.vhd’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\ISO\WindowsServer2008-amd64.iso’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

As it usually does, the Failover Cluster Management tool is being very careful, pointing out that the file server share you are using is a potential single point of failure.

In order to have true high availability, you need to make sure that file share is also highly available. To achieve that, you need to place that file share in Failover Cluster as well.

The wizard has no way to detect if the file share is also clustered, so you will always get these warnings.

Now, you can go back and check the properties of the new highly available VM and bring it online.

One interesting thing you will notice is that you will not have any storage associated with that service, as you can see below:

In the summary page, you also confirm that, since you do not have the typical clustered disk listed in the summary for the virtual machine:

Moving the VM to another node

The last step is to prove that you can fail or move the VM to another node.

To do this, I use the option to “Move this service or application to another node”, which you can find when you right-click the virtual machine. See below:

When you do this, you will see that the VM will be taken offline in the source node (the state is saved first), as you can see below:

Then the VM will be brought online on the destination node (by restoring the state). Check below:

This process takes only a moment, and will depend only on how much memory you VM has and how long it takes to save the state to the file server share (from SPTNODE1) and then to restore the state from that same file share (from SPTNODE2).

You can see the final state, after the move to SPTNODE2 is completed, below:

More information can be found at source.

After a couple of complex deployments, I would like to share some of our findings and recommendations.

Quick Migrations & Clustering:

1. Make sure you install this hotfix if you plan on using Failover Clusters.
2. SCVMM does not support managing virtual machines if there is more than one virtual machine in a cluster group.
3. Physical disk resource for the pass-through disk should be moved to the failover cluster node that hosts the virtual machine before it is added to the configuration of that virtual machine.
4. Parent and child VHDs must be on disks that are in the same Services or Applications group as the virtual machine resource.
5. To enable independent migration and failover of virtual machines with Microsoft Hyper-V, one storage LUN must be dedicated to each virtual machine.

Storage:

1. If you need to expose the LUNs directly to a VM, your shared storage must be an iSCSI SAN (no Virtual HBA is supported in Hyper-V)
2. Disk GUIDs can overcome the drive letter shortage but are terrible to use.
3. Hyper-V IDE and SCSI storage devices both offer equally fast high I/O performance when integration services are installed in the guest operating system.
4. Virtual machine must use a virtual IDE device as the startup disk to start the guest operating system but you have many options to choose from when selecting the physical device that will provide the storage for the virtual IDE device.
5. To use the native disk support included in Failover Clustering, use basic disks, not dynamic disks.

Network:

1. Vendor NIC Teaming like the HP Network Configuration Utility is currently not working correctly with Hyper-V as a result of the different way the Hyper-V management partition communicates with the network drivers. I was told that Microsoft is well aware of this and is looking into it. It takes two to tango in this case which might complicate things working towards a quick fix.
2. Legacy network adapter is required if a virtual machine needs to boot from a network.
3. Hyper-V does not support wireless networks.
4. Network adapters must be dedicated to either network communication or iSCSI, not both. Moreover, You cannot use teamed network adapters, because they are not supported with iSCSI.

Some notes for more complex scenarios:

1. Check out Sanbolic Kayo FS. It can be used to enable shared access to a SAN volume from multiple physical host servers (or in other words – VMFS-like functionality for Microsoft Hyper-V)
2. For GeoClustering, check out Double-Take and their new offerings for Hyper-V.

In order to boot a Hyper-V child partition (guest) from an iSCSI LUN you need to expose that LUN to the parent partition (host), make sure the LUN is set as an offline disk in the host and then use the Passthrough option to expose the disk to the guest as IDE (ATA).

With that, you can successfully boot a Hyper-V guest from an iSCSI LUN. In fact, that works just the same for a fibre-channel LUN or SAS disks.

Here’s what the configuration of that virtual disk would look like:

There are also third-party solutions that will that will allow a Hyper-V guest to boot from an iSCSI LUN exposed directly to the guest. You can check a product from EmBoot that does exactly that at http://www.emboot.com.

How about a picture?

In the picture you see the different ways to expose a disk to a Hyper-V parent partition (host) and child partition (guest):

• C: = Using a VHD file on a directly attached disk (X:) on the host
• D: = Using passthrough to a directly attached disk on the host
• E: = Using a VHD file on a SAN LUN mounted as a volume (Y:) on the host
• F: = Using passthrough to a SAN LUN exposed to the host
• G: = Using an iSCSI LUN exposed directly to the guest

Note that, for the first four options, the disk can be exposed to the guest as either SCSI or IDE (ATA), regardless of the physical disk interface used on the host. Also note that the last option is only available for iSCSI SANs, not fibre-channel.

For all the details of what you can and cannot do in each scenario, check this post:
http://blogs.microsoft.co.il/blogs/dario/archive/2008/08/26/windows-server-2008-hyper-v-storage.aspx

Virtualization terminology

Before we start, I wanted to define some terms commonly used in virtualization. We refer to the physical computer running the Hyper-V software as the parent partition or host, as opposed to the child partition or guest, which is the term used for  virtual machine. You can, say, for instance, that the host must support hardware-assisted virtualization or that you can now run a 64-bit OS in the guest.

The other term used with Hyper-V is Integration Components. This is the additional software you run on the guest to better support Hyper-V. Windows Server 2008 already ships with Hyper-V Integration Components, but older operating systems will need to install them separately. In Virtual Server or Virtual PC, these were called “additions”.

Exposing storage to the host

A Hyper-V host is a server running Windows Server 2008 and it will support the many different storage options of that OS. This includes directly-attached storage (SATA, SAS) or SAN storage (FC, iSCSI). Once you expose the disks to the host, you can expose it to the guest in many different ways.

VHD or Passthrough disk on the host

As with Virtual Server and Virtual PC, you can create a VHD file in one of the host’s volume and expose that as a virtual hard disk to the guest. This VHD functions simply as a set of blocks, stored as a regular file using the host OS file system (typically NTFS). There are a few different types of VHD, like fixed size or dynamically expanding. This hasn’t changed from previous versions. The maximum size of a VHD continues to be 2040 GB (8 GB short of 2 TB).

You can now expose a host disk to the guest without even putting a volume on it using a Passthrough disk. Hyper-V will let you “bypass” the host’s file system and access a disk directly. This raw disk, which is not limited to 2040 GB in size, can be a physical HD on the host or a logical unit on a SAN. To make sure the host and the guest are not trying to use the disk at the same time, Hyper-V requires the disk to be in the offline state on the host. This is referred to as LUN Passthrough, if the disk being exposed to the guest is a LUN on a SAN from the host perspective. With Passthrough disks you will lose some nice, VHD-related features, like VHD snapshots, dynamically expanding VHDs and differencing VHDs.

IDE or SCSI on the guest

When you configure the guest’s virtual machine settings, you need to choose how to show the host disk (be it VHD file or Passthrough disk) to the guest. The guest can see that disk either as a virtual ATA device on a virtual IDE controller or as a virtual SCSI disk device on a virtual SCSI controller. Note that you do not have to expose the device to the guest in the same way it is exposed to the host. For instance, a VHD file on a physical IDE disk on the host can be exposed as a virtual SCSI disk on the guest. A physical SAS disk on the host can be exposed as a virtual IDE disk on the guest.

The main decision criteria here should be the capabilities you are looking for on the guest. You can only have up to 4 virtual IDE disks on the guest (2 controllers with 2 disks each), but they are the only types of disk that the virtualized BIOS will boot from. You can have up to 256 virtual SCSI disks on the guest (4 controllers with 64 disks each), but you cannot boot from them and you will need an OS with Integration Components. Virtual IDE disks will perform at the same level of the virtual SCSI disks after you load the Integration Components in the OS, since they leverage the same optimizations.

You must use SCSI if you need to expose more than 4 virtual disks to your guest. You must use IDE if your guest needs to boot to that virtual disk or if there are no Integration Components in the guest OS. You can also use both IDE and SCSI with the same guest.

iSCSI directly to guests

One additional option is to expose disks directly to the guest OS (without ever exposing it to the host) by using iSCSI. All you need to do is load an iSCSI initiator in the guest OS (Windows Server 2008 already includes one) and configure your target correctly. Hyper-V’s virtual BIOS support booting to iSCSI directly. For more details, check this post – http://blogs.microsoft.co.il/blogs/dario/archive/2008/08/26/booting-an-hyper-v-guest-from-an-iscsi-lun.aspx

Moving disks between hosts

Another common usage scenario in virtualization is moving a virtual machine from one host to another. You will typically shut down the guest (or pause it), move the storage resources and then bring the VM up in the new host (or resume it).

The “move the storage” part is easier to imagine if you are using VHD files for guest disks. You simply copy the files from host to host. If you’re using physical disks (let’s say, SAS drives that are Passthrough disks exposed as IDE disks to the guest), you can physically move the disk to another host. If this is a LUN on a SAN, you would need to reconfigure the SAN to mask the LUN to the old host and unmask it to the new host. You might want to use a technology called NPIV to use “virtual” WWNs for a set of LUNs, so you can move them between hosts without the need to reconfigure the SAN itself. This would be the equivalent of using multiple iSCSI targets for the same Hyper-V host and reconfiguring the targets to show up on the other host. If you use iSCSI directly exposed to the guest, those iSCSI data LUNs will just move with the guest, assuming the guest continues to have a network path to the iSCSI target and that you used one of the other methods to move the VM configuration and boot disk (if it’s not also on the iSCSI target).

Windows Server 2008 is also a lot smarter about using LUNs on a SAN, so you might consider exposing LUNs to multiple Hyper-V hosts and onlining the LUNs as required, as long as you don’t access them simultaneously from multiple hosts.

Keep in mind that, although I am talking about doing this manually, you will typically automate the process. Windows Server Failover Clustering and System Center Virtual Machine Manager (VMM) can make some of those things happens automatically. In some scenarios, the whole move can happen in just seconds (assuming you are pausing/resuming the VM and the disks are in a SAN).

A few tables

Since there are lots of different choices and options, I put together a few tables describing the scenarios. They will help you verify the many options you have and what features are available in each scenario.

Table 1

Table 2

Table 3

(a) Works as legacy IDE but will perform better if Integration Components are present.
(b) Works as legacy network but will perform better if Integration Components are present.
(c) Hyper-V maximum VHD size is 2040 GB (8 GB short of 2 TB).
(d) Not limited by Hyper-V. NTFS maximum volume size is 256 TB.
(e) Microsoft iSCSI Software Target maximum VHD size is 16 TB.
(f) Requires SAN reconfiguration or NPIV support, unless using a Failover Cluster.
(g) Can be used for data/boot/system disks.
(h) Requires SAN reconfiguration or NPIV support, unless using a Failover cluster.  All VHDs on the same LUN must be moved together.
(i) Requires third-party product like WinBoot/i from EmBoot.
(j) Not limited by Hyper-V.

References

http://blogs.msdn.com/tvoellm/archive/2008/01/02/hyper-v-scsi-vs-ide-do-you-really-need-an-ide-and-scsi-drive-for-best-performance.aspx
http://blogs.technet.com/jhoward/archive/2007/10/04/boot-from-scsi-in-virtual-server-vs-boot-from-ide-in-windows-server-virtualization.aspx

Screenshots

Screenshot of settings for scenario 2 in table 3 (VHD exposed as SCSI):

Screenshot of settings for scenario 8 in table 3 (iSCSI LUN Passthrough exposed as IDE, which your guest can boot from):

More information (partly outdated) can be found at source.

This hotfix contains fixes for issues that can occur, either after installation of Operations Manager 2007 SP1 or Essentials 2007 SP1 on Windows Server 2008, or after the operating system in-place upgrade from Windows Server 2003 to Windows Server 2008.

This hotfix should be applied to the following Operations Manager 2007 SP1 roles:

• RMS
  
• Management Server
  
• Gateway Server
  
• Web Console Server
  
• SCE Server
  
• Manually installed Agent (This hotfix should be applied directly to manually installed agents. Automatically deployed agents will appear in the Pending Management view to be approved for upgrade after installing this hotfix on the RMS/Management Server/Gateway server roles)

The three issue areas found and fixed are:

• An issue has been identified with upgrading an Operations Manager managed agent Operating System from Windows Server 2003 to Windows Server 2008 (any supported SKU) due to which the health service fails to start on the upgraded Operations Manager managed agent machine. The issue is due to the fact that the OS upgrade removed the certificate store in which the Operations Manager Health Service places its certificate for secure storage data encryption. When the secure storage manager component of the HealthService initializes, if there is a certificate serial number set but the store doesn’t exist, it fails. This hotfix resolves this issue.
  
• Several issues have been found due to User Access Control (UAC) changes within Windows Server 2008, where the Operations Manager Web Console fails to render pages correctly. Symptoms can include:
  
  
  
  • Web Console fails to launch
    
  • The My Workspace page fails to render
    
  • Performance views fail to render
  
  
• An issue has been identified when upgrading an Operations Manager Management Server role Operating System from Windows Server 2003 to Windows Server 2008 (any supported SKU), where the Operations Manager performance counters are not registered after upgrade. Installation of this hotfix, applied after OS upgrade, corrects this issue.

Download from here – Microsoft System Center Operations Manager 2007 SP1 & System Center Essentials 2007 SP1 Windows Server 2008 Support Hotfix.