3PAR Thin Copy Desktop for VMware VDI Reducing Costs and … · 2011-01-25 · 3PAR Thin Copy...

3PAR Thin Copy Desktop for VMware VDI Reducing Costs and Improving Performance by Provisioning Virtual Desktops on 3PAR Utility Storage

WHITE PAPER2008

3PAR Thin Copy Desktop for VMware VDI

2

Table of Contents

Introduction 3

Storage Requirements 4

Desktop Storage Requirements 4

Virtual Infrastructure Storage Requirements 5

Availability Requirements 5

Backup and Recovery Requirements 6

Performance and Scalability Requirements 7

VMware VDI Storage Deployment on 3PAR 8

Provisioning Boot Images 8

Boot Images Provisioned via RDM Volumes 9

Boot Images Provisioned from VMFS Datastores 10

Space Savings and Performance Benefits of 3PAR Utility Storage 13

Measuring Space Savings 13

Measuring Performance Benefits 13

Conclusions 14

Appendix 16


3

IntroductIon

VMware® Virtual Desktop Infrastructure (VDI) allows organizations to provision hundreds of

individual desktops from a consolidated server environment in which each desktop is a virtual

machine (VM). This capability provides a number of benefits, including lower administrative costs,

greater security, reduced maintenance costs, and greater user flexibility.

An increasing number of organizations are using VMware VDI to replace their traditional desktop

computers with virtual desktops that run on consolidated remote servers. These virtualized utility

computing environments are intended to give users new levels of mobility and allow for centralized

desktop image provisioning and updates. The use of virtual desktops also reduces total cost of

ownership of the desktop infrastructure while increasing the ability to respond to changing user

and business demands.

3PAR Utility Storage is an ideal storage platform to complement server virtualization and a virtual

desktop environment with the following unique benefits:

Increased performance and scalability to handle “boot storms.”• Boot storms occur when

large numbers of desktops boot simultaneously, such as after a power outage or at large call

centers. Since snapshot clones share the same cache area for common data, large numbers of

VMs can be booted simultaneously on the 3PAR InServ® Storage Server with minimal load

on the backend physical disks and an increase in overall performance.

Greatly reduced storage capacity.• With 3PAR Utility Storage, it is possible to use thin volumes

and writable snapshot clones for boot disks to minimize physical disk space requirements

by up to 75%.

Improved administrative efficiency.• 3PAR Utility Storage improves administrative efficiency

by 10x or more with automation technologies. With 3PAR, snapshot clones of “golden” boot

images are made quickly and efficiently, reducing administration overhead for provisioning

a new desktop or upgrading existing desktops.

Enhanced backup and recovery.• With 3PAR, snapshot clones can be used for automated,

online backup and quick recovery from failures.

Unfortunately, with traditional SAN and NAS storage infrastructures, the potential for decreased

performance combined with the high cost and complexity of provisioning, managing, and recovering

virtual desktops deter many customers from implementing a centralized desktop infrastructure

altogether. To eliminate these barriers, 3PAR has introduced 3PAR Thin Copy Desktop for VMware

VDI, which uses 3PAR Virtual Copy—one of 3PAR’s thin copy technologies—to create a resilient

utility computing infrastructure for centralized desktop management in VMware VDI environments

using the 3PAR Utility Storage platform.

3PAR Virtual Copy is 3PAR’s scalable and efficient snapshot software that is designed to allow

customers to protect and share data more affordably than is possible with traditional storage


4

arrays. 3PAR Thin Copy Desktop for VMware VDI leverages the unique capabilities of 3PAR

Virtual Copy to enable the creation of up to a hundred virtual desktops from a single “golden”

boot image using very little additional storage or bandwidth. Even when simultaneously booted,

these virtual desktops consume only minimal additional bandwidth and storage resources than

the golden desktop used to create them. The process of creating virtual desktops from a golden

image can be simply and rapidly repeated to create thousands of virtual desktops that together

consume only a fraction of the bandwidth and storage resources that would otherwise be required

to support them.

3PAR is a premier VMware Technology Alliance Partner and 3PAR InServ Storage Servers are

listed on the VMware qualified Hardware Compatibility List (HCL) for VMware ESX Server.

3PAR Virtual Copy is an optional software offering for 3PAR InServ® Storage Servers, and 3PAR

Thin Copy Desktop for VMware VDI is available with 3PAR Virtual Copy at no extra charge.

This paper compares storage requirements for traditional desktop environments to those for VM

environments and then describes in detail several methods for deploying VMs with VMware VDI

and 3PAR Utility Storage through the use of 3PAR Thin Copy Desktop for VMware VDI. Several

empirical measurements for determining space savings and performance benefits of using 3PAR

