Home > Blogs > VMware Telco NFV Blog


VMware’s vCloud NFV is OpenStack…and a whole lot more!

About twice a week I find myself having the same conversation: “This Virtual Network Function (VNF) works on OpenStack” someone says.  My response has not changed in a while: “Great, vCloud NFV is also OpenStack.”

At that point in the conversation the trajectory is never predictable, but always a lot of fun. As if I needed more convincing that the industry is confused about what OpenStack is and is not, I was lucky enough to present a session at VMworld explaining the role of VMware Integrated OpenStack (or VIO as we typically refer to it) in VMware vCloud NFV. The questions we received at the end of the presentation were a testament that we need to clarify a few things.

10-19-16_nfvopenstack-ganbar

OpenStack is a vendor-neutral Application Programing Interface (API). It has various plug-ins that allow a programmer to specify how to use a set of underlying infrastructure components: virtual compute, virtual networking, virtualized shared storage, authentication, you name it. There are a lot of plug-ins.

Guess what? That’s it. OpenStack does not specify what these underlying components should be, nor does OpenStack “come with” a specific hypervisor, virtual networking implementation or a virtualized storage component. In fact, decoupling the OpenStack framework from the underlying infrastructure is exactly one of the reasons that OpenStack is so attractive to communication service providers.

So what do I mean when I say that VMware’s multi-vendor, multi-domain NFV platform, is OpenStack?

Well, if you are reading this, I’ll assume that you are familiar with the ETSI NFV reference architecture. As part of vCloud NFV we offer our customers a choice of Virtualized Infrastructure Manager (VIM): vCloud Director or VMware Integrated OpenStack. With the inclusion of VIO, vCloud NFV is OpenStack. VIO is a DefCore-compliant OpenStack distribution that takes minutes to install (yes really, your storage will determine just how many) and allows you to consume the underlying NFV infrastructure (NFVI). That infrastructure is of course based on VMware’s stable and mature components such as VMware vSphere for virtual compute, VMware NSX for virtual networking and Virtual SAN for stared storage.  Once the infrastructure is deployed, and a VIM is attached (minutes remember?), you can start deploying VNFs.

This is actually where some of the benefits of OpenStack come to bear. A VNF could be a single virtual machine (VM) or a collection of VMs with specific networking configuration and expected traffic flows. The deployment framework for these components is typically described in a template called HEAT. If a VNF “works on OpenStack” it is likely to already have a HEAT template in HOT format which of course could be used to deploy the components in the vCloud NFV environment. The last point of confusion is the distribution format of these VMs that make up the VNF. The VMs are of course wrapped in some format that could be installed on a hypervisor. That format is typically a vmdk or OVA files which are of course supported by VIO and are easily deployed on the VMware NFV infrastructure. If the VNF is packaged in a qcow2 format, VIO also supports that.

If you are old enough, you might remember a time where each network used a different protocol to communicate. Apple had AppleTalk, there was something from Novell, and Microsoft had a specific network stack. Slowly, all these different operating systems started installing a TCP/IP stack, a communication stack based on an open standard, and suddenly computers that were isolated in their own communication islands, could exchange messages with each other. OpenStack could have a similar effect: a unifying open format for NFV. If OpenStack helps customers easily and quickly adopt and monetize their NFV platform, not only do customers gain, but the industry as a whole will mature and benefit.  This is why we give our customers the option to deploy OpenStack, and once they do, we provide support, design and deploy guidelines, and everything one could expect from a carrier-grade software.

Building walls around a stack will not benefit anyone.

Jambi

Leave a Reply

Your email address will not be published. Required fields are marked *

*