I think depending on use-case it can be accomplished. The steps we have been thinking at Y!
1. Take offline APIs & nova-compute (so new/existing VMs can't be scheduled/modified) -- existing running VMs will not be affected. 2. Save/dump nova database. 3. Translate nova database entries into corresponding neutron database entries. 4. Remove/adjust the *right* entries of the nova database. 5. Startup neutron+agents with database that it believes it was running with the whole time. 6. Restart nova-api & nova-compute (it will now never know that it was previously using nova-network). 7. Profit! Depending on the use-case and how complex your impl. is something like the above should work. Of course the devil is in the details ;) On 1/29/14, 11:50 AM, "Tim Bell" <[email protected]> wrote: > >I'm not seeing a path to migrate 1,000s of production VMs from nova >network to Neutron. > >Can someone describe how this can be done without downtime for the VMs ? > >Can we build an approach for the cases below in a single OpenStack >production cloud: > >1. Existing VMs to carry on running without downtime (and no new features) >2. Existing VMs to choose a window for reconfiguration for Neutron (to >get the new function) >3. New VMs to take advantage of Neutron features such as LBaaS >- >Tim > >> -----Original Message----- >> From: Russell Bryant [mailto:[email protected]] >> Sent: 29 January 2014 19:04 >> To: Daniel P. Berrange >> Cc: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse >>and beyond >> >> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote: >> > I was thinking of an upgrade path more akin to what users got when we >> > removed the nova volume driver, in favour of cinder. >> > >> > https://wiki.openstack.org/wiki/MigrateToCinder >> > >> > ie no guest visible downtime / interuption of service, nor running of >> > multiple Nova instances in parallel. >> >> Yeah, I'd love to see something like that. I would really like to see >>more effort in this area. I honestly haven't been thinking about it >> much in a while personally, because the rest of the "make it work" gaps >>have still been a work in progress. >> >> There's a bit of a bigger set of questions here, too ... >> >> Should nova-network *ever* go away? Or will there always just be a >>choice between the basic/legacy nova-network option, and the >> new fancy SDN-enabling Neutron option? Is the Neutron team's time >>better spent on OpenDaylight integration than the existing >> open source plugins? >> >> Depending on the answers to those questions, the non-visible >>no-downtime migration path may be a less important issue. >> >> -- >> Russell Bryant >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
