[openstack-dev] VMware Workstation / Fusion / Player Nova driver

Alessandro Pilotti apilotti at cloudbasesolutions.com
Mon Dec 2 19:40:38 UTC 2013


On 02 Dec 2013, at 20:54 , Vishvananda Ishaya <vishvananda at gmail.com<mailto:vishvananda at gmail.com>> wrote:

Very cool stuff!

Seeing your special glance properties for iso and floppy connections made me think
of something. They seem, but it would be nice if they were done in a way that would
work in any hypervisor.

I "think" we have sufficient detail in block_device_mapping to do essentially the
same thing, and it would be awesome to verify and add some nicities to the nova
cli, something like:


Thanks Vish!

I was also thinking about bringing this to any hypervisor.

About the block storage option, we would have an issue with Hyper-V. We need local (or SMB accessible) ISOs and floppy images to be assigned to the instances.
IMO this isn’t a bad thing: ISOs would be potentially shared among instances in read only mode and it’s easy to pull them from Glance during live migration.
Floppy images on the other hand are insignificant quantity. :-)


nova boot --flavor 1 --iso CentOS-64-ks --floppy Kickstart (defaults to blank image)


This would be great! For the reasons above, I’d go anyway with some simple extensions to pass in the ISO and floppy refs in the instance data instead of block device mappings.

There’s also one additional scenario that would greatly benefit from those options: our Windows Heat templates (think about SQL Server, Exchange, etc) need to access the product media for installation and due to
license constraints the tenant needs to provide the media, we cannot simply download them. So far we solved it by attaching a volume containing the install media, but it’s of course a very unnatural process for the user.

Alessandro


Clearly that requires a few things:

1) vix block device mapping support
2) cli ux improvements
3) testing!

Vish

On Dec 1, 2013, at 2:10 PM, Alessandro Pilotti <apilotti at cloudbasesolutions.com<mailto:apilotti at 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.


Thanks,

Alessandro


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/90bacf58/attachment.html>


More information about the OpenStack-dev mailing list