Coming to VMworld 2011? Let me know so we can connect!

In my last post, I asked why you love going to VMworld, and gave you a few of my reasons – like the people, the technology, the announcements, the sessions, the labs, and the parties.

But like any business trip, it is not all fun and games, beer and skittles, rainbows and unicorns.

So why do you *not* like going to VMworld?

Like my last post, I’ll go first. Here are some things I really do *not* love about going to VMworld – as well as some upsides to take the sting off :

• Las Vegas – Moscone at San Francisco was great, but I have been to Vegas so much now that I am getting tired of it.
  • Upside: if it has to be in Vegas, I think the Venetian is the best venue in town, with the best casual dining on the strip.

• Copenhagen – Copenhagen is really expensive and hard to get to from the US, and the Bella Center is so far out of town, away from most hotels, with barely anything nearby.
  • Upside: Copenhagen really is a beautiful city, and if you have a spare day you can visit the fabulous Louisiana nearby.

• The internet access – WiFi (and 3G) at VMworld is always over-subscribed and under-provisioned, though this is not surprising for such a large event. Especially in Vegas, where the casinos don’t want you to do anything except eat, drink, and gamble, I don’t expect the Venetian to be any better than Moscone last year.
  • Upside: it is a great excuse not to answer that email/IM/DM from your boss!
• The conference food – let’s face it, conference food is rarely gourmet, and VMworld is no different. In their defense, when you are serving 15,000+ people you will never get Tetsuya’s, Moto, or Le Gavroche.
  • Upside: both Vegas and Copenhagen have some great food – albeit outside the conference – including what is currently considered the best restaurant in the world.
• The VMworld website – well, the less said about that the better. Suffice to say, it frustrated me so much this year that I spent an afternoon redoing the EMEA hotel listings in a usable format.
  • Upside: once you have registered and scheduled your sessions, you really don’t need the website anymore.
• The hangover(s) – I love the parties, but not the hangovers. So be careful what, how much, how early, and how late you drink. I try to alternate hard drinks with soft drinks  so I can stay longer and suffer less (my regular is vodka & lime; my change-up is lime and soda) . It keeps me hydrated and  you can’t even tell it is non-alcoholic.
  • Upside: a hangover means you probably had a great night at a great party with some great people.
• The main party – I know loads of people loved them, but aged rockers Foreigner (with just one original member) were not my bag. And having seen INXS live at Sydney pubs (like the famous Manly Vale) in the 80s, why would I want to see them old and busted with no Michael Hutchence?
  • Upside: This year The Killers are playing the party – at least they have had a chart hit this millennium!

But really, while I can complain about all these little things, in the end they do not really matter. I still love going to VMworld

That said – what do you *not* love about going to VMworld?

Coming to VMworld 2011? Let me know so we can connect!

I love going to VMworld. It may be my favorite conference of the year (after CA World, of course!).

If you love going to VMworld too, then I would really like to know why.

I’ll start …

For me, the best part of going to VMworld is the people, the technology, the announcements, the sessions, the labs, the parties, and the buzz:

• I meet great friends, colleagues, customers, analysts, tweeps, and journalists who I hardly see during the year – even though I never seem to have enough time to see everyone I want to!
• The labs are reportedly excellent, and it is hard to beat them for in-depth hands-on training. I’m hoping to finally attend these myself this year, if only I can find the time!
• There are always interesting announcements, whether from VMware or their partners (like CA) with a load of cool new tools. I can’t wait for the keynotes!
• The Solutions Exchange is always amazing. Every year it gets bigger, with even more cool new tech. As an übergeek, I totally love it, and typically spend hours just wandering the booths!
• The SWAG from VMware and the Solutions Exchange vendors is always neat. It is fun to see what are ‘the cool tchotchkes’ every year, and the fun games, contests, and things to do on the booths make it feel like a fun fair!
• The parties – oh my goodness, the parties! I never get to all of them (my competitors don’t invite me as much as when I was an analyst ), but especially this year in Vegas, the parties should be a lot of fun.
• There are always loads of great sessions, if I can get to them between meetings. I learn so much every year, and this VMworld should be no different.

