Configuring a SAN Environment for VMM

Aplica-se a: Virtual Machine Manager 2008, Virtual Machine Manager 2008 R2, Virtual Machine Manager 2008 R2 SP1

This topic explains how storage area network (SAN) transfers work in Virtual Machine Manager (VMM) 2008 and VMM 2008 R2, and how to configure a supported SAN environment in order to perform virtual machine transfers in VMM by using your SAN rather than a local area network.

Because the files for a virtual machine are not actually moved when you transfer a virtual machine over a SAN, it is much faster than a transfer over a standard network and is independent of the size of the files associated with the virtual machine.

To enable you to take advantage of your investments in SAN infrastructures, VMM 2008 supports the following SANs for the transfer of virtual machine files:

• Canal de notificação

• iSCSI SANs using the Microsoft Initiator

• N_Port ID Virtualization (NPIV) Fibre Channel

For connections to Fibre Channel and iSCSI SANs using the Microsoft Initiator, the Microsoft iSCSI Software Initiator is available as an add-on for Windows Server 2003 at https://go.microsoft.com/fwlink/?LinkId=127930. Windows Server 2008 ships with the Microsoft iSCSI Software Initiator.

NPIV uses Host Bus Adapter (HBA) technology, which creates virtual HBA ports on hosts by abstracting the underlying physical port. This support enables a single physical Fibre Channel HBA port to function as multiple logical ports, each with its own identity. Each virtual machine can then attach to its own virtual HBA port and be independently zoned to a distinct and dedicated World Wide Port Name (WWPN). For more information about NPIV and HBA technology, refer to your HBA vendor documentation.

How SAN Transfers Work with Virtual Machine Manager

With VMM 2008 and VMM2008 R2, you can use a SAN to perform the following types of virtual machine transfers between a source computer and a destination computer:

• Store a virtual machine from a virtual machine host in the VMM library

• Deploy virtual machines from a VMM library to a host

• Migrate a virtual machine from one host to another

  Importante

  In the case of guest clustering for virtual machines or other use of an in-guest iSCSI initiator, if a guest virtual machine is itself using SAN storage and you migrate the virtual machine to another host, the guest virtual machine will not be able to reconnect to the SAN unless the SAN is also visible to the new host. VMM will not provide any warning if the new host does not have access to the same SAN as the guest virtual machine. Before you migrate the virtual machine to a different host, you must ensure that the SAN is visible to the new host so that the guest can reconnect to the SAN.

• With VMM2008 R2, you can use SAN transfers to migrate virtual machines and highly available virtual machines into and out of a cluster.

  Importante

  When you migrate a virtual machine into a cluster by using a SAN transfer, VMM checks all nodes in the cluster to ensure that each node can see the Logical Unit Number (LUN) and then automatically creates a cluster disk resource for the LUN. Even though VMM automatically configures the cluster disk resource, it does not validate it. You must use the Validate a Configuration Wizard in Failover Cluster Management to validate the newly created cluster disk resource. To migrate a virtual machine out of a cluster, the virtual machine must be on a dedicated LUN that is not using a clustered shared volume (CSV).

If a properly configured SAN is available, VMM automatically uses the SAN to make transfers. However, if you use the Store Virtual Machine Wizard, Deploy Virtual Machine Wizard, or Migrate Virtual Machine Wizard to perform a transfer, you can override the SAN usage and make the transfer over the local area network (LAN).

In some enterprises, a SAN LUN is masked to a single, non-clustered host, providing a simple, more secure, and isolated method for providing highly available storage capacity to specific non-clustered hosts. Sharing a LUN can produce efficiencies in terms of disk space management and make LUN creation much easier because the storage administrator only needs to create one big LUN. However, on some SANs sharing a LUN is not possible. On SANs that do permit sharing, if multiple virtual machines on a host share a single LUN, SAN migrations would become more complex, less secure, and ultimately less manageable. When you begin SAN migrations of virtual machines in a shared LUN to other hosts, the LUN ends up being masked to every destination host. The LUN can quickly become a very large shared file system that no longer has the benefits of isolation. Any non-clustered host can attempt to make uncoordinated access to the virtual machine files on that LUN, which can lead to unexpected results. VMM does not support SAN transfers when there are multiple virtual machines on the same LUN. You can migrate such virtual machines only by using a network transfer.

VMM 2008 supports SAN transfers of virtual machines that use initiator-based iSCSI target connections. Initiator-based iSCSI target connections require one iSCSI target for every LUN. VMM 2008 R2 adds support for LUN masking, which allows multiple LUNs per iSCSI target and expands VMM support for iSCSI SAN vendors.

Install and Configure the Source and Destination Computers

After installing VMM 2008, add stand-alone or clustered hosts and one or more VMM libraries as described in VMM Help. The VMM server, VMM hosts, and VMM libraries all may be either a source or a destination computer for SAN transfers of virtual machines.

Before you can use VMM to transfer virtual machines on a SAN, you must complete the following configuration steps.

Install Virtual Disk Service on Computers Running Windows Server 2003 R2

If you will use a Virtual Disk Service (VDS) interface for your SAN, install VDS 1.1 on all computers running Windows Server 2003 R2 that you will use as either a source or a destination computer for SAN transfers. You do not have to perform this step for computers that are running Windows Server 2008 or later. VDS 1.1 is a component of Windows Server 2003 R2 that you can install by using Add or Remove Programs. By default, VDS 1.1 is installed if you install either of the following:

