On Wed, Dec 19, 2018 at 12:42 AM Sage Weil <sage@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@hyper.sh