Configuring Quick and Live Migrations

When planning for a Hyper-V cluster, certain requirements must be taken into account. Servers must be certified for Windows 2008 R2; SANs must support SCSI-3 persistent reservation (possible firmware upgrade needed).

For more information about cluster validation see the following blog:

http://blogs.technet.com/b/askcore/archive/2009/04/15/windows-2008-failover-cluster-validation-fails-on-validate-scsi-3-persistent-reservation.aspx

The host servers should have multiple network cards (NICs) and they should be dedicated to their respective tasks.

For example:

NIC1: can be used for parent partition communications.

NIC2: reserved for virtual network communications.

NIC3: can be reserved for Clustered Shared Volumes (CSV) traffic.

NIC4: can be reserved for Live Migration traffic.

The physical NICs should also have a minimum of 1GB. If you plan on implementing Multi-path I/O (MPIO) then more dedicated NICs will be needed. By having dedicated NICs, all communications are easier to manage; traffic will not overlap on a single card. This reduces potential bottlenecks and single points of failure.

For more information see the following blog post:

http://www.virtualizationteam.com/microsoft/hyper-v/live-migration-vs-quick-migration.html

Cluster Shared Volumes (CSV), are a new feature in Windows Server 2008 R2 Failover Clustering. Its purpose is to help simplify storage, reduce errors when dealing with multiple LUNs, and failovers. CSV is a special type of NTFS. CSVs are for Hyper-V only.

To enable CSV, Failover Clustering must first be installed. A LUN must be created and presented to every host in the cluster. Format the LUN accordingly. Once the LUN is formatted, add it to the cluster through the Failover Cluster Manager. Enabling CSV is done by right-clicking the cluster and choosing Enable Cluster Shared Volumes. You will get a warning message. Once enabled, you can then create a CSV by adding an already existing clustered disk. Name the CSVs appropriately.

Dynamic I/O redirection is a feature that is part of CSVs. Its purpose is to provide a redundant path for storage paths. For example, if a storage link goes down in a cluster, the CSV network will redirect the I/O. Without redirected I/O, VMs will come to a crashing halt. There will be some performance loss until the downed link is repaired. Redirected I/O can be enabled either manually or automatically, such as performing a backup of a CSV with Data Protection Manager.

Managing Backups

Using Data Protection Manager (DPM) is one of the methods for backing up VMs and host systems. DPM supports two methods for backing up VMs; Live (online backup) and offline backup. Live backups have no downtime for the VM. Offline backups are used for VMs that don’t support live backup. This means that the VMs will be backed up when they are shutdown.

Windows Server Backup (WSB) is built into Windows Server 2008 R2. WSB can use Volume Shadow Copy Service (VSS) writers to perform block level backups which create a disk image.

There are two backup strategies that also can be used:

Host-level backup: In a host-level backup you can run the backup agent run on the host. Note you cannot backup VMs that are connected to pass-through disks or stored in remote storage such as iSCSI.

Guest-level backup: In a guest-level backup, the backup agent is on the VM. This allows you to backup contents within the VM and restores items in the VM.

Performing Non-cluster Migrations

When it comes to performing migrations, VMM will determine what types of migrations are available. These decisions are based on the topology that VMM discovers and what is best suited type of migration to use.

In order to perform a SAN migration, a SAN must be present. VMM only supports SAN migration for Virtual Server and Hyper-V. The following is from one of the links below, but the info is pretty straight forward. For SAN migration to work you need to have:

· One VM per LUN

· The SAN must be managed by VMM

· Virtual Disk Service (VDS) must be installed on the VMM server

· All servers involved must be able to communicate with the SAN

· Fiber Channel should be used

There are a few things to note in order to perform a network migration. First, performing a network migration requires the use of the Background Intelligent Transfer Service (BITS). BITS is used in migrations for Virtual Server and Hyper-V. Second, network migrations are used in transfers from two hosts for which VMM is managing, or transfers between a host and a library server. Lastly, if you are doing an ESX network migration, sFTP will be used for ESX3.0 and 3.5, and HTTPS will be used for ESX1 3.5.

The following blog posts best describe how the two migrations work:

