1podman-container-clone(1)() podman-container-clone(1)()
2
6 podman-container-clone - Creates a copy of an existing container
7
10 podman container clone [options] container name image
11
14 podman container clone creates a copy of a container, recreating the
15 original with an identical configuration. This command takes three ar‐
16 guments: the first being the container id or name to clone, the second
17 argument in this command can change the name of the clone from the de‐
18 fault of $ORIGINAL_NAME-clone, and the third is a new image to use in
19 the cloned container.
20
23 --cpu-period=limit
24 Set the CPU period for the Completely Fair Scheduler (CFS), which is a
25 duration in microseconds. Once the container's CPU quota is used up, it
26 will not be scheduled to run until the current period ends. Defaults to
27 100000 microseconds.
28 On some systems, changing the CPU limits may not be allowed for non-
31 root users. For more details, see https://github.com/containers/pod‐
32 man/blob/master/troubleshooting.md#26-running-containers-with-cpu-lim‐
33 its-fails-with-a-permissions-error
34 If none is specified, the original container's cpu period is used
37 --cpu-quota=limit
40 Limit the CPU Completely Fair Scheduler (CFS) quota.
41 Limit the container's CPU usage. By default, containers run with the
44 full CPU resource. The limit is a number in microseconds. If a number
45 is provided, the container will be allowed to use that much CPU time
46 until the CPU period ends (controllable via --cpu-period).
47 On some systems, changing the CPU limits may not be allowed for non-
50 root users. For more details, see https://github.com/containers/pod‐
51 man/blob/master/troubleshooting.md#26-running-containers-with-cpu-lim‐
52 its-fails-with-a-permissions-error
53 If none is specified, the original container's CPU quota are used.
56 --cpu-rt-period=microseconds
59 Limit the CPU real-time period in microseconds
60 Limit the container's Real Time CPU usage. This option tells the kernel
63 to restrict the container's Real Time CPU usage to the period speci‐
64 fied.
65 This option is not supported on cgroups V2 systems.
68 If none is specified, the original container's CPU runtime period is
71 used.
72 --cpu-rt-runtime=microseconds
75 Limit the CPU real-time runtime in microseconds.
76 Limit the containers Real Time CPU usage. This option tells the kernel
79 to limit the amount of time in a given CPU period Real Time tasks may
80 consume. Ex: Period of 1,000,000us and Runtime of 950,000us means that
81 this container could consume 95% of available CPU and leave the remain‐
82 ing 5% to normal priority tasks.
83 The sum of all runtimes across containers cannot exceed the amount al‐
86 lotted to the parent cgroup.
87 This option is not supported on cgroups V2 systems.
90 --cpu-shares=shares
93 CPU shares (relative weight)
94 By default, all containers get the same proportion of CPU cycles. This
97 proportion can be modified by changing the container's CPU share
98 weighting relative to the weighting of all other running containers.
99 To modify the proportion from the default of 1024, use the --cpu-shares
102 option to set the weighting to 2 or higher.
103 The proportion will only apply when CPU-intensive processes are run‐
106 ning. When tasks in one container are idle, other containers can use
107 the left-over CPU time. The actual amount of CPU time will vary depend‐
108 ing on the number of containers running on the system.
109 For example, consider three containers, one has a cpu-share of 1024 and
112 two others have a cpu-share setting of 512. When processes in all three
113 containers attempt to use 100% of CPU, the first container would re‐
114 ceive 50% of the total CPU time. If a fourth container is added with a
115 cpu-share of 1024, the first container only gets 33% of the CPU. The
116 remaining containers receive 16.5%, 16.5% and 33% of the CPU.
117 On a multi-core system, the shares of CPU time are distributed over all
120 CPU cores. Even if a container is limited to less than 100% of CPU
121 time, it can use 100% of each individual CPU core.
122 For example, consider a system with more than three cores. container
125 {C0} is started with -c=512 running one process, and another container
126 {C1} with -c=1024 running two processes, this can result in the follow‐
127 ing division of CPU shares:
128 PID container CPU CPU share 100 {C0} 0 100% of
131 CPU0 101 {C1} 1 100% of CPU1 102
132 {C1} 2 100% of CPU2
133 If none are specified, the original container's CPU shares are used.
136 --cpus
139 Set a number of CPUs for the container that overrides the original con‐
140 tainers CPU limits. If none are specified, the original container's
141 Nano CPUs are used.
142 This is shorthand for --cpu-period and --cpu-quota, so only --cpus or
145 either both the --cpu-period and --cpu-quota options can be set.
146 --cpuset-cpus
149 CPUs in which to allow execution (0-3, 0,1). If none are specified, the
150 original container's CPUset is used.
151 --cpuset-mems=nodes
154 Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effec‐
155 tive on NUMA systems.
156 If there are four memory nodes on the system (0-3), use --cpuset-
159 mems=0,1 then processes in the container will only use memory from the
160 first two memory nodes.
161 If none are specified, the original container's CPU memory nodes are
164 used.
165 --destroy
168 Remove the original container that we are cloning once used to mimic
169 the configuration.
170 --force, -f
173 Force removal of the original container that we are cloning. Can only
174 be used in conjunction with --destroy.
175 --memory, -m=limit
178 Memory limit (format: <number>[<unit>], where unit = b (bytes), k
179 (kibibytes), m (mebibytes), or g (gibibytes))
180 Allows the memory available to a container to be constrained. If the
183 host supports swap memory, then the -m memory setting can be larger
184 than physical RAM. If a limit of 0 is specified (not using -m), the
185 container's memory is not limited. The actual limit may be rounded up
186 to a multiple of the operating system's page size (the value would be
187 very large, that's millions of trillions).
188 If no memory limits are specified, the original container's will be
191 used.
192 --memory-reservation=limit
195 Memory soft limit (format: <number>[<unit>], where unit = b (bytes), k
196 (kibibytes), m (mebibytes), or g (gibibytes))
197 After setting memory reservation, when the system detects memory con‐
200 tention or low memory, containers are forced to restrict their consump‐
201 tion to their reservation. So you should always set the value below
202 --memory, otherwise the hard limit will take precedence. By default,
203 memory reservation will be the same as memory limit from the container
204 being cloned.
205 --memory-swap=limit
208 A limit value equal to memory plus swap. Must be used with the -m
209 (--memory) flag. The swap LIMIT should always be larger than -m (--mem‐
210 ory) value. By default, the swap LIMIT will be set to double the value
211 of --memory if specified. Otherwise, the container being cloned will be
212 used to derive the swap value.
213 The format of LIMIT is <number>[<unit>]. Unit can be b (bytes), k
216 (kibibytes), m (mebibytes), or g (gibibytes). If you don't specify a
217 unit, b is used. Set LIMIT to -1 to enable unlimited swap.
218 --memory-swappiness=number
221 Tune a container's memory swappiness behavior. Accepts an integer be‐
222 tween 0 and 100.
223 This flag is not supported on cgroups V2 systems.
226 --name
229 Set a custom name for the cloned container. The default if not speci‐
230 fied is of the syntax: -clone
231 --pod=name
234 Clone the container in an existing pod. It is helpful to move a con‐
235 tainer to an existing pod. The container will join the pod shared
236 namespaces, losing its configuration that conflicts with the shared
237 namespaces.
238 --run
241 When set to true, this flag runs the newly created container after the
242 clone process has completed, this specifies a detached running mode.
243
246 # podman container clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
247 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584
248 # podman container clone --name=clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
252 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584
253 # podman container clone --destroy --cpus=5 d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
257 6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584
258 # podman container clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name fedora
262 Resolved "fedora" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
263 Trying to pull registry.fedoraproject.org/fedora:latest...
264 Getting image source signatures
265 Copying blob c6183d119aa8 done
266 Copying config e417cd49a8 done
267 Writing manifest to image destination
268 Storing signatures
269 5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9
270
274 podman-create(1), cgroups(7)
275
278 January 2022, Originally written by Charlie Doern cdoern@redhat.com
279 ⟨mailto:cdoern@redhat.com⟩
280 podman-container-clone(1)()