Utility Storage with VMware VDI environments are also offered. The appendix of this paper

includes more information on 3PAR Thin Copy Desktop for VMware VDI as well as a sample of

the script that makes the solution possible.

Storage requIrementS

The growth of server virtualization and virtual desktop technologies has led to new storage

requirements that differ from the requirements present when using physical desktops. 3PAR

Utility Storage is designed to address the particular needs of virtualized environments. 3PAR Thin

Copy Desktop for VMware VDI leverages unique benefits of 3PAR thin copy software to address

the specific storage needs of VMware VDI environments and deliver efficiencies that are simply

unavailable with traditional storage arrays.

desktop Storage requirements

On a traditional (physical) desktop, typical storage requirements include the following:

A local boot drive.• On a desktop running Microsoft® Windows®, the local boot drive is

typically the C: drive. In most environments, desktops are provisioned identically for a large

number of users with similar computing requirements. Users, especially those in regulated

industries like healthcare and financials, are often only granted read access so that IT can

control installed applications and prevent users from changing security and configuration

parameters. IT is called on to restore the machine in the event of a hardware failure

and to roll out new applications, operating system upgrades, patches, and install other

required software.

Personal space. • In traditional desktop environments, personal space is typically located on

a Common Internet File System (CIFS) mounted from a Network Attached Storage (NAS)

appliance for availability from multiple desktops and for centralized backup.


5

Virtual Infrastructure Storage requirements

In a virtual infrastructure, housing personal space on a CIFS-mounted file system is no longer a

requirement for mobility or centralized backup. Since the user can access his or her virtual desktop

from any computer connected to the network, user mobility no longer dictates that personal space

be accessible from the desktops of different physical machines. Personal space can be provisioned

as a local file system on a raw volume provisioned to the desktop’s virtual machine. Storage is

provisioned centrally in VM environments and still backed up centrally.

When this storage is provided via a local block interface, performance improves and CPU costs

decrease since network protocols are eliminated and network bandwidth is not used for storage.

Additional security benefits may also result since, when using VMware VDI, the environment

can be configured such that personal data is not accessed over the network. The use of personal

virtual volumes to house personal space makes monitoring of space utilization for individual users

possible. Additionally, array-based snapshots enable enhanced functionality in restoring lost data

for individual users.

availability requirements

The potential cost of losing the central desktop in a virtual desktop infrastructure is substantially

higher than the potential costs associated with the failure of a single, disparate desktop. In a virtual

desktop deployment, infrastructure failures can bring down a large number of users simultaneously.

Consequently, availability requirements for storage within VM environments are substantially

higher than is the case with storage used to support individual desktops.

The 3PAR InServ Storage Server offers high availability and resilient features that cannot be matched

by traditional arrays. Even under failure conditions, the 3PAR InSpire Architecture sustains high

levels of performance through advanced error isolation and massive parallelism. InServ Storage

Servers are also able to maintain application workloads more consistently since they were designed

to eliminate acute component-level dependencies.

3PAR Utility Storage achieves their resilient infrastructure through the following:

Built-in Redundancy. • Redundant hardware components and full redundancy of

software. Protection for extended power failures through de-staging of cache data to

permanent media.

• Non-Disruptive Upgradability. All hardware and software upgrades are completed online

and non-disruptively to minimize impact on production performance levels.

• Rapid RAID Rebuild. Reliable, rapid recovery in the event of a failure through rebuilding

only used chunklets using a many-to-many drive relationship.

• RAID Isolation. Lose a Drive Chassis without losing your data. Isolation of RAID sets

across multiple Drive Chassis minimizes the impact of failures.

• Write Data Protection. Write-cache mirroring and prevention of “pinned data” through

dedicated preserved data space.


6

The high availability benefits of 3PAR InServ Storage Servers help administrators of both standard

virtualized environments and those of virtual desktop infrastructures recover quickly and easily

from disasters, thus eliminating or at least minimizing the downtime of their organization’s

virtualized infrastructure.

Backup and recovery requirements

With virtual desktops, when personalization of the boot volume is kept to a minimum it may not

be necessary to back up each individual boot image since the boot images can be easily recreated

from a “golden” image. However, for quick recovery and to minimize administrative overhead, it is

desirable to maintain backup copies of each boot image, especially in environments with persistent

desktops deployed. A desktop administrator can then quickly use these backup copies to recover

an individual boot image when necessary.

To address these requirements, 3PAR Virtual Copy can be leveraged to enable the creation of

affordable, instant, point-in-time (PIT) copies of data with little or no impact on applications

and virtual desktops (see figure 1). Using efficient copy-on-write technology, 3PAR Virtual Copy

