[openstack-dev] VMware Workstation / Fusion / Player Nova driver
Alessandro Pilotti
apilotti at cloudbasesolutions.com
Sun Dec 1 22:10:15 UTC 2013
Hi all,
At Cloudbase we are heavily using VMware Workstation and Fusion for development, demos and PoCs, so we thought: why not replacing our automation scripts with a fully functional Nova driver and use OpenStack APIs and Heat for the automation? :-)
Here’s the repo for this Nova driver project: https://github.com/cloudbase/nova-vix-driver/
The driver is already working well and supports all the basic features you’d expect from a Nova driver, including a VNC console accessible via Horizon. Please refer to the project README for additional details.
The usage of CoW images (linked clones) makes deploying images particularly fast, which is a good thing when you develop or run demos. Heat or Puppet, Chef, etc make the whole process particularly sweet of course.
The main idea was to create something to be used in place of solutions like Vagrant, with a few specific requirements:
1) Full support for nested virtualization (VMX and EPT).
For the time being the VMware products are the only ones supporting Hyper-V and KVM as guests, so this became a mandatory path, at least until EPT support will be fully functional in KVM.
This rules out Vagrant as an option. Their VMware support is not free and beside that they don’t support nested virtualization (yet, AFAIK).
Other workstation virtualization options, including VirtualBox and Hyper-V are currently ruled out due to the lack of support for this feature as well.
Beside that Hyper-V and VMware Workstation VMs can work side by side on Windows 8.1, all you need is to fire up two nova-compute instances.
2) Work on Windows, Linux and OS X workstations
Here’s a snapshot of Nova compute running on OS X and showing Novnc connected to a Fusion VM console:
https://dl.dropboxusercontent.com/u/9060190/Nova-compute-os-x.png
3) Use OpenStack APIs
We wanted to have a single common framework for automation and bring OpenStack on the workstations.
Beside that, dogfooding is a good thing. :-)
4) Offer a free alternative for community contributions
VMware Player is fair enough, even with the “non commercial use” limits, etc.
Communication with VMware components is based on the freely available Vix SDK libs, using ctypes to call the C APIs. The project provides a library to easily interact with the VMs, in case it sould be needed, e.g.:
from vix import vixutils
with vixutils.VixConnection() as conn:
with conn.open_vm(vmx_path) as vm:
vm.power_on()
We though about using libvirt, since it has support for those APIs as well, but it was way easier to create a lightweight driver from scratch using the Vix APIs directly.
TODOs:
1) A minimal Neutron agent for attaching networks (now all networks are attached to the NAT interface).
2) Resize disks on boot based on the flavor size
3) Volume attach / detach (we can just reuse the Hyper-V code for the Windows case)
4) Same host resize
Live migration is not making particularly sense in this context, so the implementation is not planned.
Note: we still have to commit the unit tests. We’ll clean them during next week and push them.
As usual, any idea, suggestions and especially contributions are highly welcome!
We’ll follow up with a blog post with some additional news related to this project quite soon.
Thanks,
Alessandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131201/b58b499c/attachment.html>
More information about the OpenStack-dev
mailing list