The Virtual Data Center

Ok, I was going to hold off on posting anything until I was back in the home office next week, but a post over at CNET by Jon Oltsik called “The real issue around server virtualization security” caused a minor ulcer eruption in my core being and I had to let out some steam.

First off, the good: Jon is correct in the 2nd half of the post that the primary threat today is virtual infrastructure management, and how to integrate virtualization into our existing physical data centers. Management is the #1 issue that’s keeping us from fully moving to a complete Virtual Data Center. Before we can virtualize everything in our data center, we have to guarantee that we can manage it just like we can today with physical resources. So yes, Jon did have something good to say.

But unfortunately this is outweighed by his complete incorrectness on devaluating the security risks associated with virtual platforms. He uses the argument that since there hasn’t been an exploit ever against a virtual environment platform then you shouldn’t worry about it:

Starting with IBM and virtual machines on the mainframe, there hasn’t been a single compromise at the virtualization operations layer that I know of.

This has 3 problems:

1. This is the exact same argument we faced 3-4 years ago with Web Application Firewalls (WAFs), and look where we are now. PCI not only includes a clause that specifically addresses WAFs but they’ve recently released a clarification document on what it means to use a WAF within the PCI guidelines. 3 years ago, that would have been unheard of, because we didn’t have press every other week about web application vulnerabilities. We do now, and of course everyone is cramming to install a WAF in front of their apps and we’re inundated with reports of identity theft via applications (in state or over the wire). Had those customers evaluated and been conscious of their risk up front maybe they wouldn’t have been open to all those SQL Injection and XSS attacks. Risk Management is all about planning, not reacting.
   
2. Yeah, IBM virtual machines on mainframes have been around for a long, long time, and there hasn’t been a public exploit since day 1. However, any homegrown hacker can’t simply download the IBM virtualization solution in 3 clicks and beat the hell out of it in her basement for 6 months just to gain virtual street cred. It’s a different time, Jon, and everyone has access to all three major x86 hypervisor platforms today for free (and with Xen, they even have source). And she knows that every enterprise in the world is looking at x86 virtualization right now so her addressable insecure market is limitless. There’s more incentive to hack VMware’s hypervisor than IBM. It’s simple hacker economics.
3. No compromise of the “virtual operations layer?” I would disagree, as I’m sure VMware, Xen, and Joanna would. Has there been a mass (or at least public) “ownership” of a major x86 hypervisor yet? No. Does that mean there won’t be? No. A comet hasn’t hit the earth and destroyed all mankind, but we still have people watching out for it.

Long story short, it is a disservice to tell the public not to worry about virtualization security threats. Is it a good idea to tell people it’s so insecure not to implement it? Absolutely not. But to tell people “Nah, it’s all good; there’s nothing to worry about with security. I’m sure it will be fine; these aren’t the droids you’re looking for” is just plain wrong. You should always be prepared, and aware of your possible threats and risk. And adding another processing and computing platform of any type to your data center does introduce a risk metric. Is more likely that someone is going to take down your data center through your hypervisor than because of a natural disaster? Probably not. But at least ake sure you measure that security risk and metric and don’t ignore it.

I’m headed out to take the VDC message on the road next week. This trip will be focusing on the business benefits of “Future-Proofing” the Data Center and blowing out the smoke that the vendors are telling customers today. The basic premise is to architect your Data Center and your long-term Virtualization plan around your applications, not around single-point virtualization solutions like OS virtualization and the hypervisor. I’ve been working out the kinks in my “VDC as a Service Model” presentation, and it’s almost ready for primetime, so it’s going to be nice to focus on the business benefit of the VDC on this trip and talk about what happens after you adopt the Service Model.

I’m sure I’ll come back with all kinds of stories, rants, suggestions, etc…

Sticking with the Cloud theme-of-the-week, I just read Diane Greene’s, President and CEO of VMware, comments over on Server Virtualization Blog about Cloud Computing. Yep, everyone’s talkin’ about it. Here’s the paragraph in particular that struck me:

