The science behind Virtual Machine Monitors, or VMM, aka Hypervisors, was demystified almost half a century ago, in a famous ACM publication, “Formal Requirements for Virtualizable Third Generation Architectures”.
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?
Tags: Cisco, hypervisor, network, network hypervisor, open source, SDN, security, virtualization, vmm, Xen
The practice of using Open Source Software (OSS) and other third-party software (TPS) to build products and services is well established. Not only can it create tremendous efficiency--why build an operating system or web server if you don’t need to?--it also allows individual products to leverage best-of-breed functionality. This best-of-breed functionality can be critical on today’s Internet as security and scalability are often difficult or even patently ignored until it is too late.
The use of TPS to build things has been so successful and is so widespread that many products may even be assembled from a majority of software written by unknown third parties. This practice is not without its challenges. One of those challenges is security.
How does the security of a product’s constituent TPS affect its own security? How does the creator of the product learn of, manage and ultimately resolve security issues that originate in the relevant TPS packages?
These are the types of questions I attempted to address during a recent presentation at O’Reilly OSCON 2012. During that session I touched on seven challenges and offered five tools that I believe can make a difference.
Our friends on the Cisco Security Marketing team have posted the slides from that presentation online at slideshare.net.
Is this an area of concern for you? If it is, I’d like to know how you are tackling it. What is working well? What is working not-so well?
Tags: open source, product security, security, third party software
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.
Tags: KVM, Nexus 1000v, open source, OpenStack, Xen
It’s finally out! The Architecture of Open Source Applications, Volume II, is now available in dead tree form (PDFs will be available for sale soon, I’m told).
Additionally, all content from the book will also be freely available on aosabook.org next week sometime (!).
But know this: all royalties from the sales of this book go to Amnesty International. So buy a copy; it’s for a good cause.
Both volumes 1 and 2 are excellent educational material for seeing how other well-known open source applications have been architected. What better way to learn than to see how successful, widely-used open source software packages were designed? Even better, after you read about each package, you can go look at the source code itself to further grok the issues.
Read More »
Tags: HPC, mpi, Open MPI, open source
We’ve held our annual Cisco Open Source event this week, on May 1st in San Jose. I’m very impressed to see the large turnout and the ultra positive feedback after the keynote and 5 tracks on Linux, SDN, Big Data, Emerging Technologies and Community Development. Wonderful to see Irving Wladawsky-Berger from IBM, Jim Zemlin from the Linux Foundation, Simon Crosby from Bromium and the great discussions that ensued. Next time we’ll have to open this event up to more than just one afternoon, there is just so much open collaboration that is taking place. My thanks to our track leads, Michael Hein who helped me put together the Linux track, Jan Medved and Dave Ward on SDN, Mark Voelker and Ed Warnicke on Big Data, Fabio Maino and Flavio Bonomi on Emerging Technologies, and Peter Saint-Andre for the Community Management and Tools — these guys have already left their mark on timeless and enduring open standards, but it’s amazing to see how good they are in open source! We’ll have to post the key takeaways in these next blog entries, for now to all those of you who came, contributed and enjoyed this event, we salute you! Open at Cisco is a vibrant and growing community.
Tags: Big Data, Cisco, Linux, open source, SDN