On 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) <kmest...@cisco.com> wrote:
> 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! My personal opinion is that drivers should stay outside of Nova in a separate project. Said that, this driver is way easier to mantain than the Hyper-V one for example, so I wouldn’t have objections if this is what the community prefers. On the other side, this driver will hardly have a CI as it’s not a requirement for the expected usage and this wouldn’t fit with the current (correct IMO) decision that only drivers with a CI gate will stay in Nova starting with Icehouse. Said that, I would’t have of course anything against somebody (VMware?) volunteering for the CI. ;-) IMO, as also Chmouel suggested in this thread, a Stackforge project could be a good start. This should make it easier for people to contribute and we’ll have a couple of release cycles to decide what to do with it. Alessandro > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
