[lxc-users] Announcing LXC, LXD and LXCFS 3.0 LTS

2018-04-11 Thread Stéphane Graber
The LXC, LXD and LXCFS teams are proud to announce the release of the
3.0 version of all three projects.

This is an LTS release which comes with 5 years of upstream support for
bugfixes and security updates, in this case until June 2023.

We'd like to note that despite the major version bump, no APIs have been
broken and both liblxc and the LXD REST API remain backward compatible.

Our existing 2.0 LTS will now be getting one last major bugfix update
over the next month or so before going into a much slower maintenance
phase where only critical bugfixes, special requests and security fixes
get backported.


LXD highlights (since LXD 2.21):

 - Support for clustering LXD servers together
 - New tool to convert existing systems into containers
 - Support for NVIDIA runtime & library passthrough
 - Hotplug support for unix-char and unix-block devices
 - Local copy/move of storage volumes
 - Remote transfer of storage volumes
 - A new `proxy` device type to forward TCP connections
 - Event based notification in the /dev/lxd API
 - Replaced our command line parser
 - New lifecycle events for tracking/auditing

LXC highlights (since LXC 2.1):

 - Introduction of some new configuration keys (see list in announcement)
 - Improved CLI
 - Support for CGroupV2
 - Template scripts have been moved out of tree
 - Support for using images generated by our new `distrobuilder` tool
 - Support for using OCI images for application containers
 - Ring buffer based console logging
 - Argument filtering in Seccomp policies
 - Daemonized application containers
 - Deprecation and rename of some config keys (`lxc-update-config` to convert)
 - Removal of legacy CGroup drivers (cgmanager & cgfs in favor of cgfsng)
 - Removal of the aufs storage backend (use overlayfs)

LXCFS highlights (since LXCFS 2.0):

 - libpam-cgfs has been moved over to LXC


The announcements for the 3 projects can be found here:

 - LXD 3.0: 
https://discuss.linuxcontainers.org/t/lxd-3-0-0-has-been-released/1491
 - LXC 3.0: 
https://discuss.linuxcontainers.org/t/lxc-3-0-0-has-been-released/1449
 - LXCFS 3.0: 
https://discuss.linuxcontainers.org/t/lxcfs-3-0-0-has-been-released/1440


We'd like to thank all of our contributors and our amazing community for
their contributions, bug reports and help testing those releases!

On behalf of the LXC, LXD and LXCFS teams,

Stéphane Graber


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Issue upgrading from LXD apt to snap

2018-04-11 Thread Sean McNamara
Update:

The error about the DB schema from the apt version of lxd
(/usr/bin/lxd) was due to apt, for some reason, deciding to install
lxd *2.0.11* instead of the 2.21 I had been using from backports. I
forced the backport version and now both LXD daemons start
concurrently!

However, lxd.migrate doesn't complete cleanly. See below. I am using
ZFS for storage but I have no idea why it's trying to umount / !

# lxd.migrate
=> Connecting to source server
=> Connecting to destination server
=> Running sanity checks

=== Source server
LXD version: 2.21
LXD PID: 17828
Resources:
  Containers: 9
  Images: 3
  Networks: 1
  Storage pools: 1

=== Destination server
LXD version: 3.0.0
LXD PID: 3238
Resources:
  Containers: 0
  Images: 0
  Networks: 0
  Storage pools: 0

The migration process will shut down all your containers then move
your data to the destination LXD.
Once the data is moved, the destination LXD will start and apply any
needed updates.
And finally your containers will be brought back to their previous
state, completing the migration.

Are you ready to proceed (yes/no) [default=no]? yes
=> Shutting down the source LXD
=> Stopping the source LXD units
=> Stopping the destination LXD unit
=> Unmounting source LXD paths
=> Unmounting destination LXD paths
=> Wiping destination LXD clean
=> Moving the data
=> Moving the database
=> Backing up the database
=> Opening the database
=> Updating the storage backends
error: Failed to update the storage pools: Failed to run: zfs set
mountpoint=/var/lib/snapd/hostfs/ tank/root: umount: /: target is busy
(In some cases useful info about processes that
 use the device is found by lsof(8) or fuser(1).)
cannot unmount '/': umount failed


Current state of my ZFS volumes:

# zfs list
NAME
USED  AVAIL  REFER  MOUNTPOINT
tank
556G  1.21T19K  none
tank/containers
182G  1.21T19K  none
tank/containers/cont1
   18.9G  1.21T  18.1G
