Open Stack

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-
> 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.

Matt

-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160930/fd3d6287/attachment.html>