Network Appliance and VMware Virtual Desktop Infrastructure M. Vaughn Stewart & Michael Slisinger, Network Appliance, Inc. August 2007 | TR-3612 | Version 1.0

Abstract This document discusses the virtual storage solutions that reduce cost while increasing storage utilization and administration efficiencies when implementing VMware VDI environments using Network Appliance™ technology.

2

TABLE OF CONTENTS

Executive Summary..................................................................................................................................................3 Virtual Desktop Infrastructures .................................................................................................................................3 VDI Storage Requirements.......................................................................................................................................4 NetApp Storage Technologies..................................................................................................................................4 Deploying VDI on FAS Systems ...............................................................................................................................5 Configuration and Setup...........................................................................................................................................6 VMware Storage Basics ...........................................................................................................................................6 VDI Storage Layout ..................................................................................................................................................8 Building Virtual Desktops for Mass Deplyment ......................................................................................................10 Step 1: Building a Gold Image Virtual Machine......................................................................................................10 Step 2: Building a Gold Image Datastore ...............................................................................................................11 Deduplicating Redundant Data with A-SIS.............................................................................................................12 Step 3: Rapidly Mass Deploying Virtual Machines.................................................................................................14 Sample VDI StartUp Script .....................................................................................................................................16 Storing End-User Data ...........................................................................................................................................18 The Challenges with Backup ..................................................................................................................................19 Providing Business Continuance to a Virtual Desktop Environment......................................................................19 Solutions Summary.................................................................................................................................................19 References .............................................................................................................................................................20 Version Tracking.....................................................................................................................................................20 

EXECUTIVE SUMMARY Network Appliance technology has a dramatic impact on VMware’s Virtual Infrastructure (VI3), by significantly reducing the amount of shared storage required in a deployment by as much as 90%. With Virtual Desktop Infrastructures (VDIs), the benefits of a NetApp solution are increased with technologies that significantly reduce the amount of time required to deploy hundreds or thousands of virtual desktops. This technical report provides an overview of the architecture and benefits of deploying VDI on NetApp FAS systems. NetApp has developed operational guidelines for the deployment of FAS systems with VI3 and VDI. These techniques have been documented and are referred to as best practices. This technical report references these best practices and suggests additional practices that are specific to VDI. Note: These practices are only recommendations, not requirements. Not following these recommendations will not affect whether your solution is supported by Network Appliance. Not all recommendations apply to every scenario. NetApp believes that their customers will benefit from thinking through these recommendations prior to making any implementation decision. The target audience for this paper is familiar with concepts pertaining to VMware VI3, VDI, and Network Appliance Data ONTAPP

® 7.X. For additional information and an overview of the unique benefits available when creating a virtual infrastructure on NetApp storage, see NetApp TR3515 VMware VI3 – Building a Virtual Infrastructure from Server to Storage.

VIRTUAL DESKTOP INFRASTRUCTURES Corporate IT departments are facing a new class of desktop management issues as they strive to provide end users with the flexibility of using any device from any network. IT is also being asked to provide access to corporate resources for an increasingly dispersed and growing audience that includes workers in offsite facilities, contractors, partners, and outsourcing providers as well as employees traveling or working from home. All of these groups demand access to sensitive corporate resources, but IT must ensure strict adherence to corporate security requirements and new regulatory standards.

VMware Virtual Desktop Infrastructure enables organizations to increase corporate IT control, manageability, and flexibility without increasing cost and while providing end users with a familiar desktop experience. VMware is committed to establishing VDI as an enterprise-class solution to deliver corporate PC services to end users.

VMware Virtual Desktop Infrastructure, based on VMware’s proven virtualization platform, delivers unprecedented desktop control and manageability, while providing end users with a familiar desktop experience; it requires no modifications to the desktop environment or applications.

VMware Virtual Desktop Infrastructure> Management: Centralized desktop images> Control: Desktops securely reside in data center, turn

off user access quickly, isolate individual desktops> Flexibility: Runs any Windows app with min overhead> End-user Satisfaction: Nearly identical to a physical PC

Figure 1) VMware Virtual Desktop Infrastructure.

3

4

VDI STORAGE REQUIREMENTS

From Desktop to Data Center

Traditional desktop workstations operate from data stored internally on inexpensive local disk drives, which provide an adequate amount of performance. With the release of VMware VDI, enterprises are moving toward a centralized desktop architecture, where storage is moved from under the end user’s desk and into the data center. With this evolution, the requirements for serving desktop data are significantly different.

