Cisco Blogs

VCE VBlock – When is the right time to start?

June 1, 2010 - 3 Comments

In talking to many people at VMware, I’ve often heard them say,”..almost anyone can virtualize the first 300-400 servers, but after that it takes a true mix of skill, technology and planning…”. I bring up this anecdote for a couple reasons. First, I’ve heard several people ask if Vblock was only useful for the largest customers or largest deployments. It’s not a coincidence that we target a Vblock 0 (the smallest version) to begin around 300 VMs. Vblock operates differently

The second reason is that I was reminded of this again this morning as I spoke with a large Enterprise customer. The customer is an early, existing Vblock account, with several thousand servers yet to be virtualized. Their technical staff had engaged the VCE team in weeks/months of rigorous technical debate about the inner workings of Vblock. They had already deployed just north of 400 VMs and were pushing back at a different operational model. So when I asked their leadership why they finally decided to more towards a VBlock architecture, their answer was, “We got to 400 VMs through far too many exceptions in process. We couldn’t move to the next level without a forcing function to align our business needs with our technology organization.” In essence, they needed a solution that combined the right technology with the right process. They didn’t believe they would get there with the current model.  

The interesting thing about this account is that the technical staff is as engaged as ever in finding ways to push the system. They have some very unique requirements as we move them from physical to virtual. They are driving us to solve their challenges today, but also helping us shape the Vblock of the future. But the conversation has changed over the last six months. The conversation is now solution-centric, with a cross-trained staff understanding the dependencies within a Vblock much better than in the past. They believe that Vblock has helped them take the first step in moving to a more efficient and coordinated model. 

300-400 VMs is by no means a defined hurdle that IT must over come. For some companies it might be 50-100 VMs. For others, it might be 1000 VMs. But like anything at scale, rapidly virtualizing your IT environment takes proper architecture and planning. In some cases, Vblock might be the right architecture. We’d be interested in hearing your feedback about when you hit those thresholds that told you it was time to do things differently…

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Brian - One of the other things that I like about VBlocks are that they provide simple guidance on storage networking decisions. Small virtualization configurations are typically running NAS or iSCSI (VBlock 0 size), while larger configurations (VBlock 1 and 2) are more likely to be FC configurations (and starting to leverage FCoE in the rack).

  2. Nice post. I see the same thing all the time.At some point, doing things the way you've always done them hampers progress, rather than facilitates it.And Vblocks tend to bring this issue into sharp focus.More posts, please!

  3. Disclosure, EMCer here.Brian, I've seen something similar with the customers I've worked with on Vblock. Beyond the technical giblets (and this is coming from one who loves technical giblets), there's an interesting forcing function"" accelerant factor behind a Vblock concept. It's more about focusing less on certain choices, and more on others. The interesting thing is that several months in, the customers are finding that the things they obsessed about before are less important than they thought.It's more about forcing the change to look at the integrated stack underneath the virtualization layer as an integrated stack - rather than a set of independent stacks. This triggers the organizational change that's often needed to make ""virtualizing servers"" to become ""operate more in a cloud-like fashion"".It's certainly an interesting thing to have a front-row seat in this exercise.BTW - just so it doesn't sound like a vendor commercial, I've seen similar effects where people have forced themselves down their own ""integrated stack design"", so I think those effects are more about the idea than the individual vendor parts.In one standout case, a customer who was very mature in this model (having already rev'ed their ""integrated stack under VMware"" twice) had an interesting perspective. I thought he would barf all over the concept (after all, here we were proposing an integrated stack over his baby, which was already on Rev 2). The architect/driver's comment? ""If you're even close, its good enough. Rev'ing to version 3 of our architecture (to keep up with technology change) would cost our org several million dollars - and frankly, that's not our business"".Interesting."