I've been voraciously reading articles about the financial services meltdown and wondering about the implications for IT. I am interested in the seeming certainty by which organizations believed they understood risk, contrasted to the degree they actually understood it. Some may argue the root cause was not poor risk management, but rather a black swan event that nobody could have foreseen. In either case, the results should be instructive to anyone that is concerned about risk.

How many companies believe today that they have a handle on their IT risks? What are the unknown unknowns that may negatively impact existing assumptions?

One of the core questions I am interested in exploring is how to manage risks that cannot be easily measured, especially those that are hard to identify without the benefit of hindsight. It may be straightforward to determine the economic impact of an application outage. It is the likelihood of such an impact that can be challenging to determine. How do you know how much to invest without knowing both of these values?

And if it is challenging to evaluate the likelihood inside your environment, with known resources and processes, it is likely even more difficult for resources that are outside of the organization’s control, such as those running in a “cloud”. One can argue that the cloud can decrease risk, because resources are being managed by an organization that ostensibly is expert in running datacenters. One can also argue that the cloud increases the likelihood of unanticipated events, if only because there is less visibility into the provider’s risks.

Most current IT organizations assume things will fail, and remediate according to application priority. In this model, it sometimes feels like some applications are overinsured and others are underinsured. It is important to consider how to leverage new technologies, including cloud, to help manage risks (and maybe with less costs) ... because most of us don't get to walk away from the mess made by miscalculating risk so easily.

I've been reading the hype on the recent Citrix move to make XenEnterprise free and have been left scratching my head asking, "Where's the beef?"

First, I've always wondered about a product with Enterprise in its name that is designed for a single user, has no logging of user actions (who deleted that virtual machine?), and other missing features.

Second, I am puzzled about the analysis of "Free". If a customer has to pay a similar amount for support as they were paying for product, how is that free?

All this talk of free and commoditization appears to be designed to distract from the facts that the product will not really be free, and much of the needed enterprise fuctionality is moving to a new management platform, called Citrix Essentials, that will retail for $1500-5000 per server.

So at the end of the day, it looks like Citrix is finally pricing XenEnterprise at its true value. And providing the management it should have built in the first place, at a price greater than its competition. Where's the news in that?

Storage is one of the most critical (and potentially frustrating) aspects of virtualization. Virtualization and other data center initiatives have led to storage growth rates that continue to climb, by some accounts at an average 22% per year. While technologies such as thin provisioning and data deduplication attempt to throttle this growth, IT may be ready to look for ways to reduce the amount of storage they have to manage in-house, and thereby reduce power, space, and other costs.

The cloud may help.

Angelo Rajadurai from Sun put forth one of the most provocative ideas I've heard recently. He first reminded us about the various storage attributes we care about: capacity, latency, IOPs and cost. He then proceeded to break down various storage options: local drives, SAN, and cloud.

Cloud for enterprise storage? OK, maybe for backups and archives?

Angelo suggests for an active storage tier. And why not... if you can track the frequency of reads and writes, and your SAN can automatically move blocks between different storage tiers, why not push those less frequently used (but still “active”) blocks to a high latency / low cost outsourced provider?

It’s not too hard to imagine integrated backups and restores as well. Could cloud storage be the first platform to be broadly integrated with internal IT?

I recently read The Tricky Math of Server Virtualization ROI ... tricky math, indeed. The position that customers with less than 20 servers are better off doing a hardware refresh than purchasing server virtualization is dead wrong on an economic basis. At least the author acknowledges, "But given the many benefits of server virtualization -- notably business continuity gains -- the virtualization route is a wise choice."

First, I'll be open about my biases: Virtual Iron sells virtualization solutions to the SME. We've been very successful in this market segment, and economics matter. You can see some of our case studies here.

Let's start with the assumptions in the article:
If you buy 20 spanking-new servers at US$5,000 to grow your datacenter or replace your current boxes the traditional way, that's a $100,000 outlay. Server virtualization's cost equivalent: three powerful host servers with hardware memory chips from the likes of AMD or Intel at $16,000 each; a SAN at $40,000; and assorted costs in staff training, management software, virtualization licenses, and consultants. That'll all run about $100,000 as well.