Storing Virtual Desktop Data

When enterprises centralize desktop storage, the hosting storage platform is required to be highly available and highly redundant and to provide shared storage. By its very nature, any consolidation places a greater workload on fewer resources. The increased dependence on these centralized platforms requires greater levels of redundancy and availability, because a failure in a consolidated platform is exponentially more destructive than a single failure in a distributed model. The protection of data begins with RAID arrays. As greater reliance is placed on storage systems, the value of RAID technologies that provide protection of data only in the event of a single disk failure is reduced. The challenge with virtual infrastructures is that common RAID technologies that provide greater protection are either drastically more expensive, as in the case of RAID10, or provide poor performance, as with RAID6.

Storing End-User Data

VDI environments require additional end-user storage in the form of CIFS network-attached storage (NAS). The reason for this is that VDI desktops tend to be read-only versions, which load the user’s profile at the time of logon. The user’s profile customizes the desktop to best suit the user’s preferred methods of working. In addition, because the desktops are read-only, the end-user’s data must be redirected to a NAS device, where it can be centrally managed and backed up.

Business Continuance

With VDI, the consolidation of desktop data to the data center introduces the challenge of scaling data center operations to accommodate this new data. In particular, backup solutions designed for VDI are required to scale and provide a low recovery time objective (RTO) in the event of a data center or site failure. Addressing this challenge requires additional software and systems, and storage capacity equal to that of the production environment. In summary, making a redundant copy of data doubles the amount of usable storage required, whether the backup media format is disk or tape.

Summarizing the Storage Requirements of VDI

VDI has moved the desktop environment from being distributed throughout an office or many offices and now centrally stores this environment in a corporate data center. The storage platform hosting this data must be highly available and redundant, including multiple storage array controllers, network connections and components, RAID, etc. End-user data requires storage on a NAS platform, which must be equally as available as the storage for serving the VDI desktops. In addition, VDI data must be backed up to another form of media and be stored offsite. This final requirement introduces additional new backup systems, media, and software. The costs associated with migrating the end-user environment into the data center with traditional storage arrays and backup solutions can be staggering, to the point that customers may decide that the costs outweigh the benefits of implementing VDI.

NETAPP STORAGE TECHNOLOGIES Virtual Storage for Virtual Infrastructures

As discussed in the previous section, the cost associated with implementing VDI on traditional arrays can be staggering. NetApp provides a solution for VDI whereby NetApp storage virtualization technologies can reduce the storage requirements for deployments by as much as 90%.

5

Unmatched Data Protection

NetApp FAS systems provide a level of data protection that is unique and unmatched in the storage industry. Data is protected with RAID-DP™, which provides data protection greater than that of RAID10 at an acquisition cost equal to that of RAID 5. With any VMware consolidation, including VDI, data protection is critical, because any RAID failure could result in dozens to thousands of users being disconnected from their desktops. For more information on RAID-DP, see NetApp TR-3298: RAID-DP: NetApp Implementation of RAID Double Parity for Data Protection.

Extending Capacity with Storage Virtualization

NetApp provides several technologies that allow VDI deployments to provision storage beyond the physical limits of the storage array. This technology is especially effective because VMware Virtual Infrastructures tend to be very redundant. The reason for the redundancy of data is that customers are successfully leveraging the VMware cloning process to deploy new virtual machines (VMs). With VDI, the level of redundancy is almost infinite, because virtual desktops are created and subsequently cloned tens to thousands of times as part of the provisioning process. NetApp uniquely reduces the costs of VDI storage with A-SIS data deduplication and instantaneous, no-cost storage provisioning via FlexClone®. These two technologies combine to reduce the amount of physical storage and time required to provision thousands of virtual desktops down to a fraction of what would be required with traditional arrays.

For more information on A-SIS and FlexClone, see NetApp TR3505: A-SIS Deduplication and Deployment Implementation Guide and NetApp TR3447: FlexClone Volumes: A Thorough Introduction respectively.

Multiprotocol Storage Appliance

NetApp storage arrays are unique in that they are the only storage platform that can simultaneously serve all of the storage protocols required to service a VDI environment. With traditional storage arrays, enterprises need multiple platforms, even if they are from a single vendor, in order to provide the storage for VDI. Specifically, Fibre Channel Protocol (FCP), Ethernet-based iSCSI, or NFS is required to allow the VI3 servers to connect to their shared storage in order to serve the virtual desktops. In addition, as described previously, CIFS-based NAS storage is required for end users’ roaming profiles and for storing end-user-generated data.

