Skip to Content

How do I Contain This Virtual Machine?

There’s been a lot of talk about containers lately, especially in the VMware space.  At VMworld 2015, we heard more about Project Photon and vSphere Integrated Containers.  While these are both great advancements in the container space, I think they can confuse people who are just starting with containers, and perhaps using VMware as their container as a launch pad.

At the heart of vSphere Integrated Containers is something called the Virtual Container Host.  A Virtual Container Host is a logical construct within a vSphere environment which hosts containers.  This Virtual Container Host can even span a whole vSphere Cluster, we aren’t limited by hardware boundaries and vSphere resource management can keep track of placement of containers for us.  These are great features, and can really help vSphere customers begin using containers in their environments.  However, they do add a layer of confusion to those new to containers.  Of course, since this is technology created by VMware, there are virtual machine like objects in use, and we’ve got some virtual machine and container inception going on.  We’re still going to be treating VMware “containers” like we treat regular old Virtual Machines, but we get to benefit from the existing VMware enterprise technologies.

If we’re striking out on our own, things are going to be a little different.  Let’s think about how we manage our virtual machines in our environment today.  Often, a virtual machine will host some component of an application, and we’ll have a number of virtual machines that make up a full application environment.  We really, REALLY care about these virtual machines.  We protect them with things like vSphere High Availability, or even vSphere Fault Tolerance.  We rely on things like Dynamic Resource Scheduling to make sure all our component virtual machines are performing well.  When it comes to disaster recovery, we use things like Site Recovery Manager to protect them, and ensure our virtual machine can be brought up in a different environment in the event of a disaster.  We also back up and protect these virtual machines in case of corruption or if a human does something stupid.  We care about our virtual machines, often we know them by name and how they relate to an application.

Now, let’s look at containers, and throw everything we know about virtual machine management out the window.  We really don’t care about our containers.  They are there to process things for us and work for us.  If one dies, we will just replace it with another.  If we’re using Docker, what we care about are our Docker volumes.  This is where we keep our data.  This is what we need to worry about backing up and protecting, just our volumes connected to our containers, not the containers themselves.

This is a fundamental shift from the way we work with our virtual machines.  As such, we’re going to have to change the way we’re doing things and thinking about things to make sure we are leveraging containers in a way that suits our organization.  There are things out there like Kubernetes (cluster management and scheduling), Weave (networking enhancements), and Flocker (Docker management) to enhance plain old Docker and bring us those enterprise features we’re so used to.

Last year, I started diving into Docker and containers, and created this lovely image to try to help explain things (it may be worth a read if you are new to this).

VM to Container2
One of the key differences (and we’re going to ignore what VMware is doing here) between a virtual machine and a classic container is that we’re running a full operating system inside of each and every virtual machine, while we are leveraging the linux operating system underneath the container and we just have our application and the binaries and libraries it requires in our container.  Because of this, containers can have much less overhead than a virtual machine.  Now, if you really want to throw a wrench into things, Microsoft is getting in the game as well, with two different types of containers, Hyper V Containers and Windows Server Containers, but let’s save that for another time.So let’s say you want to get started playing with containers in your environment.  Here are some things to keep in mind as you make the shift from virtual machines to containers.


  1. Don’t grow attached to your containers.  While it’s exiting to begin this journey, our containers are transient.  We can spin up a new one in a blink.  Instead, think about how you can protect your data by doing things like distributing containers across multiple hosts.  Remember, a container is not a virtual machine!
  2. Pick the right application to play with.  You know that app that resides on a Windows NT virtual machine someplace that no one has the code for?  That isn’t the one!  Think of applications you and your organization have the ability to develop and change.  Have you started looking at a more DevOps type of methodology for certain applications?  These applications are great candidates!  You may need to make changes to the way your application works to take advantage of some of the benefits of containers such as a distributed failure domain, and the ability to easily add more containers as demand grows.
  3. Be ready for growing pains.  Docker has lots of features, but you may need to add some third party components to get things working they way you want them to.  Also, this may be a big change for your operations team, so make sure to get them on board early if you’re seriously considering entering production with a containerized application.
Containers are a great technology, but they aren’t for everyone yet.  VMware, among other companies, is trying to make them consumable for the everyday enterprise, which is fantastic!  If you’re going to take a journey on the container ship, try to remember that a container is not a virtual machine.  Will containers completely replace virtual machines in your environment?  Probably not anytime soon, but they are a great technology to look at if you have the time and the business case.