On 02/dic/2013, at 23:47, "Vishvananda Ishaya" <vishvana...@gmail.com<mailto:vishvana...@gmail.com>> wrote:
On Dec 2, 2013, at 11:40 AM, Alessandro Pilotti <apilo...@cloudbasesolutions.com<mailto:apilo...@cloudbasesolutions.com>> wrote: On 02 Dec 2013, at 20:54 , Vishvananda Ishaya <vishvana...@gmail.com<mailto:vishvana...@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. :-) I'm not sure exactly what the problem is here. Pulling them down from glance before boot seems like the way that other hypervisors would implement it as well. The block device mapping code was extended in havana so it doesn't just support volume/iscsi connections. You can specify where the item should be attached in addition to the source of the device (glance, cinder, etc.). I have to say that I still used it for iSCSI volumes only. If Glance is supported, not only all my objections below are irrelevant, but it's also a great solution! Adding it right away! 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. I think my above comment handles this. Block device mapping was designed to support floppies and ISOs as well 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. Couldn't this also be handled by above i.e. upload the install media to glance as an iso instead of a volume? Vish 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 <apilo...@cloudbasesolutions.com<mailto: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. Thanks, Alessandro _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