In addition to the benefits previously described, the storage savings provided by A-SIS can be applied to the end user data to collapse the storage requirements even further. For more information on NetApp multiprotocol FAS systems, see NetApp TR3001: A Storage Networking Appliance.

Simple, Automated, Space-Efficient Backups

In order to address the backup and RTO challenges in a VDI environment, NetApp uses SnapMirror® to provide offsite backups that leverage the infrastructure cost savings provided by NetApp data deduplication technologies. SnapMirror is a block-level replication technology that is available on all NetApp storage platforms. SnapMirror enables the backup copy of a VDI environment to be as space efficient as the production copy. Additionally, when a VDI environment is replicated with SnapMirror, the backup data can be quickly brought online to provide production access in the event of a site or data center outage. For more information on SnapMirror, see NetApp TR3066: Data Protection Strategies for Network Appliance Storage Systems.

DEPLOYING VDI ON FAS SYSTEMS VMware and NetApp Solution Overview

By combining NetApp advanced storage virtualization technologies with VMware Virtual Desktop Infrastructure, customers gain a best-of-breed solution that provides a cost-effective, simple-to-manage centralized desktop service that results in operational cost savings and greater availability to the workstation for end users.

Operational Benefits

With NetApp FAS systems, customers gain a cost-effective storage solution for VMware VDI that provides a means to centrally deploy updated desktop systems and eliminate the need to push out operating system, application, virus, and spyware updates. NetApp FlexClone technology makes this centralized management possible by being able to instantly provision thousands of virtual machines, and the process of moving users to a new version of their desktop is automated with VDI Session Manager Software.

CONFIGURATION AND SETUP

VMWARE STORAGE BASICS Three types of storage options are available to the VMware Virtual Desktop Infrastructure. The following sections summarize the unique benefits of each option.

VMFS Datastore on Fibre Channel or iSCSI

This is the default method for deploying storage in VI3 environments. The strengths of this solution are that it is well known, and once storage has been provisioned to the VI3 Servers, the VMware administrator is free to use the storage as needed. Most operations are run exclusively through VirtualCenter. Figure 2 is a simple example of this configuration. For more information on accessing virtual disks stored on VMFS via either FCP or iSCSI, see the VMware Server Configuration Guide and NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

Figure 2) VI3 storage on VMFS via FCP or iSCSI.

6

Raw Device Mappings over Fibre Channel or iSCSI

Raw device mapping (RDM) was introduced in VMware ESX Server 2.5. The primary strength of this solution is high disk I/O performance. The shortcomings of this solution are that VMware data centers may have to be limited in size and the virtual infrastructure client cannot provision storage directly. Due to these limitations, RDM may not be the preferred storage design of VDI deployments in large environments. Figure 3 is a simple example of this configuration. For more information on raw device mapping over Fibre Channel and iSCSI, see the VMware Server Configuration Guide and NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

Figure 3) VI3 storage on RDM via FCP or iSCSI.

7

Virtual Disks over NFS Support for storing virtual disks (VMDKs) on a Network File System (NFS) was introduced in the VMware ESX Server 3.0. The strengths of this solution are that once storage has been provisioned to the ESX Servers, the VMware administrator is free to use the storage as needed; per port costs are lower than with a Fibre Channel solution; and VMDK files are thin provisioned by default, thus providing an increase in utilization of total storage capacity. In addition, this design is easy to integrate with features of advanced storage systems and provides high disk I/O performance. Figure 4 is a simple example of this configuration. For more information on storing VMDK files on NFS, see the VMware Server Configuration Guide and NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

Figure 4) VI3 storage on NFS.

VDI STORAGE LAYOUT This section focuses on the architectural layout of the VDI on NetApp solution. All references to storage in this section are focused on virtual disks (.vmdk files) and are protocol independent (FCP, iSCSI, NFS), unless otherwise noted.

Designing Datastore Layouts

When designing the storage layout, the storage administrator should plan to use a NetApp FlexVol® volume for each datastore. This recommendation is specific to VDI and is not to be confused with the recommendations for grouping datastores when deploying virtual servers in NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

8

Preparing VI3 Servers for Cloned Datastores