A $5,000 server is a tremendous server these days. Going to Dell.com, for $4,747 I can get a rack mounted server with 32 GB RAM and 2 Quad Core AMD processors. That is 8 CPUs. It also has plenty of NIC ports for iSCSI SAN.

One of the reasons people are looking at server virtualization is that their existing, old servers are running at a fraction of their total horsepower. Usually <10%. Do you know how many old single CPU Pentium IV servers can be consolidated onto a $5000 server? Answer: A lot. In fact, that $5000 server may be able to run all 20 of your existing servers.

And then the assumption about a SAN. "A SAN is overkill for most small shops, in terms of sticker price and capability..."
Most of our customers (>75%) already have a SAN. But let's say you don't. Do you need a $40,000 SAN? There are plenty of reasonably priced SANs out there. The NetApp StoreVault is an iSCSI SAN (so you don't need any additional switches or HBAs for your server) that is priced around $5,000.

So the way I see it, you can buy 20 new servers that will run with even less utilization (instead of 10%, try 0.01%), consuming power and cooling. Or you can buy maybe 2 servers to run those 20 servers on virtually. And throw in an inexpensive iSCSI SAN.

Even with virtualization licenses, it seems to me you come out ahead.

CohesiveFT (http://www.cohesiveft.com) today announced it supports Virtual Iron servers via its Elastic Server web-based factory. If you're not familiar with CohensiveFT and you do software development, I encourage you to look at Elastic Server. It functions as an automated "factory" that allows IT professionals to assemble, deploy, and manage virtual servers (i.e., virtual appliances) using a simple point-and-click interface.

What makes this interesting is you can create a server once, and deploy it to any platform you want. This simplifies deployments and makes your application agnostic as to where it is deployed. If you're thinking about leveraging public clouds, you should consider this.

They also have a very interesting product called VPN-Cubed that extends your network into public clouds.

I recently finished Lance Armstrong's book It's Not About the Bike. It’s an inspiring story of the courage to overcome obstacles and succeed.

Of course, he also talks about racing and performance. Athletes measure their performance in a variety of ways and under varying conditions. It’s hard to give a single answer to the question “How fast can you ride 100 miles” without first qualifying the scenario (i.e., is it hilly, how is the weather, etc.).

Performance of IT resources must be viewed through a similar lens. When I’m asked “What’s the performance overhead of Virtual Iron” my first reaction is to ask questions. What workload are you running? What are its characteristics?

What people typically mean when they ask the performance question is will my applications run just as well on virtual infrastructure as physical infrastructure. The answer is sometimes easy: if your application is using 6% of the resources on an old server, it’ll probably do just fine as a share of a new server.

But that’s not the entire story. What you want is to efficiently run as many applications as possible – often a variety of workloads with different characteristics. Optimization is a key to this problem. You need a solid understanding of your application’s behavior. Is it CPU or IO intensive? Does it change over the course of time? Think of it in terms of optimizing the placement of groceries in a bag, except in this scenario one axis is CPU, another axis is disk, and another axis is network. There are a number of applications that help with this process, such as Cirba and PowerRecon.

This brings us back to performance. If your virtual infrastructure has a 15% penalty compared with the same workload running on a physical server, is that acceptable? Maybe, maybe not. First, how do you determine what the penalty is? The ideal answer is to run the workload. That may be OK if you have a few workloads, but it’s painful if you have 1000s. So you may pick your most critical workloads to run directly and use synthetic workloads (i.e., benchmarks) to simulate the others.

To accurately measure overhead, think about two things:

1) Which benchmarks accurately reflect your workloads

2) What are the resource requirements for the workloads

If your resource requirements are low, it doesn’t make sense to drive the benchmark to its maximum setting. Instead, look at benchmark tools such as Intel’s vConsolidate that allow you to run a consolidated set of benchmarks to more accurately reflect your server consolidation project.

I was working on a home project the other day -- building shelves. I'm not the most handy person, but I enjoy a project from time to time. I do projects just often enough to remember why I don't do these types of activities for a living, but infrequently enough that it remains enjoyable. But I often find that I repeat a few of the same mistakes. That may be the definition of lunacy.

