Deployment Cookbook: Quick Migration with Virtual Server Host ...

Document Version 2.02 | Last Edited: 09/11/07 | Edited By: TMS

Deployment Cookbook: Quick Migration with Virtual Server Host Clustering

Windows Server® 2003 Enterprise Edition & Microsoft® Virtual Server 2005 R2 Service Pack 1

Deployment Cookbook: Quick Migration with Virtual Server Host Clustering 1

Table of Contents

Introduction .......................................................................................... 2

Before You Begin................................................................................... 6

Section 1: Set Up and Configure the Windows Server Cluster ........... 16

Section 2: Create the Virtual Server Host Cluster............................... 59

Appendix A: Install IIS via Control Panel ............................................. 83

Appendix B: Virtual Server Security Considerations........................... 88

Appendix C: Script for Virtual Server Host Clustering ........................ 89

Related Links ....................................................................................... 95

Version 1.0

2 Deployment Cookbook: Quick Migration with Virtual Server Host Clustering

Introduction Most mid‐sized and larger businesses may want to enable high availability within their virtual infrastructures. This is possible with Microsoft® Virtual Server host clustering, which can provide a wide variety of services through a small number of physical servers and, at the same time, maintain availability of the services provided.

Virtual Server host clustering is a way of combining Microsoft® Virtual Server 2005 R2 with the server cluster feature in Windows Server® 2003. This cookbook describes a simple configuration in which you use Virtual Server 2005 R2 to configure one guest operating system, and configure a server cluster that has two servers (nodes). With this configuration, you can migrate workloads easily from one node to the other. This can be used in cases when you need to schedule downtime for one of the nodes in your cluster.

You can create this configuration and, by carefully following the pattern of the configuration, develop a host cluster with additional guests or additional nodes.

Intended Audience

This deployment cookbook is written for the IT generalist at a mid‐market corporation. The goal of this cookbook is to provide you with all of the steps and guidance you need to successfully install and configure Virtual Server host clustering and migrate workloads from one node to another.

Using This Cookbook

To cover the bases, this cookbook probably contains more information than you need. In addition to the table of contents at the beginning of this cookbook, each section also includes its own table of contents so that you can easily find the steps that you need most. If you already have a component installed or a step completed, move on to the next step or section.

What Is Virtual Server?

In conjunction with Windows Server 2003, Virtual Server 2005 R2 Service Pack 1 (SP1) provides a virtualization platform that runs most major x86 operating systems in a guest environment, and is supported by Microsoft as a host for Windows Server operating systems and Windows Server System™ applications. The comprehensive COM API in Virtual Server 2005 R2, in combination with the Virtual Hard Drive (VHD) format and support for virtual networking, provides administrators with complete control of portable, connected virtual machines and enables easy automation of deployment and ongoing change and configuration.

Additionally, its integration with a wide variety of existing Microsoft and third‐party management tools allows administrators to seamlessly manage a Virtual Server 2005 R2 SP1 environment with their existing physical server management tools. A wide array of


complementary product and service offerings are available from Microsoft and its partners to help businesses plan for, deploy, and manage Virtual Server 2005 R2 SP1 in their environments.

What Is Virtual Server Host Clustering?

Virtual Server host clustering is a way of combining two technologies: Virtual Server 2005 R2 and the server cluster feature in Windows Server 2003, so that you can consolidate servers onto one physical host server without causing that host server to become a single point of failure. To give an example, suppose you had two physical servers providing client services as follows:

• Windows Server 2003 Standard Edition, used as a Web server

• Microsoft® Windows NT® Server 4.0 with Service Pack 6a (SP6a), with a specialized application used in your organization

By using a configuration like the scenario in this cookbook, you could consolidate these physical servers onto one physical server and, at the same time, maintain the availability and flexibility of services if that consolidated server required scheduled maintenance. To do this, you would run each server listed above as a guest (also known as a virtual machine) on a physical server. You would also configure this server as one node in a server cluster, meaning that a second server would be ready to support the guests. If the need arose to shut down the first server (such as scheduled maintenance), the workloads running on the first server can easily be migrated to the second server. You could perform any necessary work on the first server and then, as needed, have it once again resume support of the services.

What Is a Cluster?

There are several types of clusters. This paper deals with virtual machines running on failover clusters. Failover clustering keeps server‐based applications highly available, regardless of individual server failures. The primary function of failover clustering occurs when one server in a cluster fails or is taken offline, and the other servers in the cluster take over the offline server's operations. Clients using server resources experience little or no interruption of their work because the resource functions move from one server in the cluster to the other. In this cookbook, you will learn how to configure Virtual Server to run with failover clustering.

This paper does not deal with network load balancing clusters or high‐performance clusters. Network load balancing distributes IP traffic across multiple cluster hosts to scale network performance, and high‐performance clusters allow users to run parallel, high‐performance computing (HPC) applications for solving complex computations.

What Is a Cluster Resource?

A resource is the single unit that can be administered or managed on the cluster. Cluster resources include physical hardware devices such as disk drives and network cards, and


logical items such as Internet Protocol (IP) addresses, applications, and application databases. Each node in the cluster will have its own local resources, like a stand‐alone server. However, the cluster also has common resources, such as a common data storage array and private cluster network. These common resources are accessible by each node in the cluster. A resource can be either online or offline. A resource is online when it is available and providing its service to the cluster.

Resources are physical or logical entities that have the following characteristics:

• Can be brought online and taken offline.

• Can be managed in a server cluster.

• Can be owned by only one node at a time.

A resource group is a collection of resources managed by the cluster service as a single logical unit. Application resources and cluster entities can be easily managed by grouping logically related resources into a resource group. When a cluster service operation is performed on a resource group, the operation affects all individual resources contained within the group. Typically, a resource group is created to contain all the elements needed by a specific application server and client for successful use of the application.

Understanding Common Terms in Virtual Server Host Clustering

The following terms are important for understanding Virtual Server host clustering.

host

A physical server on which a version of Virtual Server 2005 is running.

guest

An operating system running as a virtual machine in Virtual Server 2005. Multiple guests can run on one host, and each guest can run one or more applications.

node

A computer system that is an active or inactive member of a cluster. In this cookbook, a node is also a Virtual Server 2005 host.

failover

The process of taking a group of clustered resources (such as a disk on which data is stored, plus an associated script) offline on one node and bringing them online on another node. The cluster service ensures that this is done in a predefined, orderly fashion, so that users experience minimal disruptions in service.

cluster storage

Storage that is attached to all nodes of the cluster. Each disk on the cluster storage is owned by only one node of the cluster at a time. The ownership of disks moves from one node to another during failover or when the administrator moves a group of resources to another node.


logical unit numbers (LUNs)

A unique identifier used on a SCSI bus to differentiate up to eight separate devices.

quorum disk/drive

In every cluster, a single resource is designated as the quorum resource. This resource maintains the configuration data necessary for recovery of the cluster. This data, in the form of recovery logs, contains details of all of the changes that have been applied to the cluster database. This provides node‐independent storage for cluster configuration and state data.

heartbeat

Nodes in a cluster communicate using their cluster service. The cluster service keeps track of the current state of the nodes within a cluster and determines when a group and its resources should fail over to an alternate node. This communication takes the form of messages that are sent regularly between the two nodes' cluster services. These messages are called heartbeats.

cluster service

Service that facilitates clustering of nodes. Included with Windows Server 2003.


Before You Begin This section will cover prerequisites for your environment, as well as other specifics that will help you get the most out of this cookbook.

Scenario Overview

This host clustering quick migration scenario for Virtual Server uses two host machines, with a Virtual Server‐based virtual machine (guest) on one of the host machines. Only one of the two nodes is hosting a virtual machine at any given time. The other node will be standing by and would take over hosting the virtual machines were the first node to fail. In this scenario, we will be migrating a workload from the first node to the second node.

Note: The entire cluster should be in the same geographic location.

The following diagram shows the cluster setup. The public network will be used to connect these nodes, as well as the virtual machine, to other network resources, such as domain controllers, printers, and routers. The private network is used exclusively for cluster‐related network traffic and allows the cluster nodes to verify the state of other cluster nodes. The network used to connect shared storage to the cluster will depend on what type of shared storage you use.

Figure 1: Network topology used in this cookbook

The following naming conventions will be used throughout this cookbook:


• Cluster name: MyCluster

• Domain: contoso.com

• Host machine 1 (Virtual Server host): Node 1

• Host machine 2 (Virtual Server host): Node 2

• Guest (virtual) machine: Guest1

• Quorum disk: Disk Q

• Label for volume on shared storage: Disk X

• Folder on disk where configuration files for the guest are placed: X:\Guest1

• Cluster resource group: Guest1Group

• Clustered Physical Disk Resource: DiskResourceX

• Clustered Generic Script resource: Guest1Script (uses Havm.vbs)

• Public network: Public or mixed network

• Private network: Private network

This cookbook describes a simple host clustering configuration. You can create this configuration and then, by carefully following the pattern of the configuration, develop a host cluster with additional guests or additional nodes.

The scenario described in this cookbook has the following basic characteristics (more details can be found in the Prerequisites section):

• This cluster is a two‐node cluster. This is fewer than the maximum number of nodes possible (eight).

• This cluster uses cluster storage (shared storage) connected to the nodes by SCSI, Fibre Channel, or iSCSI. Any of these will work with the instructions provided in this cookbook. Consult your hardware vendor or manufacturer’s instructions for details relating to your storage.

• You will use two shared storage disks. Disk Q will be the quorum disk which stores information to rebuild the cluster in the event of a failure. Disk X will be the shared storage for the cluster.

• It has one guest operating system, configured as a resource group in the cluster. The list of supported guest operating systems can be found in the Prerequisites section.

In a production environment, it is likely you would want more than one guest operating system. However, a scenario with one guest provides the foundation for understanding a scenario with additional guests.

• This scenario uses copies of the provided script. When you configure the script as a Generic Script resource in the cluster, it ensures that the guest functions correctly when a failover or other cluster‐related process occurs. The script also


