Open Stack

On Fri, Sep 30, 2016 at 04:36:31PM +0000, Murray, Paul (HP Cloud) wrote:
> 
> 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.

During rescue, nova should really not be touching the XML on disk at all. That
should have been left to reflect the "normal" XML of the guest. Instead nova
should have just called 'createXML' method, to boot the guest with a one-time
different XML config. There is no reason to define the XM on disk with the
custom rescue config.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|