This blog post has been updated to include details on a related talk we’ve proposed for the upcoming OpenStack Summit. You can find out more about the voting process and learn about other talks submitted by Platform9 by reading our prior blog post.
VMware vSphere and OpenStack are the shining stars in their respective fields – virtualization and private clouds. Theoretically, this means that combining the two technologies should make for instant success. The reality though is that the majority of OpenStack implementations today uses Kernel-based Virtual Machine (KVM) as the hypervisor. And for those organizations that have both vSphere and OpenStack in-house, they tend to be run as separate silos, each requiring its own dedicated management processes.
A majority of the Platform9 engineering team has worked at VMware; so we have had the opportunity to watch VMware’s own virtualization and management platforms grow and become the industry standard over the past decade. Given that context, we believe that vSphere and OpenStack can work very well together if engineered correctly. At Platform9, we have a rather opinionated take on what an ideal vSphere and OpenStack integration story should look like.
Our Vision for Private Clouds
Platform9’s private cloud manifesto is very straight-forward… We want to make the deployment of private clouds drop-dead simple. Back in January at Tech Field Day, we presented our vision behind what an ideal private cloud should look like. For us, an ideal private cloud should include – 1) 100% automated provisioning, 2) Integration with in-house infrastructure, 2) Ease of use for authorized end-users while satisfying IT policies.
Let’s elaborate a bit further on this:
- 100% automated provisioning – This means the end users are given self-service access to cloud resources and they can access them via a GUI, via a CLI, or via APIs in order to achieve end-to-end automation, without requiring manual approval from IT Ops.
- Integration with in-house infrastructure – 70% of the world’s compute capacity lives in private data centers today. Your private cloud should let you leverage all your existing infrastructure, without discrimination.
- Ease of use for authorized end users while satisfying IT policies – Under the hood, your private cloud is still powered by hardware that IT manages. Building an efficient private cloud requires being able to set the right policies, resource pools, resource tiers, and quotas such that IT feels comfortable extending self-service access to its end users.
Why Support VMware vSphere?
VMware vSphere is still the gold standard when it comes to a tried and tested virtualization platform that just works. Majority of the world’s enterprise data centers are powered by vSphere today. It is a robust hypervisor that many IT organizations choose for the stability and production-readiness of features such as resource clustering, DRS, vMotion, etc.
Most organizations that use VMware vSphere today however consume it via vCenter, which offers a manual way to manage your resources. This results in a process-driven model, where virtual machines are provisioned by VMware admins who receive request tickets from developers and have to manually address these requests. Layering OpenStack on vSphere has the potential to give you the best of both worlds – an Amazon AWS-style agile, self-service private cloud utilizing a production-grade world class hypervisor that is ideal for the majority of workloads in today’s data centers.
Challenges Ahead for VMware vSphere with OpenStack
Ok, so vSphere + OpenStack is a great idea and OpenStack already supports vSphere and provides a driver for it. Why the need for this discussion then?
Unfortunately, the capabilities in the current vSphere driver for OpenStack are limited, to say the least. A number of built-in assumptions and restrictions make it extremely difficult for an enterprise user of vSphere to seamlessly integrate with OpenStack. Some of these restrictions are tied to the core design of OpenStack and others to the way the vSphere OpenStack driver is built.
As an example, all OpenStack deployments with vSphere (including VMware Integrated OpenStack or VIO) assume that the private cloud is being deployed from scratch. This presents a fundamental on-boarding problem though, as the majority of organizations running vSphere today have large pools of existing workloads that would need some special treatment if one were to create a brand new OpenStack + VMware environment from scratch.
Over a series of posts to follow, we will get deeper into specific areas where OpenStack integration with vSphere should do better. These include, but are not limited to:
- Workload discovery: A good vSphere OpenStack integration should non-disruptively layer on top of existing infrastructure, not encourage users to create brand new silos.
- New workloads: Allow creation of new workloads that conform to cloud policies like user quotas, roles, etc.
- Support for Templates: vSphere Templates should be treated as first-class citizens in OpenStack, allowing for quick deployment of VMs using these templates.
- Software-defined Networking: A vSphere user should be able to leverage his existing vSwitch (or DVSwitch) based networking and layer Neutron-based software-defined networks on top.
- Multiple Clusters and multiple vCenters: Allow the use of multiple clusters as compute resources.
At Platform9, we believe there is great potential to make private cloud deployment and management drop dead simple for end-users. And to make the transition from virtualized infrastructure to a private cloud correspondingly simple as well, we want to make vSphere a first class hypervisor in OpenStack that is easy to deploy and manage.
In future blog posts, we will be providing further details on what we believe such an integration should entail and the work we’re doing at Platform9 to bring this vision into reality. We have also submitted a talk for the upcoming OpenStack Summit that will propose new features that will enable dynamic discovery of existing virtualize infrastructure for both KVM and vSphere environments. We will be using our own experience of moving existing dev/test workloads and infrastructure to an OpenStack-based private cloud running vSphere as an example. This use case takes advantage of features outlined in this post using code that we want to propose contributing to the OpenStack project. We hope you will consider voting for this talk and attending, should it be accepted, so you can be a part of the discussion.