[lxc-users] Live migration mkdtemp failure

[jjs - mainphrame]

That particular error was resolved, but the lxc live migration doesn't work
for a different reason now. We now get an error that says "can't dump ghost
file" because of apparent size limitations - a limit less than the size of
any lxc container we have running here.

(In contrast, live migration on all of our Openvz 7 containers works
reliably)

Jake




On Tue, Jun 21, 2016 at 4:19 AM, McDonagh, Ed <Ed.McDonagh at rmh.nhs.uk>
wrote:

>
>
> > On Tue, Mar 29, 2016 at 09:30:19AM -0700, jjs - mainphrame wrote:
> > > On Tue, Mar 29, 2016 at 7:18 AM, Tycho Andersen <
> > > tycho.andersen at canonical.com> wrote:
> > >
> > > > On Mon, Mar 28, 2016 at 08:47:24PM -0700, jjs - mainphrame wrote:
> > >>  > I've looked at ct migration between 2 ubuntu 16.04 hosts today,
> and had
> > > > > some interesting problems;  I find that migration of stopped
> containers
> > > > > works fairly reliably; but live migration, well, it transfers a
> lot of
> > > > > data, then exits with a failure message. I can then move the same
> > > > > container, stopped, with no problem.
> > > > >
> > > > > The error is the same every time, a failure of "mkdtemp" -
> > > >
> > > > It looks like your host /tmp isn't writable by the uid map that the
> > > > container is being restored as?
> > > >
> > >
> > > Which is odd, since /tmp has 1777 perms on both hosts, so I don't see
> how
> > > it could be a permissions problem. Surely the default apparmor profile
> is
> > > not the cause? You did give me a new idea though, and I'll set up a
> test
> > > with privileged containers for comparison. Is there a switch to enable
> > > verbose logging?
> >
> > It already is enabled, you can find the full logs in
> > /var/log/lxd/$container/migration_*
> >
> > Perhaps the pwd of the CRIU task is what's broken instead, since CRIU
> > isn't supplying a full mkdtemp template. I'll have a deeper look in a
> > bit.
> >
> > Tycho
> >
> > >
> > > > >
> > > > > root at ronnie:~# lxc move third lxd:
> > > > > error: Error transferring container data: restore failed:
> > > > > (00.033172)      1: Error (cr-restore.c:1489): mkdtemp failed
> > > > > crtools-proc.x9p5OH: Permission denied
> > > > > (00.060072) Error (cr-restore.c:1352): 9188 killed by signal 9
> > > > > (00.117126) Error (cr-restore.c:2182): Restoring FAILED.
>
> I've been getting the same error - was the issue ever resolved for
> non-privileged containers?
>
> Kind regards
> Ed
> #########################################################################
> Attention:
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary, confidential and/or
> privileged information and should not be copied, disclosed, distributed,
> retained or used by any other party. If you are not an intended recipient
> please notify the sender immediately and delete this e-mail (including
> attachments and copies).
>
> The statements and opinions expressed in this e-mail are those of the
> author and do not necessarily reflect those of the Royal Marsden NHS
> Foundation Trust. The Trust does not take any responsibility for the
> statements and opinions of the author.
>
> Website: http://www.royalmarsden.nhs.uk
> #########################################################################
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160621/c8c81071/attachment.html>