Open Stack

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) <pmurray at hpe.com>
wrote:

>
>
> From: Matthew Booth
> Reply-To: "openstack-dev at lists.openstack.org"
> Date: Friday, 30 September 2016 at 17:03
> To: "openstack-dev at 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) <pmurray at hpe.com>
> wrote:
>
>>
>>
>>
>>
>>
>> On 27/09/2016, 18:12, "Daniel P. Berrange" <berrange at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161003/e011824d/attachment.html>