Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On 12/03/2013 04:59 PM, Alessandro Pilotti wrote: > BTW didn't you want to come to the Hyper-V session in HK to talk about this > (off)topic? :-) Yeah. I'm sorry I couldn't be there. Conflicts at the design summit are both tough and unavoidable. I sometimes have sessions in other tracks that I *really* need to be in. For those cases, I always make sure that there are other nova-core members that are still able to attend the nova sessions that know my positions on things and that I trust, and then I sync up with them later on what happened. This was the case for the Hyper-V session. FWIW, the conflict in this case was the "Icehouse release schedule & coordination" session, which is pretty much a requirement for all PTLs. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
> On 03.12.2013, at 21:20, "Russell Bryant" wrote: > >> On 12/03/2013 04:27 AM, Daniel P. Berrange wrote: >>> On Mon, Dec 02, 2013 at 07:23:19PM +, Alessandro Pilotti wrote: >>> >>> On 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) >>> wrote: >>> This is very cool Alessandro, thanks for sharing! Any plans to try and get this nova driver upstreamed? >>> >>> My personal opinion is that drivers should stay outside of Nova in a >>> separate project. > > Oh, so when are we dropping Hyper-V (again) ? :-) Now we have two drivers to drop at the price of one! BTW didn't you want to come to the Hyper-V session in HK to talk about this (off)topic? :-) > >> If drivers were to live in separate projects we would be forced to maintain >> Nova internal code as stable APIs to avoid breaking drivers during the dev >> cycle. This would place a significant burden on Nova development and have a >> negative impact on the overal ease of development. It would also discourage >> collaboration and sharing of code between virt drivers, which is already a >> significant problem today whereby drivers come up with different ways todo >> the same thing. If you want to be isolated from the community in a separate >> project then expect your code to be broken periodically during development. >> If you don't want that, then put the code in tree and be an active part of >> the community effort working together, instead of in isolation. > > I generally agree here. If a driver wants to be separate, that's fine, > there's nothing stopping you. It just has to be done with the > understanding that it's build on unstable APIs, and you will need > something to ensure you keep up. That is probably CI. And if you're > doing CI on the driver, you've met one of the most difficult requirments > to being in Nova. > > Someone may also want to have a driver separate for control reasons. > I'd be surprised if that was really a factor with this particular > driver, though. > > -- > Russell Bryant > > ___ > 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
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On 12/03/2013 04:27 AM, Daniel P. Berrange wrote: > On Mon, Dec 02, 2013 at 07:23:19PM +, Alessandro Pilotti wrote: >> >> On 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) >> wrote: >> >>> This is very cool Alessandro, thanks for sharing! Any plans to try and get >>> this >>> nova driver upstreamed? >> >> My personal opinion is that drivers should stay outside of Nova in a >> separate project. Oh, so when are we dropping Hyper-V (again) ? :-) > If drivers were to live in separate projects we would be forced to maintain > Nova internal code as stable APIs to avoid breaking drivers during the dev > cycle. This would place a significant burden on Nova development and have a > negative impact on the overal ease of development. It would also discourage > collaboration and sharing of code between virt drivers, which is already a > significant problem today whereby drivers come up with different ways todo > the same thing. If you want to be isolated from the community in a separate > project then expect your code to be broken periodically during development. > If you don't want that, then put the code in tree and be an active part of > the community effort working together, instead of in isolation. I generally agree here. If a driver wants to be separate, that's fine, there's nothing stopping you. It just has to be done with the understanding that it's build on unstable APIs, and you will need something to ensure you keep up. That is probably CI. And if you're doing CI on the driver, you've met one of the most difficult requirments to being in Nova. Someone may also want to have a driver separate for control reasons. I'd be surprised if that was really a factor with this particular driver, though. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On Mon, Dec 02, 2013 at 07:23:19PM +, Alessandro Pilotti wrote: > > On 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) wrote: > > >> > >> > > This is very cool Alessandro, thanks for sharing! Any plans to try and get > > this > > nova driver upstreamed? > > My personal opinion is that drivers should stay outside of Nova in a separate > project. If drivers were to live in separate projects we would be forced to maintain Nova internal code as stable APIs to avoid breaking drivers during the dev cycle. This would place a significant burden on Nova development and have a negative impact on the overal ease of development. It would also discourage collaboration and sharing of code between virt drivers, which is already a significant problem today whereby drivers come up with different ways todo the same thing. If you want to be isolated from the community in a separate project then expect your code to be broken periodically during development. If you don't want that, then put the code in tree and be an active part of the community effort working together, instead of in isolation. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On 02/dic/2013, at 23:47, "Vishvananda Ishaya" mailto:vishvana...@gmail.com>> wrote: On Dec 2, 2013, at 11:40 AM, Alessandro Pilotti mailto:apilo...@cloudbasesolutions.com>> wrote: On 02 Dec 2013, at 20:54 , Vishvananda Ishaya 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 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
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On Dec 2, 2013, at 11:40 AM, Alessandro Pilotti wrote: > > On 02 Dec 2013, at 20:54 , Vishvananda Ishaya 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.). > > >> 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 >> 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 compon
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On 02 Dec 2013, at 20:54 , Vishvananda Ishaya 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. :-) 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 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,
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) wrote: > On Dec 1, 2013, at 4:10 PM, Alessandro Pilotti > 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://li
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
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: nova boot --flavor 1 --iso CentOS-64-ks --floppy Kickstart (defaults to blank image) 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 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 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On Sun, Dec 1, 2013 at 11:10 PM, Alessandro Pilotti < apilo...@cloudbasesolutions.com> wrote: > We’ll follow up with a blog post with some additional news related to this > project quite soon. > really cool, I'd love to use that for my apple laptop. It would be nice if it goes on stackforge which should be easier to contribute. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VMware Workstation / Fusion / Player Nova driver
On Dec 1, 2013, at 4:10 PM, Alessandro Pilotti 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
[openstack-dev] VMware Workstation / Fusion / Player Nova driver
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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