One of the most common mistakes I make can be captured by the saying, "Measure twice, cut once." While it may be frustrating for me to check my work, it's a really good idea, because it's even more of a pain when I do something that ends up slightly wrong. The rework is even more time consuming.

It got me thinking about data center environments. The most common causes of trouble occur when organizations forget this simple rule. While that may be OK for a home project, it is often devastating in a data center.

Even when organizations check things out ahead of time (think staging environments before services go into production), stuff happens. It is then that organizations need a plan for how to resolve issues. Planning can alleviate the crisis mentality that develops when systems go haywire. The plan must also include a process -- a checklist of steps to check and actions to perform. And of course, users must be trained on the plan. See this New Yorker article by Atul Gawande for interesting anecdotes supporting the benefits of planning and process.

Good luck with your projects!

By now we're all familiar with justifying server virtualization projects by comparing the number of servers you were going to buy without virtualization to what you will buy once you've consolidated. If your consolidation ratio is 10:1 (that is, 10 virtual machines per physical server), you have reduced your physical server outlay by 90%. The ROI is pretty easy to eyeball.

But what if you're not in the middle of a server refresh cycle? Can you justify purchasing a bunch of net new servers when you're in the middle of depreciating the last batch? I won't get into complicated financial schedules in this blog, but I wanted to tee up some thoughts based on a conversation I had last week with Gartner analyst David Cappuccio.

David recently published a report titled Energy Savings via Virtualization: Green IT on a Budget that had a provocative finding: "The effective use of virtualization can reduce server energy consumption by up to 82% and floor space by 85%... Use virtualized energy savings as a funding mechanism for future projects."

Using the model in the paper, David shows what power reduction of 80% can mean. If you have 1500 servers, he estimates your power bill is over $1M. With 220 servers (a 7:1 consolidation ratio) that power bill is now $181,000. Even with the new capital cost of almost $500,000, you have saved enough power in Year 1 to justify rip and replace of your current environment. Savings in subsequent years are even more dramatic.

Also keep in mind the benefits of less floor space, and other capital expenses (fewer switches, etc.). If you've been holding off virtualizing because you aren't at the right place in the capital budget cycle, I encourage you to run the numbers. When IT budgets are squeezed, this is one area where investing into the downturn can pay dividends.

I read with interest Charles Babcock's recent blog A Vendor-Neutral Standard For Virtual Machines? There Isn't One. In my opinion, what the world does not need is yet another standard, especially when there's a perfectly good one right in front of us.

After reading Simon Crosby's comments that OVF is "...for migration purposes, nothing more," I decided to take a peek at the OVF specification. The documentation states, "A hypervisor is allowed but not required to run software in virtual machines directly out of the Open Virtualization Format."

It seems that the DMTF also believes that OVF is perfectly acceptable for a run-time format.

And why wouldn't it be? OVF contains virtual hard disks (the format of these virtual hard disks is not specified ... they could be VHD or VMDK). And it contains metadata that describes the virtual machine. That sounds like a perfect run-time container. What is so perfect is not only that it creates an industry standard (and hence, portable) format, but it is also great for DR since the configuration lives with the data. This is in contrast to today's virtual hard disks which contain no configuration information. It's hard to reconstitute a virtual machine without that information.

Take it a step further, to make OVF truly vendor neutral, why not specify the virtual hard disk format? Both VMDK and VHD are available under open licenses. Let's pick which one is best and be done with it.

At the end of the day, it's not just about allowing customers to move virtual machines between hypervisors. We know there are issues that will remain, such as virtual hardware incompatibilities, that a standard format cannot fix. It is also important to enable organizations to archive data and rest assured that they can read that data years in the future.

Yesterday we made a partnership announcement with LeftHand Networks.

Together we offer a robust solution at the right price to enable more users to take advantage of the significant benefits of virtual infrastructure management. No wonder in a recent survey of 400+ Virtual Iron users, 87% said our affordable price was a primary driver of their purchase decision; combined with the fullness of our feature set and our ease of deployment.

LeftHand Network's virtual SAN appliance is an innovative way to take advantage of creating SANs in environments, like remote offices, where deploying a traditional SAN is not possible. LeftHand SANs can seamlessly scale through "network RAID", simplifying growth by adding new instances.

You can purchase LeftHand SANs and Virtual Iron through our partner network.