snapshots consume minimal physical capacity by referring to existing data rather than duplicating

it. Copy capacity is only needed when changes to a base volume require the old (now overwritten)

data to be retained for the integrity of the point-in-time copy. In addition, changed data is never

duplicated within a snapshot tree, representing a significant savings compared to traditional

snapshot technologies.

Fig. 1: 3PAR Virtual Copy

More importantly, 3PAR Virtual Copy’s fine-grained auto-growth capability means that

copy capacity for any or all snapshots is drawn from free space only as needed and in small

increments, thus eliminating the traditional need to reserve specific amounts of copy space on a

per-volume basis. Users can assign distinct quality-of-service levels to copy space separately from

the base volumes (for example, different RAID levels or drive types).

3 PA R S E R V E R P R OV I S I O N I N G

GOLDEN BOOTIMAGE 2.0

“GOLDEN IMAGE” VIRTUAL COPIES

BASE VOLUME SET

VIRTUALCOPIES

EXPORT, BOOT & CUSTOMIZE

(READ/WRITE)(READ-ONLY)

GOLDEN BOOTIMAGE 1.0

SNAPSHOT OF SNAPSHOT


7

With 3PAR Virtual Copy snapshots, users can make hundreds of snapshots per base volume,

enabling histories of application data to be economically archived online. Since 3PAR Virtual Copy

allows snapshots of snapshots—which may either be read-only or read-write—organizations can

selectively test, use, and change production-quality data safely and easily. Furthermore, at any

point, any snapshot associated with a base volume can be “promoted” to the original base volume,

effectively “rolling back” the base volume to a previous point in time.

3PAR Virtual Copy provides key capabilities to administrators of virtual desktop infrastructures,

enabling them to quickly and easily recover individual boot images. Users no longer need to wait

for a physical system to be restored and then recovered; administrators can simply provision a new

virtual desktop in a fraction of the time previously required for physical desktop recovery.

Performance and Scalability requirements

With potentially hundreds or even thousands of desktops being served from a single storage system,

peak performance of the systems in VM environments must be high enough to support high I/O

loads. This is especially true during recovery from a large-scale outage (such as a power outage)

when a large number of virtual desktops are booted simultaneously.

Each 3PAR InServ Storage Server features a high-speed, full-mesh, passive backplane that

interconnects multiple Controller Nodes (the high-performance data movement engines of the 3PAR

InSpire® Architecture) to form a cache-coherent, active-active cluster. The low-latency interconnect

allows for tight coordination among the Controller Nodes and a simplified software model.

In addition, the low-latency, high-bandwidth interconnect means that each application workload

is distributed and shared across all system resources in a massively parallel fashion. High and

predictable levels of service for all workload types are assured through the massively parallel and

fine-grained striping of data across internal resources. As the use of the system grows—or in the

event of a component failure—service conditions remain high and predictable.

The Controller Nodes connect using Fibre Channel over two or more paths to each Drive Chassis

and to VMware ESX servers. The cluster of Controller Nodes presents to the ESX server a single,

highly available, high-performance storage system. This cluster enables servers to access virtual

desktops over any host-connected Fibre Channel port, even if the physical storage for that data

(on physical disks) is connected to a different Controller Node. The aggregate performance of this

architecture means substantially more ESX server clusters and virtual desktops can be supported

within a single 3PAR array than a traditional dual-controller modular platform.

Another significant advantage of 3PAR Virtual Copy snapshot technology is relevant to performance.

Virtual copy snapshots for a volume share the same cache pages for shared data (data that is

common between snapshots). In the case of the boot images in a VM environment, most of the

data is common between copies so only a single copy in cache is required, which has significant

advantages for VM performance. This is especially true in scenarios where a large number of


8

desktops boot at the same time (a “boot storm”). In this situation, the first virtual desktop to boot

brings the data into cache and then all subsequent desktops hit in the cache, thereby minimizing

back-end physical disk accesses. Almost all the bandwidth of the Controller Nodes is available for

front-end accesses to the cached copy of the boot images. In contrast, other snapshot technologies

that do not share cache for common data need to make separate back-end disk accesses for all

the boot images, greatly increasing the load on the back-end and reducing the performance of the

virtual machines, which diminishes the effectiveness of the cache.

In Section 4, empirical measurements are presented that demonstrate how these benefits of 3PAR

Utility Storage can have a significant impact on the performance of virtual desktops. In particular,

these high-performance features are especially critical in environments when many virtual desktops

are initiated within a short period of time, such as at the beginning of a work shift when many users

boot up their systems simultaneously.

Vmware VdI Storage dePloyment on 3Par

With 3PAR Thin Copy Desktop for VMware VDI, efficient provisioning of boot images is made

