[CRIU] [PATCH RFC 7/8] criu: uffd: add --lazy-addr option

Pavel Emelyanov xemul at virtuozzo.com
Fri Jun 17 03:36:08 PDT 2016


On 06/16/2016 07:48 PM, Mike Rapoport wrote:
> On Thu, Jun 16, 2016 at 6:45 PM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>> On 06/15/2016 08:36 AM, Mike Rapoport wrote:
>>> On Fri, May 27, 2016 at 10:33 PM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>>>> On 05/21/2016 01:49 PM, Mike Rapoport wrote:
>>>>> to distinguish between UNIX socket address for passing uffd and the address
>>>>> of the remote dump
>>>>
>>>> Would you show when the --addredd and --lazy-addr confusion may occur?
>>>
>>> Well, we can skip --lazy-addr if we will fork() lazy-pages from
>>> cr-restore. Then the unix socket will be created in cr-restore and
>>> inherited by lazy-pages daemon.
>>
>> Yup, that should be the default behavior for migration.
>>
>>> Another possibility is to make lazy-pages daemon a variation of the
>>> page-server that does not depend on existing checkpoint directory,
>>> like Adrian suggested a while ago.
>>
>> For lazy restore from previously collected images. Yes.
> 
> I think we are talking about different things here :)
> I meant that lazy-pages could be started on its own, without reading
> checkpoint directory and then it'll get the required info from the
> cr-restore that connects to it.

Then we'll have to add "--images-dir $dir" option to the protocol with
lazy daemon, won't we?

> It's not related to difference between migration or lazy-restore from images...
> 
>>> Then it will get the required information via the unix socket. For
>>> instance, in addition to pid and uffd, lazy-pages daemon will receive
>>> the path to relevant checkpoint directory.
>>
>> Hm, what if we put the lazy socket into the images directory?
>> Or, more exactly, into __working__ directory (which coincides with
>> the images one if not specified separately).
> 
> Yes, we can :)
> I'll give it a try.

Thanks!

-- Pavel



More information about the CRIU mailing list