On Wed, Sep 26, 2007 at 10:28:58PM +0200, Martin Geißler wrote:
> Am Wednesday 26 September 2007 schrieb Herbert Poetzl:
> > On Tue, Sep 25, 2007 at 08:13:49PM +0200, Martin Geißler wrote:
> > > Dear list,
> > >
> > > after a reboot I could not start the vserversguests anymore.
> > > The data of the vservers is now on a different partition
> > > (but same mountpoint). Nothing else changed.
> > > But now I get
> > >
> > > kernel: vxW: xid=102 did hit the barrier.
> >
> > that means that a guest process (with xid 102) is
> > trying to move 'over' a barrier tagged dir
>
> Yes, but why all of a sudden?
> /data contains the vserver-root-directories.
> /data
> /data/vserver1
> /data/vserver2
> etc.
>
> It was
> ---Bui- /data/
> but I had to set it to
> ---bui- /data/
>
> >
> > > As I _had_ to start them as soon as possible I removed the barrier
> > > attribute from the /data-directory and the servers started at last.
> >
> > what is the '/data' directory and how does it related
> > to the guest's filesystem structure?
> >
> > > But what happend and how can I set the barrier attribute again.
> >
> > the barrier should be placed _above_ directories the
> > guest should be able to reach, e.g. /path/to/guest/..
> > (note that the .. is literally here)
> >
> > you can set it anytime with setattr --barrier ...
>
> But if I do that I cannot start a vserver:
> vserver name start gives:
>
> save_ctxinfo: open("/data/run/vservers/fun"): Permission denied
why is it writing to /data too? isn't that
the directory containing the guests?
if so, then this is your problem, and you
probably want to save the run time information
somewhere else than on the barrier for your
guests, e.g. /var/run/vservers (which is the
default location)
> and the kernel.log again:
> kernel: vxW: xid=108 did hit the barrier.
>
> As I just found out I can set the the barrier after the vserver is
> started. So it only inhibits the startup?
>
> But as the server should boot without intervention I would very much
> like to fix the problem.
yes, you also want to have the barrier at all
times, otherwise your guest could escape the
filesystem chroot()
> And by the way: great software! Thanks!
thanks!
HTH,
Herbert
> Yours
> m.
Received on Sun Sep 30 13:39:19 2007