possible by using 3PAR Virtual Copy snapshots of “golden” images to create multiple boot images

for the desktops.

In the simplest case, each base volume contains a single boot image and each writable snapshot is used

for a specific virtual machine. For the current 3PAR Thin Copy Desktop for VMware VDI solution,

the boot image itself is hosted on a VMFS-based file system or—with some modifications—on a

Raw Device Map (RDM)-based LUN. Much of the functionality associated with VMFS—such as

taking snapshots and cloning virtual machines—is offloaded to the 3PAR InServ, therefore freeing

additional resources (such as CPU and disk bandwidth) to be used by the virtual machines.

With this approach, there are two limits that must be considered:

The maximum number of read/write snapshots of any given base volume on a 3PAR InServ •

array. Prior to the 2.2.4 release of the 3PAR InForm® Operating System, this limit was 28

snapshots. With release 2.2.4, this limit has been increased to 128. In order to leave some

writable snapshots for backup and restore, it is recommended that, with release 2.2.4, no

more than 100 writeable snapshots be used for provisioning boot volumes.

• The maximum number of LUNs that can be supported on a single ESX cluster. As of VMware

ESX Server version 3.5, this limit is 256. If the per-user personal space is provisioned via

a local file system (instead of a CIFS-mounted file system), then some of these LUNs are

needed for data volumes and are not all available for boot volumes.

Provisioning Boot Images

Before deciding how to provision boot images to virtual desktops, one should decide on the number

of distinct desktop image types, the number of each such desktop images, and the number of

distinct ESX clusters to be used to host the virtual desktops.


9

The use of RDM over VMFS also involves advantages and disadvantages that must be weighed

against each other. For example, the use of RDM offers superior performance since it eliminates a

layer between the guest OS and the storage. On the other hand, the use of VMFS brings with it the

availability of features to manage the disk image.

Boot Images Provisioned via rdm Volumes

One of the simplest and highest performing approaches to provisioning boot images is to use ESX’s

Raw Device Map (RDM), which provides each VM with its own LUN.

There are several advantages of this approach:

VM accesses to the LUN are directly forwarded to the InServ, resulting in high •

performance levels.

If necessary, the volume can be used to boot a physical machine instead of a VM.•

Backup and restores using read-only snapshots of the volume are simple •

and straightforward.

There are also two main disadvantages:

A larger number of volumes (on the InServ) and LUNs (on the ESX cluster) are required.•

With this approach, there is no access to VMFS facilities.•

As an example, let us assume that we use RDM for the personal space for each virtual desktop.

Each virtual desktop uses two LUNs. If we want all of these desktops to be of the same type, then

it is necessary that all of the desktops be copies of the same base image. We limit ourselves to 100

writeable snapshots for any given base volume, so from a single “golden” image base volume we

can provision 100 desktops. As described earlier, each desktop also needs a LUN for the personal

space, so the total number of LUNs for the ESX cluster is 100*2, or 200. This is within the 256

LUN limit for an ESX cluster while still leaving some snapshots and LUNs for backup and restore

operations. For example, if the hosts are sized such that each host can provision on average 25

desktop VMs, then the ESX cluster should have 100/25, or 4 hosts.

If the personal space is provisioned via CIFS-mounted file systems, then each VM only needs one

LUN. We can create a full copy of the “golden” image base volume and then take 100 writeable

snapshots of the base and the full copy. This allows us to provision 100*2, or 200 desktops from a

single ESX cluster. Again, using a figure of 25 desktops per host, each ESX cluster would be sized

for 200/25, or 8 hosts.

In both cases, you would use 3PAR Thin Provisioning software to create thin provisioned volumes

for use as the base volumes. With 3PAR Thin Provisioning, the space used in these volumes is the

amount of file space actually required for written data in the golden image. The snapshots use very

little additional space since the changes between desktops are typically very small.


10

To provision 100 virtual desktop boot images using RDM volumes, use the following procedure:

Create a thin provisioned base volume (1. basevv) on the InServ, export it to the ESX cluster

(for example, as LUN 0), and make the volume available to a VM as an RDM volume.

Install a desktop operating system on the RDM volume. Install the desired patches and 2.

customizations and then use the sysprep utility (available from Microsoft Corporation) to

prepare the boot image to be cloned. This is the “golden” boot image.

Create 99 writable snapshots of 3. basevv on the InServ with the InForm InForm Command

Line Interface (CLI), as follows:

for {set i 0} {$i < 99} {incr i} {

createsv –ro basvv.ro.${i} basevv

createsv basevv.rw.${i} basevv.ro.${i}

}

Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running 4.

the following code in the InForm CLI to export the 99 snapshots to all the ESX hosts in the