Greene told the event attendees that the evolution of virtualization begins with users deploying VMs for testing and development, then easing into server consolidations for production environments. The third phase is resource aggregation, with entire data centers being virtualized, followed by automation of all of those aggregated workloads. The final “liberation” phase is cloud computing, Greene said.

Here are my two problems with this statement:

1. Phase 1 and phase 2 towards Cloud Computing are virtualizing Operating Systems. Ok, they’re the easiest part of the DC to virtualize and the most virtualized component to date, I’ll give her that. Then phase 3 is the entire data center being virtualized? That’s quite a leap. And then we just have to automate the VDC and “liberate” it and we’re there? What’s automated? What are we liberating? And more importantly, who says Cloud Computing is liberating?
2. Data centers are much, much more than just operating systems; we all know that. She’s basically lumping everything but the OS into “resource aggregation.” But what resources? What about all the other components in a data center? And of course I love how everyone talking Cloud today conveniently omits the network, which is (by definition) the backbone of Cloud Computing.

She’s basically saying “Create Virtual Machines, use them in production, then you’re ready for Cloud Computing.” Talk about your 30,000 foot view. If only it were that simple we’d all be passing packets in Cloud City already. But it’s not that simple.

And to disagree with her comments even further, I don’t believe that the virtual OS is going to be the driver to push people to the Cloud. I mean do we really care what the OS/platform is? No; we care about the Applications. I don’t want to issue a request to my Cloud vendor that says “I need SuSE v10 running kernel 2.6.25.4 with glibc 2.7 and…” I want to ask for Oracle with 10TB of available storage. Great. Done. I don’t care what OS platform (physical or virtual) they standardize on, I just want my apps to be fast, available, and secure. Cloud Computing is so interesting because it takes a good bit of the daily burden, such as OS management, off of ITs shoulders.

I know VMware has a vested interest to keep OS Virtualization at the forefront of the IT mind, but eventually even VMware will have to acknowledge that our data centers are very rapidly moving away from “OS Centers” and becoming “Application Centers.” But then again, the VMware Virtual Appliance Marketplace is up to ~1300 VMs; full operating system virtual images almost all created to distribute applications. If I want to test 10 apps, I grab 10 OS images. Seems silly if I’m just testing the apps.

Until the market tells them otherwise, I guess VMware will happily continue to think that ESX is a VDC-In-A-Box, the solution to your current virtualization problems, and the Golden Gate to Cloud Computing. Between this, Gerald Chin’s comments last week, and their half-baked storage I/O performance report today, what’s going on over there? My advice to VMware: Whatever you’re smoking, Just Say No.

Yesterday I answered the common question “Is the VDC another name for Cloud Computing?” where I pretty much said “Nope, CC is a service within your VDC.”

As an aside to that post where I discussed definitions, I later bumped into a post on Cisco’s Data Center blog where Omar equates Cloud Computing to cooking dinner. Now I’m all for analogies, but this one is a stretch. Just tell it like it is and don’t belittle the audience. And I can’t stand the term “Data Center 3.0.” Where was DC 1.0 and DC 2.0? I much prefer the idea of a Data Center Maturity Model allowing growth, rather than bottling the DC up into a fixed version that has to be rev’d like software (expect a post on this topic coming soon). Maybe I’m still stuck on Omar referring to the Cisco Disaster Truck as a virtualization solution, which has to be the worst case of using the term “virtualization” to get Google hits I’ve ever seen. What’s virtual about a truck that drives around carrying a completely physical data center? The wheels? But once again, I digress…

Today, let’s talk about the next question: What do I think about Cloud Computing? My answer is always the same; actually, it’s always two answers:

1. I Like It: Cloud Computing is a great thing for many reasons. It’s creating an accessible “compute” system for smaller companies that can’t afford to manage these workloads in-house. It’s propelling the idea that there is no physical data center anymore, and that you don’t need a physical data center with cable monkeys in order for your company’s technology assets to be successful. It’s becoming easier and easier to integrate into your existing computing resources. And probably the most interesting reason I like the idea of the Cloud? To some degree, it bridges the application people with the network/data center people. Cloud access and management is typically done through an API. Want to spin up a new OS image, then send a message to the API. This isn’t a skill shared by the more traditional NOC teams, so they’ll either need to become more application focused or bring in application coding experts as part of their team. This is a huge step in blurring the lines between the network transport silo and the application logic silo. It’s also the first step in turning the data center into a service.
2. I Don’t Like It: For all the reasons above that I do like it, I think those benefits only apply to a very small percentage of the market. They don’t apply at all to Enterprise customers and data centers. A national bank isn’t going to outsource its user-based computing resources to Amazon EC2, for example. There’s too much liability and basically too much data to manage. So I don’t think Cloud Computing and remote workloads, today, are appropriate for an Enterprise-class architecture. Much like virtualization in the data center 5 years ago, Cloud Computing is a playground right now; a place to test new ideas and start planning for tomorrow.

To me, the interesting question becomes “When will the Cloud start to make its way into the Enterprise?” When will the Enterprise begin building its own Cloud that other divisions and functional business groups plug into? So it almost becomes a question of productizing the Cloud. The first company to do that successfully will be in a very unique position. Whatever you want to call it - a platform, a framework, a fabric - I think we will start to see complete “cloud platforms” offered as solutions from virtualization companies in the near future. And I believe those solutions will be pre-packaged components of the existing and new Virtual Data Center technologies; the same components that Enterprises are using today, but they will come fully integrated, have a singular purpose, and be manageable (three of the key issues lacking from virtualization solutions today). This seems like an obvious place to start referring to this idea as Cloud City.

So down the road, if we do start to see the cloud making its way into the Enterprise data center, I think the two ideas will start to come together, and the cloud will bring with it extremely useful tools (such as management APIs) that will ultimately be incorporated into the VDC. And I think there will continue to be a market for outsourced Cloud Services that plays well with products for the in-house cloud platforms. Baby steps.

When I talk about The Virtual Data Center publicly, and during my VDC presentations, I typically get asked two questions: “Isn’t the VDC just Cloud Compluting?”, and “What do you (Alan) think about Cloud Computing?”. In this (Part 1 of 2) post, let’s start with the former: Isn’t the VDC just another name for Cloud Computing?

Short Answer: No.

Long Answer: I think the main problem we have today (you should know what’s coming by now) is that Cloud Computing as a term is way to generic and ambiguous to have any real meaning. And although there are services that specifically fall into the Cloud Computing realm, such as Amazon’s EC2 and S3, most people have a different view on what exactly Cloud Computing means. Dan Kusnetsky generally defines it as a webification trend migrating towards advanced networking and virtualization technologies. I think this is true to some extent (SalesForce.com is a great example), but it’s a bit limiting because it omits services that aren’t applications, such as storage and security, and it doesn’t wrap in the management API portion of the Cloud (see tomorrow’s post for more info on Cloud APIs). Craig Balding over at the newly-formed Cloud Security approaches it from a different angle and sums it up as a mashup of advanced data center technologies; a great definition, albeit one that’s slightly recursive.

I try to define Cloud Computing very explicitly without tying it to any single technology: a method for off-loading workloads to remote compute resources, outside the management domain of your current data center (in any format, be it physical or virtual). Cloud Computing can be a resource service for and part of the VDC, but Cloud Computing and the VDC aren’t one in the same. For example, Amazon’s S3 is a Storage Service that also happens to be a cloud service. You can have a Storage Service within your VDC’s management domain by using a SAN and a File Virtualization solution, or you can outsource your Storage Service to Amazon.

In a nutshell: Cloud Computing is basically renting computing cycles from a service outside your own domain, whatever that service is.

