Hi team, I agree that it's kind of strange thing that nova dumps xml definition to the disk but doesn't use it(at least I do not aware of it). How the proposed changed would be aligned with other drivers? The worst case I could imagine here is that libvirt has an xml as a source of truth, while others use nova for the same purposes. Taking that into account, the question here would be: why not to store all required information(e.g. boot order) in DB instead?
Timofey On Fri, Sep 30, 2016 at 7:36 PM, Murray, Paul (HP Cloud) <pmur...@hpe.com> wrote: > > > From: Matthew Booth > Reply-To: "openstack-dev@lists.openstack.org" > Date: Friday, 30 September 2016 at 17:03 > To: "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> > 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-re >> scued-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 > >
__________________________________________________________________________ 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