cluster, beginning at the next available LUN number (1 in this example, since the base virtual

volume is LUN 0):

for {set i 0} {$i < 16} {incr i} {

createvlun –cnt 99 basevv.rw.0 1 esxhost${i}

}

At this point, 100 LUNs with boot images have been created. Once you rescan the HBAs,

the ESX servers will be able to see these new LUNs.

Create the remaining 99 VMs and associate them with the 99 snapshots available as 5.

RDM volumes.

Users can now boot from these thin desktops.

Boot Images Provisioned from VmFS datastores

Another approach is to provision each VM with its own writeable snapshot (similar to the approach

using RDM described in section 3.1), but to use VMFS datastores instead of RDM. The main

advantage of this approach over using RDM is that VMFS features are available to manage the disk

image. The main disadvantage is lower performance as compared to the use of RDM.

As described in the following sections, VMs can be provisioned using either one or multiple VMs

per VMFS datastore.


11

Provisioning a Single VM per VMFS Datastore

Use the following procedure to provision 100 LUNs with VMFS datastores, each with a boot image

for a single desktop:

1. Create a thin provisioned base volume (basevv) on the InServ, export it to the ESX cluster

(for example, as LUN 0) and create a VMFS file system on it (naming the data store bootds,

for example).

2. Create a virtual machine (in this example, desk0) and install the desktop operating system

boot image on it. Install the desired patches and customizations and then use the sysprep

utility (available from Microsoft Corporation) to prepare the boot image to be cloned. This

is the “golden” boot image.

3. With the InForm CLI, create 99 writable snapshots of basevv by using the following code:

for {set i 0} {$i < 99} {incr i} {



}

4. Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running


cluster, beginning at the next available LUN number (1 in this example since the base virtual

volume is LUN 0):

for {set i 0} {$i < 16} {incr i} {


}

At this point, 100 LUNs with VMFS datastores have been created, each with a boot image for

a desktop. A rescan of the HBAs is required for the ESX servers to see these new LUNs, and the

corresponding datastores are automatically renamed beginning with “snap”.

The VM configuration files (.vmx files) in all the boot images (except the original) need to be

modified and registered with the ESX cluster.

The procedure described above can be automated. To illustrate this, a Perl script has been included

in the appendix of this paper which uses the InForm CLI in conjunction with VMware’s Perl API

to automatically perform the above procedure.

Provisioning Multiple Virtual Desktops per VMFS Datastore

To provision more than 256 desktops from a single ESX cluster, it is necessary to provision the boot

images as thin provisioned VMDK files on a VMFS file system. Since you can have multiple VMDK

files on a given file system, you can provision multiple desktops from a single LUN.

In the following example, ESX clusters have 16 hosts each and each host provisions 50 desktops

for a total of 16*50, or 800 desktops per cluster. Assuming that the personal spaces for users are


12

provided using CIFS-mounted file systems, then all the LUNs in the ESX cluster can be used for

boot images. If 100 LUNs are used for boot volumes in the ESX cluster, each LUN would need to

have 800/100, or 8 desktop boot images as VMDK files.

Provision multiple VMs per VMFS datastore as follows:

1. Create a thin provisioned base volume (basevv) on the InServ, export it to the ESX cluster (for

example, as LUN 0), and create a VMFS file system on it (naming the data store bootds, for

example). The virtual size of the base volume should be large enough for 8 boot images.

2. Create a virtual machine (for example, desk0) and install the desktop operating system boot

image on the VM. Install the desired patches and customizations and then use the sysprep

utility (available from Microsoft Corporation) to prepare the boot image to be cloned. This

is the golden boot image.

3. Clone the VMDK file seven times to create seven additional VMDK boot images on the

same VMFS file system, resulting in a total of eight boot images on the volume.

You can do this on the ESX server as follows:

a. Create seven directories (for example, desk1 through desk7) on the same datastore as

the desk0 directory.

b. Use the vmkfstools command to clone the VMDK file.

vmkfstools -i /vmfs/volumes/bootds/desk0/desk0.vmdk -d thin /vmfs/volumes/

bootds/desk1/desk1.vmdk

4. In the InForm CLI, create 99 writable snapshots of basevv using the following code:

for {set i 0} {$i < 99} {incr i} {



}

5. Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running


cluster, beginning at the next available LUN number (1 in this example since the base virtual

volume is LUN 0):

for {set i 0} {$i < 16} {incr i} {


}

At this point, there are 100 LUNs with VMFS datastores, each with eight boot images for a total

of 800 desktops. A rescan of the HBAs is required for the ESX servers to see these new LUNs. The

corresponding datastores are automatically renamed beginning with “snap”.