triggers restart of the guest if the guest stops running. You can find this script in Appendix C.

Overview of Cluster Setup Procedure

The procedure for setting up your cluster is broken into two sections. In Section 1, you will create a server cluster with two physical machines. In Section 2, you will create a Virtual Server host cluster by installing Virtual Server on one of the physical machines.

Licensing Considerations

The license for Windows Server 2003 Enterprise Edition, Enterprise x64 Edition, or later versions on the server hosting your virtual machines, enables you to run up to four instances of Windows Server 2003 Standard Edition, Enterprise Edition, or later versions as the operating systems for those virtual machines, at no extra cost.

The license for Windows Server 2003 Datacenter Edition, Datacenter x64 Edition, or later versions on the server hosting your virtual machines, enables you to run an unlimited number of instances of Windows Server 2003 Standard Edition, Enterprise Edition, Datacenter Edition, or later versions as the operating systems for those virtual machines, at no extra cost.

For each host machine that is a member of your cluster, you will need a Windows license.


AMD Virtualization Technology Support

All AMD64 processors are built on Direct Connect Architecture. Direct Connect architecture eliminates traditional bottlenecks inherent in connecting CPUs, memory and I/O for reduced latency and optimized memory performance.

Direct Connect Architecture enhances performance of memory bound applications – virtualized or not. Direct Connect Architecture provides inherent benefits to virtualization workloads since the reduced latency and performance improvements increase the number of virtual machines that can run on a server.

Supplementing the inherent benefits provided by Direct Connect Architecture, AMD64 processors starting from Opteron Family F, Rev F processors incorporate extensions to significantly enhance performance of virtual machines. These extensions are collectively known as AMD Virtualization (AMD‐V).

AMD‐V is built on the Direct Connect Architecture foundation and significantly reduces overheads associated with traditional software‐based virtualization solutions. Use of AMD‐V allows many instances of off‐the‐shelf operating systems to run concurrently on a single instance of Virtual Server 2005.

Starting with the Opteron Family 10h processors, besides many new virtualization performance improvements, AMD64 processors also incorporate an extension to allow virtual machines to manipulate their page tables without Hypervisor intervention. This extension is called Nested Page Tables (NPT) and significantly reduces overheads associated with Shadow Paging algorithms found in today’s software‐based virtualization solutions.

Additional benefits that are derived from AMD‐V are enhanced security and reduced complexity. By diminishing the reliance on the virtualization software platform, AMD‐V also reduces the attack surface and eliminates points of failure.

Advanced memory handling capabilities offered by AMD Virtualization allows increased isolation of virtual machines and can exclude device access, both of which increase the overall security of virtualization.

AMD‐V and AMD Direct Connect Architecture enhance virtualization by providing efficient isolation of virtual machine memory. Virtualization software uses these hardware capabilities ensuring errors that interfere with operations running in one virtual machine have no effect on other virtual machines on the same computer.

Service Pack 1 (SP1) for Microsoft Virtual Server 2005 R2 is built to take advantage of AMD‐V hardware‐assisted virtualization and delivers marked improvement in system performance of guest virtual machines.


Prerequisites

The following system requirements include software, hardware, network, and storage requirements.

Software Requirements and Guidelines

• You must have Windows Server 2003 Enterprise Edition, Datacenter Edition, or later installed on all computers in the cluster. Microsoft strongly recommends that you also install the latest service pack for Windows Server 2003. If you install a service pack, the same service pack must be installed on all computers in the cluster. Either the x86 or x64 version of these operating systems can be used.

• You will need licensed copies of the operating system and other software that you will run on the guests. The following operating systems are supported for the guest machine:

o Windows Server 2003 Standard Edition (Windows Server 2003 SP1 support for Virtual Server 2005 R2 only)

o Windows Server 2003 Enterprise Edition or later

o Windows Server 2003 Web Edition or later

o Windows® Small Business Server 2003 Standard Edition or later

o Windows® Small Business Server 2003 Premium Edition or later

o Windows® 2000 Server

o Windows® 2000 Advanced Server

o Windows NT Server 4.0 with SP6a

• Your system must be using a name‐resolution service, such as Domain Name System (DNS), DNS dynamic update protocol, Windows Internet Name Service (WINS), or Hosts file. Hosts file is supported as a local, static file method of mapping DNS domain names for host computers to their Internet Protocol (IP) addresses. The Hosts file is provided in the systemroot\System32\Drivers\Etc folder. In most cases, DNS should be sufficient.

• All nodes in the cluster must be in the same Active Directory® directory service domain. As a best practice, all nodes should have the same domain role (either member server or domain controller), and the recommended role and the role we will use in this cookbook is member server. Exceptions that can be made to these domain role guidelines are described later in this cookbook.

• When you first create a cluster or add nodes to it, you must be logged on to the domain with an account that has administrator rights and permissions on all nodes in that cluster. The account does not need to be a Domain Admin level


account, but can be a Domain User account with Local Admin rights on each node.

Hardware Requirements and Guidelines

• All nodes in the cluster must have identical hardware and be of the same architecture. You cannot mix x86‐based, Itanium‐based, and x64‐based computers within the same cluster. Also, each hardware component must be the same make, model, and firmware version. This makes configuration easier and eliminates compatibility problems.

• If you are installing a server cluster on a storage area network (SAN), and you plan to have multiple devices and clusters sharing the SAN with a cluster, your hardware components must be compatible.

• You must have two mass‐storage device controllers in each node in the cluster: one for the local disk, one for the cluster storage. You can choose between SCSI, iSCSI, or Fibre Channel for cluster storage on server clusters that are running Windows Server 2003 Enterprise Edition or Datacenter Edition. You must have two controllers because one controller has the local system disk for the operating system installed, and the other controller has the shared storage installed.

• You must have storage cables to attach the cluster storage device to all computers. Refer to the manufacturer's instructions for configuring storage devices.

• The following table includes specifications that each host machine should meet:

Table 1: Host Machine Prerequisites

Hardware Requirement

Minimum CPU speed 550 MHz

Recommended CPU speed

1.0 GHz or higher

Processor information

AMD Opteron, Athlon, Athlon 64, Athlon X2, Sempron, Duron

Minimum RAM 256 MB (additional memory needed for each guest operating system)

Required available hard‐disk space

2 GB on each node. Additional disk space needed on shared storage for each guest operating system.

Recommended monitor

• Super VGA (800×600) or higher resolution monitor recommended; VGA or hardware that supports console redirection required

• Keyboard and mouse or compatible pointing device, or hardware that supports console redirection required

Additional processor support

Intel Celeron, Pentium III, Pentium 4, Xeon


Network Requirements and Guidelines

Each cluster node requires at least two network adapters and must be connected by two or more independent networks. At least two LAN networks (or virtual LANs [VLANs]) are required to prevent a single point of failure. A server cluster whose nodes are connected by only one network is not a supported configuration—the adapters, cables, hubs, and switches for each network must be able to be stopped independently. This usually means that the components of any two networks must be physically independent.

Two networks must be configured to handle either All communications (mixed network) or Internal cluster communications only (private network). The recommended configuration for two adapters is to use one adapter for the private (node‐to‐node only) communication and the other adapter for mixed communication (node‐to‐node plus client‐to‐cluster communication), as we will do here.

You should keep all private networks separate from other networks. Specifically, do not use a router, switch, or bridge to join a private cluster network to any other network. Do not include other network infrastructure or application servers on the private network subnet. To separate a private network from other networks, use a cross‐over cable in a two‐node cluster configuration, or a dedicated hub or switch in a cluster configuration of more than two nodes.

Note if you are using iSCSI storage, you will need a dedicated NIC to communicate with your iSCSI storage target. See your storage company documentation for details.

Your cluster network infrastructure should have the following characteristics:

• A unique name for each node on your network.

• A static IP address for the cluster. Resources on the public network will use this IP address to communicate with the cluster. We will use 192.168.10.50 on the public interfaces as the cluster IP address in the example network provided in this paper.

• One static IP address for each network adapter on each node. Set the addresses for each linked pair of network adapters (linked node‐to‐node) to be on the same subnet. You will use the following IP addresses:

o Node 1 private network IP address: 10.0.0.11

o Node 2 private network IP address: 10.0.0.12

o Node 1 public network IP address: 192.168.10.11

o Node 2 public network IP address: 192.168.10.12


Note: Server clusters do not support the use of IP addresses assigned from Dynamic Host Configuration Protocol (DHCP) servers.

• The nodes in the cluster must be able to access an Active Directory domain controller. The cluster service requires that the nodes be able to contact the domain controller to function correctly. The domain controller should be in the same location and on the same local area network (LAN) as the nodes in the cluster. To avoid a single point of failure, the domain must have at least two domain controllers. However, for this scenario, these domain controllers should not be part of the cluster, due to additional complexity associated with clustering domain controllers.

• Each node must have at least two network adapters. One adapter will be used exclusively for internal node‐to‐node communication (the private network). The other adapter will connect the node to the client public network. It should also connect the cluster nodes to provide support in case the private network fails. (A network that carries both public and private communication is called a mixed network.) The network adapters connected together into one network must be identical to one another.

• Teaming network adapters on all cluster networks concurrently is not supported because of delays that can occur when heartbeat packets are transmitted and received between cluster nodes. For best results, when you want redundancy for the private interconnect, you should disable teaming and use the available ports to form a second private interconnect. This achieves the same end result and provides the nodes with dual, robust communication paths. The mixed network can use teamed network adapters, but the private network cannot. If you are using fault‐tolerant network cards or teaming network adapters, you should ensure that you are using the most recent firmware and drivers. Check with your network adapter manufacturer to verify compatibility with the cluster technology in Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition.

Storage Requirements and Guidelines

• An external disk storage unit must be connected to all nodes in the cluster. This will be used as the cluster storage. You should also use some type of hardware redundant array of independent disks (RAID).