And along those “Rent-A-Resource” computing lines, you can begin thinking of Cloud Computing simply as a service role for the VDC (whatever that particular service workload or role is that you’re passing into the cloud). Then you can see where Cloud Computing becomes another resource available to you as part of your complete Virtual Data Center strategy. Just like you’re going to choose a hypervisor provider for your OS Service, you’re going to be able to choose options from the Cloud for all of the services within your VDC. You’ll have VDC services that are inside your domain and some that are outside.

And if you choose to push everything to the cloud, well then, I guess the Cloud is your VDC.

Part 2 tomorrow, on my opinions about the usefulness of the Cloud in general.

I sat down this afternoon to write a 2-part post on the VDC and Cloud Computing - how they relate, where I think they’re merging, etc - and realized I was basing a good portion of my opinions and arguments on the idea that the VDC is nothing more than a data center service made up of smaller services. Unfortunately I don’t think I’ve really addressed that model on the blog before, so no time like the present. So let me introduce the VDC Service Model.

As you’re probably already aware, the Virtual Data Center is made up of 8 unique virtualization technology groups, and each one of these groups provide a service to the VDC. You can read about these virtualization groups in more detail here, but the 7 types of virtualization services in the VDC are:

• OS Service
• Application Server Service
• Application Service
• Management Service
• Network Service
• Hardware Service
• Storage Serivce

NOTE: There are really 8 types of virtualization services in the VDC, but the 8th type, “Service Virtualization,” is actually the VDC itself.

The goal of each one of these virtualization services is to provide a manageable task (or “workload”) for the virtual technologies managed by each service. For example, when you need to spin up a new VM on your hypervisor of choice, you call the OS Service (your VM and hypervisor), the Storage Service (your VMDK), and the Application Server Service (your Application Delivery Controller that routes connection to your application). These services can be further clustered together to create macro-virtualization solutions. For example:

• Desktop Virtualization is made up of the OS, Storage, and Application Services
• Data Center Virtualization is made up of the OS, Network, Application Server, Storage, and Management Services.

What is a service? First off, don’t think SOA; “service” in the context of a Virtual Data Center is so much more than just SOA. A service is a system that simply takes input, processes that input, and provides output. Two slides from my MMS presentation explain it all (click for larger versions):

So let’s look at the Network Service as a real-world example. One of the resources within the Network Service is an IP address. When I want to start passing users to a new VM behind my load balancer, I need to know the IP address of the VIP/Virtual Server that the “outside” will see, so I call the Network Service IP Address resource with the external VIP attribute (the IP address resource can have limitless attributes, such as private IP, NAT’d IP, source IP, next-hop IP, etc) and I get back the external IP address I need. Simple enough? And each service has it’s own specific resources. Some examples are:

• OS Service -> Hypervisor type and location
• Storage Service -> LUN
• Hardware Service -> CPU Core ID
• So on, so forth…

The Virtual Data Center is a service itself made up of 7 smaller services, with each one of those made up of even smaller services, all the way down the line until the specific resource needed for any task is utilized. In our example above, the Network Service IP Address resource may have to call the Network Service DHCP resource in order to get the IP address.

So that’s basically the VDC Service Model I introduce when I talk what’s needed to move beyond the physical constraints of the data center today. If you’re up for it, let me know what you think.

I know analysts get a bad rap; a lot of people aren’t fans, to say the least. I typically don’t agree with that negative viewpoint. It’s been my experience that most technology analysts tend to actually be the experts they purport to be. I talk to a lot of them and am routinely impressed with their understanding of the markets and technologies I work in. A good amount of their criticisms come from their business model, but nothing in life is free. I would be more critical of analysts if they just gave away their knowledge; we all get paid for something (except my friend who retired from Google a few years ago, but that’s a story for a different day ;). But every now and then I do run into a comment from an analyst that’s just plain wrong and causes big problems.

Case in point: Gartner analyst John Enck’s comments over on SearchServerVirtualization re: Hyper-V and Xen. Here’s the quote:

Citrix has a strong working relationship with Microsoft, and Microsoft’s Hyper-V is built on the Xen engine, which makes the two platforms interoperable, Enck said.

