This series of articles has been taking a look at how end users in the communications service providers space pick their components to build the network function virtualization infrastructure (NFVI) infrastructure. In this article we’ll take a look at the virtualized infrastructure manager (VIM).

The ETSI NFV specification identifies three major components for Management and Orchestration (MANO) including the VIM, the NFV Orchestrator and virtual network function manager (VNFM). The VIM layer handles the virtualization of physical hardware in the data center by integrating with virtual-machine managers, providing the capability to create multiple virtual compute, network, and storage elements. Without the VIM, NFV solutions simply don’t work. It is a foundational component of an NFV strategy, and it is increasingly seen as an important part if NFVI. Faults in the VIM can increase costs to the project or risk the success of the project itself.

When selecting a VIM, network architects must understand the environment including open source projects, commercial players and future implications to choose the right platform.

One of the big players in the VIM space, is, of course, OpenStack. OpenStack is an open source software platform for cloud computing that includes VIM functionality. It’s a platform that controls multi-vendor hardware pools of processing, storage, and networking resources and its free.

But OpenStack, of course, isn’t the only VIM. One of the leaders in cloud management platforms, VMware, positions its proprietary vSphere with VIM functionality and it’s also working on carrier-focused versions such as VMware Integrated OpenStack or VIO. Other vendors have focused on carrier-hardened flavors of OpenStack, including HPE’s Helion, Mirantis, Oracle, and Red Hat. Some of these platforms add functions specifically geared to carrier requirements – many of which we have written about here – such as support for NIC bonding and other fault-tolerant features.

Other popular NFV orchestration products that have VIM functionality including Apache’s CloudStack and the open-source OPNFV. For most of the end users, NFV decisions loom large in selecting both management platforms and the VIM: Free vs. fee, open vs. proprietary, and whether these platforms will be implemented in private, public or hybrid clouds.

One of the large questions in the industry is: Do we use OpenStack? OpenStack has gained a lot of popularity in the industry and is consolidating its lead as one of the biggest NFV open-source solutions. But the game is hardly over. OpenStack gets a lot of attention, but it still has a somewhat rocky history in the service provider world.

One of the biggest risks cited by service providers in the telco cloud is the lack of maturity of components including cloud management platforms that offer VIM functionality. Several large-scale users have cited OpenStack as “immature” and not stable enough to run telco clouds. This comes from public statements from some carriers. BT famously threatened to ditch OpenStack at the SDN & OpenFlow World Congress in Dusseldorf in 2015.

More recently, Javier Gavilán, Planning and Technology Director, Global CTO, Telefónica, raised these very concerns in an email to me:

“The of maturity of OpenStack regarding assurance and operation issues is slowing the advances of NFV projects. The main lesson is that when faced with highly challenging and innovative goals such as this the whole industry needs to redouble their efforts. This is the reason why Telefónica is actively leading the industry through our participation in standardization groups and open source initiatives.”

This is why some vendors are willing to pay for VIMs and other NFV components from proprietary vendors.

Customers trust a commercial company for support and recognize the large number of vendors ready to build solutions on a widely deployed platform. This is the classic open-source vs. commercial conflict we’ve all seen before.

The OpenStack question has perhaps spawned a new trend: a number of providers are building a platform that handles VIM, specifically targeted at the service provider NFVI requirements – that is, supporting high scale and large fault tolerance.

The best approach to choosing a VIM might require making a list of requirements and whether the targeted platform supports features such as:

• Support for a wide range of hypervisors
• Fault tolerant features such as compute node failure and auto-healing
• Enhanced security
• Ability to integrate with networking functionality – e.g. capability to manage NFV infrastructure in multiple racks – and integration with networking features such as Nova or Neutron
• Robust management and monitoring capabilities
• Service-chaining capabilities
• Proven scalability
• Integration with high-performance NFV hardware features such as DPDK, SR-IOV, and NIC bonding.
• Support for programmatic provisioning and API

The VIM landscape is progressing rapidly. One thing that is clear is that service providers are asking for proven, scalable VIMs with a wide range of fault tolerance and networking features that are geared specifically for high availability. Our research indicates that VIMs are likely to be delivered as part of a more complete NFVI platform that includes full integration with the hardware to deliver a carrier-grade requirements.