• All cluster storage disks, including the quorum disk, must be physically attached to a shared bus. If you are using SCSI or Fibre Channel, each node must have a mass‐storage device controller dedicated to the cluster storage (in addition to the device controller for the local disk).

• If you are using iSCSI, each node must have a network adapter dedicated to the cluster storage. That network adapter, must be dedicated to iSCSI. The network


adapters used for iSCSI on each node should be identical, and we recommend that the adapters be Gigabit Ethernet.

• A disk that contains the active boot or system partitions cannot be used as a cluster resource disk. System partition refers to the disk volume that contains the hardware‐specific files needed to start Windows. The boot partition refers to the disk volume that contains the Windows operating system files (by default, in the WINDOWS folder) and its support files. The boot partition can, but is not required to, be the same partition as the system partition.

• The external shared storage must appear as two logical drives visible to both nodes in the cluster. In this scenario, you will have two logical drives: disk Q will be the quorum disk and disk X will be the shared storage disk.

• On your shared storage, you will need a dedicated resource to be used by the cluster as the quorum resource. The recommended minimum size for the volume is 50 MB. You should not store user data on any volume on the quorum LUN.

• If you are using SCSI, ensure that each device on the shared bus (both SCSI controllers and hard disks) has a unique SCSI identifier. If the SCSI controllers all have the same default identifier (the default is typically SCSI ID 7), change one controller to a different SCSI ID, such as SCSI ID 6. If more than one disk will be on the shared SCSI bus, each disk must also have a unique SCSI identifier.

• Software fault tolerance is not natively supported for disks in the cluster storage. For cluster disks, you must use the NTFS file system and configure the disks as basic disks with all partitions formatted as NTFS. They can be either compressed or uncompressed. Cluster disks cannot be configured as dynamic disks. In addition, features of dynamic disks, such as spanned volumes (volume sets), cannot be used without additional non‐Microsoft software.

• All disks on the cluster storage device must be partitioned as master boot record (MBR) disks, not as GUID partition table (GPT) disks.

• For this scenario, the storage should contain at least two separate volumes, that is, two separate logical unit numbers (LUNs). One volume will function as the quorum (disk containing configuration information needed for the cluster), and one will contain the virtual disk for the guest.

Additional Considerations

• All cluster nodes must be on the same logical subnet.

• If you are using a virtual LAN (VLAN), the one‐way communication latency between any pair of cluster nodes on the VLAN must be less than 500 milliseconds.


• In Windows Server 2003 operating systems, cluster nodes exchange multicast heartbeats rather than unicast heartbeats. A heartbeat is a message that is sent regularly between cluster network drivers on each node. Heartbeat messages are used to detect communication failure between cluster nodes. Using multicast technology enables better node communication because it allows several unicast messages to be replaced with a single multicast message. Clusters that consist of fewer than three nodes will send unicast rather than multicast heartbeats.

• Determine an appropriate name for each network connection, by renaming the network interfaces in the Network Connections window. For example, you might want to name the private network Private and the public network Public. This will help you uniquely identify a network and correctly assign its role.

• You will need the script, Havm.vbs. You will copy this script to each node of the cluster. It can be found in Appendix C.

Required Network Information, Accounts, and Administrative Credentials

In order to set up a cluster, you will need the following network information and accounts:

• An account that you will log on to when you are configuring and managing the cluster. This account must be a member of the local Administrators group on all nodes.

• If you use iSCSI with network adapters in the nodes, you will also need a static IP address for each of these adapters.

• A domain account for the cluster service. Do not use this account for other purposes. The New Server Cluster Wizard gives this account the necessary permissions when you set up the cluster.

• A name for the cluster, that is, the name administrators will use for connections to the cluster. (The actual applications running on the cluster can have different network names.) In this cookbook, the cluster is named Mycluster.


Section 1: Set Up and Configure the Windows Server Cluster

This section will walk you through the steps of setting up a two‐node Windows server cluster with your physical host machines.

Install Windows ................................................................................................................ 17 Windows will need to be installed on both physical host machines before proceeding.

Set the order of the network adapter binding ................................................................. 17 In this step, connections are listed in the order in which they are accessed by network services.

Configure the private network adapters.......................................................................... 18 You will start by setting up the private network for cluster‐specific network traffic.

Configure the public network adapters ........................................................................... 21 The second network will be the public network, used by the cluster to communicate with other network resources.

Setting up a cluster service user account......................................................................... 22 In this section, you will create a unique account used only by the cluster service.

Set up disks....................................................................................................................... 23 You must set up disks for shared storage. All nodes in the cluster must be able to communicate with the same shared storage device(s) in order for failover to occur.

Configure cluster disks ..................................................................................................... 24 Each node in the cluster must independently communicate with the storage device(s).

Configure Node 1 ............................................................................................................. 32 This first step is required before you proceed with other cluster installation steps.

Validate the cluster installation ....................................................................................... 41 This step is necessary to make sure that the cluster is operating correctly.

Configure Node 2 ............................................................................................................. 42 Each subsequent node will be quicker to configure than the first node.

Heartbeat configuration................................................................................................... 47 This step will ensure that the private cluster‐specific network is functioning properly.

Prioritize the order of the heartbeat adapter .................................................................. 50 You must prioritize the order for internal cluster communication.

Quorum disk configuration .............................................................................................. 53 The location of the quorum disk is set automatically.

Test whether group resources can fail over..................................................................... 55 Test the failover capability of the cluster to make sure it works.


Create a cluster

The following sections will show you how to create a two‐node cluster. You will need to perform the following steps up to and including Verify Domain Membership on both Node 1 and Node 2.

Install Windows

Install Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition on both Node 1 and Node 2. For information about how to perform this installation, see the documentation you received with the operating system. Before configuring the cluster service, you must be logged on locally with a domain account that is a member of the local administrators group. The cluster service will be installed by default when you install Windows Server 2003.

Set the order of the network adapter binding

One of the recommended steps for setting up networks is to ensure the network adapter binding is set in the correct order, as shown in step 4. To do this, use the following procedure:

1. To open Network Connections, click Start, click Control Panel, and then double‐click Network Connections.


2. On the Advanced menu, click Advanced Settings.

Figure 2: Advanced Settings for network connections

3. In Connections, click the connection that you want to modify.

4. Set the order of the network adapter binding as follows:

• External public network

• Internal private network (Heartbeat)

• [Remote Access Connections]

5. Click OK.

6. Repeat this procedure for all nodes in the cluster.

Configure the private network adapters

As stated earlier, the recommended configuration for two adapters is to use one adapter for private communication, and the other adapter for mixed communication. To configure the private network adapter, use the following procedure. Perform this first for Node 1, and then for Node 2.


1. To open Network Connections, click Start, click Control Panel, and then double‐click Network Connections.

2. Right‐click the connection for the adapter you want to configure, and then click Properties. Local Area Properties opens.

3. On the General tab, verify that the Internet Protocol (TCP/IP) check box is selected, and that all other check boxes in the list are clear. This is because the private network is only used for cluster‐related network traffic.

Figure 3: Properties for private network adapter

4. On the General tab in Network Connections, select Internet Protocol (TCP/IP), and then click Properties. The Internet Protocol (TCP/IP) Properties dialog box opens.


5. On the General tab, verify that you have entered a static IP address that is not on the same subnet or network as any other public network adapter. For Node 1, use 10.0.0.11 for the IP address and for Node 2, use 10.0.0.12 for the IP address. If you want to select your own IP addresses, you should put the private network adapter in one of the following private network ranges:

• 10.0.0.0 through 10.255.255.255 (Class A)

• 172.16.0.0 through 172.31.255.255 (Class B)

• 192.168.0.0 through 192.168.255.255 (Class C)

On the General tab, verify that no values are defined in Default Gateway under Use the following IP address, and no values are defined under Use the Following DNS server addresses. After you have done so, click Advanced. Advanced TCP/IP Settings opens

Figure 4: TCP/IP Properties for the private network adapter


6. On the DNS tab, verify that no values are defined on the page and that the check boxes for Register this connection's addresses in DNS and Use this connection's DNS suffix in DNS registration are clear.

Figure 5: Advanced TCP/IP Settings for the private network adapter

.

7. On the WINS tab, verify that no values are defined on the page, and then click Disable NetBIOS over TCP/IP.

8. After you have verified the information, click OK. You might receive the message This connection has an empty primary WINS address. Do you want to continue? To continue, click Yes.

9. Repeat this procedure for all additional nodes in the cluster. For each private network adapter, use a different static IP address on the same network ID.

Configure the public network adapters

If DHCP is used to obtain IP addresses, it might not be possible to access cluster nodes if the DHCP server is inaccessible. For increased availability, static, valid IP addresses are required for all interfaces on a server cluster. If you plan to put multiple network


adapters in each logical subnet, keep in mind that the cluster service will recognize only one network interface per subnet. If you don’t use DHCP, you can follow the steps above to configure your public network using static IP addresses. Make sure that these addresses are in different IP ranges than your private network. For this cookbook, you can use the following IP addresses:

• Node 1 public network IP address: 192.168.10.11

• Node 2 public network IP address: 192.168.10.12

To verify that the private and public networks are communicating properly, ping all IP addresses from each node. To ping an IP address means to search for and verify it. You should be able to ping all IP addresses, both locally and on the remote nodes. To verify the name resolution, ping each node from a client using the node's computer name (Node 1 and then Node 2) instead of its IP address. It should only return the IP address for the public network. You might also want to try using the ping command to perform a reverse name resolution on the IP addresses using the ping –a command. The public network is the only network in this configuration on which DNS is used.

Setting up a cluster service user account

The cluster service requires a domain user account that is a member of the Local Administrators group on each node. This is the account under which the cluster service can run. Because Setup requires a user name and password, you must create this user account before you configure the cluster service. This user account should be dedicated to running only the cluster service and should not belong to an individual.

Note: It is not necessary for the Cluster Service Account (CSA) to be a member of the Domain Administrators group. For security reasons, domain administrator rights should not be granted to the Cluster Service Account.

