I first installed LXD 2.2.1 on 3 - centOS7 nodes with snap.
there were 4 containers respectively on 3 nodes,
one node using kernel ( version : 4.14.15-1.el7.elrepo.x86_64 )
and two nodes using kernel (version : 4.15.0-1.el7.elrepo.x86_64 )
yesterday snap refresh and updated LXD to version 3.0.
after updated, command “sudo lxc list” does not show any containers that created at 2.2.1 version on one node(4.14.15-1.el7.elrepo.x86_64). But container data not removed.
On other two nodes, command “sudo lxc list” shows containers but can not execute on containers.
I initiated LXD with default values except storage backend (changed to dir)
and I used Docker on LXD, so I set the container’s config with
I thought that this is because of changes in config key (like aa_profile => apparmor_profile).
right?
In conclusion, I dont want unsuspected crash on my container environment.
So is there a way to install LXD with specific version on centos7 without snap?
(could not find except on Ubuntu)
Or can I disable auto snap refresh(client side)?
(except iptable control, just snap option or another)
yes, the reason why your container wouldn’t start is because lxc.aa_profile should be lxc.apparmor.profile instead now. Not that this would matter on CentOS as apparmor isn’t a thing there, so not setting that key at all should work just as well.
Now that 3.0 is out, I’d recommend you switch to the 3.0 channel, which will then keep you on LXD 3.0 and only get you the bugfix updates for it. You can do so with snap refresh lxd --channel=3.0/stable.
The node that doesn’t show any container running is odd. Could you e-mail me (stgraber at ubuntu dot com), the following files:
/var/snap/lxd/common/lxd/lxd.db
/var/snap/lxd/common/lxd/lxd.db.bak
/var/snap/lxd/common/lxd/logs/lxd.log
(output of) journalctl -u snap.lxd.daemon
I suspect it’s the DB conversion to raft having gone bad, but it’s not something we’ve seen outside of the early betas, so it’d be good to understand what happened and if that was in fact the issue, it should be pretty simple to revert to the database backup and upgrade again, hopefully successfully this time.
As sudden crash, I reinstalled lxd immediately(snap remove and snap install) so cannot send that files, sorry.
I tried to reproduce the crash on dev environment
snap install lxd --channel=2.0
create container with above configs
snap refresh lxd --channel=3.0
lxc list
I cannot see the crash(did not show container list).
But I cannot execute my container.
$ lxc exec my-container – /bin/bash
-> Error: Error opening startup config file: "loading config file for the container failed"
Error: EOF
I tried to edit container’s config
$ lxc config edit my-container
lxc.aa_profile = unconfined => lxc.apparmor.profile = unconfined
then I cannot save config with below msg.
Config parsing error: Update will cause the container to rely on a profile’s root disk device but none was found.
Press enter to start the editor again
and I cannot create new container with failure
$ sudo lxc launch images:centos/7/amd64 my-container2 -c security.privileged=true -c security.nesting=true
=> Error: Failed container creation: No root device could be found.
Now, I’m using lxd 3.0 as you said.( “snap install lxd --channel=3.0/stable” )
but I don’t know why it does not work properly.
Oh, I’m sorry.
I didn’t know I have to init lxd again after refreshing.
but after init (below step), I cannot access my container too.
$ sudo lxd init
Would you like to use LXD clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]: no
Would you like to connect to a MAAS server? (yes/no) [default=no]:
Would you like to create a new network bridge? (yes/no) [default=yes]: no
Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: yes
Name of the existing bridge or host interface: lxdbr0
Is this interface connected to your MAAS server? (yes/no) [default=yes]: no
Would you like LXD to be available over the network? (yes/no) [default=no]:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] no
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:
Looks like some of the 2.0 to 3.0 migration didn’t work too well… To fix things, I suspect you’ll want to run:
lxc profile device add default root disk path=/ pool=default
ip link del lxdbr0
lxc network create lxdbr0
I’d also recommend a reboot of the system at that point to make sure everything is clean.
Launching new containers should then work fine, and hopefully interacting with existing ones will be fixed too (though I don’t see a good reason for that exec error you’re getting…).
If the exec error continues, please post the output of snap list and snap changes as well as lxc info --show-log NAME that should help.