Nov 14
Three Things You Should Know About VDI (Part 1)
Jason Cooper
I’ve been a C/D/H consultant for three years. I have the dual distinction of being both C/D/H’s first Southeast Michigan consultant AND our first VMware Certified Professional. I’ve done such a stellar job at both that we’ve grown both the Royal Oak office and our virtualization practice. Specializing in desktop management and virtualization, projects involving MetaFrame or ZENworks or VMware expose me to almost every corner of the enterprise, from messaging to networking to collaboration.
Technology is what I work at. Family and music are what I work for. In my copious spare time I enjoy gardening, camping, and cycling. I play guitar and a little harmonica, sometimes simultaneously. It occurs to me that I could duct tape a tambourine to my knee, but that would just be too weird.
More about Jason
Articles by Jason Cooper
Everyone is talking virtualization. Most enterprises have adopted VMware in some form, for testing or production server consolidation. The new buzzword is VDI, or Virtual Desktop Infrastructure. (Read all about it at http://www.vmware.com/products/vdi/.)
In this model, client workstations are virtualized; meaning virtual machines are deployed as Windows workstations. Using a remote access protocol (like VNC or RDP) client connections are brokered through the Virtual Desktop Manager. A user logs into a client device (ANY client device) and accesses the same Windows desktop.
If you’ve already invested in VMware Infrastructure 3, you know the price tag can be steep. You can host up to 40 virtual machines on a single ESX server. You need a SAN or iSCSI NAS device. You’ll need network infrastructure and thin client devices. The initial cost may be greater than that of deploying new workstations. The cost justification for VDI is in the long term cost of owning Virtual Machines running your desktop operating system vs. physical boxes running it.
The purpose here isn’t to sell you on VDI, or Virtualization in general. This series of blog entries is intended to dispel a handful of misconceptions about the solution. These are based on real-world experiences and conversations with clients and peers.
First on the Agenda is your network infrastructure. The misconception: “Once I deploy VDI I won’t need nearly as many Ethernet switches or IP addresses.”
Don’t laugh. It’s REALLY bad for a consultant to laugh in the client’s face. Anyone that ever ran a thin-client device for Citrix or Terminal services sees the flawed logic in this statement.
YES, the VDI desktops connect to virtual switches defined inside of VDI. YES, the traffic between the virtual desktops and any server running in VMware is hyper-fast; it occurs virtually, not using “real” switches. YES, the network traffic being delivered across the wire is very light—basically keystrokes, mouse clicks, and video (audio, maybe…..but that’s another blog).
Not only will replacing a physical desktop with a VDI enabled thin-client not reduce the number of Ethernet ports you host, you’ll double the number of IP addresses you need. If you have 100 physical machines today that you migrate to 100 virtual desktops, the replacement thin-client devices still need a network connection and an IP address. Don’t look to save money with VDI by downsizing the number of physical ports on your network. On the up side, VDI could delay or eliminate the need for a costly upgrade to GigaBit Ethernet.
Next time, I’ll share more truths about VDI deployments, and why best practice is still best practice whether the desktop is physical or virtual.
From http://www.vmware.com/files/pdf/vdi_datasheet.pdf (VMware Virtual Desktop Infrastructure Product Data Sheet)
Update: Part 2 was published on Dec 1, 2008! (http://www.cdhtalkstech.com/2008/12/01/three-things-you-should-know-about-vdi-part-2/)
Update: Part 3 was published on Dec 12, 2008! (http://www.cdhtalkstech.com/2008/12/10/three-things-you-should-know-about-vdi-part-3/)
December 14th, 2008 at 11:49 am
I didn’t see this mentioned in this or the other parts of this series, but in my opinion, the STORAGE is the number one point to consider when planning or managing a VDI deployment. Most places considering VDI or VMware in general should have a decent network (I would hope) but when it comes to storage, VDI becomes an I/O beast that no one considers. Storage infrastructure has to be the number one consideration for any VDI deployment because everything relies on it.
Jason Cooper Reply:
December 18th, 2008 at 11:44 am
Storage used to be a bigger issue (and boy has it been aired out…), but VMware View is taking huge strides towards addressing that.
One of the most exciting new features in VMware View (the heir apparent to VDI) is storage reduction in the View Composer. Check out this blog from VMTN (http://blogs.vmware.com/vmtn/2008/12/view-composer-.html) and the information guide for VMware View Composer (http://www.vmware.com/files/pdf/View_Composer_wp.pdf). In a nutshell, you can link multiple Virtual Desktops to a single (per LUN) clone source, only maintaining delta’s for the purpose of storage. This might reduce storage requirements for VDI as much as 90%, depending on LUN design and server configuration.
chouse Reply:
December 18th, 2008 at 12:21 pm
Indeed, but a capable storage architecture is critical especially with View3 because now you’re introducing vmfs metadata locking to expand snapshot deltas and this can be worse than standard VMs during a period of heavy I/O across all virtual machines. My original point is that storage design is the most critical part of any VDI deployment, especially with larger enterprises.
Jason Cooper Reply:
December 18th, 2008 at 2:25 pm
Your point is well taken. The storage requirements for ANY virtualization deployment are critical. I have worked in environments where the vendor pre-allocated an entire SAN with 256 GB LUNS (easily addressed, thanks to the VMware team and Storage vMotion). I’ve worked in enviroments where the policy was to have one VMFS LUN per virtual machine. I have seen SQL run with RDMs, I’ve seen it using VMDK disks. We’ve deployed Exchange server with both RDM and VMDK as well.
What is most important is storage manageability. Avoid any “cookie cutter” approach that makes hard, fast rules. Education and awareness about what VM loads are memory intense, which are CPU heavy, which require fat network pipes, and which have high disk reads and writes is always important. Both your storage infrastructure and your VM management team need to be flexible enough to mold to the needs of your particular enterprise.
Especially following the release of VMware View, I would say that the requirements for storage design particular to virtualizing desktops isn’t substantially different than virtualizing servers. Distributing disk load, optimizing high speed fiber infrastructure, avoiding iSCSI and SATA for heavy I/O VMs, and effectively allocating SAN storage need to be built in to your VI3 datacentre long before the first VDI/View VM is deployed.