[lxc-users] LXD 3.9/3.10 and ARM

[Geaaru]

Hi guys,

before other... thank you very much for your job at FOSDEM.

I'm trying to integrate LXD task of Mottainai project on ARM
architecture but I see two different issues:

1) I imported with lxc command a sabayon image created with
distrobuilder in my BananaPi and here all works fine. When I try to
copy image from LXD server to another BananaPI node:

lxc image copy bpi1:4cfc809388f5 local:

I see that on bpi1 node lxd process begin (probably) to load image in
memory instead of begin copy data of a stream to bpi2 node. It's an
already know issue ? It's related to some particular option ?

Obviously, I must stop image copy because this operation begin to
allocate all RAM memory and all swap memory without begin to copy image
versus bpi2 node.
Bpi1 node has image stored on ZFS pool and Bpi2 has a BRTFS pool, i
dunno if could be important this information.

2) As described also on irc channel I'm developer of Mottainai project,
a CI Platform that now integrate also LXD technology. Mottainai permits
to configure multiple agents node for execute CI tasks and currently in
Sabayon we use it for compile packages. I configured a BPI node for
build ARM packages. Agent uses golang LXD API for create a LXD
container (ephemeral or not), run CI task in the same way of "lxc
execute" command and then stop container. On AMD64 all works perfectly
but on ARM I see often a weird issue.
When Agent try to stop container call UpdateContainerState command:

https://github.com/MottainaiCI/mottainai-server/blob/master/pkg/tasks/l
xd.go#L623

and then it seems that it never wakeup by Wait() method of operation
object returned by UpdateContainerState.

It's very weird because I don't see any exception or errors. The
process remains seems locked.
But from lxc command I see that container is correctly in stopped
status but it seems that LXD Api never wakeup my process.

This happens only on ARM. I can't reproduce this in AMD64 env.

Have you an idea about what happens here ? Have you ever see a use case
similar ? Could be related to a kernel issue ? Or to a LXD API issue?

On BPI I have a kernel 4.9.109 and LXC 3.1.0.

Thanks in advance for any suggestions.
G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20190223/74370b8d/attachment.html>