Now I don’t know if the author mis-quoted John or if John really believes this, but the above just ain’t true. Hyper-V is not built on top of Xen nor are the two platforms interoperable or interchangeable. This is a rumor that’s been floating around for at least 8 months, mostly based on the MS XenSource announcement in 2006, and although the rumor is completely false, there is some overlap in their technologies. According to Chris Stirrat over at the SCVMM team, their plan as of Sept. 2007 was to include management support for both VMware and Xen with the Carmine SCVMM release. The key term here is manage Xen, not run on Xen. But even that hasn’t happened yet. SCVMM only supports managing VMware deployments; it does not yet support managing Xen.

I’m sure there was some development assistance that came from XenSource to help MS run Linux-based guests on top of Hyper-V. Xen is a paravirtualized hypervisor, meaning that guests must be aware that they’re running on a hypervisor. Hyper-V has also implemented a paravirtualization architecture. Paravirtualized Windows guests would be easy for Hyper-V since MS owns the host kernel, the hypervisor, and the guest kernel; paravirtualization makes complete sense if you own all pieces of the puzzle. My guess is that anything they got from XenSource has do with supporting non-MS paravirtualized guests on Hyper-V, which is why their Linux support is currently limited to only one distro: SuSE Linux Enterprise Server v10.

But John continues his downward spiral:

Thus Microsoft might be more likely to refer Linux-leaning prospects to Citrix than to, say, Novell’s virtualization technology because of Citrix’s additional features, he said.

First off, Novell’s virtualization technology is Xen. Second, what exactly is a Linux-leaning prospect? I’m sure that Microsoft would try to move all OS virtualization prospects over to Hyper-V; Microsoft doesn’t have a track record of referring anyone somewhere outside of Microsoft (and why should they). To be blunt, Citrix and Microsoft have always had a love/hate relationship: Metaframe/Presentation Server ICA and Terminal Server RDP; their joint Branch Office Box (BOB); Xen and Hyper-V. I can’t imagine Microsoft ever referring a customer to Citrix instead of going with one of their solutions. Is there room for technology overlap and sharing? Absolutely. But for MS to shrug its shoulders and turn over any customer that wants to implement Linux OS virtualization to Citrix isn’t going to happen. Virtual Server can run multiple flavors of Linux. SCVMM can manage Virtual Server, Hyper-V, and VMware. In the collective MS mind, there’s no virtual OS deployment that can’t run on or be managed by Microsoft products.

I guess my main beef is back to money. If a customer comes to John at Gartner asking which hypervisor solution should they deploy for their data center OS virtualization project, and John’s answer is “Choose Hyper-V or XenSource because they work together,” well that comment could end up costing the customer much more in the long run than just their annual Gartner subscription fees. Analysts are excellent authoritative resources, but always do your research, just in case one of them is a little off on their technical details.

Hot off the virtual presses, there’s an excellent write-up/interview over at Server Virtualization Blog on VMware and the cost of implementing VDI. Even with the numbers stated, I think Gerald Chin is still underestimating the TCO of a massive pave-and-nuke VDI replacement. It would be really interesting to see a complete TCO analysis and evaluation comparing physical desktop costs for an enterprise vs. virtual desktop costs, covering issues such as the following:

• Hardware (client-side and in the data center)
• Impact on the Network - re-pushing those images every morning isn’t free. What happens on the wire when everyone clocks in at 8:00 AM and requests their new image at the same time? Will you need to upgrade your switches and cabling, for example? Does your network team know you’re about to flood the building?
• Provisioning: In a typical local desktop model, if someone’s machine dies IT can just drop a temp one on their desk and they’re back up. What happens if someone’s VM image gets horqued? How long would it take to restore from backup? How often are they backed up?
• Speaking of backups, storing those images will definitely jack your price up. Again with the local model, you’re basically getting free storage with every system. With the thin model, storage happens on the back-end.
• IT/Help Desk Staff: Back to one of my tried and true big arguments against virtualization saving you money, IT staff now has to be able to troubleshoot OS problems locally, over the wire, on the hypervisor, through the VDI/Infrastructure, and in storage.