Speaking of the sessions, I am really excited to be speaking again this year. In Las Vegas I am presenting  ‘Extending the value of  VMware solutions: How to design, deliver, and maintain reliable, mission-critical virtualization and cloud services‘ (session SPO3974).

I think this will be a really useful session, where I will explain how you can leverage your investment in great foundational technologies from VMware to design, deliver, and maintain mission-critical virtual and cloud services, including how to smooth your evolution and revolution to private, public, and hybrid cloud, with key excerpts from my book, ‘Visible Ops – Private Cloud: From virtualization to private cloud in 4 practical steps‘. Please book SPO3974 into your online schedule builder for Wednesday, August 31 at 10:00 a.m. PT. I would love to see you there!

Plus, please don’t miss a couple of my CA Technologies colleagues speaking too:

• The Agony and the Ecstasy: Two Days in the Life of a CIO – Karen Sage, our vice president of Alliance Solutions, will present this Super Session on Monday, August 29 at 2:00 p.m. PT. Karen has incredible experience and insight into the world of the IT executive, and will discuss how converged cloud computing infrastructure is radically reshaping how organizations will use technology to increase innovation and improve business agility.
• Avoid Virtual Stall with Linked Clones – Allan Andersen, vice president of Product Management, will present this breakout session on Thursday, September 1 at 10:30 a.m. PT. Alan is a fascinating guy and really smart, and will explain how to extend VMware View Linked Clones to reduce storage costs, simplify management, and overcome virtual desktop stall, plus how other enterprise management technologies are critical for the success of VMware View deployments.

