lxc-copy(1) | lxc-copy(1) |
lxc-copy - copy an existing container.
lxc-copy
{-n, --name name} [-P, --lxcpath path] {-N, --newname
newname} [-p, --newpath newpath] [-B, --backingstorage
backingstorage] [-s, --snapshot] [-a, --allowrunning] [-K,
--keepname] [-D, --keepdata] [-M, --keepmac] [-L, --fssize size
[unit]] [-- hook arguments]
lxc-copy
{-n, --name name} [-P, --lxcpath path] [-N, --newname
newname] [-p, --newpath newpath] {-e, --ephemeral} [-B,
--backingstorage backingstorage] [-s, --snapshot] [-a,
--allowrunning] [-K, --keepname] [-D, --keepdata] [-M, --keepmac] [-L,
--fssize size [unit]] [-- hook arguments]
lxc-copy
{-n, --name name} [-P, --lxcpath path] [-N, --newname
newname] [-p, --newpath newpath] {-e, --ephemeral} [-B,
--backingstorage backingstorage] [-s, --snapshot] [-t, --tmpfs] [-K,
--keepname] [-M, --keepmac] [-- hook arguments]
lxc-copy
{-n, --name name} [-P, --lxcpath path] {-N, --newname
newname} [-p, --newpath newpath] {-R, --rename}
lxc-copy creates and optionally starts (ephemeral or non-ephemeral) copies of existing containers.
lxc-copy creates copies of existing containers. Copies can be complete clones of the original container. In this case the whole root filesystem of the container is simply copied to the new container. Or they can be snapshots, i.e. small copy-on-write copies of the original container. In this case the specified backing storage for the copy must support snapshots. This currently includes btrfs, lvm (lvm devices do not support snapshots of snapshots.), overlay, and zfs.
The copy's backing storage will be of the same type as the original container. overlay snapshots of directory backed containers are exempted from this rule.
When the -e flag is specified an ephemeral snapshot of the original container is created and started. Ephemeral containers will have lxc.ephemeral = 1 set in their config file and will be destroyed on shutdown. When -e is used in combination with -D a non-ephemeral snapshot of the original container is created and started. Ephemeral containers can also be placed on a tmpfs with -t flag. NOTE: If an ephemeral container that is placed on a tmpfs is rebooted all changes made to it will currently be lost!
When -e is specified and no newname is given via -N a random name for the snapshot will be chosen.
Containers created and started with -e can have custom mounts. These are specified with the -m flag. Currently two types of mounts are supported: bind, and overlay. Mount types are specified as suboptions to the -m flag and can be specified multiple times separated by commas. overlay mounts are currently specified in the format -m overlay=/src:/dest. When no destination dest is specified dest will be identical to src. Read-only bind mounts are specified -m bind=/src:/dest:ro and read-write bind mounts -m bind=/src:/dest:rw. Read-write bind mounts are the default and rw can be missing when a read-write mount is wanted. When dest is missing dest will be identical to src. An example for multiple mounts would be -m bind=/src1:/dest1:ro,bind=/src2:ro,overlay=/src3:/dest3.
The mounts, their options, and formats supported via the -m flag are subject to change.
If the container being copied has one or more lxc.hook.clone specified, then the specified hooks will be called for the new container. The first 3 arguments passed to the clone hook will be the container name, a section ('lxc'), and the hook type ('clone'). Extra arguments passed to lxc-copy will be passed to the hook program starting at argument 4. The LXC_ROOTFS_MOUNT environment variable gives the path under which the container's root filesystem is mounted. The configuration file pathname is stored in LXC_CONFIG_FILE, the new container name in LXC_NAME, the old container name in LXC_SRC_NAME, and the path or device on which the rootfs is located is in LXC_ROOTFS_PATH.
These options are common to most of lxc commands.
Note that this option is setting the priority of the events log in the alternate log file. It do not have effect on the ERROR events log on stderr.
This configuration file if present will be used even if there is already a configuration file present in the previously created container (via lxc-create).
lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)
Christian Brauner <christian.brauner@mailbox.org>
2023-02-19 |