[CRIU] [RFC] mount: Add ability to c/r devtmpfs

[Serge Hallyn]

Quoting Cyrill Gorcunov (gorcunov at gmail.com):
> On Fri, Oct 17, 2014 at 07:54:51AM +0000, Serge Hallyn wrote:
> > Quoting Cyrill Gorcunov (gorcunov at gmail.com):
> > > On Thu, Oct 16, 2014 at 08:57:40PM +0000, Serge Hallyn wrote:
> > > > Quoting Cyrill Gorcunov (gorcunov at openvz.org):
> > > > > Looking into experiments with OpenVZ kernel
> > > > > it seems plain tar over devtmpfs should be
> > > > > enough for a while. So here is a new option
> > > > > comes in "--devtmpfs-content".
> > > > 
> > > > Hi - so I'm pretty sure this is the case, but just want to make 100%
> > > > sure, and looking at the criu git HEAD didn't help me - when this
> > > > gets restore, it will be mounted as tmpfs right?  (not devtmpfs, I
> > > > hope?)
> > > 
> > > Hi, Serge! It's mounted as devtmpfs on restore and the option
> > > --devtmpfs-content simply untar devices to newly mounted fs.
> > > Because in vanilla kernel devtmpfs is not virtualized at all
> > > this option is mostly for custom kernels such as openvz (or
> > > any other which implements devtmpfs virtualization). IOW,
> > > it's not a common case but I need it for openvz case.
> > 
> > Can you detect the openvz kernel and refuse the untar if on
> > upstream kernel?  You can really screw up the host otherwise...
> 
> Look, you need to pass --devtmpfs-content on both invocations:
> with checkpoint and with restore, otherwise the contents won't
> be handled at all, just like before. By default this option is
> inactive.

Ok, thanks.  That means that all toolsets using criu will need to be
aware of the option, but I suppose that realistically if you have an
openvz kernel you'd be using vsctl :)

-serge