• The Cluster Service Account requires the following rights to function properly on all nodes in the cluster. The Cluster Configuration Wizard, which we will use later, grants the following rights automatically:

o Act as part of the operating system

o Adjust memory quotas for a process

o Back up files and directories

o Restore files and directories

o Increase scheduling priority

o Log on as a service

You should ensure that the Local Administrator Group has access to the following user rights:


• Debug programs

• Impersonate a client after authentication

• Manage auditing and security log

You can use the following procedure to set up a Cluster Service Account:

1. On the domain controller, click Start, All Programs, Administrative Tools, Active Directory Users and Computers.

2. In the left pane, right‐click User, point to New, and then click User.

3. New Object‐User dialog box opens.

4. Type a first name, Cluster, and last name, Admin (these should make sense but are usually not important for this account).

5. In the User logon name text box, type Clusteradmin , and then click Next.

In Password and Confirm password, type a password that follows your organization's guidelines for passwords. If User must change password at next logon is selected, unselect it and then select User Cannot Change Password and Password Never Expires. Click Next, verify the summary information, and then click Finish to create the account.

If your administrative security policy does not allow the use of passwords that never expire, you must renew the password and update the cluster service configuration on each node before the passwords expire.

6. In the console tree of the Active Directory Users and Computers snap‐in, right‐click Cluster Admin, and then click Properties.

7. Click the Member Of tab, click Add, type Administrators, click Check Names, and then click OK. This gives the new user account administrative permissions on the computer. Click OK.

Set up disks

This section includes information and step‐by‐step procedures you can use to set up disks.

Note: To avoid possible corruption of cluster disks, ensure that both the Windows Server 2003 operating system and the cluster service are installed, configured, and running on at least one node before you start the operating system on another node in the cluster. The cluster service should be installed by default when you install Windows Server 2003. When creating the cluster, configure disks on Node 1 first, then turn Node 1 off, then turn on Node 2, configure the storage there, and turn Node 2 off. You can now turn both nodes on: Node 1 first, then Node 2. Instructions for how to configure disks will follow.

Quorum resource. The quorum resource maintains the configuration data necessary for recovery of the cluster. The quorum resource is generally accessible to other cluster


resources so that any cluster node has access to the most recent database changes. There can only be one quorum disk resource per cluster.

The requirements and guidelines for the quorum disk are as follows:

• The quorum disk should be at least 50 MB in size.

• You should use a separate LUN as the dedicated quorum resource, if you are using a SAN.

• A disk failure could cause the entire cluster to fail. Because of this, we strongly recommend that you implement a hardware RAID solution for your quorum disk to help guard against disk failure. Do not use the quorum disk for anything other than cluster management.

Cluster disks. When you configure a cluster disk, it is best to manually assign drive letters to the disks on the shared bus. The drive letters should not start with the next available letter. Instead, leave several free drive letters between the local disks and the shared disks. For example, start with drive Q as the quorum disk, and then use drives R and S for the shared disks. Another method is to start with drive Z as the quorum disk and then work backward through the alphabet with drives X and Y as data disks. You might also want to consider labeling the drives in case the drive letters are lost. Using labels makes it easier to determine what the drive letter was. For example, a drive label of "DriveR" makes it easy to determine that this drive was drive letter R. In this paper, we will use drive Q as the quorum disk and drive X as the other shared drive letter.

The letter Q is commonly used as a standard for the quorum disk and is used in the next procedure.

The first step in setting up disks for a cluster is to configure the cluster disks you plan to use. It is necessary to complete this step before you configure the cluster because shared storage is a requirement for creating a cluster. To do this, use the following procedure.

Configure cluster disks

This procedure should be performed twice for Node 1 and then again twice for Node 2. On each node it should be performed once for disk Q and once for disk X. This is true when using iSCSI; however, if you chose different storage, you may be able to configure both disk Q and disk X at the same time on each node. Disk Q is the quorum disk and disk X is the volume on shared storage.

1. Make sure that only Node 1 is turned on (Node 2 should be turned off).

2. On Node 1, open Computer Management (Local) by clicking Start and then right‐clicking My Computer and selecting Manage.

3. In the console tree, click Computer Management (Local), click Storage, and then click Disk Management. Alternatively, you could go to Start, Run and type diskmgmt.msc.


4. When you first start Disk Management after installing a new disk, a wizard appears that provides a list of the new disks detected by the operating system called Initialize and Convert Disk Wizard. If a new disk is detected, the Write Signature and Upgrade Wizard starts. Follow the instructions in the wizard.

Figure 6 Initialize and Convert Disk Wizard, Welcome page

5. Because the wizard automatically configures the disk as dynamic storage, you must reconfigure the disk to basic storage. To do this, right‐click the disk, and then click Convert To Basic Disk.


6. Right‐click an unallocated region of a basic disk, and then click New Partition.

7. In the New Partition Wizard, click Next.

Figure 7: New Partition Wizard, Welcome page


8. On the Select Partition Type page, click Primary partition, and then click Next.

Figure 8: New Partition Wizard, Select Partition Type page


9. On the Specify Partition Size page, use the default partition size. By default, the maximum size for the partition is selected. When you are finished, click Next.

Figure 9: New Partition Wizard, Specify Partition Size page


10. On the Assign Drive Letter or Path page, change the default drive letter to one that is further into the alphabet. In this cookbook we will use drive Q as the quorum disk, and then use drive X for the data disk. When you are finished, click Next.

Figure 10: New Partition Wizard, Assign Drive Letter or Path page


11. On the Format Partition page, format the partition with the NTFS file system. In Volume Label, enter the name Quorum for the quorum disk and the name Data for the data disk. Assigning a drive label for cluster disks reduces the time it takes to troubleshoot a disk recovery scenario. Click Next.

Figure 11: New Partition Wizard, Format Partition page

12. Review the summary information, and then click Finish.

13. When you have completed this procedure for both disk Q and disk X, turn off Node 1, and turn on Node 2.

14. On Node 2, go to Disk Management, you will see the new disks, Q and X, listed and the word Basic under each disk’s name. This indicates that both disk are present and are both basic.


15. Right‐click on the white space representing the disk for disk Q and click Change Drive Letter and Paths.

Figure 12 Change Drive Letter and Paths

16. Click Add and the Add Drive Letter or Path screen appears. Click the radio button next to Assign the following drive letter: From the drop‐down list, choose Q. Click OK.

Figure 13 Add Drive Letter or Path

17. Repeat steps 15 and 16 for disk X.


18. After you have configured the cluster disks, you should verify that the cluster disks are accessible. To do this, use the following procedure:

1. Turn off Node 2, and turn on Node 1.

2. On Node 1, open Windows Explorer.

3. Right‐click Quorum, click New, and then click Text Document.

4. Verify that the text document was created and written to the specified disk, and then delete the document from the cluster disk.

5. Repeat steps 2 through 4 for disk X, to verify that it is accessible from Node 1.

6. Turn off Node 1, and then turn on Node 2.

7. Repeat steps 2 through 5 to verify that the disks are accessible from Node 2.

8. When finished, turn off Node 2 and then turn on Node 1 again.

Create a new server cluster

At this point, we have two Windows Server machines that are connected to each other via both a public and a private network. We have also configured each machine to be able to access the same shared storage device. Now we are ready to create a server cluster that will use these two machines.

The New Server Cluster Wizard and the Add Nodes Wizard automatically select the drive used for the quorum device. The wizard automatically uses the smallest partition it finds that is larger than 50 MB.

In the first phase of creating a new server cluster, you must provide all initial cluster configuration information. To do this, you will use the New Server Cluster Wizard.

Note: Before configuring Node 1, make sure that all other nodes are turned off. Also make sure that all cluster storage devices are turned on.

The following procedure explains how to use the New Server Cluster Wizard to configure Node 1. This wizard should be installed by default with Windows Server 2003.

Configure Node 1

1. On Node 1, log in with a user account that has local administrative rights. Open Cluster Administrator. To do this, click Start, Control Panel, Administrative Tools, Cluster Administrator.


2. In the Open Connection to Cluster dialog box, in Action, select Create new cluster, and then click OK.

Figure 14: Open Connection to Cluster dialog box

3. The New Server Cluster Wizard appears. Verify that you have the necessary information to continue with the configuration, and then click Next to continue.

Figure 15: New Server Cluster Wizard, Welcome page


4. In Cluster Name and Domain, select the name of the domain in which the cluster will be created. In Cluster name, enter a unique NetBIOS name. Here we will use the name MyCluster. When you have finished with this, click Next.

Figure 16: New Server Cluster Wizard, Cluster Name and Domain page

5. If the Domain Access Denied page appears, it may mean that you are logged on locally with an account that is not a domain account with local administrative permissions, and the wizard will prompt you to specify an account. This is not the account the cluster service will use to start the cluster. If you have the appropriate credentials, the Domain Access Denied page will not appear.


6. Since it is possible to configure clusters remotely, you must verify or type the name of the computer you are using as Node 1. On the Select Computer page, verify or type the name of the computer you plan to use as Node 1. Click Next.

Figure 17 New Server Cluster Wizard, Select Computer page


7. On the Analyzing Configuration page, Setup analyzes the node for possible hardware or software issues that can cause installation problems. Review any warnings or error messages that appear. Click Details to obtain more information about each warning or error message. When the tasks have completed, click Next.

Figure 18: New Server Cluster Wizard, Analyzing Configuration page


8. On the IP Address page, type the unique, valid, cluster IP address that is on the same network ID as the external interfaces in the cluster, and then click Next. The wizard automatically associates the cluster IP address with one of the public networks by using the subnet mask to select the correct network. The cluster IP address should be used for administrative purposes only, and not for client connections. In this scenario, use 192.168.10.50. When you are finished entering the IP address, click Next.

Figure 19: New Server Cluster Wizard, IP Address page


9. On the Cluster Service Account page, type Clusteradmin for the user name and in the password field, type the password that you chose when you created this account. In Domain, select the domain name. The wizard verifies the user account and password. When you are finished typing, click Next.