Also, CA Technologies will be giving away a limited number of free copies of ‘Visible Ops – Private Cloud‘ at the CA Technologies booth (#439) in the Solutions Exchange. They will be there every day, so you can pick them up and have a chat with the great people on the CA booth. You might catch me there too, in between meetings. Even better, come along on Wednesday, August 31 at 11:15 a.m. PT (right after my session), when all three authors ‘of Visible Ops – Private Cloud‘ – Jeanne Morain, Kurt Milne, and myself – will be there to give away and sign copies too!

So if you are going to VMworld, let me know. I would love to connect, maybe hit a party or two together!

And let me know why you love going to VMworld too!

Mike Laverick's RTFM Education

I recently had the great pleasure of recording a ‘Chinwag’ on RTFM Education hosted by the inestimable Mike Laverick (@Mike_Laverick). Mike is a consummate pro with a comprehensive understanding of virtualization, so it was a privilege and a joy to record this video chat with him.

Andi and I covered a wide range of questions – and we simple didn’t have enough time to cover every topic. These are the questions we DID manage to get through in our time!

Q1. Folks used to talk about VM Sprawl, now their talking about VM stall. What is VM Stall, and what causes it?

Q2. I see you took a side swipe at the “the software mainframe” analogy for virtualization – go on let rip!

Q3. So you have just published a new book on virtualization and private cloud – what is that all about?

Q4. There’s a lot of talk on both sides about whether or not ITIL can coexist with virtualization and cloud. What is your take on that?

You can see/download  the whole Chinwag (on video or audio-only) here – Chinwag with Mike.

More than four reasons count towards VM stall

I recently saw a great article in IT World Canada titled “Virtual stall: What it is and why you have it,” written by Jay Litkey, that took up my idea of VM stall, which I first came up with in my blog from May ‘Is “VM Stall” the Next Big Virtualization Challenge?‘.

Though they barely acknowledge my blog as their inspiration (and as a competitor to CA Technologies – my employer – why would they?), it seems Jay and his team have wholeheartedly taken up my concern with VM stall, and not just in the IT World Canada article. Marketing lead David Lynch was quoted on the topic in a post by Bruce Hoard of Virtualization Review, and in a recent Tech Target article on ‘ISV stall’. Several posts on their corporate blog also address the issue as if it was their own baby.

In my past life at EMA, I have spoken with both Jay and David a number of times, and had a lot of time for what they were doing in the management space. For a small startup with limited resources, it is great that they can take the time to pick up my idea and run with it.

The IT World Canada article is really worthwhile, because it zeroes in on some important concepts. It helps to expand the thought around VM stall, and specifically on a couple of additional causes, as it notes:

Virtual stall has four main causes:

• Scalability issues:  A single IT team often finds it difficult to scale beyond the 25-30 per cent penetration range. This is due to the combination of lack of automation and reporting in virtualization management tools, creating time-consuming manual processes that are a particular problem when there is a lack of experienced and trained staff.
• Management issues: The data centre is not a place that can be managed manually; there are too many elements to be checked, and too many independencies [sic]. And, while there are levels of automation built into the virtualization platform, they can be difficult to define and implement. The lack of automated monitoring, alerting and control becomes more and more of a problem as the overall level of virtualization in the data centre increases.
• Process issues:  Enterprise virtualization impacts a wide range of existing data centre processes, all of which need to be modified, replaced, or augmented. As long as the virtual environments are small and self-contained, these processes can be manipulated or ignored. But as the environment grows, it reaches a point when they have to be dealt with before real efficiencies can be reached. The more “process-mature” an organization is, the more quickly this point is reached.
• Co-ordination issues: Virtualization crosses multiple silos and ultimately requires a level of co-operation and integration that is impossible to achieve with the traditional silo management structure. In addition, the first workloads to be virtualized tend to be less critical ones.  However, as environments grow, higher-risk, higher-impact services are virtualized. These tend to have more stakeholders, more politics, more distributed infrastructures, and a greater cost of failure and downtime. Consequently, they require more coordination.

This is great insight, and offers a number of important causes. However, I don’t think it is reasonable to say there are just “four main causes.” Not to pick on Jay, as it is probably just unfortunate phrasing, but I think it is important to see that the issues of VM stall are much more varied, complex, and numerous.

I am not entirely without fault either. To start with, when I first identified the issue of VM stall in my blog post back in May, I said that “I see many possible causes for VM stall,” but like Jay I only identified four examples. As Jay recounts in his analysis, I saw scalability and manageability as key issues; but unlike Jay, I chose to highlight risk aversion and resourcing as two more of my examples.

However, even these six are just a part of the problem. As I said when I spoke with my great mate (and one of the industry’s great virtualization gurus, observers, and commentators), David Marshall of Hyper9 and InfoWorld in his article, “VM stall: Breaking through the second phase of virtualization“:

“… many organizations strike a ‘perfect storm’ of challenges that slows their virtualization rollout, or stops it entirely. Some causes at this stage include greater complexity of services and applications, higher demand on scarce virtualization skills, limited visibility into a growing deployment, increasingly heterogeneous systems, and greater resistance from risk-averse application owners and recalcitrant application vendors.”

In the same article, David spoke with Dave Bartoletti, formerly of automation vendor Enigmatec and now a leading light showing the way through the virtualization darkness with research and advisory analyst firm, the Taneja Group:

“The second wave of issues is always harder when a core technology matures. Server virtualization essentially paid for itself in CAPEX savings, but when we virtualize Tier 1 business-critical applications, or user desktops, CAPEX savings take a backseat to application performance and IT efficiency, and this is why we’re stalling.”

My former editor at Tech Target and another keen virtualization observer, Colin Steele, highlighted another core element of VM stall, in his article “ISV stall makes virtualizing applications a challenge“:

By now, the benefits of virtualizing applications are clear, but the goal of 100% virtualization remains elusive. One reason is that some independent software vendors (ISVs) don’t support their server-based applications — databases, telecom apps, healthcare programs, etc. — on virtual servers.

Moreover, I talk a lot with customers about their real world concerns, so I can quickly pinpoint many other causes. They talk to me about issues like vendor licensing, facilities constraints, capacity blindness, service prioritization, deployment costs, line-of-business resistance, internal politics, a lack of skills, and even senior management resistance.

In fact, last week at CA Expo in Australia, I talked with CA Technologies customers about seven significant issues in virtualization that are contributing to (among other things) VM stall, as you can see from one of the slides from my presentation:

Virtualization is not clear sailing - from CA Expo Australia

(You can see the whole deck at the CA Expo site)

To be fair to Jay and his team, other posts on his corporate blog agree with me, citing issues like mission-critical apps, management skepticism, bureaucracy, poor project vetting, and more.

I am really glad to see my thoughts around VM stall have captured the imagination of the market. Thanks to Jay for taking this up, and to his team for joining me and CA Technologies in raising awareness of issues causing VM stall.

However, I think we all need to be careful about being categorical about VM stall. It is important to be clear that VM stall – like most enterprise IT issues, and indeed most organizations – is both complex and varied, so trying to categorically define four (or six, or seven, or really any number) of causes for VM stall is underestimating this important problem.

But if we can all contribute new ideas to the community, we will all learn more, and our enterprise customers will benefit from our combined wisdom.

Is 'VM Stall' A Stop Sign for Virtualization?

There appears to be a challenger to ‘VM sprawl’ as the scourge of virtualization success – a problem I call ‘VM stall’.

We know about ‘VM sprawl’ – because new virtual machines are so easy to deploy, organizations can end up with more VMs that they can handle, or even use. This has the potential to cause severe problems to availability, performance, compliance, costs, security, and more.

However, I am seeing more and more evidence of this new phenomenon I think of as ‘VM stall’ – the tendency for virtualization deployments to stall once the ‘low-hanging fruit’ has been converted (typically around 20-30% of servers).

I think it happens more or less like this…

In general, organizations start virtualization deployments by converting relatively low-risk, low-impact systems – dev/test servers, Web servers, file servers, internal applications, etc. – to virtualization. With a big impact, great results, and reasonably fast and easy implementation, it is a great hit with IT and business owners. This may even spawn a ‘virtual first’ initiative, where all new server requests are deployed as virtual servers by default.

However, when faced with the next step, converting the remaining existing servers – including tier 1 business services, customer-facing environments, enterprise-wide systems, 3^rd-party applications, multi-platform services, and composite applications – virtualization projects often stall.

I was interested to see the notion of VM stall confirmed again last week (courtesy of eWeek via @JSchroed) in some new research into virtualization (PDF) coming out of Prism Microsystems, a software vendor in the SIEM market.*

One of the most interesting outcomes in this research was again the low penetration of server virtualization within each organization. As the chart below shows, most organizations have still virtualized less than a third of their production servers.

Source: Prism Microsystems, ‘2010 State of Virtualization Security Survey’, April 2010

What’s more, fully 15% have not even started to virtualize their production servers at all!

It might seem that this is really at odds with ‘the common wisdom’ that sees virtualization as mature, ubiquitous, commoditized, and even passé. We hear so much about virtualization, how it has been a top priority for years, about how everyone is deploying virtualization. For example:

• The IBM Global CIO Study 2009 in September showed 76% of 2500 global CIOs are undergoing or planning virtualization projects
• The Gartner 2010 CIO Survey in January reported that virtualization is the top priority for over 1500 global CIOs (up from number 3 the previous year).
• In January, CDW’s Server Virtualization Life Cycle Report (registration required) found that 90% of respondents have implemented server virtualization at some level.
• As far back as 2008, EMA research showed 75% of enterprises were using virtualization for production use cases
• The Prism Microsystems report the chart above comes from states that 85% of their sample have adopted virtualization to some degree

I am even starting to hear that virtualization is set to be irrelevant, becoming nothing more than just a stepping stone to cloud.

However, despite the widespread adoption of virtualization as a percentage of organizations, it is consistently still very low as a percentage of production servers.

Indeed, this is not the only recent (and not so recent) research study to highlight this issue. Over time, CIOs have reported a persistent difficulty in expanding their virtualization deployments beyond the initial 20-30% of servers. For example:

• Around 6 months ago, Gartner reported that “only 16 percent of workloads are running in virtual machines today.”
• Research from EMA has found that the average organization has only virtualized around 25% of servers (and only retired just 17%).
• The CDW Server Virtualization Life Cycle Report cited above showed that just 34% of the average organization’s total server infrastructure consists of virtualized servers
• CIO and HP survey in October 2009 reported that on average just 38% of mission-critical business services have been virtualized by companies with virtualization projects
• Forrester Research from May this year (conducted for CA) shows that the average enterprise has virtualized only around 30% of their servers.

At a time when so many organizations are experiencing VM sprawl, it seems hard to believe that VM stall is such an issue. Yet time and again we see that organizations find it difficult to ‘get over the hump’ of the initial 20-30% of servers, and difficult to move from low-risk/low-impact servers to high-risk/high-impact services.

If this were just a point-in-time observation, then VM stall might not exist. The low penetration rate may just be a point in the deployment cycle. However, VM stall appears to be a longitudinal effect, as it has been holding many deployments at around 20-30% of servers for several years. IIRC, something resembling VM stall was cited as an issue in EMA research as far back as 2008, and again in 2009. The CDW virtualization lifecycle research also reinforces the potential for long-term VM stall. In it, even organizations that self-report as “fully deployed” for server virtualization have only virtualized 37% of their servers. So while many organizations see VM stall as a short-term delay to virtualization rollout, many others are seeing VM stall as a permanent situation.

I see many possible causes for VM stall. For example:

• Risk aversion – high-risk, high-impact services have more stakeholders, more politics, larger and more distributed infrastructures, greater cost of failure and downtime, reduced or non-existent 3^rd-party support, and maximum management attention, among many other risk factors. The risk of failure may be too great, and the newest technology is always blamed for any new problems. Without new ways to address continuity, availability, performance, cost allocation, and other business requirements, conversion risk may be enough to stall virtualization deployment.
• Resourcing – with around 20-30% of servers converted, virtualization staffing starts to become a real challenge. As I talked about recently with my great mate, David Marshall, staff and skills shortages put a real throttle on virtualization deployments, especially as virtualization starts to scale. Not only is demand for virtualization skills still high, but supply continues to lag. Plus, the problem is getting worse, not better. Without the resources and skills to go forward, there is often little alternative to VM stall.
• Scalability – with one (typically small) team trying to manage a quarter of the entire server workload, staff from the virtualization project team simply cannot handle further virtualization deployment. In some cases, the virtualization technology itself does not scale well either; and in others, the management tools do not scale. Throwing more bodies at the problem is rarely the answer – after all, nine women cannot make a baby in one month. So organizations end up with VM stall almost by default, as they find that they need to fundamentally change their processes and technologies to enable further virtualization growth.
• Manageability – new IT management issues come up as the scale and risk of virtualization deployment increases. Enterprise virtualization needs new approaches to performance assurance, process automation, VM mobility, continuity planning, security and audit, software compliance, OEM support, configuration compliance, and more. The importance of manageability is greatly magnified  for high-risk/high-impact services, but few (if any) organizations seem to have the virtualization-aware management tools to scale to handle enterprise-class virtualization deployments. Again, VM stall happens almost by default, as IT tries to figure out enterprise-class manageability.

There may be more or different causes, but whatever the reasons, there is little doubt in my mind that VM stall exists. It is not universal – indeed, every study shows that a decent percentage of organizations are able to power through it – but for the majority of organizations, it appears to be very real. I have personally seen many enterprises going through it. More and more research continues to support it. For affected organizations, it is a significant problem, too, because stalled virtualization deployment means the highly desirable outcomes of virtualization – OpEx reduction, improved continuity, greater IT and business agility, energy cost reduction, ROI, etc. – either stalls as well, or even starts to backslide.

Whether VM stall represents as big a problem as VM sprawl, time will tell; but it is certainly a significant and growing challenge to the success of virtualization – and a fundamental driver for better virtualization management.

(EDIT: This article has been picked up and published on CIO.com! Join in the discussion there, or here.)