LXD 3.10 -- lxd init didn't ask me what storage backend to use?

I’m guessing this is a new feature, as I don’t have ZFS utils installed on this host, but would like confirmation. When I ran **lxc init** I wasn’t asked what storage backend to use:

[root@staging1 etc]# 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]: 
Name of the new storage pool [default=default]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none
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] 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:

Followup question: Suppose I start out using dir as my storage backend. Is it possible to install/configure ZFS after the fact and switch any already created containers to using this new storage backend?

if you are not asked, that’s because there is only one:

            if len(availableBackends) > 1 {
                    pool.Driver = cli.AskChoice(
                            fmt.Sprintf("Name of the storage backend to use (%s) [default=%s]: ", 

dir is always available, usually btrfs is available and zfs is not by default (evil software…)
So you are using dir (check with lxc storage info default or show default)
BTW, you are titling your post ‘lxc init’, and the screen dump shows ‘lxD init’.

There are posts on this forum on copying containers from a storage to another. let’s see…

now it is implemented

1 Like

Thanks for your response. What file is your referenced code snippet from? I kept careful notes while running lxd init on this machine and it definitely asked me what storage backend to use:

[pgoetz@erap-atx ~]$ pacman -Q lxd
lxd 3.10-1

[pgoetz@erap-atx ~]$ lxc storage list
|  NAME   | DESCRIPTION | DRIVER |               SOURCE               | USED BY |
| default |             | dir    | /var/lib/lxd/storage-pools/default | 3       |

I’d like to check to see if that code is present in lxd 3.10, as this machine has neither btrfs nor zfs installed/available AFAIK.

Curious: why to you suggest ZFS is evil? I’d be happy to use btrfs, but it always seems to suffer from scary stability problems, and I can’t risk losing data on my production servers.

Finally, updated the title of this post – thank you for catching that error.

code is here:

zfs evil was mostly a joke, there is a controversy I never looked into, I believe it’s linked to patents owned by Oracle (not sure) and as such for legal reasons zfs is not shipped by default by many Linux distros. So you always have to enable it yourself, like with Nvidia drivers, or some Dvd copying protections workarounds. This leads to incredibly boring forum fightings.
To not even have to think about this borefest, I have just used btrfs everywhere. So I’m not (too much) evil :slight_smile: And btrfs probably deserved its bad reputation at some point, but I had a crash due to full disk in a very recent test and the not very important data was good to go afterwards, so this very scientific test is positive (so far)

About dir storage, it is only to be used when nothing else is possible, LXD designer said so (bad performer and not every feature available, especially snapshots, and that’s a pity to not have snapshots with containers if you ask me)

Looking at the Git Blame log for this file, it looks like this was changed about a year ago: The previous version looked like this:

	// Storage backend
	pool.Driver = cli.AskChoice(
		fmt.Sprintf("Name of the storage backend to use (%s) [default=%s]: ", strings.Join(availableBackends, ", "), defaultStorage), availableBackends, defaultStorage)

A couple of corrections, though. First and most importantly you can definitely still create snapshots when using dir storage. On exactly the same machine I reference above:

[pgoetz@erap-atx ~]$ lxc snapshot archon archon_snap_20190316
[pgoetz@erap-atx ~]$ lxc info archon
Name: archon
Location: none
Remote: unix://
Architecture: x86_64
Created: 2019/02/22 01:11 UTC
  archon_snap_20190316 (taken at 2019/03/16 09:13 UTC) (stateless)

Regarding ZFS, the problem is not patents, but rather that the ZFS license, CDDL, is too permissive for linux, which is licensed under the GPL. You can read more about that here:

I’m OK with ZFS forever being an add on, although one does run the risk of introduced incompatibilities, i.e. what just happened with the release of the linux 5.0 kernel, which removed a questionable internal ABI that ZFS was using. Finally, Ubuntu does package ZFS as part of their distro, hence the liberal use of ZFS in LXD.

oh my bad you are correct.
Well, it’s not copy on write though that’s why I had remembered it as a ‘no’.