Hi, I am Xing, a PHD candidate in University of Utah. I am also quite interested in container-based virtualization. That's why I register this email list. :) Now, I am working on Container migration of OpenVZ in Emulab. I just begin to hack OpenVZ kernel. On Sun, Mar 21, 2010 at 3:36 PM, Oren Laadan <orenl@xxxxxxxxxxxxxxx> wrote: > > Let's separate the issues of file system snapshot and deleted files. > > 1) File system snapshot: > ------------------------ > The requirement is to preserve the file system state between the time > of the checkpoint and the time of the restart, because userspace will > expect it to remain the same. > > The alternatives are: > > a) Use capable file system, like brfs, or (modified) nilfs. > Do you mean btrfs? These two file systems both support snapshot. Sound great. b) Userspace saves the state e.g. w/ tar or rsync (maybe incremental) > > c) Assume/expect that the file system isn't modified between checkpoint > and restart (e.g. if we use c/r to suspend a user's session) > This is what OpenVZ does. OpenVZ assumes the underlying file system to be consistent during checkpoint and restart. If the file does not exist when restoring the container, the restoring will fail(It will give a message to show which file can not be found). OpenVZ also does not support nfs. If a nfs is mounted in the container's file system, this container can not be suspended. Since we want to enable container migration in Emulab, so we are trying to solve these issues. nfs is the big issue since almost all users will store their files at their home directories which are mounted from the nfs server. We are still discussing how to deal with this. -- Regards, Xing School of Computing, University of Utah http://www.cs.utah.edu/~xinglin/ _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
