Storage has always been a hot subject, especially in regards to VDI. One misconception that some people seem to have is that the storage requirements in VDI environments are so high that VDI would be a bad idea for most companies. Although I agree that the storage requirements for VDI are higher than for Terminal Server, I do not necessarily agree that this automatically renders VDI solutions cost-ineffective from the get-go. One reason for this is that VDI often gets implemented in environments that already have enterprise storage (SAN) in place. The second reason is that the storage requirements are not as large as some portray them to be. I’ve seen calculations based on 20GB of disk space per virtual desktop, which, in most cases, is a pretty high number. If you’re looking at VDI as a means to deploy Windows XP desktops, chances are 6-10GB per virtual desktop is more than sufficient to fulfill your needs. If you multiply that number by 500 virtual desktops, the difference is pretty significant. Another reason for my disagreement is that the choice of virtualization platform could very well dictate the storage requirements of a VDI solution. Parallels Virtuozzo Containers, for example, is inherently storage-optimized. Using this platform as the foundation for a turnkey VDI stack, you will dramatically reduce the storage requirements, making VDI very similar to Terminal Server (Quest and Parallels have an exclusive VDI partnership).
By no means am I denying there is ample room for improvement in the way of reducing VDI’s storage requirements. Needless to say, reducing these requirements will certainly yield higher ROI. At Quest Software, we have been keenly aware of this fact right from the beginning. That’s why we have been working very diligently to further extend the already rich feature set of our virtual desktop management solution with an image management solution dubbed CIMS (Common Image Management System) which we publicly announced at VMworld 2007. I would like to take this opportunity to talk a little more in detail about CIMS.
CIMS borrows on the concept of snapshot technology often found in vendor-specific volume management implementations. Snapshot technology is used by SAN and NAS vendors to create point-in-time snapshots of data stored on disk volumes. Snapshots are mainly used to streamline data backup procedures and speed up the process of data recovery. There are two main types of storage snapshots: copy-on-write (i.e., low-capacity) snapshot and split-mirror snapshot. Like copy-on-write snapshots, CIMS is based in part on the concept of creating empty indexes (aka. pointers) to a base volume (i.e., golden image), but without the need to implement a copy-on-write scheme.
Here’s how traditional copy-on-write snapshots work for storage backup purposes: the snapshot is created nearly instantaneously by creating an empty index holding the original values contained in the base volume. Typically, the base volume is quiesced during the snapshot creation phase so that a stable image of the moment in time is available. Whenever data in the base volume is updated, the original data is automatically saved to the snapshot. The snapshot is actually “seen” by overlaying (combining) the base volume data with the snapshot containing original data changed in the base volume over time. As such, the snapshot gives an accurate image of the data at the moment the snapshot was taken.
Figures 1 and 2 below illustrate the index states before and after base volume data have been modified. In short, the integrity of the point-in-time snapshot is preserved regardless of these changes.
Figure 1. The point-in time snapshot index reflects the state of the base volume at the time the snapshot was taken.
Figure 2. Changes made to the base volume do not impact the integrity of the point-in-time snapshot.
Like copy-on-write snapshots, CIMS relies on the presence of a base volume (i.e., a golden image containing an operating system and installed applications) serving as a basis for creating an arbitrary number of snapshots. These indexes can then be presented to the virtualization platform as individual logical disks (or LUNs), depending on the virtualization vendor’s terminology. Finally, because CIMS requires the use of a read-only base volume, there is no need to implement a copy-on-write scheme. In effect, the snapshots themselves, not the golden image, are writable.
Figure 3. Changes made to the base volume do not impact the integrity of the point-in-time snapshot.
Although we’re working to offer multiple flavors of CIMS, here’s how we are currently implementing it in conjunction with a major snapshot-capable storage provider:
- The broker interfaces with the storage management system using a published SDK (i.e., Web services interface, command line interface, SMI-S, etc).
- The Broker requests a new writable snapshot (i.e., logical disk) be created from a specific golden image (i.e., the base or parent image).
- The Broker creates a new diskless virtual machine by interfacing with the virtualization software (i.e., VMware ESX, Microsoft Hyper-V/SCVMM, Virtual Iron, etc) using its published SDK.
- The freshly created virtual machine will PXE-boot and attach itself directly to its corresponding logical disk using the boot-from-SAN iSCSI initiator.
- Upon power-on, the OS customization process is started in order to assign the virtual machine a unique identity (i.e., unique attributes including name, SID, address information, etc). Upon completion of the customization process, the virtual machine is ready to be deployed to an end-user.
- Upon power-off, the broker may optionally request that the virtual machine and associated disk be respectively destroyed by the virtualization software and volume management system.
Watch Provision Networks closely this year to learn more on the Provision Networks approach in dealing with the storage requirements of VDI.
You can leave a response, or trackback from your own site.
July 3rd, 2008 at 5:00 am
Great article, the question is when? Since Provision is already running more than 3 months late with the 5.10 release when will this come 5.11, 6.0? Also will it form part of the core product or is it going to be another license to get this functionality?
Of the topic but relevant: Since PN is supporting Hyper-V in 5.10 does this mean that you now also support Windows 2008 and x64 for TS environments like you do get with Citrix?
July 3rd, 2008 at 5:12 am
Hi Louis,
It will not part of 5.10. We have not decided on licensing yet.
Supporting Hyper-V is very much different from support Windows Server 2008 Terminal Services. Support for Windows Server 2008 Terminal Services is slated for a future release.
By the way, the versions of Presentation Server that you can buy do not support 2008 yet, correct?
July 3rd, 2008 at 7:38 am
Thanks for the update. XenApp supports 2008 TS. So customers buying new or upgrade can do so. I dont understand what the problem is with supporting x64 it has been around for 2/3 years and still with Provision one cannot even do TS x64 on Windows 2003.
July 7th, 2008 at 4:36 pm
Support for X64 was delayed due to lack of interest, and interest from customers in higher priority features (mostly related to VDI). As of 5.10 we support X64 on the connection broker, database, Print-IT & Web-IT servers. we also support X64 for the data collector on TS. What is now being tested and validated for X64 is seamless windows and our power tools, i.e. user profile management, desktop configuration & lockdown… It’s not been that this is so difficult, but that there have been other features that have been requested by larger customer populations. X64 is now a priority so we can support Virtuozzo Containers.
July 7th, 2008 at 9:25 pm
It’s true that we’re overdue for x64 support. As you may already know, 2008 is a special year in that it brought about not just the need for x64 support, but yet another version of Windows, namely, WS08. Moreover, we now have to deal with not just TS, but VDI as well. When you think about it, that’s 8 different flavors of the OS that can potentially be hosted: Windows XP, W2K3, Vista, and WS08, all of which can be either 32-bit or 64-bit. This is not to mention that W2K3 and WS08 have to be supported in either TS mode or single-user (VDI) mode (yes, some customers may want to use W2K3 or WS08 in single-user hosted dekstop mode).
Worse, Vista’s architecture as it relates to the GINA and Winlogon constitutes a significant departure from XP/W2K3. For example, most of our features rely on Winlogon notifications. These notifications, such as Logon, Logoff, Connect, and Disconnect, are absolutely essential. For example, when a user logs on, a notification is sent to the universal printer subsystem to start auto-creating client printers. The same goes for launching a published app or loading the user’s profile, etc. Because Winlogon notifications no longer exist in Vista/WS08, we had to devise an alternative approach, whicg we did. We’re now able to load the same notification DLLs under either XP/W2K3 or Vista/WS08.
To make a long story short, we’re pretty darn close. Expect it soon.
Peter
July 8th, 2008 at 2:13 am
Patrick / Peter, thanks for the updates. The x64 issue I was referring to more specifically was in a TS environment. I don’t really see the need for x64 support for any component apart from what runs on the TS server as this is where the greatest benefit lies. Also I don’t see the need for supporting XP/Vista on x64 as users with such a requirement from a VDI perspective will in all likelihood have PC’s dedicated as such, i.e. CAD users.
Patrick, the connection broker comparison document you did how accurate is the features set for 5.11 and the time frame of delivering such? My personal opinion is that only from 5.11 the product will be ready to a great extent for VDI adoption as many of the features you are referring to is a requirement to make VDI viable. Is Q3 still the due date since 5.10 is more than 3 months delayed already?
Another critical area that needed to be addressed is the inclusion of Virtual Iron compatibility within the connection broker. I know that Virtual Iron is supported but one needs to run scripts that I received from Stephen Yorke to do this, and this is not mentioned anywhere. It seems that VMware gets all the attention and I think Virtual Iron is better suited especially in the mid market sector. If the integration of all the hypervisors can be integrated and automated as much as possible it will greatly assist at implementation time.
Lastly and probably the most important is the JAVA AppPortal client with support for local sound, usb and printing.
July 8th, 2008 at 2:31 am
If you look at the “current” broker comparison, I made changes to timelines some time ago, as the document has been updated several times. As for the “3 months delayed”, I’m not sure where that number came from. Our original target was the end of may, as we showed a pre-release the first week of May at MMS. From the end of May to now is less than 2 months, which in dev & QA time is a blink. We historically have released two point releases each year, and that will likely continue to be the case, but with additional interim point releases as new features are added that don’t rely on bits that are still in development.
se thin
We will continue to improve our non-Windows clients, i.e. Java, Linux, and Mac when the market demands it. Features are however driven by paying customers, and staying ahead of the competition, so we always have to weigh these things. For a formal roadmap discussion, please contact us offline, as a blog is not the appropriate place.