Import exported container as an image

[melato]

Feature Request. Based on LXD 3.6

I would like to import an exported container as an image. It already contains all the files of an exported image but with a different path prefix.

Justification: A tarball created by exporting a container is very similar with a tarball created by exporting an image. I would like to be able to use them interchangeably, with either or both of the following enhancements:

• Import an exported container as an image (avoiding repackaging the tarball).
• Export a container as an image (bypassing the storage of an intermediate image).

The two different tarballs are currently created by:

export a container:

lxc export ${container} ${export-dir}/${container}.tar.xz --container-only

export a container as an image:

lxc snapshot ${container} temp
lxc publish ${container}/temp --alias=${container}
lxc image export ${container} ${export-dir}/${container}
lxc image delete ${container}
lxc delete ${container}/temp

An image has the following file structure:

metadata.yaml
templates
templates/...
rootfs
rootfs/...

An exported container has the file structure:

backup/index.yaml
backup/container/backup.yaml
backup/container/metadata.yaml
backup/container/templates/
backup/container/templates/...
backup/container/rootfs/
backup/container/rootfs/...

Both can be used for backups. The container export is faster, because it can be exported and imported directly between the container and the disk tarball. But it is more restrictive, because it can be imported only in a very similar LXD setup. I'm not exactly sure where it can be imported, but I've run to at least three problems:

• The importing LXD must have the same storage pool type. (Why?)
• For a ZFS storage pool, the importing LXD must use a dataset with the same name (Why?)
• The importing LXD must have profiles with the same names as used by the exported container

These are some errors, I've encountered while trying to import an exported container:

Error: Internal import request: The storage pool's "default" driver "dir" conflicts with the driver "zfs" recorded in the container's backup file Error: Internal import request: Failed to list ZFS snapshots: cannot open 'z/lxd/containers/pound': dataset does not exist Error: Internal import request: Create container: Requested profile 'prod0' doesn't exist

An image does not have these restrictions. It is therefore more versatile as a backup solution (except that it needs the profiles, and perhaps other configuration, which can be exported and imported separately).

[stgraber]

I expect we'll be keeping the two concepts separate and that addition to our backups will further drive them away from images.

Right now they differ in:

• Backups include container configuration and storage information
• Backups can (and usually should be) backend specific, including optimized binary data for restoration in the storage pool
• Backups are shifted, that is, all files belong to the container rather than root
• Backups may include snapshots

To import a backup as a valid image, LXD would need to:

• Unshift all files in the backup
• Remove snapshots
• Require the backup not be storage specific
• Cleanup container metadata/backup data
• Inject image metadata somehow
• Re-compress the resulting artifact and hash it to obtain the image fingerprint

Because it'd need to be recompressed and re-hashed, this would equate to doing lxc import + lxc publish, at which point you may as well just do that.

As for your questions, I suspect you were dealing with an optimized backup, or LXD thought it was an optimized backup anyway, in which case, binary ZFS data is part of the backup and so requires restoration on a ZFS pool running the same or more recent version of ZFS and because the various binary dumps refer to each another based on dataset name, requires the name be the same.

Closing this issue as we don't plan on the two concepts to become closer to each another, quite the opposite actually.