When connecting to cloned datastores, by default the VI3 Servers do not serve the cloned data. To enable the use of clones, you must enable the VMware Logical Volume Manager to accept cloned datastores. Follow these steps to enable this functionality.

1 Connect to the ESX system’s console using either SSH, Telnet, or Console connection.

2

Execute the following command:

esxcfg-advcfg -s 1 /LVM/EnableResignature

3 Repeat step 2 for each ESX host.

Datastore Contents

For the purposes of VDI, VMware administrators should design their process to store a single OS type, build, and version on a dedicated datastore. Because VDI focuses on delivering vast quantities of identical desktops, this design layout can be leveraged to mass deploy a different distribution based on the same base operating system. For example, the administrator can begin with a base Windows® XP datastore. This datastore can be cloned to become the template for a marketing department’s XP virtual desktop. The same base image can be cloned a second time to be used as the template for a sales department’s XP virtual desktop, and so on. In this design, once the core operating system image is created, it can be customized to meet the needs of a department or a user community, while consuming only the storage required to hold the data that is unique to the template. Figure 5 shows this design using FlexClone.

Figure 5) Deploying multiple versions of a desktop using FlexClone.

Granting Access to FCP and iSCSI Datastores

VMware data centers are composed of multiple ESX hosts that concurrently access shared storage. To provision LUNs for access via FCP or iSCSI, you begin by creating initiator groups (igroups) on the FAS system. NetApp igroups provide a form of LUN masking that controls host access to a LUN. Because of the shared access, NetApp

9

recommends that an igroup be created that includes all of the FCP worldwide port names (WWPNs) or iSCSI qualified names (IQNs) for each of the ESX Servers in the data center. For assistance, see NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

Granting Access to NFS Datastores

VMware data centers are composed of multiple ESX hosts that concurrently access shared storage. To provision FlexVol volumes for access via NFS, you begin by creating a DNS entry that represents all of the VMkernel IP addresses in the VMware data center. Because of the shared access, this design provides a single fully qualified domain name (FQDN) to manage access to FlexVol volumes.

After the access management name has been created, FlexVol volumes can be created and exported for access by the data center. This can be done via the command line or the FilerView® GUI. With either method, be sure to grant read-write access to the FQDN that represents the data center. For more details on NFS exports with VMware, see NetApp TR3428 VMware VI3 on NetApp Storage Best Practices.

BUILDING VIRTUAL DESKTOPS FOR MASS DEPLOYMENT Preparing virtual machines for VDI requires the same processes to be completed as for deploying VMs as virtual servers. This process includes ensuring that the guest operating system is in a condition to be duplicated. The scale of the VDI deployments requires a few additional steps in the creation of a VM and eventually a datastore template. This section focuses on the process of creating a VM to be the master template, and from there creating a datastore filled with multiple copies of this VM to be used as a datastore template for mass deployment. This section focuses on Windows desktops, because they make up the largest share of virtual desktop environments. Figure 6 shows an overview of the VDI on NetApp mass deployment process.

Figure 6) Mass deploying VDI on NetApp.

STEP 1: BUILDING A GOLD IMAGE VIRTUAL MACHINE In the phase, you create a virtual machine that will be the template of the virtual desktops that you plan to provision to your end users. This process should be familiar, because it is the same process that VMware administrators follow when creating virtual server templates. The process includes building a virtual machine, installing the operating system, applying patches, installing applications, and making any additional system settings that may be needed. Figure 7 shows the process of building a gold image VM.

Figure 7) Building a gold image virtual machine.

10

Preparing a Windows Virtual Machine for Use As a Template

Windows guest operating systems require several steps to be completed to ensure their proper functionality after being used in a cloned deployment. Microsoft provides an excellent tool for preparing a system to be cloned, Microsoft® Setup Manager. This step ensures that the VMs security identifier (SID) is not duplicated.

In addition, you need to automate several steps to be used when the cloned VM is deployed. These steps can also be completed with Microsoft Setup Manager. Specifically, be sure to automate the assigning of a random hostname and the joining of Active Directory®. To complete both of these steps, refer to Microsoft Setup Manager.

Creating a Base Datastore for Use As a Template

When you have successfully built a virtual machine for template deployment, you must complete the following steps before you can create a datastore template. This process begins by disconnecting the datastore that was used while creating the VM. Before disconnecting, make sure that the VM is powered down, has been “sealed” with Microsoft Setup Manager, and is unregistered from the Virtual Center. When you have completed these steps, disconnect the datastore and then unmap the LUN from its igroup.

