Over the last couple of months I’ve had my first experiences with Acropolis in the field. Both quite different but they highlighted two important design goals in the product; simplicity of management and machine migration.
Before I begin I want to take you back a few months to talk about Acropolis itself. If you know all about that you can do two things:
- Skip this section and move on
- Go to YouTube and watch some classic Sesame Street and carry on reading with a warm glow only childhood muppets can bring.
I knew you couldn’t resist a bit of Grover but now you’re back I’ll continue.
Over the summer Acropolis gained a lot of happy customers both new and old. In fact some huge customers were already using it since January thanks to a cunning soft release and that continues into our Community Edition too.
The main purpose of Acropolis was to remove the complexity and unnecessary management modern hypervisors have developed and to let customers take a step back and simply ask “what am I trying to achieve?”
It’s an interesting question and one that is often posed when too deeply lost down the rabbit hole. For someone like me who used to spend far too long looking at problems with a proberbial microscope there’s a blossoming clarity in the way we approached these six words. The journey inside Nutanix to Acropolis was achieved by asking our own question:
“For hypervisors, if you had to start again, what would you better and what would you address first?”
Our goal was to make deploying an entire virtual environment, regardless of your background and skill set, intuitive and consumable. Our underlying goal for everything we do is simplicity and while we’ve achieved this with storage many years ago (which we call as our ‘distributed storage fabric’) the hypervisor was the next logical area to improve.
Developing our own management layer and beginning its work on top of our own hypervisor was a logical step and that’s what brought us to where we are today with the Acropolis Hypervisor. You can see a great video walk through of the experience of setting up VMs and virtual networks in this video.
Anyway on to my first customer story.
Back in summer I spent time working with manufacturing company on their first virtualisation project. They were an entirely physical setup using some reasonably modern servers and storage but due to many reasons they’d put off moving to a virtual platform for many years. One of the most glaring reasons was one I hear a lot here as well as in my previous role at Citrix; “it worked yesterday just fine so why change?” While this is true I could still be walking two miles to the local river to beat my clothes against rocks to clean them. But I chose to throw them in a basket and (probably by magic) they get cleaned. If my girlfriend is reading this, it could be my last blog…
Part of the resistance is related to human apathy but their main concern was having to relearn new skills, which takes focus and resources away from their business, and it simply being too time consuming. I completely agreed. They wanted simplicity. They needed Acropolis.
Now, I could have done what many would and do a presentation, demo and finishing Q&A but I chose to handle our meeting slightly differently. To allay their fears I let them work out how to create a network and create a new VM. As we went I took them through the concepts of what a vCPU was and how it related to what they wanted to achieve for the business. If someone with no virtualisation experience can use Acropolis without any training there can’t be any better sign off on its simplicity. We were in somewhat of a competitive situation as well where ‘the others’ were pushing vCenter for all the management. The comparison between the two was quite clear and while I’ll freely admit that feature to feature vSphere as many more strings to its bow, that wasn’t what the customer needed and isn’t the approach we are taking with the development of Acropolis. We had no wish to just make a better horse and cart and the customer was extremely grateful for that.
One happy customer done, one to go…
Our second customer story, dear reader (because there is only one of you), was already a virtualisation veteran and had been using ESXi for a few years before they decided to renew their rather old hardware and hopefully do something different with their infrastructure. Their existing partner, who’d been implementing traditional three-tier platforms previous to this chose to put Nutanix in front of them and see if we could ease their burden on management overhead, performance and operating expenditure.
While the simplicity of Acropolis was a great win for them and made up most of their decision it was how we migrated their ESXi VMs on to Acropolis that really struck me most and that’s what I’m going to summarise now.
This was my first V2V migration so I needed something simple as much as the customer and partner did and wow did we deliver. Here is everything we needed to do to migrate:
- Setup the Nutanix cluster and first container
- Whitelist the vSphere hosts in Prism
- Mount the Nutanix container on the existing vSphere hosts
- Copy the VM to the Nutanix container
- Create a new VM is Prism and select Clone from NDFS then pick the cloned disk from step 4
- Start the VM and connect to the console
- Strip out the VMware tools
- Install the VirtIO drivers
- Go to 4 until all other VMs are done
Now of course doing a V2V also has a few extra parts such as ensuring any interdependent services are migrated as a group but really that’s all you need to do.
The clever bit is the Image Service. This is a rather smart subset of tools that convert disks like the vmdk in this example to ones used by Acropolis. There’s no requirement for any other steps or management to get a VM across and the customer had their entire estate completed in an afternoon. To me, that’s pretty damn impressive.
I’m really pleased with what engineering have done in such a short period of time and to think where this can go is quite amazing.
And now we come to the point explaining why I said this stuff was “idiot proof.” I can only describe what happened as an organic fault in the system also known as a cock-up on my part. I hold my hands up and say I was a dumb-dumb. As HR don’t read this, and to be honest it’s just you and I anyway, I should be ok.
While we were preparing the cluster for the VM migrations I decided to upgrade the Nutanix software to the latest version and while this was progressing smoothly node by node I somehow managed to…erm…hmm…well……I sort of sent a ctrl+alt+del to the IPMI console. Call it brain fade. This obviously rebooted the very host it was upgrading right in the middle of the operation. After a lot of muttering and baritone swearing I waited for the node to come back up to see what mess I had created…
Here’s where engineering and all our architects need a huge pat on the back. All I had to do was restart genesis on the node and the upgrade continued. What makes this even more amazing is that while I was mashing the keyboard to self destruction the partner was already migrating VMs – during my screw up the migration was already in progress! If I’d have done this to any other non-Nutanix system on the planet it would have been nothing short of catastrophic. However, in this case there was no disruption, downtime and if I hadn’t let off a few choice words at myself nobody would have known. That is frankly amazing to me and shows just how good we’ve designed our architecture.
So how can I summarise Acropolis? It (and Nutanix) isn’t just a consumer-grade infrastructure, it’s also idiot proof and I for one am very grateful for it 🙂