Figure 20: New Server Cluster Wizard, Cluster Service Account page


10. On the Proposed Cluster Configuration page, review the information for accuracy. You can use the summary information to reconfigure the cluster if a system recovery occurs. You should keep a hard copy of this summary information with the change management log at the server. To continue, click Next.

Figure 21: New Server Cluster Wizard, Proposed Cluster Configuration page


11. On the Creating the Cluster page, review any warnings or error messages that appear while the cluster is being created. Click to expand each warning or error message for more information. To continue, click Next.

Figure 22: New Server Cluster Wizard, Creating the Cluster page


12. Click Finish to complete the cluster configuration.

Figure 23: New Server Cluster Wizard, Completion page

13. To view a detailed summary, click View Log or view the text file stored at the following location: %SystemRoot%\System32\LogFiles\Cluster\ClCfgSrv.Log

Validate the cluster installation

You should validate the cluster configuration of Node 1 before configuring Node 2. To do this, use the following procedure:

1. On Node 1, open Cluster Administrator. To do this, click Start, click Control Panel, double‐click Administrative Tools, and then double‐click Cluster Administrator.


2. In the left pane, click Resources and verify that all cluster resources are successfully up and running. Under State, all resources should be Online.

Figure 24: Verify cluster resources are online

Configure Node 2

After you install the cluster service on Node 1, it takes less time to install it on any subsequent nodes. This is because the Setup program uses the network configuration settings configured on Node 1 as a basis for configuring the network settings on subsequent nodes. You can also install the cluster service on multiple nodes at the same time and choose to install it from a remote location.

After you have configured Node 1, you can use the following procedure to configure Node 2:

1. On Node 2, open Cluster Administrator. To do this, click Start, Control Panel, Administrative Tools, Cluster Administrator.

2. In the Open Connection to Cluster dialog box, in Action, select Add nodes to cluster. Then, next to Cluster or server name, click Browse and choose MyCluster, and then click OK to continue.

Figure 25: Open Connection to Cluster dialog box


3. When the Add Nodes Wizard appears, click Next to continue.

Figure 26: Add Nodes Wizard, Welcome page

4. If you are not logged on with the required credentials, you will be asked to specify a domain account that has administrator rights and permissions on all nodes in the cluster.


5. On the Select Computers page, in the Computer name box, type the name of the node that you want to add to the cluster. Here, type Node 2.

Figure 27 Add Nodes Wizard, Select Computers page


6. Click Add, and then click Next.

Figure 28 Add Nodes Wizard, Select Computers page


7. On the Analyzing Configuration page, when the Add Nodes Wizard has analyzed the cluster configuration successfully, click Next.

Figure 29 Add Nodes Wizard, Analyzing Configuration page


8. On the Cluster Service Account page, in Password, type the password for the cluster service account. Ensure that the correct domain for this account appears in the Domain list, and then click Next.

Figure 30 Add Nodes Wizard, Cluster Service Account page

9. On the Proposed Cluster Configuration page, view the configuration details to verify that the server cluster IP address, the networking information, and the managed disk information are correct, and then click Next.

10. When the cluster is configured successfully, click Next, and then click Finish.

Additional Configuration

You have now created a two‐node server cluster. The following sections will show you various configuration steps including heartbeat, network, and quorum configuration.

Heartbeat configuration

After the network has been configured on each node and a Windows server cluster created, you should determine each network's function within the cluster.

Use the following procedure to configure the heartbeat:


2. In the console tree, double‐click Cluster Configuration, and then click Networks.


3. In the Scope pane, right‐click the private network you want to enable, and then click Properties.

Figure 31 Select properties


4. The Private Properties dialog box opens. Select the Enable this network for cluster use check box. Click Internal cluster communications only (private network), and then click OK.

Figure 32 Private Properties page

5. In the Scope pane, right‐click the public network you want to enable, and then click Properties.


6. The Public Properties dialog box opens. Select the Enable this network for cluster use check box. Click All communications (mixed network), and then click OK.

Figure 33: Cluster configuration properties for the public network adapter

Prioritize the order of the heartbeat adapter

After you have decided the roles in which the cluster service will use the network adapters, you must prioritize the order in which the adapters will be used for internal cluster communication. To configure network priority, use the following procedure:



2. In the console tree, click MyCluster.

Figure 34 My Cluster in the console tree


3. On the File menu, click Properties.

Figure 35 File menu


4. Click the Network Priority tab. In Networks used for internal cluster communications, click Private. To increase the network priority, click Move Up; to lower the network priority click Move Down. For this scenario, the private network should be above the public network.

Figure 36: Network priority for internal cluster communication

5. When you are finished, click OK.

Note: If multiple networks are configured as private or mixed, you can specify which one to use for internal node communication. It is usually best for private networks to have higher priority than mixed networks.

Quorum disk configuration

The New Server Cluster Wizard and the Add Nodes Wizard automatically select the drive used for the quorum device. The wizard automatically uses the smallest partition it finds that is larger than 50 MB. If you want to, you can change the automatically selected drive or partition of at least 50 MB to a dedicated one that you have designated for use as the quorum. The following procedure explains what to do if you want to use a different disk for the quorum resource:



2. In the console tree, click MyCluster.

3. On the File menu, click Properties, and then click the Quorum tab. The quorum property page opens. On the Quorum tab, click Quorum resource, and then select the new disk or storage‐class resource that you want to use as the quorum resource for the cluster. In Partition, if the disk has more than one partition, click the partition where you want the cluster‐specific data kept. In Root path, ensure that the path to the folder on the partition is: \MSCS\. When you are finished, click OK.

Figure 37: Change quorum resource

Test the Server Cluster

After Setup, there are several methods you can use to verify a cluster installation. In this cookbook, we will be using the Cluster Administrator method.

• Use Cluster Administrator. After Setup is run on Node 1, open Cluster Administrator, and then try to connect to the cluster.

• Services snap‐in. Use the Services snap‐in to verify that the cluster service is listed and started.

• Event log. Use Event Viewer to check for ClusSvc entries in the system log. You should see entries that confirm the cluster service successfully formed or joined a cluster.


Test whether group resources can fail over

You might want to ensure that a new group is functioning correctly. To do this, use the following procedure:


2. In the console tree, expand the Groups folder.

3. In the console tree, click Cluster Group.

Figure 38: Cluster Administrator before failover


4. On the File menu, click Move Group. When using Move Group, select Node 2 to move the group to, if prompted to choose a node. Make sure the Owner column in the details pane reflects a change of owner for all of the group's dependencies.

Figure 39 File menu, Move Group


5. If the group resources successfully fail over, the group will be brought online on the second node after a short period of time. In this example, we have moved the group from Node 1 to Node 2 manually. This allows us to confirm that the group is able to move between nodes. Therefore, in the event of the physical failure of a node with active groups, the groups will move to the node that is still active. Clustering is valuable for high availability in both planned and unplanned downtime; this test shows us an example of planned downtime.

Figure 40: Cluster Administrator after failover


Dependencies Between Cluster Resources in Virtual Server Host Clusters

It is very important to specify the correct resource dependencies in any kind of server cluster, including a Virtual Server host cluster. When you specify a dependency, you ensure that the cluster service starts resources in the correct order. Each dependent resource is started after the resources that it depends on.

Before considering the dependencies, it can be useful to review the two types of resources used in a Virtual Server host cluster: Generic Script resources, each representing a script that ensures smooth functioning of a guest in the cluster, and Physical Disk resources, each representing a disk used by a guest.

The two principles in specifying the correct dependencies are as follows:

For guests with multiple Physical Disk resources, the principle is "operating system disk depends on data disk": The Physical Disk resource that contains the guest's operating system must depend on any Physical Disk resources that contain the guest's data. This ensures that all the resources associated with data are online before the guest's operating system attempts to access data on them.

For all guests, the principle is "script depends on disk": The Generic Script resource used for a guest must depend on the Physical Disk resource used for that guest. If the guest has more than one Physical Disk resource, the Generic Script resource must depend on the Physical Disk resource that contains the guest's operating system. This ensures that all of the guest's Physical Disk resources are up and available before any line of the script is run.

If, after trying the configuration in this cookbook, you decide to create a configuration with multiple guests in the same resource group (meaning the guests would always move together, never separately), begin by understanding the principles listed in this section. Then plan your resource dependencies, building them into an orderly chain or tree, keeping in mind that each dependent resource is started after the resources that it depends upon.

In the Complete the configuration of Guest1 so it can fail over section, we will go through the steps of creating an example dependency.


Section 2: Create the Virtual Server Host Cluster

This section explains the steps for creating the Virtual Server host cluster.

Steps covered in this section:

Install IIS by using the Configure Your Server Wizard ...................................................... 59 Internet Information Services is a prerequisite for installing Microsoft Virtual Server, which uses a Web‐based console that depends on the Internet Information Server World Wide Web service.

Install Virtual Server 2005 R2 SP1 .................................................................................... 60 The installation process will automatically set up the Virtual Server Administration Website.

Configure shutdown on the cluster node ........................................................................ 63 In this section, you will create a batch file that will later be used to stop the cluster service on Node 1 to force Virtual Server to fail over to Node 2.

Configure the disk resource, resource group, and guest control script........................... 66 In this section, you will create cluster resources and resource groups. This step is required in order for the cluster to manage these resources.

Create Guest1 on one of the hosts .................................................................................. 71 In this section, you will create a virtual machine called Guest1 on Node 1. Guest1 will be used as the virtual machine that fails over.

Install the guest operating system from a startup CD or image file ................................ 76 The virtual machine that you have created is analogous to a physical server that you have just taken out of the box; you will need to install an operating system on it before you can install applications.

Install Virtual Machine Additions ..................................................................................... 77 Virtual Machine Additions improve mouse cursor tracking and control, and also greatly improve overall performance of the guest operating system on the virtual machines.