At this step in the process, you have a single NetApp FlexVol volume that is either an NFS datastore or contains a LUN that is the datastore. In either scenario, this datastore contains a single virtual machine that is the master copy or template. Because the NetApp FlexVol volume contains the datastore, be sure that this volume has a descriptive name that easily identifies its contents. For example, consider a hierarchical naming scheme that includes operating system type, patch level, and published version, such as a datastore that stores a Windows XP desktop, complete with Service Pack 2, and that is the initial release. The volume name could be /vol/XP_Sp2_v1.

STEP 2: BUILDING A GOLD IMAGE DATASTORE In this phase, you create a datastore populated with virtual machines. Later in the process, this datastore will be leveraged as a template that will be duplicated via FlexClone. In this manner, every FlexClone copy results in the provisioning of tens of VMs. Figure 8 shows the process of building a gold image datastore.

Figure 8) Building a gold image datastore.

11

Creating a Production Datastore from a Template

You begin by cloning the volume that contains the template datastore. NetApp recommends that you make this clone a fully provisioned volume, because it will later be deployed into production and can be replicated via SnapMirror for offsite backup and business continuance. Follow these steps to complete this process.

1 Connect to the FAS system’s console, using either SSH, Telnet, or Console connection.

2 Execute the following command: vol clone create <vol name> <snapshot>

After completing the FlexClone operation, you should rename the new volume to a hierarchical naming scheme that includes operating system type, deployment type (if appropriate), published version, and date. For example, consider a datastore that stores a Windows XP desktop, designed for all users, that is the initial release published in August, 2007. A suggested new volume name could be /vol/XP_Sp2_Global_v1_082007.

Populating the Datastore with Virtual Machines

To fill the datastore with virtual machines, you begin by having an ESX host scan and connect to the new datastore. When this step is completed, you can populate the datastore with VMs. To complete this step, you duplicate the template VM directory and its contents into new directories. Each new directory represents a VM. Don’t use Virtual Center to create new VMs from the template VM. This technical report includes scripts for the process of registering and starting all of the VMs after they have been mass duplicated.

To summarize, in this step, you build a datastore populated with VMs to be used as a template to clone. There are other methods that will work to fill this system with copies of the template VM directory. Feel free to use a tool or script of your preference.

Deduplicating Redundant Data with A-SIS

After you have created the datastore template, you can use A-SIS data deduplication to reduce the storage requirement of the datastore down to that of an individual virtual machine. Because your datastore was populated with identical data, the storage savings will be considerable. For a comparison of typical storage consumption in a VI3 deployment and the same layout after A-SIS is invoked, see Figures 9 and 10.

12

Figure 9) Data storage consumption with traditional storage arrays.

Figure 10) Data storage consumption after A-SIS data deduplication is enabled.

13

14

A-SIS must be enabled and initialized on the appropriate FlexVol volume. With VDI there is no need for recurring A-SIS updates, so you can configure A-SIS based on the following process.

1 Connect to the FAS system’s console, using either SSH, Telnet, or Console connection.

2 Execute the following command: sis on <volume path>

3 Sis start <volume path>

When the A-SIS process is complete, there is a large amount of free space in the FlexVol volume, and the size of the volume can be reduced to the size of the actual written data.

A-SIS Considerations with VMFS and RDM LUNs

Enabling A-SIS when provisioning LUNs also produces storage savings. However, the default behavior of a LUN is to reserve an amount of storage equal to the provisioned LUN. This design means that although the storage array reduces the amount of storage capacity consumed, any gains made with A-SIS are, for the most part, unrecognizable because the space reserved for LUNs is not reduced.

To recognize the storage savings of A-SIS with LUNs, you must enable LUN thin provisioning. Configuring LUN thin provisioning is covered in depth in the Storage Thin Provisioning section. In addition, although A-SIS reduces the amount of consumed storage, the VMware administrative team does not see this benefit directly because their view of the storage is at a LUN layer, and LUNs always represent their provisioned capacity, whether they are traditionally or thin provisioned.

A-SIS Considerations with NFS

Unlike with LUNs, when A-SIS is enabled with NFS, the storage savings are both immediately available and recognized by the VMware administrative team. No special considerations are required for its usage.

For A-SIS best practices, including scheduling and performance considerations, see TR 3505: NetApp A-SIS Deduplication Deployment and Implementation Guide.

