The demonstration at Synergy showed the consistent deployment architecture for the Nexus 1000V distributed virtual switch, NX-OS feature-set, operational workflows, and port profile based provisioning of virtual Ethernet ports (vEths) via XenCenter. Two virtual workloads – Ubuntu server and Windows Client – were shown to interact with each other as in the diagram below.
One of the things that has always been clear to us is that a pragmatic cloud and virtualization solution is going to need to embrace diversity. There were going to be many paths to cloud and customers would want the freedom to choose to host workloads on physical infrastructure, any of the hypervisors available or one of the emerging number of cloud options. This realization has been one of the factors that has shaped our strategy for delivering practical solutions for virtualization and cloud to the market.
Cloud Networking: Multi-Hypervior and Multi-Service
Initially, we focused on physical/virtual consistency and separation of duties. We kicked this effort off with the Nexus 1000V, which was a fully functioning NX-OS switch rendered fully in software. With L2 handled, we moved on to deploy virtual services consistent with this physical counterparts like the ASA 1000V, the Virtual Security Gateway (VSG) and vWAAS. Finally, we fleshed out the networking stack with the Cloud Services Router (CRS 1000V).
The network has always been a platform for enabling heterogeneous OS and heterogeneous applications to connect. Naturally, the next step was to take the capabilities we had built and extend them across multiple hypervisors so we could now deliver a consistent experience for customers with heterogeneous hypervisor environments. We built on our success with over 6,000 enterprise and service provider VMware vSphere customers and are now extending those came capabilities to Microsoft Hyper-V environments as well for Xen and KVM open source hypervisors. With the recently announced shift to a “freemium” pricing model, with the Nexus 1000V-Essential Edition, customers are gaining these benefits with minimal cost and risk.
vCider and Virtuata: Opportunity for Secure Multi-cloud Networking
However, some of the most interesting progress has come from our two of our more recent acquisitions that have been centered on the concept of providing better operations and management of multi-cloud environments. As customers more broadly adopt cloud and virtualization, security and isolation at the VM level become of paramount importance. To address this need we acquired Virtuata this summer. The Virtuata technology will give us (okay, you) the ability to have sophisticated and consistent security for VMs across multi-hypervisor and multi-cloud environments.
[Update 11/26/12: the free Nexus 1000V virtual switch is available for download from here.]
Following on the heels of the announcement of our Nexus 1000V 2.1 release last month, Cisco is today announcing a new pricing and packaging strategy for its flagship virtual switch portfolio. Starting with that new 2.1 release, which is now in beta, we will have two editions of the Nexus 1000V, an Essential Edition and an Advanced Edition. The Nexus 1000V Essential Edition will be available for free, plus a nominal annual support fee, in a move that we believe will encourage customers and our partners to proliferate what has already become the most popular virtual switch in the industry with over 6,000 customers to date.
The Nexus 1000V Essential Edition provides all the rich Layer-2 networking features to connect virtual applications to the network and integrate into VMware environments, including: VXLAN capability, Cisco vPath service insertion, integration with vCloud Director, and a plug-in for management and monitoring in VMware’s vCenter Server. This free version will enable rapid, low-risk adoption of Cisco’s virtual network technology environments.
The Advanced Edition, priced at $695 per CPU, the same price as the current 1.5 release, includes:
The Cisco Virtual Security Gateway (VSG) for Nexus 1000V, a virtual firewall with visibility to virtual machine attributes for building sophisticated compliance policies, and logical trust zones between applications (VSG was previously sold as a separate product).
In my life, I had the honor of working on some of the most bleeding edge virtualization technologies of their day. My first was IBM’s VM, VSAM and a host of other v-words. My last was at XenSource (now Citrix) and Cisco, on what I still think is the most complete hypervisor of our age, true to its theoretical foundation in the Math paper I just mentioned.
Though Xen is arguably the most widely used hypervisor in the Cloud or sum of all servers in the world today, I actually think its most interesting accomplishment lies in what its founders just announced this week. Therefore, I want to extend my congratulations to my good friends Simon Crosby and Ian Pratt for the admirable work at Bromium with vSentry.
I think it is remarkable for two reasons. It addresses the missing part of what hypervisors are useful, which is security; for those of you that actually read Popek & Goldberg’s paper, you would note that VMM’s are very good at intercepting not just privileged but also sensitive instructions, and very few people out there, until now have focused on the latter, the security piece. But there is one more reason, in fact the key point of this paper, the necessary and sufficient conditions for a system to be able to have a VMM or hypervisor, and I am hoping the Xen guys who have done so well articulating that for real (not fictional or hyped) hypervisors, can also help sort our the hype from fiction in what is ambiguously called nowadays a “network hypervisor”.
Could this approach be what is actually missing, to sort out truth from hype in what we call SDN today? Is this the new age of hypervisors? Or is this just another useful application of an un-hyped hypervisor?
Last week at Cisco Live, Cisco unveiled the Cisco ONE strategy. I won’t go into detail on Cisco ONE in this blog post, there has been plenty of blog and analyst coverage of this elsewhere. One piece of the announcement I would like to talk about is the Nexus 1000V and it’s move to running on Open Source hypervisors, along with OpenStack Quantum integration.
Nexus 1000V on KVM With OpenStack: The Cisco Live Demo
At Cisco Live, we demonstrated the Nexus 1000V on KVM with integration into OpenStack. The demo included both the Nexus 1000V Virtual Supervisor Module (VSM), as well as the Virtual Ethernet Module (VEM). The VSM is a virtual machine running Cisco NX-OS software. For the demo, the VSM was running on a Nexus 1010 physical appliance. The VEM was running on the Linux host itself, which was running Fedora Linux, version 16. The OpenStack version we demoed was OpenStack Essex. We were running Nova, Glance, Keystone, Horizon and Quantum. We also wrote a Nexus 1000V Quantum plugin which handles interaction between Quantum and the Nexus 1000V VSM. This is done via a REST API on the Nexus 1000V VSM.
What we demonstrated was the ability for providers to create networks using the standard “nova-manage” CLI in OpenStack. These networks were then mapped to port-profiles on the Nexus 1000V VSM. When a tenant then powered up a VM, the VM was placed on the provider network, and ultimately had it’s VIF attached to the port-profile associated with the provider network. The network administrator, through the VSM, is now able to see the virtual interfaces attached to veth ports, and can apply policies on them. We demoed ACLs on the virtual ports, to demonstrate a Nexus 1000V feature in use with OpenStack. What the demo ultimately showed was the Nexus 1000V operational model separating network and server administrator in an OpenStack deployment.
Where To Go From Here
One thing we are planning to do around our Quantum plugin is to expose the port-profile concept as an extension to the standard Quantum API. This allows profiles to be managed by our Quantum plugin, and allows for us to provide the ability to expose profiles to users of Quantum via the extension API. One immediate benefit this allows for is a GUI such as Horizon to expose port-profile information back into their UI, allowing tenants to select port-profiles to map to virtual interfaces when powering up virtual machines. Effectively, this would allow for providers to create port-profiles and make them available for their tenants to select when powering up virtual machines. Providers can then control policy on the virtual interfaces on their networks.
The End Result
The result of integrating Nexus 1000V with Open Source hypervisors is allowing for the continued evolution of advanced virtual machine networking onto these platforms. OpenStack Quantum integration allows for the integration of the concept of network and server administrator separation into the OpenStack deployment model. Both of these are ultimately about providing more control, visibility, and programmability for customers. I think this is something customers will be excited about, just as we are excited about driving to deliver this to those same customers.