http://itproctology.blogspot.ca/2009/03/migration-types-de-mystified.html

http://social.technet.microsoft.com/Forums/en-US/virtualmachinemanager/thread/eccf99fc-d55f-4575-b9c5-82e5d51796eb

Managing Snapshots

Dealing with snapshots can be a bit of a headache. First, best practice mandates that you never use snapshots in a production environment. The second headache is dealing with them especially using snapshot trees. Keep in mind that snapshots should only be used in a test environment.

A snapshot is a saved point in time of a VM. When a snapshot is taken, an AVHD file is created, which creates a differencing disk of sorts.

In the properties of a VM under Management, you can specify the location of where the snapshot will be saved. By default, the VM folder is the save location.

Taking a snapshot can be done from a few places; in Hyper-V Manager, from the VM Connection Tool console, or through VMM.

Reverting a VM is the act of applying a snapshot and setting the VM back to the point when the snapshot was taken.

Applying a snapshot can be done by selecting Revert from the menu bar of the Virtual machine Connection Tool, right-clicking the snapshot in Hyper-V Manager and then selecting Apply.

Deleting a snapshot will delete the snapshot from the console, but the AVHD file will remain until the VM is turned off.

Merging snapshots involves combing the differences of multiple snapshots back into the parent disk. For example you would do this if you had a snapshot tree and wanted to combine them back into the parent.

Here’s more information about deleting a snapshot:

http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/04/15/what-happens-when-i-delete-a-snapshot-hyper-v.aspx

Performing physical-to-virtual (P2V) and virtual-to-virtual (V2V) migrations

Virtual Machine Manager (VMM) has an intelligent placement feature that allows the VMM admin to place VMs on host servers to best suit the needs of the work load or performance of the VM in question.

Ideal placement is suggested based on a star rating for the hosts. There are some scenarios -where intelligent placement comes into play. This includes: New VM (from a template, from a disk, or from a VM), New P2V, New V2V, Migrate VM (quick, Live, storage, or network-based migration), or deploying a VM from the library. There are also some factors that impact intelligent placement:

VM settings: Processor Count, Memory Amount, Virtual Disks on IDE Controller, High Availability, Virtual Disk size

VMM can also reserve host settings which can impact intelligent placement. Those settings are: CPU percentage, memory (in MB), disk space (in MB), maximum disk I/O per second, and network capacity percentage.

If the standard star rating doesn’t suit your needs you can customize the rating system. There are a few ways VMM allows for customization of the rating system:

Resource maximization (preferred hosts with the most resources or hosts that meet the VMs’ needs) Load balancing (spreading VMs over as many hosts as possible to prevent overwhelming any one host).

A second way is to customize the main VM resources; CPU, memory, disk I/O, and network utilization. A third way is to specify the VM load for the CPU, disk or network.

You may have some servers that you need to convert to VMs. Could it be that where they are, they are being under-utilized? There are a few things that can be done in this instance. This is where Physical to Virtual (P2V) and Virtual to Virtual (V2V) migrations come in.

P2V is the process that VMM uses to convert the contents of a physical server into virtual machine. There are two methods of doing P2V migrations; offline and online.

V2V is the process of converting VMware ESX VM files to VHD files. You can do this either online or offline too.

Performing online /offline P2V

Virtual Machine Manager (VMM) has a wizard that takes you through the process of doing a P2V migration. You will need to supply the name of the physical server you want to migrate, an administrative account, password and domain name. Next you will need to specify the VM name to which the physical server will be copied to, who the owner is, and a description. After all this is done, VMM will install a P2V agent on the physical server and begin the P2V process. The following table outlines what OSes are supported:

Source: Mastering Virtual Machine Manager 2008 R2, Sybex (Note: parts of this list may be out of date)

If an OS is not in the list, it is not supported.

For offline P2V, the process is similar, however, in the offline P2V wizard you will need to specify IP information. The offline process will create a WinPE image. VMM will deploy the image to the specified system, alter the boot order and restart the server. WinPE will start up and begin the copying process to the VMM server.

Performing online /offline V2V migrations

