Open Stack

On Wed, Dec 19, 2018 at 12:42 AM Sage Weil <sage at newdream.net> wrote:
>
> On Tue, 18 Dec 2018, Stefan Hajnoczi wrote:
> > On Tue, Dec 18, 2018 at 02:19:26AM +0000, zhangwei (CR) wrote:
> > > Virtio-fs is in RFC state, it could be OK as long as it doesn't have native gap for supporting live migration,  and I will be glad to see it being listed in some roadmap.
> >
> > Migration is always good to have at the QEMU level, so I'm sure we'll
> > look into it more deeply.
> >
> > It's tricky when sharing local file systems because the
> > destination host must have access to the same files in order for
> > migration to be possible.  One approach is to carefully copy the files
> > during live migration.  The  file system daemon must also migrate its
> > state (e.g. open files and handles).  It's non-trivial but can be done
> > with enough development effort.
>
> I think the live migration case is only going to make sense when the files
> in question are on a network file system and the same path is available at
> the destination.
I agree. Live migration should be considered from a total solution POV
not just in the container runtime itself. Other important parts
include network migration and storage migration. For storage, it is
more often to use a shared or distributed storage rather than trying
to move data between hosts.

OTOH, virtio-fs is a special case here. Even if the files are backed
by a remote file system, we still need to migrate the user space fuse
daemon otherwise all the file handles are invalidated, or we design
the fuse daemon to be able to re-instantiate itself.

>
> (I think it also makes sense that this is something KubeVirt will be more
> interested in than Kata!)
Sure, it mostly rests in the realm of KubeVirt, but kata is also
interested in keeping the container states especially for cloud
providers to provide non-disruptive service.

Cheers,
Tao
-- 
bergwolf at hyper.sh