Complete the configuration of Guest1 so workloads can move onto it .......................... 78 This section will cover additional steps that are necessary for Guest1 to be managed by the cluster.

Migrate a workload .......................................................................................................... 82 You will now migrate a workload from Node 1 to Node 2.

Install IIS by using the Configure Your Server Wizard

IIS must be installed on both Node 1 and Node 2. You must install the World Wide Web Service component of IIS so that you can use the Administration Website to manage Virtual Server.


1. From the Start menu of the physical computer that will run the Virtual Server service, select Programs > Administrative Tools > Manage Your Server.

2. Under Managing Your Server Roles, click Add or remove a role.

3. Read the preliminary steps in the Configure Your Server Wizard, and then click Next.

4. Under Server Role, click Application server (IIS, ASP.NET), and then click Next.

Figure 41 Select Application Server in Configure Your Server Wizard

Note: By default, the wizard installs and enables IIS, COM+, and DTC. In addition, the Configure Your Server Wizard enables Microsoft® ASP.NET by default.

5. Read the summary, and then click Next. You will need the installation medium (CD or network file share) for the operating systems of this computer to complete this step.

6. Complete the wizard, and then click Finish.

7. Repeat steps 1‐7 on Node 2.

Install Virtual Server 2005 R2 SP1

You will need to install Virtual Server on both Node 1 and Node 2.

1. Start Virtual Server 2005 Setup (Setup Wizard) from the Virtual Server 2005 CD‐ROM.


Note: If you start the Setup Wizard manually, be sure to use Setup.exe.

2. Proceed through the wizard until you reach the Setup Type page.

3. On the Setup Type page, select Complete, which installs Virtual Server by using the default configuration, and then click Next.

Figure 42 Virtual Server Setup Wizard, Setup Type page


4. On the Configure Components page, either accept the default Web site port value of 1024, or type a new value for the port, and then click Next. Here we will accept the default.

Figure 43 Virtual Server Setup Wizard, Configure Components page 1


5. On the second Configure Components page, leave the Enable Virtual Server exceptions in Windows Firewall check box enabled, and then click Next.

Figure 44 Virtual Server Setup Wizard, Configure Components page 2

Note: If you have not installed the latest service pack for Windows Server 2003, you may have to reenter the same credentials that you used to log on to the remote computer on which you try to access the resource files with Administration Website.

6. Click Install to begin the installation.

7. When the installation is complete, the Setup Complete page appears. Click Finish to close the page and exit the Setup Wizard.

8. Repeat steps 1‐7 on Node 2.

Note: You can close the Installation Summary page that opens in Windows® Internet Explorer® when the installation is complete.

Configure shutdown on the cluster node

In this section, you will create a batch file that will be used later to stop the cluster service on Node 1 to force Virtual Server to fail over to Node 2. In addition, when cluster service is stopped on a node, all resources will fail over.


As a reminder, the following conventions will be used in this section:

• Folder on disk where configuration files for the guest are placed: X:\Guest1

• Cluster resource group: Guest1Group

• Label for volume on shared storage: Disk X

• Clustered Physical Disk Resource: DiskResourceX

• Clustered Generic Script resource: Guest1Script

1. On each node, open Notepad.

2. Type the following line: net stop “clussvc”

3. Go to File, Save as, and save the batch file as “C:\ Stop_clussvc_script.cmd”. Make sure you include the quotation marks around the file name or else the file will be saved with the .txt file extension and will not run.

Figure 45: Batch file to configure shutdown

4. Add the batch file as a shutdown script on both Node 1 and Node 2. On each disk, click Start, click Run, type gpedit.msc, and then press ENTER.

Figure 46: Opening local group policy editor


5. In the left pane, click Local Computer Policy, click Computer Configuration, click Windows Settings, and then click Scripts (Startup/Shutdown).

Figure 47: Local Group Policy Object Editor

6. In the right pane, double‐click Shutdown.

7. In the Shutdown Properties dialog box, click Add. For the Script Name, type: c:\Stop_clussvc_script.cmd or use the Browse button to browse for the file and then click OK. Shutdown Properties dialog box will appear. Click OK.

Figure 48: Add a Script to Shutdown


Configure the disk resource, resource group, and guest control script

In this section, you will create cluster resources and resource groups.

1. On Node 1, click Start, click Control Panel, click Administrative Tools, and then click Cluster Administrator. View the cluster, Mycluster, which you created earlier.

2. In the left pane of the Cluster Administrator, right‐click Groups, and then select New Group. Name the group Guest1Group. Click Next.

Figure 49: Creating a new group

3. If you want to specify a Preferred Owner for the group, specify the node on which you want the guest to run most of the time. While the virtual machine can only run on one node, the virtual disk and configuration files (.vhd and .vmc files) are stored on shared storage (Disk X). The name that you give the group is for administrative purposes only. Click Finish. A dialog box will appear to tell you that the procedure was successful. Click OK.


4. In Cluster Administrator, create a new disk resource, or use the appropriate disk resource if it has already been created. To create a new disk resource, right‐click Resources, point to New, and click Resource. In the New Resource dialog box, call it DiskResourceX. Make sure it is a Physical Disk resource. Assign the resource to Guest1Group. Click Next.

Figure 50: New Resource dialog box


5. On the Possible Owners page, make sure that both Node 1 and Node 2 are selected as possible owners. Click Next.

Figure 51: Possible Owners dialog box

6. On the Dependencies page, do not specify any dependencies. Click Next.

Figure 52 Dependencies page


7. On the Disk Parameters page, for the disk, choose Disk X. Click Finish.

Figure 53 Disk Parameters page

Note: If Disk X is not listed in the drop‐down menu, click Cancel. Then, in the left pane, click Resources and see if Disk X is already listed in the right pane. If it is, right‐click Disk X and click Delete. Then, start from the beginning of the wizard (step 4). Click Next. A window will appear to let you know that the procedure was successful. Click Next.


8. Ensure that Guest1Group is online on a node by checking the status column in the Cluster Administrator. If it is not, right‐click Guest1Group in the left pane, and click Bring Online.

Figure 54 Guest1Group, Bring Online

9. Use Windows Explorer to navigate to disk X and then create a folder there called \Guest1.

Figure 55 Guest1 folder


10. On both Node 1’s and Node 2’s local disks, in the %systemroot%\Cluster folder (if you used the default Windows installation, this will be C:\Windows\Cluster), copy the script called Havm.vbs, which can be found in Appendix C. The script must be copied to the %systemroot%\Cluster on each node's local hard disk, not to a disk in the cluster storage.

Figure 56: Location of Havm.vbs script

Create Guest1 on one of the hosts

In this section, you will create a virtual machine called Guest1.

1. On Node 1, click Start, click Programs or All Programs, click Microsoft Virtual Server, and then click Virtual Server Administration Website.

2. In the navigation pane, under Virtual Networks, click Create.


3. In Virtual network name, type ClusterNetwork.

Figure 57: Virtual Server Administration Website, Network Properties

4. In Network adapter on physical computer, select the network adapter associated with the public network (not the private network), and then click OK.

5. In the navigation pane, under Virtual Networks, click Configure, and then click View All.

6. Point to the virtual network you just created, and then click Edit Configuration.

Figure 58: Virtual Networks, Edit Configuration

7. In the line labeled .vnc file, select the path, and then open a text editor such as Notepad and copy and paste the path into a file for later use.

Figure 59: Virtual Network Properties


8. In the Virtual Server Administration Website, click Back.

9. Point to the virtual network you just created, and then click Remove. Then click OK on the dialog box that appears. The purpose of this step is not to undo the creation of the virtual network, but to clear Virtual Server of information that will prevent you from moving the configuration file for the virtual network (the .vnc file) to the cluster storage. If this step is skipped, the virtual network might not fail over properly.

Figure 60 Virtual Server, Remove Cluster Network


10. While still on Node 1, open Windows Explorer, and then navigate to the path in the text that you copied into a text file in step 7, or just click Search from within Windows Explorer and search for ClusterNetwork.vnc. Right‐click ClusterNetwork.vnc, and then click Cut.

Figure 61: Location of virtual cluster network configuration file

Note: You must cut and paste the file, not copy it.

11. Navigate to X:\Guest1 and paste the .vnc file, ClusterNetwork.vnc.


12. In the Virtual Server Administration Website, under Virtual Networks, click Add.

Figure 62 Add Virtual Network pane

13. In the Existing configuration (.vnc) file text box, type x:\Guest1\ClusterNetwork.vnc, and then click Add.

14. In the navigation pane, under Virtual Machines, click Create.


15. In Virtual machine name, instead of simply typing the name, type the following path. This not only names the virtual machine Guest1, but places the virtual machine's configuration file on the cluster storage: X:\Guest1\Guest1.vmc.

a) In Memory, type 512 megabytes for the amount of RAM used by the virtual machine. In this scenario, you will only be creating one virtual machine, but if you wanted to create other virtual machines on this physical host, you would use only part of the physical RAM for Guest1.

b) In Virtual hard disk, select Create a new virtual hard disk. To set the size of the virtual hard disk, specify 16 in Size, and then select GB for gigabytes. From the Bus dropdown list box, select IDE.

c) In Virtual network adapter, select ClusterNetwork.

d) Click Create.

Figure 63 Create Virtual Machine

16. In the Master Status page, click the Guest1 thumbnail. If you are prompted to enable the VMRC server, do so. Click OK. If you are prompted to install an ActiveX® control, do so. Click OK to any subsequent security dialog boxes.

Install the guest operating system from a startup CD or image file

1. On Node 1, if it is not already open, open the Virtual Server Administration Website. On the desktop of the computer running the Virtual Server service, click Start > All Programs > Microsoft Virtual Server > Virtual Server Administration Website.


2. In the left column of the Virtual Server Administration Website, under Virtual Machines, point to Configure, and then click the appropriate virtual machine. In Figure 45, this is Guest1.

Figure 64 Virtual Machine Administration Website, Configure virtual machine

3. In the Configuration section for the virtual machine that you are configuring, click CD/DVD and do one of the following:

• Insert the startup CD for the operating system into the CD drive on the physical computer running the Virtual Server service. On the CD/DVD Drive Properties page of the virtual machine that you are configuring, under Capture, click Physical CD/DVD drive. If necessary, select the corresponding CD or DVD drive letter from the drop‐down menu.

• On the CD/DVD Drive Properties page of the virtual machine that you are configuring, under Capture, click Known image files. If the image file containing a startup CD image is located in the default directory (\Documents and Settings\All Users\Documents\Shared Virtual Machines\), it is available from the drop‐down menu. Otherwise, in the Fully qualified path to file field, type the complete directory path to the image file.

4. After you have performed one of these two actions, click OK.

5. In the Status section for the virtual machine that you are configuring, point to the virtual machine name, and then click Turn On.

6. When the virtual machine is turned on, point to Guest1, and then click Remote Control.

7. When you are connected to the virtual machine, follow the instructions provided by the operating system to complete the installation.

Install Virtual Machine Additions

Virtual Machine Additions allow the virtual machine to run more efficiently. This step is not required for Virtual Server or for the guest machine to run.

Note: Prior to installing Virtual Machine Additions, the mouse pointer may appear as a dot on the screen. The mouse still functions correctly; only the display of the pointer is affected.

Guest1


1. On Node 1, if it is not already open, open the Virtual Server Administration Website. On the desktop of the computer running the Virtual Server service, click Start > All Programs > Microsoft Virtual Server > Virtual Server Administration Website.

2. In the navigation pane of the Virtual Server Administration Website, under Virtual Machines, point to Configure, and then click Guest1.

3. In Status section for Guest1, point to Guest1, and then click Turn On.

4. When the virtual machine has started, point to Guest1, and then click Remote Control.

5. Log on to the virtual machine as an administrator or a member of the Administrators group.

6. When the guest operating system is loaded, press the HOST KEY (by default, the RIGHT ALT key) to release the mouse pointer, and then in the lower‐left corner, under Navigation, click Configure Guest1.

7. In Configuration section, click Virtual Machine Additions, select the Install Virtual Machine Additions check box, and then click OK.

8. In the Status section for the virtual machine that you are configuring, point to Guest1, and then click Remote Control.

9. Click in the Remote Control window to return to the guest operating system. The Virtual Machine Additions Installation Wizard will start. Proceed through the wizard.

10. When the wizard is complete, you will be prompted to restart the virtual machine to complete the installation.

Complete the configuration of Guest1 so workloads can move onto it

In this section, we will configure Node 2 so that it can see the virtual machine (Guest1) and the virtual network (ClusterNetwork). This is necessary so that Node 2 can see these resources and will be able to restart the virtual machine on Node 2 in the event that Node 1 fails.

1. On Node 1, in Cluster Administrator, move Guest1Group from Node 1 to Node 2. To do this, right‐click Guest1Group and then click Move Group.

2. On Node 2, where Guest1Group is now located, open the Virtual Server Administration Website.


3. In the left pane, under Virtual Networks, click Add.

Figure 65 Add Virtual Network pane

4. In the box next to Existing configuration (.vnc) file, type: X:\Guest1\ClusterNetwork.vnc and then click Add.

Figure 66: Add Virtual Network

5. In the left pane, under Virtual Machines, click Add.

Figure 67 Add Virtual Machines pane


6. In Fully qualified path to file, type: X:\Guest1\Guest1.vmc and then click Add.

Figure 68: Add Virtual Machine

7. On Node 1, in Cluster Administrator, we will now create a new script resource with the Havm.vbs script which can be found in Appendix C. Havm.vbs does a variety of operations, all of which are required for Virtual Server to fail over properly.

8. Start by opening Cluster Administrator by clicking Start, Administrative tools, Cluster Administrator.

9. Expand MyCluster. Right‐click Resources in the left pane and select New Resource.

10. On the New Resource page, name the script Guest1Script. Make the Resource type a Generic Script resource. Assign the resource to Guest1Group, by clicking the Group combo box and selecting Guest1Group. Click Next.

Figure 69: New script resource, name and type


11. On the Possible Owners page, make sure both Node 1 and Node 2 are listed as possible owners.

Figure 70: New script resource, possible owners

12. On the Dependencies page, add DiskResourceX to the list of resource dependencies by selecting DiskResourceX and clicking Add. Click Next.

Figure 71: New script resource, dependencies


13. For the Script filepath, specify the following, typing the percent character (%) as shown: %systemroot%\Cluster\Havm.vbs. Click Finish.

14. On Node 1, ensure Guest1Script is in the offline state by checking in the status column in the Cluster Administrator. When a resource is created, it is offline by default. Offline is a state that marks a component in a cluster as unavailable. A node in an offline state is either inactive or not running.

15. Next, click Start, click Run, type the following command: cluster res "Guest1Script" /priv VirtualMachineName=Guest1. Press ENTER. This command associates the Guest1Script resource with the guest named Guest1.

Note: The command must be typed in exactly as stated above. There will be no immediate feedback; if the step does not complete successfully, the script will not be associated with the resource and failover will not be successful.

16. In Cluster Administrator, right‐click Guest1Group, and click Bring Online.

17. In the Virtual Server Administration Website, check in the Master Status page, and verify that Guest1 has a status of Running.

Migrate a workload

1. In Cluster Administrator, make sure that Guest1Group is online.

2. In Cluster Administrator, right‐click Guest1Group and then click Move Group. In the display for Guest1Group, you should see Owner change to NODE2. The virtual machine workload has now moved to Node 2.

Figure 72: Move Guest1Group


Appendix A: Install IIS via Control Panel

This alternate method for installing IIS is for installations of Virtual Server 2005 R2 SP1 on operating systems that do not have the Configure Your Server Wizard—for example, Windows XP Professional. Although Virtual Server 2005 R2 SP1 is supported on operating systems such as Windows XP Professional and Windows Small Business Server 2003, due to maximum supported memory and restrictions connected with operating systems other than the Windows Server family of operating systems, Microsoft does not recommend using such an operating system on the host machine running your virtual machines in a production environment.

Install IIS by using Control Panel

You must install the World Wide Web Service component of IIS so that you can use the Administration Website to manage Virtual Server.

1. From the Start menu of the physical computer that will run the Virtual Server service, select Settings > Control Panel.

2. Double‐click Add or Remove Programs.

3. In the left column, click Add/Remove Windows Components.


4. In the Components list box, select the check box next to Application Server, and then click Details.

Note: On this page and on subsequent pages of the wizard, leave check boxes that are already selected.

Figure 73 Select Application Server in Windows Components Wizard, Windows Components

page


5. In the Subcomponents of Application Server list box, select the check box next to Internet Information Services Manager, and then click Details.

Figure 74 Application Server page


6. In the Subcomponents of Application Server list box, select the check box next to World Wide Web Service, and then click Details.

Figure 75 Internet Information Services (IIS) page

7. Select the check box next to World Wide Web Service, and then click OK.

Figure 76 World Wide Web Service page

8. On the Internet Information Services (IIS) page, click OK.


9. On the Application Server page, click OK.

10. On the Windows Components page, click Next. You will need the installation medium (CD or network file) for the operating system of this computer to complete this step.

11. Wait while the Windows Components Wizard configures these settings. Then, on the Completing the Windows Components Wizard page, click Finish.


Appendix B: Virtual Server Security Considerations

Virtual Server has the following default configuration:

• The Virtual Machine Remote Control (VMRC) server is disabled.

• The VMRC server uses port 5900.

• Virtual Server uses Integrated Windows authentication.

• Only local administrators can access the Administration Website, configure Virtual Server, and create and configure virtual machines and virtual networks; other users must be granted the appropriate permissions manually. The Administration Website is a browser‐based tool for configuring and managing Virtual Server and its associated virtual machines and virtual networks.

• Firewall and antivirus software running on the host operating system will not protect guest operating systems. To obtain this protection, you must install firewall and antivirus software directly on the guest operating systems.

• The two Virtual Server services run under security accounts that have low privileges: The Virtual Server service (Vssrvc.exe) runs under the Network Service account, which has limited access to the local computer and authenticated access (as the computer account) to network resources. The Virtual Machine Helper service (Vmh.exe) runs under the Local Service account. This account has limited access to the local computer and anonymous access to network resources.

• Only local administrators can configure Virtual Server or create and configure virtual machines. You can give other users the ability to create and configure virtual machines by changing file system security settings. Use care in giving such permissions to other users.

• Virtual machines run under the account of the user who started the virtual machine, unless you specify a different user account under which to run virtual machines and assign the user account to each virtual machine. Make sure that you specify a user account that has a low level of privileges.

Note: To provide a more secure file system, use NT File System (NTFS) on the server that will run the Virtual Server service.


Appendix C: Script for Virtual Server Host Clustering

The following Visual Basic script ensures that in a Virtual Server host cluster, the guest functions correctly when a failover or other cluster‐related process occurs. The script also triggers restart of the guest if the guest stops running. The script is configured as a Generic Script resource in the cluster.

To use the script, carefully copy only the script text (not including "Havm.vbs") into a text editor such as Notepad and then save the script, using Havm.vbs as the filename. When saving the file, be sure to save it in a way that does not add line breaks.

Havm.vbs

'******************************************************************************************************************************************************* 'Global variables '******************************************************************************************************************************************************* 'Script Version ScriptVersion = "1.0" 'Flagged TRUE if the virtual machine has ever responded to an additions heartbeat. VirtualMachineHasHeartbeat = FALSE 'Used by Terminate() to make failure recovery decisions. VirtualMachineFailedOnline = FALSE 'Time in miliseconds to wait to save/restore state. Timeout = 300000 'Stores the percentage of received heartbeats over 1 time block at which the guest is considered dead. AdditionsIsAliveHeartbeatThreshold = 0 '******************************************************************************************************************************************************* 'Open() ' 'Check to see if "Virtual Server" service is running. If not attempt to start it. ' 'Check to see if the following private properties exist. If not, create/set them: ' VirtualMachineName - Stores the name of the virtual machine that is made highly available by this resource. (User has to set it explicitly) ' UseAdditionsIsAlive - 1 to use the additions heartbeat code path in IsAlive(), 0 to not use that code path. (Default is 1) ' AdditionsIsAliveFailureRecoveryAction - 1 to turn off vm, 0 to save state. (Default is 1) '******************************************************************************************************************************************************* Function Open() On Error Resume Next


