The Journey to the Secure Software-Defined Data Center

So one of the key differentiators that my company, MTI Technology, has over some of the other VMware partners in the UK is that we have quite an established Security Practice (We even hold the Royal Warrant for security work for the Royal Household!)

I’ve been asked to present a short deck on MTI’s Secure Software-Defined Data Center solution at an upcoming event (non-technical, it’s aimed at C-level or decision makers). If you haven’t already signed up, then register below!

Organisations across the public and private sectors have been steadily consolidating their IT infrastructures, as they seek improved efficiency and better performance. While this activity will undoubtedly continue, many organisations are now setting their sights on the next big thing – securing their software-defined datacentre.

In a secure software-defined datacentre, an organisation’s entire infrastructure is virtualised. This empowers the integration of compute, storage, network, and security solutions, and enables you to deliver IT as a service, and provision services securely via the cloud. In turn, this allows IT departments to keep pace with growing business and technology demands, and to achieve the speed and agility that IT users require.

The journey to the secure software-defined datacentre

Join MTI at the Institute of Directors, London, on Friday 15th April as we explore how you can advance the way you deliver IT today to meet the needs of your business tomorrow, while combatting ever-evolving security threats. During the half-day workshop, you will learn how a secure software-defined datacentre can:

  • Help you to ensure strong alignment between your IT and business objectives
  • Deliver ‘built-in’ security that evolves as your IT infrastructure grows and adapts
  • Offer the balance of performance, capacity, and availability demanded by your critical business applications
  • Deliver simple and cost-effective test & development environments with management and delivery services to reduce application overheads
  • Drive improved efficiencies and cost saving for your business
  • Turn large volumes of commodity servers into a high-performance, low cost infrastructure
  • Protect your data, infrastructure, and environment, detect and, if necessary, remediate against intrusions

To register, please visit

VM displays to two port groups after migrating to a distributed vSwitch

Do you ever encounter the same issue over and over again and forget how you solved it the first time, or what caused it to happen in the first place?!?

It happened to me today on a customer site….. we were migrating a couple hundred VMs off a standard vSwitch onto a newly created Cisco Nexus 1000v switch and several VMs were showing to be connected to the old port group on the standard vSwitch as well as the new port group on the distributed vSwitch.
The VM Summary showed connections to 2 port groups even though there was only 1 vNIC and what made it more confusing was if you went and edited the VM hardware settings the vNIC was configured with the correct port group….. hmmm…..

It was a case of Déjà vu…. I sat there thinking “Damn, I’ve seen this before… but for the life of me I can’t remember what’s causing the problem!”

After a quick “Google”, I stumbled across the following KB and my foggy brain suddenly cleared!!

……If the virtual machine has snapshots associated with the old network, when you reconfigure the virtual machine to use a new network configuration, both old and new networks are associated with the virtual machine……”

“Doh…. Snapshots!!!”……. it’s all down to the VMs possibly having a snapshot attached to it!!


Basically someone had taken a few snapshots of the affected VMs, and because it’s a “snap shot” of the VMs state at that point in time, the snap shot had the old vSwitch port group whilst the new ‘delta’ VMs had been re-configured with the new 1000v port groups!
Kinda makes sense right? If you wanted to roll back to the old snapshot then it must have the configuration of the VM from the point in time when the snapshot was taken – ie with the old vSwitch port group!

Anyways, a quick check with the client and after a lengthy consolidation process all the VMs were happily only showing connections to the 1000v port group!


….. and so to make sure I don’t forget that I’ve encountered this issue millions of times before, I’ve decided to post up a blog entry about it….
(Which was one of the reasons I started blogging in the first place – a place where I can not only share my knowledge but also somewhere I can access solutions to past problems!)

Cisco Announces its Software Defined Network – Application Centric Infrastructure (ACI)

So when I did my VMworld 2013 Europe round up, I mentioned that it was strange to see that Cisco were not one of the supported partners for NSX and I hinted at the possibility of Cisco having something SDN up their sleeves (also from rumours heard from Cisco employees)…..

And so at the beginning of the month they announced their entry into the SDN arena….. Application Centric Infrastructure (ACI)….

