WHITE PAPER 2008
3PAR Thin Copy Desktop for VMware VDI Reducing Costs and Improving Performance by Provisioning Virtual Desktops on 3PAR Utility Storage
3PAR Thin Copy Desktop for VMware VDI
Table of Contents Introduction
3
Storage Requirements
4
Desktop Storage Requirements
4
Virtual Infrastructure Storage Requirements
5
Availability Availabili ty Requirements
5
Backup and Recovery Requirements
6
Performance and Scalability Requirements
7
VMware VDI Storage Deployment on 3PAR Provisioning Boot Images Boot Images Provisioned via RDM Volumes Boot Images Provisioned from VMFS Datastores Space Savings and Performance Benefits of 3PAR Utility Storage
8 8 9 10 13
Measuring Space Savings
13
Measuring Performance Benefits
13
Conclusions
14
Appendix
16
2
3PAR Thin Copy Desktop for VMware VDI
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 3
3PAR Thin Copy Desktop for VMware VDI
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. 4
3PAR Thin Copy Desktop for VMware VDI
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.
5
3PAR Thin Copy Desktop for VMware VDI
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
BASE VOLUME SET
“GOLDEN IMAGE” VIRTUAL COPIES (READ-ONLY)
VIRTUAL COPIES
EXPORT, BOOT & CUSTOMIZE
(READ/WRITE) SNAPSHOT OF SNAPSHOT
GOLDEN BOOT IMAGE 2.0
GOLDEN BOOT IMAGE 1.0
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). 6
3PAR Thin Copy Desktop for VMware VDI
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 st orage 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
7
3PAR Thin Copy Desktop for VMware VDI
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.
8
3PAR Thin Copy Desktop for VMware VDI
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. 9
3PAR Thin Copy Desktop for VMware VDI
To provision 100 virtual desktop boot images using RDM volumes, use the following procedure: 1. Create a thin provisioned base volume ( 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. 2. Install a desktop operating system on the RDM volume. 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. Create 99 writable snapshots of 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} }
4. Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running 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. 5. Create the remaining 99 VMs and associate them with the 99 snapshots available as 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.
10
3PAR Thin Copy Desktop for VMware VDI
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 Cor poration) 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} { createsv –ro basvv.ro.${i} basevv createsv basevv.rw.${i} basevv.ro.${i} }
4. Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running 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 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 11
3PAR Thin Copy Desktop for VMware VDI
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 Cor poration) 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} { createsv –ro basvv.ro.${i} basevv createsv basevv.rw.${i} basevv.ro.${i} }
5. Export each of the 99 writable snapshots to the ESX cluster. This can be achieved by running 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, 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”. 12
3PAR Thin Copy Desktop for VMware VDI
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.
ESX Cluster
VDI Boot
Clone 1
Clone 2
Clone 3
Clone 7
VMware VMFS Datastore
3PAR Writeable Snapshot 100 3PAR Writeable Snapshot 1 3PAR Writeable Snapshot 0
3PAR Thin Volume Written Data
SPACE SAVINGS AND PERFORMANCE BENEFITS OF 3PAR UTILITY STORAGE This section contains two key empirical measurements to illustr ate 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.
13
3PAR Thin Copy Desktop for VMware VDI
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
883
x2200-vdi-vista-csdemo.1.RW
Read
0
0
0
17393
17338
99
883
x2200-vdi-vista-csdemo.1.RW
Write
2
0
0
617
238
38
885
x2200-vdi-vista-csdemo.2.RW
Read
0
0
0
17383
17322
99
885
x2200-vdi-vista-csdemo.2.RW
Write
5
0
0
623
237
38
887
x2200-vdi-vista-csdemo.3.RW
Read
0
0
0
17356
17285
99
887
x2200-vdi-vista-csdemo.3.RW
Write
13
0
0
600
165
27
889
x2200-vdi-vista-csdemo.4.RW
Read
0
0
0
17333
17261
99
889
x2200-vdi-vista-csdemo.4.RW
Write
2
0
0
597
173
28
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.
14
3PAR Thin Copy Desktop for VMware VDI
•
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.
15
3PAR Thin Copy Desktop for VMware VDI
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(!dened($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);
16
3PAR Thin Copy Desktop for VMware VDI
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’}{‘cong’}{‘vmPathName’}; if(!dened$$VM{‘resourcePool’}) { die(“ERROR: No resource pool dened 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$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]); }
18
3PAR Thin Copy Desktop for VMware VDI
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.
19
U.S. CORPOR ATE HEADQUARTERS 3PAR Inc. 4209 Technology Drive Fremont, CA 94538 Phone: 510-413-5999 Fax: 510-413-5699 Email:
[email protected]
vdi-wp-08.0