Resource.LogInformation("Entering Open() for Virtual Server Host Clustering Generic Script Version " & ScriptVersion) Set wmiProvider = GetObject("winmgmts:/root/cimv2") Set vsService = wmiProvider.Get("win32_service='Virtual Server'") vsServiceState = vsService.State If uCase(vsServiceState) <> "RUNNING" Then returnValue = vsService.StartService() 'Check if the call to start the service succeeded or not. 0 or 10 means it did. If (returnValue <> 0) and (returnValue <> 10) Then Resource.LogInformation("Attempt to start 'Virtual Server' service on this machine failed with error " & returnValue) Open = returnValue Exit Function End If End If If Resource.PropertyExists("VirtualMachineName") = FALSE Then Resource.AddProperty("VirtualMachineName") End If If Resource.PropertyExists("UseAdditionsIsAlive") = FALSE Then Resource.AddProperty("UseAdditionsIsAlive") Resource.UseAdditionsIsAlive = 1 End If If Resource.PropertyExists("AdditionsIsAliveFailureRecoveryAction") = FALSE Then Resource.AddProperty("AdditionsIsAliveFailureRecoveryAction") Resource.AdditionsIsAliveFailureRecoveryAction = 1 End If End Function '******************************************************************************************************************************************************* 'Online() ' 'Issue a start control to the virtual machine. ' 'If the virtual machine is already in "Running" state, this can either mean the virtual machine has very recently failed, or it is really up and running. 'Handle the worst case by setting VirtualMachineFailedOnline = TRUE, which will cause Terminate() to attempt to save the state. '******************************************************************************************************************************************************* Function Online( ) On Error Resume Next If Resource.VirtualMachineName = "" Then Resource.LogInformation("The VirtualMachineName private property is blank. Please run the following command on any one node of the cluster to correct the problem: cluster.exe res """ & Resource.Name & """ /priv VirtualMachineName=" & """name of virtual machine""" ) Online = 13 '13 - The data is invalid. Exit Function


Else Resource.LogInformation("Entering Online() for " & Resource.VirtualMachineName) End If Set virtualServer = CreateObject("VirtualServer.Application") Set vm = virtualserver.FindVirtualMachine(Resource.VirtualMachineName) Set state = vm.Startup() Select Case err.number <> 0 Case err.number = "-1610349312" 'Handle the case where the virtual machine is already in "Running" state at the time the resource is brought online. If vm.state = 5 Then Resource.LogInformation("Startup() was called for virtual machine " & Resource.VirtualMachineName & ", however it was already in the started state. Setting VirtualMachineFailedOnline = TRUE") VirtualMachineFailedOnline = TRUE Online = 1 Exit Function End If Case err.number = "2147614729" If vm.state = 5 Then Resource.LogInformation("Startup() was called for virtual machine " & Resource.VirtualMachineName & ", however it was already in the started state. Setting VirtualMachineFailedOnline = TRUE") VirtualMachineFailedOnline = TRUE Online = 1 Exit Function End If Case err.number = "2684617984" If vm.state = 5 Then Resource.LogInformation("Startup() was called for virtual machine " & Resource.VirtualMachineName & ", however it was already in the started state. Setting VirtualMachineFailedOnline = TRUE") VirtualMachineFailedOnline = TRUE Online = 1 Exit Function End If Case Else Resource.LogInformation("Startup() for virtual machine " & Resource.VirtualMachineName & " failed with error " & err.number) Online = err.number Exit Function End Select Call state.WaitForCompletion(Timeout) If state.IsComplete = TRUE Then Online = 0 End If End Function '******************************************************************************************************************************************************* 'LooksAlive() '


'Return success '******************************************************************************************************************************************************* Function LooksAlive() LooksAlive = TRUE End Function '******************************************************************************************************************************************************* 'IsAlive() ' 'If UseAdditionsIsAlive = 1 and if VirtualMachineHasHeartbeat = TRUE and if vm.GuestOS.HeartbeatPercentage =< AdditionsIsAliveHeartbeatThreshold set IsAlive to FALSE and exit function. 'If UseAdditionsIsAlive = 1 and if VirtualMachineHasHeartbeat = TRUE and if vm.GuestOS.heartbeatpercentage > AdditionsIsAliveHeartbeatThreshold set IsAlive to TRUE and exit function. 'If UseAdditionsIsAlive <> 1 or if VirtualMachineHasHeartbeat <> TRUE, then attempt to set VirtualMachineHasHeartbeat and do basic IsAlive. '******************************************************************************************************************************************************* Function IsAlive() On Error Resume Next IsAlive = FALSE Set virtualServer = CreateObject("VirtualServer.Application") Set vm = virtualserver.FindVirtualMachine(Resource.VirtualMachineName) If (Resource.UseAdditionsIsAlive = 1) Then If VirtualMachineHasHeartbeat = TRUE Then If vm.GuestOS.HeartbeatPercentage <= AdditionsIsAliveHeartbeatThreshold Then IsAlive = FALSE Exit Function Else IsAlive = TRUE Exit Function End If End If End If 'Set VirtualMachineHasHeartbeat VirtualMachineHasHeartbeat = vm.GuestOS.IsHeartbeating 'Do basic IsAlive check If vm.state = 3 or vm.state = 4 or vm.state = 5 Then IsAlive = TRUE End If End Function '******************************************************************************************************************************************************* 'Offline() '


'Issue a save state control to the virtual machine. ' 'If the virtual machine is not already in the "Running" state, assume success. '******************************************************************************************************************************************************* Function Offline() On Error Resume Next Resource.LogInformation("Entering Offline() for " & Resource.VirtualMachineName) Set virtualServer = CreateObject("VirtualServer.Application") Set vm = VirtualServer.FindVirtualMachine(Resource.VirtualMachineName) Set state = vm.Save() Select Case err.number <> 0 'Handle the case where the virtual machine is not already in the "Running" state at the time the resource is taken offline. Case err.number = "2684617222" Resource.LogInformation("Save() was called for virtual machine " & Resource.VirtualMachineName & ", however it was not in the started state.") 'Handle another case where the virtual machine is not already in the "Running" state at the time the resource is taken offline. Case err.number = "-1610350074" Resource.LogInformation("Save() was called for virtual machine " & Resource.VirtualMachineName & ", however it was not in the started state.") Case Else Resource.LogInformation("Save() for virtual machine " & Resource.VirtualMachineName & " failed with error " & err.number) Offline = err.number Exit Function End Select Call state.WaitForCompletion(Timeout) If state.IsComplete = TRUE Then Offline = 0 End If End Function '******************************************************************************************************************************************************* 'Terminate() ' 'If Online() failed because the virtual machine was already "Running" (VirtualMachineFailedOnline = FALSE), then Terminate() needs to attempt to save state. 'If UseAdditionsIsAlive = 1 and VirtualMachineHasHeartbeat = TRUE, then take failure action specified by AdditionsIsAliveFailureRecoveryAction. '******************************************************************************************************************************************************* Function Terminate() On Error Resume Next Set virtualServer = CreateObject("VirtualServer.Application") Set vm = virtualserver.FindVirtualMachine(Resource.VirtualMachineName)


If VirtualMachineFailedOnline = TRUE Then Set state = vm.Save() Call state.WaitForCompletion(Timeout) Exit Function End If If Resource.UseAdditionsIsAlive = 1 AND virtualMachineHasHeartbeat = TRUE Then If Resource.AdditionsIsAliveFailureRecoveryAction = 0 Then Set state = vm.Save() Call state.WaitForCompletion(Timeout) Exit Function Else Set state = vm.TurnOff() Call state.WaitForCompletion(Timeout) Exit Function End If End If End Function '******************************************************************************************************************************************************* 'Close() ' 'Return success '******************************************************************************************************************************************************* Function Close() Close = 0 End Function


Related Links For more information about Virtual Server 2005 R2 SP1, visit the Virtual Server 2005 R2 home page at: www.microsoft.com/windowsserversystem/virtualserver/default.aspx

To download Virtual Server 2005 R2 or Service Pack 1, visit the Microsoft Virtual Server TechCenter home page at: www.microsoft.com/technet/virtualserver/default.mspx

To learn more about Server clustering, visit the Windows Server 2003 R2 Enterprise Edition – Server Cluster Website at: www.microsoft.com/windowsserver2003/enterprise/clustering.mspx

Microsoft Virtual Server Information at: http://go.microsoft.com/fwlink/?LinkId=55574

"Using iSCSI with Virtual Server 2005 R2" paper at: http://go.microsoft.com/fwlink/?LinkId=55646

"Maximum number of supported nodes in a cluster" article at: http://go.microsoft.com/fwlink/?LinkId=55482

Windows Server Catalog at: http://go.microsoft.com/fwlink/?LinkId=4303

Microsoft iSCSI Software Initiator Version 2.04 download at: http://go.microsoft.com/fwlink/?linkid=44352

"Setting up operating systems for virtual machines" TechNet article at: http://go.microsoft.com/fwlink/?LinkId=55573

"How to manually re‐create the cluster service account" article at: http://go.microsoft.com/fwlink/?LinkId=55161

"Installing Virtual Server" TechNet article at: http://go.microsoft.com/fwlink/?LinkId=55163


Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e‐mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e‐mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of Microsoft of the site or the products contained therein.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Copyright © 2007 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, and Windows Server either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Deployment Cookbook: Quick Migration with Virtual Server Host ...

Documents

Transcript of Deployment Cookbook: Quick Migration with Virtual Server Host ...