13

Note that the VM configuration files (.vmx files) in all the boot images (except the original) need to

be modified and registered with the ESX cluster.

Fig. 2: Boot images provisioned from VMFS datastores with multiple boot images per volume.

SPace SaVIngS and PerFormance BeneFItS oF 3Par utIlIty Storage

This section contains two key empirical measurements to illustrate the space savings and performance

benefits of the desktop boot image provisioning methods described above, which use 3PAR Thin

Copy Desktop for VMware VDI.

measuring Space Savings

To measure space savings, first we tested the space requirements for the example described in

Provisioning a Single VM per VMFS Datastore (p.11), where boot images are provisioned by VMFS

and one VM is provisioned per volume.

We first ran the script to create new VMs that are provisioned from the writeable snapshots of the

golden image. Before powering on the VMs, the snapshots consumed no additional space.

After the VMs booted to the Windows Vista® login prompt, each snapshot consumed approximately

3 MBs of space, which increased to 300 MB each after the login process completed and Vista idled

at the welcome screen. This compares to several gigabytes of capacity per virtual desktop required

with traditional provisioning approaches.

measuring Performance Benefits

To measure performance benefits, we powered on five VMs simultaneously. Since the VMs were

all provisioned from writeable snapshots, most of their data is shared and therefore will also be

shared in the cache. We measured the cache hit rate per volume using the InForm CLI’s statcmp –v

command. The command began running just as we powered on the VMs and the last iteration of

the command ran after all the VMs had booted up to the login screen.

ESX Cluster

3PAR Thin Volume

Written Data

3PAR Writeable Snapshot 0

VMware VMFS Datastore



VDIBoot

Clone1

Clone 2

Clone 3

Clone 7


14

16:52:58 05/09/08 ---- Current ----- ------ Total ------

VVid VVname Type Accesses Hits Hit% Accesses Hits Hit%

881 x2200-vdi-vista-csdemo.0.RW Read 61 61 100 17920 17847 99

881 x2200-vdi-vista-csdemo.0.RW Write 21 2 9 937 281 29









As you can see, the read hit rates for the volume accesses are extremely high (99%). Because

booting a virtual machine brings data into cache from the physical disks, upon subsequent machine

boots, data that is common between the boot images is retrieved from cache much more quickly

than when reading from disk. The 99% read hit rate recorded above demonstrates this efficiency

in action.

concluSIonS

3PAR Thin Copy Desktop for VMware VDI is designed to let VMware VDI customers automatically

provision hundreds of high-performance virtual desktops that consume only a fraction of the

bandwidth and storage capacity required with traditional storage.

By leveraging the unique performance benefits of 3PAR Utility Storage, 3PAR Thin Copy

Desktop for VMware VDI offers customers cost-effective and simple storage scaling for their VDI

environments. The combined solution allows both RDM boot volumes and VMFS-based boot

images to be provisioned quickly and easily, making it an ideal solution for provisioning boot

images for a large number of virtual desktops in VMware VDI environments. The advantages of

using 3PAR Utility Storage with VMware VDI include:

• Increased performance. 3PAR snapshots share cache space for shared data, so cache hit

rates for boot images are very high—99% in our tests. This is especially useful when

simultaneously booting a large number of desktops.

• Substantial space savings. Each additional desktop provisioned with 3PAR Thin Copy

Desktop for VMware VDI consumed only a few hundred MBs instead of several GBs.

• Automated desktop image creation and management. 3PAR Thin Copy Desktop is designed

to work with VMware VDI to allow simple and predictable creation and management of

hundreds to thousands of virtual desktops. The new virtual desktops are ready in seconds

without manual provisioning and the burden of time-consuming host-based cloning.


15

• Improved responsiveness for backups and restores. With 3PAR Thin Copy Desktop for

VMware VDI, administrators have the ability to recover virtual desktop images in just

seconds from more granular recovery points than with other SAN or NAS offerings. With

the ability to schedule snapshots to complete automatically on a regular basis, recovery of

virtual desktops for users who accidentally delete or corrupt data is not only quicker but

more accurate than with traditional virtual desktop products.

Highly degree of visibility:• 3PAR Thin Copy Desktop supports virtual desktops mounted via

VMFS and RDM. In both cases, one-to-one relationships are maintained between the virtual

desktop and the underlying snapshots to give administrators precise insight into I/O and

capacity utilization for each virtual desktop. No extra tools are required to monitor these

usage statistics, and visibility is even preserved while rebalancing virtual desktops using

VMware VMotion software. In addition, an RDM volume can be mounted to either virtual

or physical hosts.


16

aPPendIx

The procedure for 3PAR Thin Copy Desktop for VMware VDI described in this paper can be