I have to hold my hands up and say I’m not a networking guy (in fact it’s pretty rare in the IT market to find someone who knows server/network/storage/virtualisation….!), so I haven’t really had a chance to read up on ACI and understand how it works and differs from VMwares’ NSX.

From what I can see, ACI is pretty much reliant on you having a Cisco switch infrastructure – and specifically their new line of Nexus 9000 switches!
So whilst VMware NSX is a proprietary software control layer which doesn’t care what the underlying switch hardware is, ACI locks you into Cisco hardware but gives you the choice of what software control layer you use via APIs (integration into OpenStack, Hyper-V, VMware, etc).
Clever tactic, as it means that whilst you maybe locked into Cisco switches, it means you can deploy any sort of hypervisor!

This obviously becomes very interesting when you start looking at the converged stacks like VCE, VSPEX and FlexPod…… if SDN is going to be implemented, it’s more than likely that Cisco’s ACI will win here just because of how open it looks!

On a side note, it turns out that ACI could be a by-product of Cisco’s stealth start-up company – Insieme Networks – funded solely by Cisco and un-surprisingly run by the same guys that brought Cisco their UCS server portfolio (Nuova) and their MDS SAN switches (Andiamo)…. There’s a very interesting article on Bloomberg about Mazzola and his motley crew of engineers!

Cisco acquires Whiptail

Opened up my work email this morning to be inundated with mails about Cisco acquiring the flash-array startupWhiptail – for $415m…

What makes this interesting was several years ago when I attended the launch of UCS blades, someone in the audience questioned whether Cisco would enter the storage arena…. the answer at that time was “No Way… Cisco won’t do storage!”
This has pretty much been their response for the past few years – even though the market has always been awash with rumours that they were on the prowl for a storage company (*cough* NetApp *cough*).

Cisco is one huge beast….. it has its paws in every part of the IT infrastructure…… and if I’m honest, they’ve probably pissed off a lot of people along the way….. =)
VMware – UCS Director (Cloupia)…… HP – UCS servers…… and now EMC/NetApp.

So it seems all the noise coming out of Cisco is that this acquisition is so that they can build a “flash tier within their UCS platform”….
Makes sense as the market view is that since storage is getting faster (flash/SSD), bringing it closer to the compute resources will help accelerate application/OS performance by using flash as some sort of caching tier.

It’s an clever acquisition by Cisco….. a flash-array start-up which already has products that could be pushed to market or integrated. Plus the arrays leverage a ‘scale-out’ approach to storage where a customer would start small and then just bolt on additional nodes when required – sound familiar?!? Isn’t that what blade servers are supposed to offer? The ability to scale out compute by just slotting in new stateless blades. So what UCS does for compute, Whiptail may offer Cisco for storage!

Cisco marketing bods have stated that they’re still 100% behind their involvement with VCE, so it will be interesting to see what they end up doing with the flash-arrays that Whiptail sells….. surely they won’t just kill all off the work that has gone into these arrays!
Yes, they’ll strip out some of the flash tech to build into UCS, but I still reckon that they’ll release some sort of flash-array to the market!
Afterall, that would be the smart (and logical) thing to do……
Compute – Cisco UCS
Storage – Cisco Whiptail
Network – Cisco Nexus
Cloud – Cisco UCS Director (formally Cloupia)

… all they need now is a hypervisor and they will pretty much OWN a cloud stack!!
Hmm… there’s probably some KVM-based hypervisor offering out there that could be gobbled up! Any suggestions?

So yes, while in the short term Cisco will still buddy up to EMC/NetApp for their vBlock/VSPEX/FlexPod offerings, in the long term I guess this will all be answered by how Cisco go to market with Whiptail….. whether they will continue offering it as a standalone storage array, or whether (like their other acquisitions) they roll it all in as part of a solution bundle.
And whether they push the Whiptail products as being a Direct Attached Storage to their UCS platform rather than NAS/SAN storage (which will directly challenge the likes of EMC/NetApp).

In fact…. I wouldn’t be surprised if they went the way of HP and offered a Cisco/Whiptail storage blade!! (Remember, you read that prediction here first…..) ;oP

Watch this space…… Interesting times ahead!


Edit: Just read a really good article by Jason Nash regarding Cisco’s acquisition of Whiptail…. he’s put forward some good points about why Whiptail and how it fits into Cisco’s view of SDDC!