Disclaimer (Oct ‘09): This page is a popular Google hit. I assume that’s due to significant community interest in virtualization, esp. desktop virtualization. However, this post is now only of historical value. The market has changed. The products have changed. Altiris (now Symantec) has changed its positioning and strategy significantly since this was written. For current info on Symantec Endpoint Virtualization, visit Symantec Connect.

- – -

This article has been sitting in my Drafts folder for months. Between being very busy and SoftGrid becoming less of a competitive issue for us since the MS acquisition (and their subsequent demotion of it to a promotional tool), I haven’t really had the opportunity or motivation to complete either this or my promised open letter to Bill Anderson. But there’s some good info in here, so I figured I’d post it in raw form, with minimal updating for any factual changes since it was originally composed back in May or June. If I have already extracted out some of this text for previous posts, my apologies for the duplication. Enjoy.

- – -

I never got to the discussions on file system and registry redirection and file system and registry virtualization that I promised, so let’s visit those two concepts.

File System Redirection – For once, Wikipedia fails me for a definition. But file system redirection is a simple enough concept. It’s making stuff in the file system appear to be somewhere other than where it “really” is. The very concept of a file system is about making bits that are physically all over the place appear to be in some sort of order that they truly are not in. So in a sense, a file system is inherently “virtual”. But each file system — NTFS, FAT, NFS, NWFS, whatever — has some established convention about “where” a file “is” that it communicates up to the user and to the rest of the system. Redirection changes what the user and the system see as a file’s location, to something other than what the file system is saying.

Redirection can occur at the file-by-file level (like with SVS), at the directory level (e.g., UnionFS) or at the volume level (like the old DOS SUBST command). So it’s nothing new and it certainly is not specific to Altiris. In fact, as mentioned previously, Microsoft is doing file system redirection in Vista to better support legacy applications that want to write to protected system areas; see this. [Unfortunately, they are calling the feature "file system and registry virtualization," which is causing some customer confusion. But it is "virtualization" by my own definition, so we'll just have to do our best explaining the differences.]

At Altiris, we also do registry redirection, at the value level. This is something we often leave out in describing the SVS core technology, or tack on as an afterthought. “The filter driver does this, that and the other thing. Oh, yah, and it does the same thing for the registry too.” But we should be careful not to trivialize our registry redirection; it’s critical to being able to contain an entire application in a Virtual Software Package (VSP). And getting it right in SVS 2.0 was no simple task. As with the file system, registry redirection allows SVS to present registry keys and values wherever we want the system to see them, even tho they are actually stored somewhere else.

I mentioned that we call the core technology in SVS “Fortress”. Fortress is file system and registry redirection for the purpose of file system and registry virtualization. (Update: As of a couple weeks ago, the SVS implementation of this is patented technology.)

File System Virtualization – Sometimes it’s hard to decide what label to apply to a virtualization technology. Do you name it after the thing that is being virtually represented or the thing that is being fooled by that virtual representation? VMware, for instance, is sometimes called “OS virtualization,” but VMware doesn’t impersonate the OS — it impersonates the physical machine and fools the OS. The community has largely settled on the term “system virtualization” for that type of technology (tho Bob Muglia did call it “hardware virtualization” in his TechEd keynote). (VirtualIron, interestingly, can in fact do the inverse of VMware, which is why I show their logo a little lower in the stack graphic part way down this page.)

At Altiris, we call our approach “software virtualization”. But for the purpose of my stack slide I call it “file system” virtualization (with “software” in parenthesis). At the risk of confusing things, I do this because what Altiris SVS virtually represents — or impersonates — is in fact the file system (and registry). It’s the software (including the OS) that gets fooled. Either label would have been a valid choice for the product name. Regardless, what we don’t call it is “application virtualization“.

Yes, the term “application virtualization” has slipped through in a few places from Altiris in regard to SVS. Currently, the primary use case of SVS is for one VSP (Virtual Software Package) to map to one application, so it’s temping to call it app virtualization. [For example, a VSP for Adobe Acrobat contains all of the software (files and reg keys) that Adobe Acrobat consists of.] But Softricity and others have already defined that term to mean something else, and officially Altiris does not use “application virtualization” in describing our product.

One of the most frustrating parts of the current battle has been over terminology. Several blog commentors, and Softricity in their own competitive documentation, have expended a lot of key strokes explaining why SVS isn’t application virtualization, or “real” application virtualization. Uh… Yes, that’s correct. Thanks for the help.

I first saw this in a Webinar by Douglas Brown of DABCC on Nov 1, 2005 (archived here). The whole presentation was about the definition of application virtualization and whether or not the three products covered — Softricity, Citrix and Altiris — met the definition. The conclusion that Softricity is the only vendor to meet the definition was apparently meant to somehow imply greater value. At least, that’s how I interpreted it; otherwise the whole thing was a mere academic exercise not worth the workday hours of most IT professionals. I mean, you would expect a comparative Webinar like that to ultimately be discussing value prop and fitness to task… Right?

Well, there was no mention of value or fitness to task, and neither has there been in much of the subsequent talk of why SVS is not application virtualization. I’d like to appeal to some of the more aggressive SoftGrid advocates. C’mon guys — stop spending so much time talking about what you do that we don’t do and start explaining why it’s a good thing and when! There are compelling use cases for the SoftGrid approach. When we go to speak to customers about SVS, they often tell us what they like about SoftGrid and why. Surely they tell you as well?

(Update: Competitive documentation from the “other guys” has improved since the MS acquisition. We still don’t agree with much of it, obviously, but it’s focusing more on value prop and functionality relevant to customers and less on irrelevancies and FUD.)

The problem, of course, for customers, is the overlap in our respective value propositions. Both vendors (Altiris and, now, Microsoft) need to take responsibility for trying to clarify that overlap.