On Fri, Sep 30, 2016 at 4:38 PM, Murray, Paul (HP Cloud) <pmur...@hpe.com> wrote:
> > > > > > On 27/09/2016, 18:12, "Daniel P. Berrange" <berra...@redhat.com> wrote: > > >On Tue, Sep 27, 2016 at 10:40:34AM -0600, Chris Friesen wrote: > >> On 09/27/2016 10:17 AM, Matthew Booth wrote: > >> > >> > I think we should be able to create a domain, but once created we > should never > >> > redefine a domain. We can do adding and removing devices dynamically > using > >> > libvirt's apis, secure in the knowledge that libvirt will persist > this for us. > >> > When we upgrade the host, libvirt can ensure we don't break guests > which are on > >> > it. Evacuate should be pretty much the only reason to start again. > >> > >> Sounds interesting. How would you handle live migration? > >> > >> Currently we regenerate the XML file on the destination from the nova > DB. I > >> guess in your proposal we'd need some way of copying the XML file from > the > >> source to the dest, and then modifying the appropriate segments to > adjust > >> things like CPU/NUMA pinning? > > > >Use the flag VIR_MIGRATE_PERSIST_XML and libvirt will write out the > >new persistent XML on the target host automatically. > > We have a problem migrating rescued instances that has a fix in progress > based > on regenerating the xml on unrescue, see: > > https://blueprints.launchpad.net/nova/+spec/live-migrate- > rescued-instances > > That might be another case for generating the xml. > I thought it was a counter-argument (unless I've misunderstood). If you migrate the instance as-is without modification, you don't need to worry about whether it's currently a rescue instance. This problem goes away. The major complication I can think of is things which genuinely must change during a migration, for example cpu pinning. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK)
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
