Open Stack

From: Matthew Booth
Reply-To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>"
Date: Friday, 30 September 2016 at 17:03
To: "openstack-dev at lists.openstack.org<mailto: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<mailto:pmurray at hpe.com>> wrote:





On 27/09/2016, 18:12, "Daniel P. Berrange" <berrange at redhat.com<mailto: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-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160930/10b3ba42/attachment.html>