[lxc-users] How to configure lxd to comply with commands
Stéphane Graber
stgraber at ubuntu.com
Wed Aug 17 20:45:12 UTC 2016
So one way around the problem would be with:
lxc config set core.https_address 192.168.111.193:8443
on your olympia host. This will force LXD to use that IP during
container transfer and should fix your problem.
On Wed, Aug 17, 2016 at 01:28:52PM -0700, jjs - mainphrame wrote:
> Hi Stephane -
>
> lxd1, lxd2, and kangal are all on the same lan, and connectivity is good:
>
> root at olympia:~# ssh kangal w
> root at kangal's password:
> 13:26:53 up 3 days, 14:50, 0 users, load average: 0.29, 0.37, 0.37
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
>
> root at ronnie:~# ssh kangal w
> root at kangal's password:
> 13:27:09 up 3 days, 14:51, 0 users, load average: 0.29, 0.36, 0.37
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
>
> Regards,
>
> Jake
>
>
> On Wed, Aug 17, 2016 at 1:24 PM, Stéphane Graber <stgraber at ubuntu.com>
> wrote:
>
> > On Wed, Aug 17, 2016 at 01:14:43PM -0700, jjs - mainphrame wrote:
> > > Greetings,
> > >
> > > I'm running lxd version 2.0.3-0ubuntu1~ubuntu16.04.2
> > >
> > > I'm trying to get lxd to correctly execute a move of a container from one
> > > lxd host to another. I have two ubuntu 16.04 hosts, ronnie (designated as
> > > lxd1) and olympia (designated as lxd2):
> > >
> > > root at olympia:~# lxc remote list
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | NAME | URL | PROTOCOL
> > > | PUBLIC | STATIC |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | images | https://images.linuxcontainers.org | lxd
> > > | YES | NO |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | local (default) | unix:// | lxd
> > > | NO | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | lxd1 | https://192.168.111.20:8443 | lxd
> > > | NO | NO |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | ubuntu | https://cloud-images.ubuntu.com/releases |
> > > simplestreams | YES | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | ubuntu-daily | https://cloud-images.ubuntu.com/daily |
> > > simplestreams | YES | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > >
> > > root at ronnie:~# lxc remote list
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | NAME | URL | PROTOCOL
> > > | PUBLIC | STATIC |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | images | https://images.linuxcontainers.org | lxd
> > > | YES | NO |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | local (default) | unix:// | lxd
> > > | NO | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | lxd2 | https://192.168.111.193:8443 | lxd
> > > | NO | NO |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | ubuntu | https://cloud-images.ubuntu.com/releases |
> > > simplestreams | YES | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > > | ubuntu-daily | https://cloud-images.ubuntu.com/daily |
> > > simplestreams | YES | YES |
> > > +-----------------+-----------------------------------------
> > -+---------------+--------+--------+
> > >
> > > You can see that the remotes are configured with their local lan
> > addresses.
> > > So far so good?
> > >
> > >
> > >
> > > Here are the 2 containers currently on lxd2:
> > > root at olympia:~# lxc list
> > > +--------+---------+-----------------------+------+---------
> > ---+-----------+
> > > | NAME | STATE | IPV4 | IPV6 | TYPE |
> > SNAPSHOTS |
> > > +--------+---------+-----------------------+------+---------
> > ---+-----------+
> > > | akita | RUNNING | 192.168.111.22 (eth0) | | PERSISTENT | 0
> > |
> > > +--------+---------+-----------------------+------+---------
> > ---+-----------+
> > > | kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0
> > |
> > > +--------+---------+-----------------------+------+---------
> > ---+-----------+
> > >
> > >
> > >
> > > Now, I try to move a container from lxd2 to lxd1:
> > > root at olympia:~# lxc move kangal lxd1:
> > > error: Error transferring container data: Unable to connect to:
> > > 192.168.1.8:8443
> >
> > Is there any way for lxd1 to connect to kangal?
> >
> > The way LXD currently deals with cross-host communication is that the
> > client has the source host issue a token which the client sends to the
> > target along with instructions on how to connect to the source.
> >
> > The target then directly connects to the source to fetch the data
> > (in this case, the container).
> >
> > This means that there must be a way for the target to connect to the
> > source on the LXD port without being blocked by firewalls or going
> > through NAT.
> >
> >
> > Some more details can be found at
> > https://www.stgraber.org/2016/04/12/lxd-2-0-remote-hosts-
> > and-container-migration-612/
> > in the "network requirements" and "how this all works" sections.
> >
> >
> > The client is currently supposed to iterate through all the IPs that the
> > source server advertises (see addresses field in "lxc info kangal"), the
> > one that's in the error message is usually the last one of those.
> >
> >
> > If core.https_address is set on the source host, then only that address
> > will be attempted since it's the only one LXD will be listening on.
> >
> >
> > As mentioned in the blog post, we do have a plan to improve the
> > situation by having the client relay the data in cases where the two
> > servers can't talk, but we haven't made much progress on implementing
> > that so far.
> >
> > >
> > > Why is it trying to connect to 192.168.1.8? That is a local wireless
> > > address on lxd2, but it was never mentioned in any lxd configuration:
> > >
> > > root at olympia:~# ifconfig wlp3s0
> > > wlp3s0 Link encap:Ethernet HWaddr 80:56:f2:05:ce:6c
> > > inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
> > > inet6 addr: fe80::8256:f2ff:fe05:ce6c/64 Scope:Link
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > RX packets:401712 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:219214 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:1000
> > > RX bytes:95097222 (95.0 MB) TX bytes:34201360 (34.2 MB)
> > >
> > >
> > > So my question is, how do we get lxd to ignore the local wireless IP, and
> > > execute the lxc move command using the configured IPs?
> > >
> > > Regards,
> > >
> > > Jake
> >
> > > _______________________________________________
> > > lxc-users mailing list
> > > lxc-users at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> >
> > --
> > Stéphane Graber
> > Ubuntu developer
> > http://www.ubuntu.com
> >
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160817/5e54de3b/attachment.sig>
More information about the lxc-users
mailing list