automated through the use of a script. To illustrate this, a Perl script has been created to serve as

an example of how to create virtual machine clones using the 3PAR InForm OS and Virtual Copy

software. The code uses the InForm CLI in conjunction with VMware’s Perl API to automatically

perform the steps to quickly provision multiple virtual desktops.

This sample code is provided as-is, with no support or warranties of any kind, including but not

limited to warranties of merchantability or fitness of any kind, express or implied.

Below is a sample from the script. For a full copy of the 3PAR Thin Copy example script, please

contact your local 3PAR sales representative or email [email protected].

#!/usr/bin/perl

########################################################################

# 3PAR Thin Copy Desktop main()

########################################################################

Opts::add_options(%opts);

Opts::parse();

Opts::validate();

Util::connect();

select STDERR; $| = 1; # make unbuffered

select STDOUT; $| = 1; # make unbuffered

# Get the command line arguments and the VMWare API handles parsing and # erroring if

something required is not given.

my $VMName=Opts::get_option(‘vmname’);

my $INSERV=Opts::get_option(‘array’);

my $INSERVUSER=Opts::get_option(‘arrayuser’);

my $SNAPNAME=Opts::get_option(‘snapname’);

my $SNAPDSNAME=Opts::get_option(‘snapdsname’);

my $NEWVMNAME=Opts::get_option(‘newvmname’);

my $COUNT=Opts::get_option(‘count’);

if(!defined($COUNT)) {

$COUNT=1;

}

if($DEBUG>=2) {

printf(“DEBUG 2: ARG vmname [%s]\n”,$VMName);

printf(“DEBUG 2: ARG array [%s]\n”,$INSERV);

printf(“DEBUG 2: ARG arrayuser [%s]\n”,$INSERVUSER);

printf(“DEBUG 2: ARG newvmname [%s]\n”,$NEWVMNAME);

printf(“DEBUG 2: ARG snapname [%s]\n”,$SNAPNAME);

printf(“DEBUG 2: ARG snapdsname[%s]\n”,$SNAPDSNAME);

}

# We do not need the array version, but use this method as a quick

# way to verify that we can talk to the array correctly.

my $TPDVER=GetInServVer($INSERV,$INSERVUSER);


17

if($TPDVER!~/^2\.2\.\d+\.\d+/) {

die(“ERROR: Problems getting TPD version. Got [$TPDVER]\n”)

print_conditional(1, “Got InServ version %s\n”,$TPDVER);

my %HOSTTABLE=GetInServHosts($INSERV,$INSERVUSER);

my %VVTABLE=GetInServVVs($INSERV,$INSERVUSER);

my $VM=GetVMByName($VMName);

my $VM_PARENT=$$VM{‘parent’};

my $VM_PARENTNAME=$$VM{‘parent’}{‘value’};

my $VM_HOST=$$VM{‘runtime’}{‘host’};

my $VM_HOSTOB=Vim::get_view(mo_ref =>$VM_HOST);

my $VM_HOSTNAME=$$VM_HOSTOB{‘name’};

my $VMPATH=$$VM{‘summary’}{‘config’}{‘vmPathName’};

if(!defined$$VM{‘resourcePool’}) {

die(“ERROR: No resource pool defined for that VM\n”);

}

my $VM_POOL=$$VM{‘resourcePool’};

my $VM_POOLNAME=$$VM_POOL{‘value’};

print_conditional(1, “Found VM [%s] Pool [%s] Path [%s] Running On [%s]\n”,$$VM{‘name’},$VM_

POOLNAME,$VMPATH,$VM_HOSTNAME);

my $DSOB=GetVMDataStore($VM);

print_conditional(2, “Found VM datastore\n”);

my $EXTENTNAME=GetDSExtentName($DSOB);

print_conditional(1, “Found datastore extent name as [%s]\n”,$EXTENTNAME);

my @HOSTS=GetDSHosts($INSERV,$INSERVUSER,\%HOSTTABLE,$DSOB);

my $VVNAME=GetDSVVName($INSERV,$INSERVUSER,\%VVTABLE,$DSOB,$EXTENTNAME);

print_conditional(1, “Found VV Name [%s]\n”,$VVNAME);

my @SNAPNAMELIST=();

my @SNAPDSNAMELIST=();

my @SNAPWWNLIST=();

my @NEWVMNAMELIST=();

if($COUNT==1) {

$SNAPNAMELIST[0]=(“$SNAPNAME”);

$SNAPDSNAMELIST[0]=(“$SNAPDSNAME”);

$NEWVMNAMELIST[0]=(“$NEWVMNAME”);

} else {

for(my $CNT=0;$CNT<$COUNT;$CNT++) {

$SNAPNAMELIST[$CNT]=”$SNAPNAME.$CNT”;

$SNAPDSNAMELIST[$CNT]=”$SNAPDSNAME.$CNT”;

$NEWVMNAMELIST[$CNT]=”$NEWVMNAME.$CNT”;

}

}


18


$SNAPWWNLIST[$CNT]=MakeRWSnap($INSERV,$INSERVUSER,$VVNAME,$SNAPNAMELIST[$CNT]);

ExportToHosts($INSERV,$INSERVUSER,”$SNAPNAMELIST[$CNT].RW”,\@HOSTS);

}