• Storage Manager for SANs, a component in Windows Server 2003 R2

• Windows Server 2003 R2

To install Virtual Disk Service 1.1

1. No Painel de Controle, abra Adicionar ou Remover Programas.

2. Clique em Adicionar ou Remover Componentes do Windows para iniciar o Assistente de Componentes do Windows.

3. Marque todas as caixas de seleção Permitir e clique em OK.

4. Click Next, and then follow the instructions to install VDS 1.1.

5. Reinicie o computador.

   Dica

   Repeat this procedure for all computers that will serve as either a source or a destination location for your virtual machine SAN transfers.

Install a Virtual Disk Service Hardware Provider

Install a Virtual Disk Service (VDS) hardware provider on the VMM server only. You do not need to install the provider on any host or library server computers.

You can obtain a VDS hardware provider and installation instructions from your SAN vendor. For more information about installing a VDS hardware provider, refer to the vendor's documentation.

Install an iSCSI Software Initiator for an iSCSI SAN

If you are using an iSCSI SAN that is on a computer running Windows Server 2003 R2 SP2, install the latest version of the Microsoft iSCSI Software Initiator on all computers that will serve as a source or a destination location for SAN transfers. This includes computers that are running Windows Server 2008 or later. Para obter mais informações sobre o Microsoft System Center Operations Manager 2007, consulte https://go.microsoft.com/fwlink/?Linkid=79243. For an iSCSI SAN on Windows Server 2008, you should enable and configure the iSCSI Software Initiator in Administrative Tools. Para obter mais informações, consulte a Ajuda do Windows.

If your iSCSI target is configured to use one-way Challenge Handshake Authentication Protocol (CHAP) to provide security, VMM automatically generates a shared CHAP secret between the destination computer and the iSCSI target when you transfer a virtual machine on a SAN.

Install a Multipath I/O driver for a Fibre Channel SAN

If you are using a Fibre Channel SAN, you must install a Multipath I/O (MPIO) driver on all computers that are connected to your SAN, even if you are using only one host bus adapters (HBA) port on a computer. You can obtain a MPIO driver and installation instructions from your SAN vendor. For more information about installing an MPIO driver, refer to your SAN vendor's documentation.

Configure the SAN

After you have configured the source and destination computers, you must configure the SAN by:

• Configuring LUNs and volumes

• Exibindo a topologia da rede

Esses recursos são descritos nas próximas seções.

Configure LUNs and Volumes

In a SAN, a logical unit number (LUN) must be masked to and mounted on a host or library server to allow that managed computer to access the files on the LUN. To migrate the files that make up a virtual machine to another host or library server, the SAN LUN on the source computer can be dismounted and unmasked on the source computer, and then masked and mounted on the destination computer.

Use the following requirements to configure a logical unit number (LUN) and a volume for each virtual machine you plan to transfer on a SAN.

• Configure each LUN as a basic disk.
  A virtual machine on a LUN mapped to dynamic disks cannot be transferred on a SAN.

• Create a single volume on each disk.
  A virtual machine on a LUN that contains multiple volumes cannot be transferred on a SAN.

• Format the volume with the NTFS file system.
  When performing SAN transfers, ensure that the selected destination path is on a volume that is also formatted with NTFS.

• Place the files for a single virtual machine either on a single volume or, if a virtual machine’s files span multiple volumes, each volume should contain the files of only one virtual machine.
  In VMM 2008, you can only have one virtual machine per LUN, and each LUN must have only one volume.

Exibindo a topologia da rede

Ensure that all source and destination computers can access the LUN on the SAN.

For a Fibre Channel SAN, you can ensure that the source and destination computers have access to the LUN by creating the appropriate zones. For example, if you have storage array A and two hosts H1 and H2, you can create Zone1, which has host H1 and array A, and Zone2, which has host H2 and array A. The creation of these zones ensures that both host H1 and host H2 can access the LUN.

For SAN migrations into a cluster, all nodes of the cluster must be in the same zone so that they can all access the LUN.

For an iSCSI SAN, you can ensure that the source and destination computers are able to access the LUN by making sure both have access at least one of the portals on the iSCSI target. As long as the source and destination computers have access at least one of the portals on the iSCSI target, you can make SAN transfers between them.

Designating a Host for Virtual Machine Deletion on a SAN

When you create and deploy a virtual machine that can be transferred on a SAN, the virtual machine's files are stored on a logical unit number (LUN) of the SAN. This LUN is mapped and allocated to the virtual machine host on which the virtual machine is deployed. VMM supports one volume per LUN and one virtual machine per volume.

When you delete a virtual machine that has its files stored on a LUN, the empty LUN remains mapped and allocated to the host from which the virtual machine was deleted. Over time, empty LUNs can build up and become spread out over a number of hosts, making it difficult for you to locate empty LUNs to use for creating new virtual machines.

One way to avoid this difficulty is to designate one host that you consistently use for deleting virtual machines. Before you delete a virtual machine, move it to the designated host. By doing this, you always know where to look for empty LUNs to create new virtual machines, which you can then migrate to other hosts.