Create the Reference Snapshot Copy

The final step in creating the template datastore is the creation of a NetApp Snapshot™ copy. This copy will be utilized in the cloning process. Snapshot copies are taken at the volume level. To create a Snapshot copy, follow these steps.

1 Connect to the FAS system’s console, using either SSH, Telnet, or Console connection.

2

Execute the following command: snap create <volume name> <snapshot name>

STEP 3: RAPIDLY MASS DEPLOY VIRTUAL MACHINES

In the phase, you mass deploy virtual desktops by leveraging the template datastore, FlexClone, and the VDI mass deployment script included in this document. Note that each FlexClone volume does not consume any additional storage and is immediately online and available for use. It is an understatement to say that the mass deployment process is where the VDI on NetApp solution distinguishes itself from other storage solutions. Figure 11 shows the process of mass deploying virtual machines.

Figure 11) Mass deploying virtual machines.

Provision Production Datastores with FlexClone

At this point in the solution, you use FlexClone to make multiple clones of the template datastore. As stated previously, for each datastore that you clone, you accomplish cloning multiple virtual machines. The storage design deployed in the VDI environment dictates the level at which clones are created. If the datastore is provisioned on VMFS LUNs, you create the FlexClone volume at the LUN level. If the datastore is provisioned on an NFS file system, you create the FlexClone volume at the FlexVol level.

For VMFS formatted iSCSI or FCP LUNs, follow these steps for each clone that is required.

1 Connect to the FAS system’s console, using either SSH, Telnet, or Console connection.

2

Execute the following command to clone the LUN: lun clone create <cloned lun path> -o noreserve –b <template lun path> <snapshot>

3 Execute the following command to map the initiator to the LUN: lun map <cloned lun path> <igroup>

4 Repeat steps 2 and 3 for additional clones

For NFS datastores, complete the following steps for each clone that is required. With NFS, you must provide a name for the volume. You can continue by incrementing the name from the hierarchical naming scheme suggested here.

1 Connect to the FAS system’s console, using either SSH, Telnet, or Console connection.

2

Execute the following command: vol clone create <cloned vol name> –s none –b <template vol> <snapshot>

3 Repeat step 2 for additional clones.

Bringing the Clone Datastores Online

After provisioning the cloned datastores, they must be connected to the ESX Servers. This process can be completed in the Virtual Infrastructure client. For details on this step, refer to NetApp TR3428: VMware VI3 on NetApp Storage Best Practices.

A command line option is available for NFS solutions. To connect NFS datastores, complete the following steps for each clone that is required.

1 Connect to the ESX system through the console, using either SSH, Telnet, or Console connection.

2

Execute the following command: esxcfg-nas –a –o <FAS System> -s <path> <Datastore name>

15

16

3 Repeat step 2 for additional datastores.

Bringing the Virtual Desktops Online

When the datastores have been mounted and are online, the VMs are ready to be deployed. This process can be simplified by running the following VDI startup script. This script requires that each ESX host have SSH shared access from a single management station. For more information on how to establish SSH shared key access, see NetApp TR3393: Using NetApp Snapshots with VMware ESX.

SAMPLE VDI STARTUP SCRIPT

This script allows effortless deployment of virtual machines residing on multiple datastores. The initial starting of many VMs may temporarily place a large load on multiple systems. This temporary load is normal. Systems to monitor include but are not limited to the disk subsystem, ESX hosts, Virtual Center servers, session managers, DHCP servers, DNS servers, and Active Directory domain controllers. The script includes a slight pause between registering and starting each VM to avoid overtaxing any system that is accessed in the process of starting new VMs. This script is an example that can easily be modified to meet the needs of your environment. #!/usr/bin/bash # # Example code to register and start all VMs # # This sample code is provided AS IS, with no support or warranties of any # kind, including but not limited to warranties of merchantability or # or fitness of any kind, expressed or implied. # # 2007 Vaughn Stewart & Matt Robinson, Network Appliance # # -------------------------------------------------------------------------- VERBOSE=0 LOGFILE=/dev/null RSH=/usr/bin/ssh RSH_USER=root RSH_CMD="${RSH} -l ${RSH_USER}" # # Name: write2log() # Func: Write information out to the log file. # write2log() { TEXT=$1 echo "`date '+%D %T'` \c" >> ${LOGFILE} 2>&1 echo ": ${TEXT}" >> ${LOGFILE} 2>&1 if [ ${VERBOSE} != 0 ] ; then echo $1 else RES=`echo ${TEXT} | egrep '(WARNING|ERROR)'` if [ "${RES}" ] ; then echo $1 fi fi } # # Name: check_server() # Func: Determine whether ping and rsh/ssh access to the server are working properly. #

