VDI issues: How to use SSD to improve performance
A comprehensive collection of articles, videos and more, hand-picked by our editors
VDI vendors push the technology as a way to simplify management of desktops. VDI expert Brian Madden argues that there are myriad problems along the way to simplified management and, in the end, you don't need VDI to accomplish it. In this video, Madden explains how VDI storage performance issues are handled by putting a single VDI image into SSD or cache. He also describes why that practice doesn't mitigate the fundamental trade-offs required for simplified desktop management. Watch the video or read the transcript below.
Madden: [VDI vendors] push VDI as easier to manage. When they push VDI they'll say, "Oh, you just manage one image for all your users -- or non-persistent images, or shared images – [and] all the users are going to share that same image." And that's easier to manage. You've got 1,000 users. What would you rather manage? One thousand images or one image? I think I would rather have one image. Of course. With VDI we can do that. That's cool. So let's dig into this. Let's say that this blue box is my VDI host -- it's like my ESX server or whatever. I'll throw eight desktops on there just for ease of illustration. Eight desktops, eight hard drives, eight VMDK files or VHD files. Every user has his or her own hard drive; this is theoretical. If we had eight VMs, this is what we're looking at, right? Well, if I want to share images, I've got this one hard drive. Now, let's imagine I want all eight of those to share this one image. That's where we're starting to talk about the savings. So, I'm sharing that one image. Of course, I can't literally have all these machines mount the same image because Windows wants to own and lock that image. So, we mark that central image as read-only, and then all the delta [differentials] (the block-level differentials that the user writes) just go somewhere else. And every VM has its own delta differential. VMware has Linked Clones; there's [NetApp's] [Flex Clones]. These things all work basically the same way, right? So I've got a central read-only image, and all of my users have their own tiny little slivers of the changes that they happen to make themselves. And that's cool, because if I take a look at [that] base image plus all those little slivers of changes, that's way less than if all my users had their own complete, full images. So, that's cool; from a capacity standpoint, I like this, right? And [for] people selling VDI, this is their slideware, so it's cool. So, VDI is good for capacity. Sharing images is good for capacity. That's nice.
In this case, we have all of our users who are sharing that one read-only copy, that one master copy, and that thing gets hotter and hotter and hotter until it overheats, slows down [and] causes all sorts of bottlenecks. So, we've got a potential problem with this because we like what we can do for capacity, but we're sharing that master image, and that's tough for performance.
Now, again, the people selling you VDI [say], "Hang on." They talk about the movie 300. How many people saw that movie? In [the] movie, you know we have 300 soldiers who defend against tens of thousands because they were able to channel them through a valley, and they knew exactly where they were going to attack. So, if you know what the problem is going to be, you can marshal your resources and make it happen. Hey, that's kind of what's happening here, right? If I know that that read-only image is going to be shared by everyone, I can do all sorts of cool things like put it in SSD [or] put it in one of those DRAM-based solutions, right? RAID cache might handle that automatically. Heck, even NTFS cache will kind of handle this because [it's] read-only. … Read-only is super easy to cache. We can cache reads. I can put that whole thing in cache, so that's nice.
More on VDI image management
Stream applications with a VDI image
Disk streaming for single-image management
Tweaking VDI golden images to improve performance
OK, so now I've got my story. I'm less on capacity, I can take this read-only, white-hot area that everyone wants, throw it to RAM or RAM cache, and now my VDI is looking pretty good. So, of course, this is the Day 1 picture. Now, what happens over time as the user does more stuff with their C drive? What do you think? The users are installing software, putting hot fixes on there … whatever they're doing. So now, they've got more stuff they've written and more stuff gets added. That little sliver that they had -- that was a small, little sliver -- starts to grow a little bit, and our balance is not quite as cool as it was before. Then a service guide comes out, then a new version of iTunes comes out, then a new version of Chrome comes out six weeks later. And now, these little slivers are even bigger and we kind of have an upside-down equation. So now, not only are we getting screwed on capacity because all these little, individual sections are getting bigger and bigger, but also, our cache is no good. Remember, the real thing we're focused on is performance. If I have [Microsoft] Office installed, that's my base image that everyone is sharing, and with every single user session they all install a service pack to Office that's replacing all those files and dynamic link libraries (DLLs) that are not needed anymore. Those blocks are redirected into every single person's own sliver (into their own delta file). So now, all that cache, all that work that I did to put that read-only copy in cache, [is] not going to work. And now, I start to [freak out] because I had this VDI, I sold it as being awesome, I want everyone to use it, it's supposed to be cheaper, [the] cache isn't working, the hard drives are too big, and I think, "This is not working at all."
All those changes went into that little sliver that grew and grew and grew -- let's just take those changes and put them back into that master image. [It would be like cracking] open that master image, [resealing] it, and now we have a new master image that has all those new changes. And then, we just create a brand new sliver for each user. And now, [we're] back to where we were in the beginning where we have that one master image and all those little slivers per user, and I only had to manage one image. Nice. VDI, managing one image -- I like that.
This is where the vendor presentations typically end, by the way. Because the problem is that one master image. Remember our users? Well, what did they write? When their own slivers got bigger and bigger and bigger, what were they doing in there? They were putting applications, and colors, and changes, and settings, and apps, and data, and iTunes, and music, and configurations, and drivers and all this stuff, right? So that environment when we were starting to cry was looking like this. And then, we said, "No, we can recompose." But no, when you recompose, you take a read-only master copy and crack that open; you invalidate all those little slivers. You throw those all away.
… So the people selling VDI [say], "No, you've got it wrong, man. You're just trying to make people mess up and throw out FUD." [This is] the way you do it: [The] read-only copy is shared and … you take that and wrap that up and call it the OS. You don't put any user changes into the OS. You just do the domain memberships and the technical stuff. And then, you take all the user settings and just redirect them somewhere else. Let's call that "user data." Give it a D drive, [for example]. You can go into Windows policies and [designate the] desktop [as] the D drive and [the] documents [as] the D drive. And you're redirecting the home folders, and all this kind of stuff. And, if I do this, that means that I can take my OS, crack it open, add new service packs; I can change my OS and the user data doesn't change. And I can do it again, and the user data doesn't change. So, see what we've done here? We've basically locked down the Windows copy -- say, "Users don't touch that; we'll just redirect everything you do into your own data disk," and that's how we have single-image management. And that single-image management is way easier than the old environment.
So, think of all these great benefits of single-image management: the benefit of a shared-based image. That's awesome. We have the benefit of locking down the desktop; that's awesome. We have the benefit of taking away users' admin rights; that's awesome. We have the benefit of no user-installed apps; that's awesome.
Sharing a base image, locking down a desktop, taking away admin rights, no user-installed apps, all users are the same [and the desktop environment] is easier to manage? Absolutely, yes. Hell, yeah, it's easier to manage. But is this easier to manage because of VDI? No. It's easier to manage because we don't allow users to install their own applications. It's easier to manage because we took away users' admin rights. It's because every user has to be identical. The thing is, this is way easier. But this is really hard to do. Like, really hard to do. Because let me tell you, you don't need VDI to do this. If your desktop computing environment allows your users to not have admin rights, to all have to be configured exactly the same, to have all your software virtualized -- if that worked in that pristine way, you would have been doing it since 1985.