Got myself interviewed and mentioned in another VDI article, Virtual desktop infrastructure adds new wrinkle to data center storage management, though this one for some reason pegs me as being at The MetroHealth System in Cleveland. Oh well. I emailed the correction but got an out-of-office auto-reply.
One administrator in a large VDI environment said his IT staff still doesn’t back up desktop data, though it lives on data center storage. “If an individual desktop goes down, we’re just going to assign the user to a new one and reinstall their applications,” said Chris House, senior network analyst at The MetroHealth System, a hospital network based in Cleveland. MetroHealth uses 1,500 VMware virtual desktops and stores data on a Hewlett-Packard Co. StorageWorks XP1024 high-end disk array.
House said the initial VDI deployment was done using a midrange HP StorageWorks EVA8000 array, but with more than a thousand desktops, the IOPS required pushed it up to tier 1 storage. “The VDI environment was averaging between 4,000 and 9,000 IOPS most of the time, but once a week at 2 a.m. it would spike to 40,000 IOPS,” he said.
The spike was accounted for by an inventory scan process that involved all the desktops. “The [XP] array can handle it, but you lose some ROI going with more expensive storage,” House said.
We are also mentioned in a new VMware case study on VDI and there’s still that video…
Virtual desktop infrastructure case study: Metro Health
The storage issues that are more critical in a VDI environment include capacity planning and management and performance, as illustrated by a case study of early adopter Metro Health, an independent health care system serving the greater Grand Rapids area and western Michigan.
via Virtual desktop infrastructure tutorial: Part 1 .
A very excellent two-part article (though Metro is only featured in the first part) based on content from an interview I gave to SearchStorage back in February regarding our experience with VDI and the storage issues/expense we have encountered.
Storage VMotion is a nifty feature in VMware ESX 3.5 (it existed earlier but there wasn’t really any way to use it) for migrating a running Virtual Machine’s virtual disks from one SAN datastore to another without shutting the VM down. Previously the VM had to be powered off and then it was migrated from one server to another (or the same server) with the option of relocating one or more of its disks to a new datastore. With the release of the Remote CLI for VMware Infrastructure, there is now the perl script svmotion.pl (among others) to use Storage VMotion. The Remote CLI install & reference guide (PDF) indicates how to install it and get started but has some problems when doing command line arguments with the svmotion.pl script versus just running it in interactive mode where it always prompts you.
This is my first attempt at using the svmotion.pl script using command line arguments. I had a good experiene using the interactive mode with a different VM but I kept running in to problems trying to move a 2nd VM using the command line arguments. This is when using the RCLI installed on my Windows server that hosts VirtualCenter.
I was originally looking at the Datastore with the VM in VC to see where the VM and its VMX was located. I was incorrectly assuming that all the VM’s disks and config file were together on this datastore. I had to Edit Settings on the VM in VC and go to the Options tab to see that the Virtual Machine Configuration File was actually on a different datastore while the Virtual Machine Working Location was on the datastore that I was assuming held everything. Once I provided this correct datastore path to the VM’s VMX file, then it worked.
Also, I found that I had to format the –vm line with double quotes: –vm=”[Servers09] Delta/Delta.vmx:Servers00″ versus the single quotes shown in the PDF. I also had to omit the –password command since I wasn’t going to put my password in the command and wanted to be prompted. Omitting it causes it to prompt you. Including it with no argument makes the script complain about the formatting of the next option (in my case, the datacenter command). Here is my full command line for moving the “Delta” VM with its config file on “Servers09″ and a couple disks on different datastores consolidating everything to the “Servers00″ datastore:
svmotion.pl --url=https://sol/sdk --username=testuserÂ
--datacenter=VDC --vm="[Servers09] Delta/Delta.vmx:Servers00"
From there it prompted me for my password and then appeared to hang with no status bar like in interactive mode but checking in VC shows the task running and slowly moving to 100%.
Pretty cool stuff.