lxd/lxc command to specify ZFS clone or full copy of container

[naisanza]

Required information

• Distribution: Ubuntu
• Distribution version: 16.04 Desktop
• The output of "lxc info" or if that fails:
  
  
  
  • Kernel version: 4.4.0-22-generic
  
  
  • LXC version: 2.0.2
  
  
  • LXD version: 2.0.2
  
  
  • Storage backend in use: ZFS
    
    

    Issue description

  
  

There could be an improvement with the way containers are copied or deleted when using ZFS as the backstore.

The issue is when a ZFS dataset (container) is the origin of a lxc copy command. Currently, LXD/LXC allows you to delete a ZFS dataset (container) that has existing clones; and does this by renaming the ZFS dataset and putting it under the ZFS location lxc/deleted/container/<deleted-container>

This gets messy real quick when you have copies of copies of containers with an origin of a deleted ZFS dataset.

LXC initially did this correctly. lxc-copy allowed you to either create an actual copy of the container (default behavior) or the more space-saving option of creating a ZFS clone of the container. LXD needs these options as well.

LXD's default behavior of creating ZFS clones of any container with the lxc copy command and without the checking of lxc delete if a container has dependent ZFS clones, eventually leads to a messy tree of dead ZFS datasets in lxc/deleted/containers

Information to attach

• N/A

[stgraber]

That messy tree does clean itself up when the last container using bits from the deleted container goes away though. It is a slightly annoying limitation of ZFS which our other backends don't have so I'm not convinced we should make this a first class option.

We may want to offer a knob for zfs container copies to not use clones as a daemon-wide storage option (storage.zfs_full_copy or something along those lines, using send/receive rather than clone).

[stgraber]

A branch doing this would be welcome.

[Lisio]

Need this feature to create a full copy. It is not very comfortable to use such workarounds:

lxc copy c1 c2
zfs destroy pool/c2
zfs send pool/c1@copy-{hash} | zfs recv pool/c2
zfs destroy pool/c1@copy-{hash}
zfs destroy pool/c2@copy-{hash}

[stgraber]

Yeah, I think with the recent snapshot copy code that @brauner wrote last week we should have the needed send/recv logic for such cases and should be able to add a new pool property to control this behavior.

@brauner thoughts?

[brauner]

@stgraber, @Lisio: https://github.com/lxc/lxd/issues/3006#issuecomment-288121328 that what you mean?

[Lisio]

@brauner Yes, it looks similar.
P.S. You mistyped in "zfs destroy zfs receive".

[stgraber]

@brauner yeah but configurable at the storage pool level similar to the other zfs.* options we've got in there.

If set to true, then LXD would use "zfs send | zfs recv" for any container copy. We'd still be cloning from images though for the initial creation (if there is a good reason not to in some cases, we can add another option for it later).