VMM has a V2V wizard that can convert VMware files to VHDs. First VMM must control a VMware environment. The VMware Tools must be uninstalled and the VM must be turned off. Next, run the VMM V2V wizard and supply all requested information and settings for the new VM. Note that V2V needs the VMware file type VMDK in a support format. There is no online method for V2V.

Performing import/export migration

If you find yourself needing to move VMs between servers, aside from migrations, you can export and import VMs.

Exporting a VM can be done through Hyper-V Manager. When you export a VM you get the following dialogue box. All you need to do is to specify where the VM will be saved. A copy will be made. Note also that the VM must be turned off before exporting.

When importing a VM you will be presented with the following dialogue box:

Specify where the VM is located and the import settings.

Move or restore the virtual machine (use the existing unique ID): This option imports the original VM retaining its original ID.

Copy the virtual machine (create a new unique ID): This option imports the VM assigning it a new ID.

Duplicate all files so the same Virtual machine can be imported again: This option will create a new VM in the same location as the original.

Manage non-Hyper-V aware virtualization hosts

If you have a VMware environment and want to manage it along with your Windows environment then VMM is the answer. VMM has the capability to manage VMware hosts. In order for VMM to manage VMware hosts, VMM must first manage vCenter. Only through vCenter can VMM see the hosts that vCenter is controlling. Adding an ESX host is done the same way as adding a Hyper-V host. vCenter and ESX have a secure mode, so additional information will be needed; the certificate from the ESX host and the public key. You can also enable full management of an ESX host. To achieve this, you will need to provide the local host credentials for each ESX host you intend to manage.

There are some instances when VMM will not be able to manage a host. For example, a host may not be able to run Hyper-V, or when dealing with Server 2003. In these cases, VMM will install Virtual Server 2005 in order to manage the host. Once the host has Virtual Server 2005 on it, VMM will also deploy an agent to it.

Create roles and configure authorization rights

This section revolves around Authorization Manager. Authorization Manager (AzMan) is the best way to control user rights when it comes to Hyper-V. AzMan is accessed through the AzMan.msc management console. Hyper-V relies on XML files to store the user rights. The default AzMan store is called InitialStore.xml. Azman allows the admin to assign role-based access to users and then assign delegations and rights. AzMan allows you to create a scope which targets VMs and then roles which target users or groups. AzMan allows for greater control of delegating right to users and groups. With this kind of control, you can delegate rights with finer control.

Configuring delegation of rights

User policies for SSP are a set of rules that define what a user or group can do within SSP. For instance quotas can be assigned as to how many VM can be created, what permissions or restrictions there are for the user or group. There are three types of user policies that can be used:

· Single self-service policy use a domain group with the required users in the group.

· Multiple self-service policies, each that have their own domain group but smaller number of users in each group.

· One self-service policy per self-service user

When dealing with templates, there are three types you can create in VMM:

· from a virtual disk in the library

· from an existing VM

· from an existing template

To create a template from a virtual disk in the library, open the library view, choose New Template in the Library Actions menu. Follow the wizard that opens. You will configure Template Identity, Hardware settings, and Gust Operating System settings. Additional properties can be set after the template is created: Cost center, Tag, ten custom properties and a quota for self-service users.

To create a template from an existing VM, right click a stopped VM, and select New Template. You will get a warning message. Creating a template in this manner will destroy the source VM. A wizard will follow. You will configure Template Identity, Hardware settings, Gust Operating System settings, Select Library Server, and Select Path (which is the path on the library where you will the place template).

To create a template from an existing template, you will right click a template in the library. Follow the wizard that opens. You will configure Template Identity, Hardware settings, and Gust Operating System settings.

Templates are managed through the library.

Libraries are an integral part of VMM. Libraries are file shares that reside preferably on a file server. If you find that you need to replicate them you can use DFSR and DFSN. Although there are some things that you will need to take into consideration, namely VMM is not DFS aware and there are other known issues. Backing up the library shares on a regular basis is also good practice. Another way of dealing with libraries is to make library file shares highly available through clustering. You can also create custom library groups for easier management. So what can you store in the library? Just about anything from VMs that are not being used to templates, scripts, and ISOs.