# No longer needs other arguments, returns nothing.

RescanHostHBA($DSOB);

RescanVMFS($DSOB);


# Find the virtual volumes (VVs)

my ($SNAPDISKDSNAME,$SNAPDISKDS)=FindVV($SNAPWWNLIST[$CNT],

$DSOB,$VM_HOSTNAME);

print_conditional(1, “Found snapshot DS name as [%s]\n”,

$SNAPDISKDSNAME);

my $TMPPATHNAME=$VMPATH;

$TMPPATHNAME=~s/^.* //;

my $NEWPATHNAME=”[$SNAPDISKDSNAME] “ . $TMPPATHNAME;

print_conditional(2, “New VM pathname [%s]\n”,$NEWPATHNAME);

print_conditional(1, “Registering new VM\n”);

my $FOLDOB=Vim::get_view(mo_ref=>$VM_PARENT);

$VM_POOL=$$VM{‘resourcePool’};

print_conditional(2, “RegisterVM_Task(name=>$NEWVMNAMELIST[$CNT],

path=>$NEWPATHNAME, asTemplate=>false\n”);

my $NEWVMTASK=$FOLDOB->RegisterVM_Task(name=>$NEWVMNAMELIST[$CNT],

path=>$NEWPATHNAME, asTemplate=>’false’,host=>$VM_HOST,

pool=>$VM_POOL);

my $TASK=Vim::get_view(mo_ref=>$NEWVMTASK);

my $STATE=uc($$TASK{‘info’}{‘state’}{‘val’});

while(($STATE ne “ERROR”) && ($STATE ne “SUCCESS”)) {

print_conditional(2, “Task state [%s]\n”,$STATE);

sleep(1);

$TASK=Vim::get_view(mo_ref=>$NEWVMTASK);

$STATE=uc($$TASK{‘info’}{‘state’}{‘val’});

}

if($STATE eq “ERROR”) {

die(“ERROR: VM creation failed\n”);

}

my $SNAPDISKDSOB=Vim::get_view(mo_ref=>$SNAPDISKDS);

$SNAPDISKDSOB->RenameDatastore(newName=>$SNAPNAMELIST[$CNT]);

print_conditional(1, “Renamed new datastore to

[%s]\n”,$SNAPNAMELIST[$CNT]);

}


19

aBout 3Par

3PAR® (NYSE Arca: PAR) is the leading global provider of utility storage, a category of highly

virtualized, tightly-clustered, and dynamically-tiered storage arrays built for utility computing.

Organizations use utility computing to build cost-effective virtualized IT infrastructures for flexible

workload consolidation. 3PAR Utility Storage gives customers an alternative to traditional arrays

by delivering resilient infrastructure with increased agility at a lower total cost to meet their rapidly

changing business needs. As a pioneer of thin provisioning—a green technology developed to

address storage underutilization and inefficiencies—3PAR offers products designed to minimize

power consumption and promote environmental responsibility. With 3PAR, customers have reduced

the costs of allocated storage capacity, administration, and SAN infrastructure while increasing

adaptability and resiliency. 3PAR Utility Storage is built to meet the demands of open systems

consolidation, integrated data lifecycle management, and performance-intensive applications. For

more information, visit the 3PAR Website at: www.3PAR.com.

©2008 3PAR Inc. All rights reserved. 3PAR, the 3PAR logo, Serving Information, InServ, InForm, InSpire, and Thin Built In are all trademarks or registered trademarks of 3PAR Inc. All other trademarks and registered trademarks are the property of their respective owners.

http://www.3PAR.com

u.S. corPorate HeadquarterS

3PAR Inc.4209 Technology Drive

Fremont, CA 94538

Phone: 510-413-5999

Fax: 510-413-5699

Email: [email protected]

vdi-wp-08.0

3PAR Thin Copy Desktop for VMware VDI Reducing Costs and … · 2011-01-25 · 3PAR Thin Copy...

Documents

Transcript of 3PAR Thin Copy Desktop for VMware VDI Reducing Costs and … · 2011-01-25 · 3PAR Thin Copy...