17

check_server() { # Check ping SERVER=$1 write2log "check_server(): Checking network access to server ${SERVER} ..." result=`/usr/bin/ping ${SERVER} -n 3 > /dev/null 2>&1` if [ $? != 0 ] ; then write2log "check_server(): ERROR: ${SERVER} is not available on the network" exit 1 else write2log "check_server(): Server ${SERVER} is on the network." fi # Check rsh/ssh write2log "check_server(): Checking remote access to server ${SERVER} ..." result=`${RSH_CMD} ${SERVER} "id"` tr=`echo "$result" | grep ${RSH_USER}` if [ "${tr}" = "" ] ; then write2log "check_server(): ERROR: ${SERVER} is not accessible with (${RSH_CMD})!" exit 1 fi write2log "check_server(): access with (${RSH_CMD}) to ${SERVER} successful." } # # Name: run_vmhost # Func: Run the operations for each VMWare host specified on the command line. # run_vmhost() { # assign the server SERVER=$1 write2log "run_vmhost(): Starting VMs on server ${SERVER} ..." # first make sure the host specified is up check_server ${SERVER} # get the find output write2log "run_vmhost(): Running ${RSH_CMD} ${SERVER} find /vmfs/volumes -mindepth 3 -maxdepth 3 -name '*.vmx' -print ..." VMXES=`${RSH_CMD} ${SERVER} "find /vmfs/volumes -mindepth 3 -maxdepth 3 -name '*.vmx' -print"` if [ $? != 0 ] ; then write2log "run_vmhost(): ERROR: Execution of ${RSH_CMD} failed!" exit 1 fi if [ "${VMXES}" != "" ] ; then # We have a set of VMFS volumes -- let's perform operations on them for VMX in ${VMXES} ; do # register the VM write2log "run_vmhost(): Running ${RSH_CMD} ${SERVER} /usr/bin/vmware-cmd -s register ${VMX} ..." ${RSH_CMD} ${SERVER} "/usr/bin/vmware-cmd -s register ${VMX}" if [ $? != 0 ] ; then write2log "run_vmhost(): ERROR: Execution of ${RSH_CMD} failed!" exit 1 fi # start the VM write2log "run_vmhost(): Running ${RSH_CMD} ${SERVER} /usr/bin/vmware-cmd ${VMX} start ..."

18

${RSH_CMD} ${SERVER} "/usr/bin/vmware-cmd ${VMX} start" if [ $? != 0 ] ; then write2log "run_vmhost(): ERROR: Execution of ${RSH_CMD} failed!" exit 1 else write2log "run_vmhost(): VM ${VMX} started." fi done else write2log "run_vmhost(): WARNING: Server ${SERVER} did not have any VMFS volumes active!" fi write2log "run_vmhost(): Configuration of server ${SERVER} completed." } # # MAIN SCRIPT # ARGS=$# while [ ${ARGS} -gt 0 ] ; do case "$1" in -v) VERBOSE=1 ; ARGS=`expr ${ARGS} - 1` ; shift ;; *) HOST=$1 ; shift ; ARGS=`expr ${ARGS} - 1` ; run_vmhost $HOST ;; esac done write2log "Script completed."

STORING END-USER DATA

As described earlier in this document, most VDI implementations leverage read-only virtual desktops. The benefit of a read-only environment is that the contents of an individual desktop are not important because any data of value is redirected to network-attached storage.

Roaming Profiles

With read-only end-user environments, Active Directory must be configured for roaming profiles. For more information on roaming profiles and enabling the use of this technology in your environment, see Microsoft Configuring Roaming User Profiles. NetApp also provides a best practices guide that addresses roaming profiles: NetApp TR3367: NetApp Systems in a Microsoft Windows Environment.

User-Generated Data

Continuing with read-only end-user environments, the home directories that store data created by the user environment must be redirected to a NAS location. Microsoft provides a large amount of information on how to redirect folders at Configuring Folder Redirection.

Considerations for MultiStore

