On Dec 1, 2013, at 4:10 PM, Alessandro Pilotti <apilo...@cloudbasesolutions.com> wrote: > > 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. > > This is very cool Alessandro, thanks for sharing! Any plans to try and get this nova driver upstreamed?
Thanks, Kyle > Thanks, > > Alessandro > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev