[lxc-users] Network settings and snapshots copied to another server

[Steven Spencer]

All,

We have a native LXD server (3.0.0) that has the native and snap package
installed. Apparently, we never ran the lxd.migrate on that server, so I'm
doing some testing with a snapshot server and copying snapshots from the
LXD native server (3.0.0) to an LXD native server recently installed
running 3.0.3.

My ultimate goal was to copy over a few containers as snapshots. Make sure
they would start and run. Stop them and then run lxd.migrate on the server.
What I wasn't expecting was that when I started the snapshot on the new
server, the network stack, which had contained static IP address
information, now looked like a freshly installed container with the dhcp
default. The containers are mostly CentOS 7 with a few Ubuntu servers.

Instead of the static IP information that existed on the 3.0.0 native
server, the configuration in the CentOS 7 container showed:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
HOSTNAME=rocketchat
NM_CONTROLLED=no
TYPE=Ethernet
MTU=
DHCP_HOSTNAME=`hostname`

This information is stored in the filesystem of a CentOS 7 machine in
/etc/sysconfig/network-scripts/ifcfg-eth0

My question is: Why does the static IP not follow the container, is this by
design? and secondly, Is there a way to force the static IP (all network
information) to be contained in the snapshot. If not, that isn't a big
deal, we just have to develop procedures for taking care of this in the
event that we need to take our snapshots live.

All of the other services that are running in the original container are
running in the snapshot and since we have a macvlan profile type in use on
both servers, setting the IP to a static IP is a simple matter of
repopulating the ifcfg-eth0 information.

I did ultimately test the lxd.migrate on the test server which worked as
expected.

Thanks,
Steven G. Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20190405/ff30515c/attachment.html>