In the event of a site or data center outage, SnapMirror provides for simple business continuance of the VDI environment. However, the path to user profiles and end-user-generated data on a NAS location is hard coded in Active Directory. An elegant way to achieve site failover of the Windows NAS location is to store the data in a virtual filer. Virtual filers are a feature of NetApp MultiStore® software. With virtual filers, the identical vFiler comes on line in the event of an outage in which the physical hosting FAS system is unavailable. The benefits of virtual

19

filer are analogous to implementing ESX HA across two physical data centers. For more information on virtual filers, see NetApp TR3462: Storage Virtualization & DR Using MultiStore.

THE CHALLENGES WITH BACKUP

PROVIDING BUSINESS CONTINUANCE TO A VIRTUAL DESKTOP ENVIRONMENT Although there are many obvious advantages to implementing a virtual desktop environment, this technology can introduce new challenges as well. One of these challenges is in the realm of disaster recovery (DR) and business continuance (BC).

In a traditional distributed desktop architecture, the value of any individual component is typically limited. A component failure typically affects only a single user at a time. With a consolidated virtual desktop infrastructure, if a site or data center disaster were to disable the hosting platform, the number of users affected could be in the hundreds or thousands.

Therefore it is extremely important to consider DR and BC when planning a VDI deployment, including incorporating off-site backups and a recovery platform for use in the event of a site disaster.

Using SnapMirror for VDI Disaster Recovery and Business Continuance

NetApp SnapMirror can quickly and simply provide business continuance and disaster recovery protection to a VDI environment. SnapMirror provides block-level replication of NetApp FlexVol volumes, which allows the storage administrator to replicate any and all template datastores to another NetApp storage device at another facility.

In the event of a disaster, the replicated template datastores can be cloned and new virtual desktops can be quickly provisioned, using the procedures described earlier in this document.

This solution provides the simplest possible DR and BC solution for VDI, because only the template datastores must be replicated. In addition, the space savings realized by A-SIS deduplication are maintained on the replica. For more information on implementing SnapMirror with VDI, see NetApp TR3446: SnapMirror Best Practices Guide.

SOLUTIONS SUMMARY As you can see, the VMware Virtual Desktop Infrastructure provides customers with tremendous benefits by centralizing the data and management of the end-user desktop environment. However, because of the storage requirements of deploying VDI, traditional storage arrays may not be practical. NetApp storage platforms and storage virtualization technologies not only make the solution obtainable by reducing the costs associated with storage; they also introduce unique mass deployment technologies that significantly reduce the amount of administration time required in deployment. This paper is not intended to be a definitive implementation or solutions guide. Many factors are not addressed in this document. Expertise may be required to solve specific deployments. Please contact your local Network Appliance representative and make an appointment to speak with one of our VMware solutions experts. Comments on this technical report are welcome. Please contact the authors here.

REFERENCES

NetApp TR3428: VMware VI3 on NetApp Storage Best Practices

NetApp TR3515: Network Appliance and VMware ESX Server 3.0: Building a Virtual Infrastructure from Server to Storage

NetApp TR3482: Network Appliance and VMware ESX Server 2.5.x

NetApp TR3001: A Storage Networking Appliance

NetApp TR3347: FlexClone Volumes: A Thorough Introduction

NetApp TR3066: Data Protection Strategies for Network Appliance Storage Systems

NetApp TR3393: Using NetApp Snapshots with VMware ESX

NetApp TR3367: NetApp Systems in a Microsoft Windows Environment

NetApp TR3462: Storage Virtualization & DR Using MultiStore

NetApp TR3446: SnapMirror Best Practices Guide

Wikipedia RAID Definitions and Explanations

VMware Introduction to Virtual Infrastructure

VMware Server Configuration Guide

VMware ESX Server 3.x Storage/SAN Compatibility Guide

VMware VMworld Conference Sessions Overview

VMware Recommendations for Aligning VMFS Partitions

Microsoft: Configuring Roaming User Profiles

Microsoft Setup Manager

Microsoft Configuring Folder Redirection

VERSION TRACKING

Version 1.0 August 2007 Original Document

20 www.netapp.com

© 2007 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, Data ONTAP, FilerView, FlexClone, FlexVol, MultiStore, and SnapMirror are registered trademarks and Network Appliance, RAID-DP, and Snapshot are trademarks of Network Appliance, Inc. in the U.S. and other countries. Microsoft, Active Directory, and Windows are registered trademarks of Microsoft Corporation. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.