From: Matthew Booth Reply-To: "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" Date: Friday, 30 September 2016 at 17:03 To: "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" Subject: Re: [openstack-dev] [nova][libvirt] Lets make libvirt's domain XML canonical
On Fri, Sep 30, 2016 at 4:38 PM, Murray, Paul (HP Cloud) <pmur...@hpe.com<mailto:pmur...@hpe.com>> wrote: On 27/09/2016, 18:12, "Daniel P. Berrange" <berra...@redhat.com<mailto: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. Rescue currently saves the libvirt xml in a separate file and replaces it with new xml to define a vm with a rescue boot disk; to unrescue it replaces the libvirt xml used for the rescue with the saved file to go back to the original state. On migration that saved xml would be lost because its an arbitrary file that is not handled in the migration. The spec above relies on the fact that we do not need to save it or copy it because we can recreate it from nova. So yes, the migration just works for the rescued vm, but when it is unrescued the original libvirt xml would be regenerated. Paul
__________________________________________________________________________ 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