Like the Virtual Data Center, I’m a huge fan of the VDI model. I’d love to be able to bring my Vista or Mac machines into my local IT department and get their Gold Enterprise XP image and bring it back with me to my remote, not-in-the-HQ-city home office. Well, actually I’d much prefer to just stream Outlook and Office 2007 over my 8Meg broadband connection directly from HQ and have nothing but a local application hypervisor installed, but I’m willing to take baby steps. But I know that my IT department is weighing the cost and impact of the virtualization solutions before deciding if it’s advantageous. That’s all I’m asking: do the math yourself and determine if it’s economically viable before you take Gerald Chin on faith.

Oh, and for those keeping score, yes, I did catch his “All of the information is safe in the data center…” comment (as well as the security benefit title of the article itself). Beyond my PB&J getting lodged in my throat and his comment making my head explode, I thought I would stick to just one “Really?” response for today. Maybe tomorrow, if I can get through my lunch.

Well, I’m finally getting back into the routine of things after MMS last week, and what a week it was. This was my first trip to MMS and it was definitely one of the best (if not the?) conferences I’ve ever been to, right up there with various SANS shows. And props to having it overlap Interop, which gave it an excellent contrast point: small, focused show vs. large, all-encompassing show. I had a great time with my session, got some good questions, and already looking forward to next year.

There’s been a lot of talk about what MS revealed in their keynote and launched last week:

• SCOM Cross Platform Support: The ability to manage non-Microsoft platform. This is an excellent first step for building a complete data center management platform. They’re opening up their platform all of us that have heterogeneous data centers. I bump into an extremely small number of people that have standardized on one platform in the data centers, so this is officially a Good Idea(TM). And beyond the obvious, the fact that the *nix agents are open is another smart move.
• SCVMM Supports VMware: The big news from the show, although we knew it was coming from Rakesh. And if you combine this with an OpsMan agent, then you can spin up *nix images through VMware and manage them as soon as they come up. Very cool.

There’s obviously a lot of good that came out of last week for all of us, especially as we all tread down our respective paths towards building the true Virtual Data Center. However, it wasn’t all roses; there were some key pieces missing from the System Center suite. Chris Wolf sums up what System Center is supposed to do perfectly:

“System Center provides management of the entire software stack: application, OS, hypervisor, and hardware.”

Chris is spot-on about SC, but that’s not the entire software stack; the two key missing components are Network and Storage. And likewise, these were the two conspicuously absent categories from the keynote and announcements last week.

As I’ve said before (I actually think it follows “Good Morning” to my co-workers every morning along with my coffee;), data centers are built for application delivery. It’s great if you can manage the server and hypervisor running the apps, but if you can’t manage the applications as they go in and out of the data center then you really don’t have a complete software or data center management solution. And even though they brought in some extremely cool, necessary, and market-changing technologies to the SC family last week, they need to also bring in the network and storage (in front of and behind the app, respectively). Before you tell SCVMM to spin up a new image because your Sharepoint app is unresponsive, you need to know what’s going on with the network. Then you need to know what spinning up that new image is going to mean to the storage and network services. Are there VLAN issues? Can your new image access the correct portion of your iSCSI network?

Bottom line from the show: there was a ton of buzz around SCVMM in general and everyone was talking about how to use SCCM, SCOM, and SCVMM to create a complete solution. And those three pieces can provide a complete solution - build, monitor, manage, and deploy - if the rest of the application stack was part of the solution. Networking and storage are critical to all apps, and thus critical to managing a complete application delivery infrastructure. Now if you wanted to give the System Center + Network + Storage solution a name…oh I don’t know…say, the “Virtual Data Center”, then it would be ok with me.

Two Disclaimers:

1. This is nothing more than an “I’m catching up with a ton of stuff after two weeks off the grid and I’m tired” rant, so you’ve been warned.
2. I’m not in the habit of slamming things. Everything has a purpose somewhere. More specifically stated, one of my rules with technology is “Don’t blame the technology because of the implementation.” This is not a slam, just a frustrated observation.

I truly do believe that Parallels is onto something with their technology. Virtual containers are going to fill the void between full OS virtualization and straight application virtualization (app hypervisors, streaming apps, SaaS, etc). OS virtualization is usually overkill (although still good for what it does when it’s absolutely needed; remember, I don’t blame the technology… ;). Having a stripped down portable virtual kernel environment is going to be critical for applications that can’t run virtual-aware. Sure, initiatives like Oslo are going to great for excavate and rebuild applications, but we all know that those aren’t viable alternatives for most apps (goodness knows that’s true in the security market, which is why we have WAFs today). So containers (or kernel virtualization as I usually refer to them) are a good alternative. And Parallels, with their acquisition of Virtuozzo, are primed to lead that front.

However (and it’s a big however), they need to get their marketing and publicity ducks in a row. To me, a company’s website is the de facto place for technical information about their solutions. Let’s face it: implementing virtualization is a technical task, not a marketing task. When I want to find out how Parallels has implemented kernel virtualization with Virtuozzo, I expect to find that information on their site. When I want to know, in under 3 minutes, why I should choose Virtuozzo over ESX or Hyper-V, I need to be able to read it on my own. I’m a big boy, I can make my own decisions; I don’t need someone from the company to call me and explain it.

So what am I getting at (I’ve almost forgotten in my spun-up rant state)? Parallels has, IMO, mislead me twice now on what their technology does (or rather what their technology doesn’t do). Both of these events have stopped my testing dead in its tracks:

1. Virtuozzo Containers only runs on very specific Linux distros and Windows platforms. You may be thinking “hey, that’s no big deal,” and I would mostly agree with you. But they don’t mention that on their site. No kidding, I had to call them to get a list of which distros would work. To boot (no pun intended), they do a terrible job of separating technologies based on host platforms. I run a data center, I want to know what software will run on which host platforms immediately. I don’t have time to download, install, and try only to find out I have to repeat that process because they don’t document their running environment. Just tell me up front so I don’t waste my time. If you have to run on Win2003 because you own the kernel and you can’t run on Vista with 2003 support enabled for the binaries, or you don’t like the I/O kernel patch I installed in my RHEL farm, then just tell me.
2. Parallels Server Beta 4 won’t run Leopard virtually on a Win platform but will on a Mac. Ok, again, I’m sure there are good technical reasons for this. But for the love of all things holy, please don’t send me an email that generically says “now runs Leopard on Leopard!” and a link to download a Windows binary without an explicit explanation.

I can find a podcast on their site on how to protect my business in 3 clicks. Why can’t I find a quick list of what they do and what they don’t do, what they support and what they don’t support? What are they trying to hide? Sure, if I’m a Service Provider CIO and I tell my IT staff that I just head about this Parallels thing and want to find out if it will work for our customers, great. But I’m not. Like the IT staff, I dig through the weeds to test this technology, and after today, I think I’m done with Parallels. Fool me once, you’re fault; fool me twice…

Nothing gets me more frustrated than bad marketing; it’s not rocket science. They’re already fighting a huge uphill battle. Why do they sink to these levels?

And please remember: this is just one person’s tired and frustrated opinion. It’s entirely possible that in my excitement to test these new technologies that I glossed over some disclaimer text about platforms, but I know that Hyper-V requires Intel VT-x enabled to run, and that ESX won’t run on laptop SATA drives. How do I know? Because the vendors clearly state it in their marketing and on their websites. So when I build an ESX box, I make the correct choices from the get-go. Don’t make me jump through hoops and waste time to test your software; tell me how you work out of the gate. Otherwise I get frustrated and write a blog rant about it, although I still know how to be up front with disclaimers.

Tomorrow: My thoughts on the MMS keynote announcements.