/var/snap/lxd/common/lxd/storage-pools/tank/containers/cont1
tank/containers/cont2
 5.85G  1.21T  6.03G
/var/snap/lxd/common/lxd/storage-pools/tank/containers/cont2
tank/containers/cont3
 252M  1.21T   433M
/var/snap/lxd/common/lxd/storage-pools/tank/containers/cont3
tank/containers/cont4
   10.5G  1.21T  9.00G
/var/snap/lxd/common/lxd/storage-pools/tank/containers/cont4
#... etc (for several more containers)





On Wed, Apr 11, 2018 at 11:54 PM, Sean McNamara  wrote:
> Hi,
>
> I'm on Ubuntu 16.04; the last working version of LXD I had was 2.21
> from backports.
>
> I wanted to upgrade to 3.0 but it isn't in the backports repo yet, it
> seems, so I went ahead and installed the snap. Then I removed the
> original package, perhaps not realizing until it was too late that I
> wasn't suppposed to do that.
>
> It seems the lxd.migrate command that you're *supposed* to run (which
> I wasn't aware of until recently) requires the original lxd server to
> be running -- that is, in my case, the one installed via apt. However,
> that one now won't start. It says:
>
> error: The database schema is more recent than LXD's schema.
>
> I wish the lxd binary had more flexibility and information about:
>
>  - How do I identify the directory where this lxd command is looking
> for its database/config files?
>  - How do I *tell it* to use a specific (non-default) directory for
> its database/config files?
>  - What environment variables should I check, if those are applicable?
>
> That info should go in `lxd --help`, IMO. As of now I'm stuck on this
> error. I assume I have a working LXD database in the normal /var
> location that somehow got updated to database schema for version 3.0,
> but I can't start *either* version of LXD now.
>
> When I try to start /usr/bin/lxd, I get the above error. When I try to
> start /snap/lxd/bin/lxd, it just hangs trying to connect:
>
> # /snap/lxd/current/bin/lxd -d
> DBUG[04-12|03:54:05] Connecting to a local LXD over a Unix socket
> DBUG[04-12|03:54:05] Sending request to LXD   etag=
> method=GET url=http://unix.socket/1.0
>
> How can I salvage my original LXD config / containers in /var/lib/lxd
> and make it work with the snap?
>
> Thanks,
>
> Sean
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Announcing LXC, LXD and LXCFS 3.0 LTS

2018-04-11 Thread Tomasz Chmielewski

On 2018-04-12 06:25, Stéphane Graber wrote:

The LXC, LXD and LXCFS teams are proud to announce the release of the
3.0 version of all three projects.


Great news, great features!

What's the best way to upgrade from a 2.xx deb to a 3.xx snap?


Tomasz Chmielewski
https://lxadm.com
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Issue upgrading from LXD apt to snap

2018-04-11 Thread Sean McNamara
Hi,

I'm on Ubuntu 16.04; the last working version of LXD I had was 2.21
from backports.

I wanted to upgrade to 3.0 but it isn't in the backports repo yet, it
seems, so I went ahead and installed the snap. Then I removed the
original package, perhaps not realizing until it was too late that I
wasn't suppposed to do that.

It seems the lxd.migrate command that you're *supposed* to run (which
I wasn't aware of until recently) requires the original lxd server to
be running -- that is, in my case, the one installed via apt. However,
that one now won't start. It says:

error: The database schema is more recent than LXD's schema.

I wish the lxd binary had more flexibility and information about:

 - How do I identify the directory where this lxd command is looking
for its database/config files?
 - How do I *tell it* to use a specific (non-default) directory for
its database/config files?
 - What environment variables should I check, if those are applicable?

That info should go in `lxd --help`, IMO. As of now I'm stuck on this
error. I assume I have a working LXD database in the normal /var
location that somehow got updated to database schema for version 3.0,
but I can't start *either* version of LXD now.

When I try to start /usr/bin/lxd, I get the above error. When I try to
start /snap/lxd/bin/lxd, it just hangs trying to connect:

# /snap/lxd/current/bin/lxd -d
DBUG[04-12|03:54:05] Connecting to a local LXD over a Unix socket
DBUG[04-12|03:54:05] Sending request to LXD   etag=
method=GET url=http://unix.socket/1.0

How can I salvage my original LXD config / containers in /var/lib/lxd
and make it work with the snap?

Thanks,

Sean
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users