I had discussion with Richard Garsthagen during the Dutch VMUG about View/VDI related blogs, or better said the lack of. It appears that desktop is a topic bloggers are avoiding. The weird thing about it is that in the industry View is picking up more and more.
Yes there are a couple of bloggers out there who are focussing onView like my colleague Christoph Dommermuth but compared to the “core” product their share is tiny. For me personally there’s a simple reason you don’t see me blogging about View, it’s not part of my focus area.
Something I overlooked during the discussion are the two excellent whitepapers/articles Herco van Brugh wrote. The first one is a brand new whitepaper and discusses how to correctly scale your storage based on a couple simple formulas.
- Download whitepaper here. (NEW!)
Virtual Desktop Infrastructure, or VDI, is hot. It’s cool, secure, centrally managed, flexible – it’s an IT manager’s dream.
However, as it turns out, there is a hidden danger to VDI. There’s a killer named “IOPS”. - Creating a VDI template
This guide is based on Windows XP because of its low resources usage compared to Vista and even Windows 7. The general idea however also applies to those versions although specific services and registry keys will most likely not work. Skipping Vista, the next version of this guide will focus on Windows 7.
Another thing I overlooked when I was doing a little research were the Reference Architectures EMC did. There’s some good info to be found in these. So it seems that there is info out there, I guess the “problem” is that there are only 1 or 2 bloggers who are solely focusing on View. So if you are a VDI/View Consultant now it is time to speak up. Step into the world of blogging and let your voice be heard!
Chad Sakac says
Disclosure – I’m an EMC employee.
Duncan – it’s a bang on topic. IMHO, View blogging is rare because VDI architectures in general are complex (the end-to-end picture) and very, very variable (workload type, client type, connectivity type, connection management type, virtualization layer config, storage type/config all vary wildly).
The first whitepaper nailed a core issue (there are many that are in a design) – the IOPs challenge. People don’t naturally think about it:
– Q: How many hard drives do 1000 desktops have? A: 1000.
– Q: will you use a shared storage (FC/iSCSI/FCoE SAN or NAS) config with 1000 drives? A: of course not.
There are loads of things that help, but that paints the problem in a way people seem to understand.
Things that help:
1) duty cycle of desktop (not everyone does the same thing at the same time
2) cache architecture of the shared storage array buffers burst writes, and does some read caching (but in the end, you need to commit the write volume, otherwise write cache is guaranteed to overflow, no matter what)
3) the VMware and storage layers do some coallescing of IO
4) you can mitigate boot effect through a variety of means (both at the connection manager – eg. VMware View can stage client boot/logon behavior
The author of the first whitepaper also was bang on – initially we expected 90/10 read/write mixes at customers, but in practice we’re seeing 50/50. Big read caches help, but cache helps with cacheable reads, and protects you against bursts – your storage needs to be able to “sink” (drain the write cache) the sustained write IO workload.
There are several very important things you can do to mitigate extra guest IO:
1) guest OS alignment is important, and reduces extra backend IO.
2) avoid vswap at all costs in this use case. People think that using memory density will be their bottleneck in the economic model. It can be, but just as often its the storage. in general configure guest mem = reserved mem.
3) avoid guest-level swapping if at all possible (don’t undersize the amount of configured VM memory) – follow the guest OS guidelines.
4) any time you are able to move the user data (“my documents”) out of the guest and into a NAS device, it’s a huge win (in many dimensions). This is not an option for some user use cases (for example, doesn’t work easily on “check in/out” use cases).
5) Disable automated AV updates
6) Disable boot optimization
7) Disable system restore
In my experience (and my team’s experience) working on many VDI projects (with all sorts of configs) – at larger scales, this problem becomes very hard. Seeing some customers deploy Atlantis (and similar approaches) – though these break the encapsulation model (everything is a trade-off).
On the EMC side, we think that EFD (enterprise-class solid state) is an important part of the answer. The author of the whitepaper is right in terms of the consumer SSD life, but there are enterprise SSDs which can sustain the same duty cycle and lifetime of any enterprise magnetic media. Over time, this will apply even to consumer SSDs.
BUT – they are not currently a simple answer – as with View 4, currently you can’t put a base replica on one datastore, and the linked clones on another. This means you would need to use EFDs for the entire datastore, which is not scalable.
We’ve used all the methods above in the current View 4 VMware/Cisco/EMC reference architecture to get to a $750/client end-to-end cost (everything – including Microsoft VECD licensing, but it doesn’t include the client hardware).
To try to make the economics even better, we’re working on a couple things:
1) vStorage APIs for Array integration – “hardware accelerated locking” – this will help with VM density per datastore.
2) FAST v2 (block level autotiering) will enable a datastore (on NFS or VMFS) will help in the sense that a datastore will be able to be “blended” with EFDs supporting “hot” blocks/portions of files, and large, slow SATA/SAS being used for ones that are “cold”.
3) Future versions of View have some things that are explicitly targeted to help with this.
Great post!
Andrew says
Duncan – Agreed with the article.
We bought View Premiere. This provides enough infrastructure to run concurrent desktops and ThinApps. All good, but try finding anyone actually documenting or sharing where they are with their installations or pilots: good luck.
We are using SSD drives in an Openfiler server as an iSCSI target for the desktop VMs. (Actually got up to 1450 IOPS in XP SP3) Doing linked clones for the VMs. Using PCoIP in software, but still waiting for hardware version to show up in market. Use of AutoIT to provide system stress testing and sharing results. Mixing roaming profile with folder redirection with User Experience management tools. Collecting business impact to determine if there is a positive business case. All topics that are not discussed in forums or blogs.
Where do you start blogging or sharing?
Dave B says
“it’s not part of my focus area.”
I suspect that’s the real answer behind any lack of blogging. Desktop support is a completly different world that has unique pain points. Off the top of my head:
– Desktop provisioning time
– End user support
– Application delivery
– Realtime / multimedia performance
– Harder to quantify any cost savings (desktops have more exceptions, more soft costs)
Interestingly, the MSDN terminal services blog (http://blogs.msdn.com/rds/) is mostly VDI these days. Maybe it’s the old school TS guys that will push VDI forward?
Sven Huisman says
I totally agree with you, there are way more Infrastructure Virtualization bloggers than Desktop Virtualization bloggers out there. But then again, there are also more Infrastructure Virtualization implementations then VDI implementations.
My own blog at virtualfuture.info, which I share with some friends, became more VDI-flavoured this year, but because of the variaty of bloggers, the focus of virtualfuture.info remains Virtualization in general. Therefore I decided to start a new blog-site which will be dedicated to VDI: Desktop and application virtualization.
So as an answer to your last phrase (“Step into the world of blogging and let your voice be heard!”), my new site will be launched in January.
Anykey says
Just registered desktopvirtualization.info 🙂 so might start a pure desktop virtualization resource site / blog as well 🙂