qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] migration: do not exit on incoming failure


From: Daniel P . Berrangé
Subject: Re: [PATCH] migration: do not exit on incoming failure
Date: Thu, 18 Apr 2024 16:43:27 +0100
User-agent: Mutt/2.2.12 (2023-09-09)

On Thu, Apr 18, 2024 at 06:40:38PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 18.04.24 17:37, Daniel P. Berrangé wrote:
> > On Thu, Apr 18, 2024 at 01:13:29AM +0300, Vladimir Sementsov-Ogievskiy 
> > wrote:
> > > We do set MIGRATION_FAILED state, but don't give a chance to
> > > orchestrator to query migration state and get the error.
> > > 
> > > Let's report an error through QAPI like we do on outgoing migration.
> > > 
> > > migration-test is updated correspondingly.
> > > 
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> > > ---
> > > 
> > > Doubt: is exiting on failure a contract? Will this commit break
> > > something in Libvirt? Finally, could we just change the logic, or I need
> > > and additional migration-parameter for new behavior?
> > 
> > There's a decent risk that this could break apps, whether
> > libvirt or something else, especially if the app is just
> > launching QEMU with '-incoming URI', rather than using
> > '-incoming defer' and then explicitly using QMP to start the
> > incoming migration.
> > 
> > I'd say that with '-incoming defer' we should *not* exit on
> > migration error, because that arg implies the app explicitly
> > wants to be using QMP to control migration.
> > 
> > With the legacy '-incoming URI' it is probably best to keep
> > exit on error, as that's comparatively more likely to be used
> > in adhoc scenarios where the app/user is ignoring QMP on the
> > dst side.
> > 
> > None the less, I think we need to check how libvirt behaves
> > with this patch to be sure of no surprises.
> > 
> 
> Sounds reasonable, thanks! I'll rework it to behave the new
> way only with "-incoming defer", and check how libvirt behave with it.

If there are problems and/or we want to be super safe wrt
backcompat, we could add a new  '-incoming managed' as
being equivalent to '-incoming defer' but without the
implicit exit.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]