qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH V2] migration: file URI


From: Fabiano Rosas
Subject: Re: [PATCH V2] migration: file URI
Date: Thu, 15 Jun 2023 11:50:28 -0300

Peter Xu <peterx@redhat.com> writes:

> On Wed, Jun 14, 2023 at 02:59:54PM -0300, Fabiano Rosas wrote:
>> In this message Daniel mentions virDomainSnapshotXXX which would benefit
>> from using the same "file" migration, but being done live:
>> 
>> https://lore.kernel.org/r/ZD7MRGQ+4QsDBtKR@redhat.com
>> 
>> And from your response here:
>>  https://lore.kernel.org/r/ZEA759BSs75ldW6Y@x1n
>> 
>> I had understood that having a new SUSPEND cap to decide whether to do
>> it live or non-live would be enough to cover all use-cases.
>
> Oh, I probably lost some of the contexts there, sorry about that - so it's
> about not being able to live snapshot on !LINUX worlds properly, am I
> right?
>

Right, so that gives us for now a reasonable use-case for keeping live
migration behavior possible with "file:".

> In the ideal world where we can always synchronously tracking guest pages
> (like what we do with userfaultfd wr-protections on modern Linux), the
> !SUSPEND case should always be covered by CAP_BACKGROUND_SNAPSHOT already
> in a more performant way.  IOW, !SUSPEND seems to be not useful to Linux,
> because whenever we want to set !SUSPEND we should just use BG_SNAPSHOT.
>

I agree.

> But I think indeed the live snapshot support is not good enough. Even on
> Linux, it lacks different memory type supports, multi-process support, and
> also no-go on very old kernels.  So I assume the fallback makes sense, and
> then we can't always rely on that.
>
> Then I agree we can keep "file:" the same as others like proposed here, but
> I'd like to double check with all of us so we're on the same page..

+1

> And maybe we should mention some discussions into commit message or
> comments where proper in the code, so we can track what has happened
> easier.
>

I'll add some words where appropriate in my series as well. A v2 is
already overdue with all the refactorings that have happened in the
migration code.



reply via email to

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