Unfortunately, 2.21 is not available for 18.04 Bionic so i have to use the snap package. However, it uses /var/snap/lxd/common/lxd instead of /var/lib/lxd. Is it possible to use /var/lib/lxd for the snap package?
I am trying to share containers between ubuntu and gentoo/openrc. Thus i need consistent PATHS between the two. I was thinking of using a ZFS dataset ‘rpool/liblxd’ mounted to ‘/var/lib/lxd’. This dataset could then be used for both Gentoo and Ubuntu. This is not possible to do with the custom snap path.
Hmm, so it’s likely going to be a bit harder than that.
For LXD itself, yes, a bind-mount would work fine. The problem is that LXD also expects all the container datasets to have a valid mountpoint under its main directory, this wouldn’t be true in your case, so you’d likely need a small init script which updates the mountpoint property of all your datasets at boot.
It may actually be easier to do it the other way around, running the non-snapped LXD using /var/snap/lxd/common/lxd as its directory. In theory all you’d need to do to make that happen is update the init script in your distro to set LXD_DIR=/var/snap/lxd/common/lxd.
Nice idea. I modified my gentoo init script and setup ZFS mountpoint to /var/snap/lxd/common/lxd and it worked in gentoo. Unfortunately ‘lxc list’ in Ubuntu is giving me an empty list,
$ lxc list
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
# ls -la /var/snap/lxd/common/lxd
total 37
drwx--x--x 14 root root 18 Mar 31 02:36 .
drwxr-xr-x 5 root root 9 Mar 31 02:36 ..
drwx------ 2 root root 3 Mar 31 02:36 cache
drwx--x--x 2 root root 2 Mar 31 02:36 containers
drwx--x--x 2 root root 2 Mar 31 02:36 devices
drwxr-xr-x 2 root root 2 Mar 31 02:36 devlxd
drwx------ 2 root root 2 Mar 31 02:36 disks
drwx------ 2 root root 2 Mar 31 02:36 images
drwxr-xr-x 3 root root 4 Mar 31 02:36 logs
-rw-r--r-- 1 root root 58368 Mar 31 02:36 lxd.db
drwx--x--x 2 root root 2 Mar 31 02:36 networks
drwx------ 2 root root 2 Mar 31 02:36 security
-rw-r--r-- 1 root root 1927 Mar 31 02:36 server.crt
-rw------- 1 root root 3243 Mar 31 02:36 server.key
drwx--x--x 2 root root 2 Mar 31 02:36 shmounts
drwx------ 2 root root 2 Mar 31 02:36 snapshots
drwx--x--x 3 root root 3 Mar 31 02:37 storage-pools
srw-rw---- 1 root lxd 0 Mar 31 02:36 unix.socket
I can see the containers,
# ls -la /var/snap/lxd/common/lxd/storage-pools/default/containers
total 18
drwxr-xr-x 4 root root 4 Mar 31 02:37 .
drwxr-xr-x 3 root root 3 Mar 31 02:37 ..
drwxr-xr-x 4 1000000 1000000 6 Mar 31 01:33 openhab
drwxr-xr-x 4 1000000 1000000 6 Mar 31 01:33 zmvm
Just for posterity I had to make following changes in Gentoo,
# cat etc/init.d/lxd
#!/sbin/openrc-run
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
DAEMON=/usr/sbin/lxd
PIDFILE=/run/lxd.pid
extra_commands="stopall"
depend() {
need net
use lxcfs
}
start() {
ebegin "Starting lxd service"
start-stop-daemon --start \
--pidfile ${PIDFILE} \
--exec ${DAEMON} \
-e LXD_DIR=/var/snap/lxd/common/lxd \
--background \
--make-pidfile \
-- \
${LXD_OPTIONS}
eend $?
}
stop() {
if [ "$RC_GOINGDOWN" = "YES" ] || [ "$RC_REBOOT" = "YES" ]; then
stopall
else
ebegin "Stopping lxd service (but not containers)"
start-stop-daemon --stop --quiet -R TERM/45 -p ${PIDFILE}
eend $?
fi
}
stopall() {
ebegin "Stopping lxd service and containers"
if "${DAEMON}" shutdown; then
/etc/init.d/lxd zap
rm -f ${PIDFILE}
fi
eend $?
}
# cat etc/env.d/52lxd
LXD_DIR="/var/snap/lxd/common/lxd"
I suspect the problem here is that we’ve changed the database path in recent commits which have been included in the snap.
So one of your installs is now looking at /var/snap/lxd/common/lxd/database/local.db and /var/snap/lxd/common/lxd/database/global and the other is looking at /var/snap/lxd/common/lxd/lxd.db and /var/snap/lxd/common/lxd/raft.
If that’s the issue, then there’s not much you can do really until the non-snap side of your system catches up and looks at the right place.
That’s assuming you’ve still got that setup in place and that the output above comes from the gentoo side.
Gentoo is likely using lxd.db, so that’d mean that the snap did the migration to /database/, then was probably working fine, switching back to Gentoo re-created lxd.db and now things are pretty confused.
Because the snap package has received a number of post-release bugfixes (cherry-picks) which I suspect haven’t been applied to the Gentoo package.
When someone finds a bug in LXD and they’re using the snap, we push the fix on top of the snap package.
So while the version number doesn’t change, we do push new revisions of it with bugfixes.
The same is true for some distributions (the Ubuntu 3.0.0 has 20-ish fixes on top) but there’s never any guarantee that they’re all perfectly in sync.
Well I don’t mean to sound pedant (so please don’t take it as such, we the work on LXD ), but I can’t refrain from wondering what good are versions number if different software versions have the same version number??
Why not incrementing the patch part of the version number (the Z in version X.Y.Z) after each bugfix?
For non-backward compatible changes, the Y or even X version should change according to semantic versioning.
Distributions cherry-picking fixes on top of the upstream release isn’t a new thing, this doesn’t come with a change to the version number because upstream didn’t actually release a new version. Instead the packaging revision is what’s bumped, as is the case here.
the work on LXD ), but I can’t refrain from wondering what good are versions number if different software versions have the same version number??