The storage driver and the storage options in storage.conf should
match, but if you change the storage driver via the command line
then we need to nil out the default storage options from storage.conf.
If the user wants to change the storage driver and use storage options,
they need to specify them on the command line.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
on old kernels the ioctl NS_GET_PARENT is not available.
Handle the error code and immediately return the same fd. It should
be fine now that we use the namespace resolution using the conmon pid,
so the namespace parent resolution is just a safety measure.
Closes: https://github.com/containers/libpod/issues/2968
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
With multiple `containers` projects updating VM Image metadata,
it would be very difficult to discover which Cirrus-CI setup
was responsible. Add the GCE project name to the list
of metadata labels to update when this container runs. This
will give more context as to which images are currently in use.
Signed-off-by: Chris Evich <cevich@redhat.com>
The option to restore a container from an external checkpoint archive
(podman container restore -i /tmp/checkpoint.tar.gz) restores a
container with the same name and same ID as id had before checkpointing.
This commit adds the option '--name,-n' to 'podman container restore'.
With this option the restored container gets the name specified after
'--name,-n' and a new ID. This way it is possible to restore one
container multiple times.
If a container is restored with a new name Podman will not try to
request the same IP address for the container as it had during
checkpointing. This implicitly assumes that if a container is restored
from a checkpoint archive with a different name, that it will be
restored multiple times and restoring a container multiple times with
the same IP address will fail as each IP address can only be used once.
Signed-off-by: Adrian Reber <areber@redhat.com>
If restoring a container from a checkpoint it was necessary that the
image the container is based was already available (podman pull).
This commit adds the image download to podman container restore if it
does not exist.
Signed-off-by: Adrian Reber <areber@redhat.com>
The difference between container checkpoint/restore and container
migration is that for migration the container which was checkpointed
must not exist during restore. To simulate migration the container
is remove ('podman rm -fa') before being restored. The migration test
does following steps:
* podman run
* podman container checkpoint -l -e /tmp/checkpoint.tar.gz
* podman rm -fa
* podman container restore -i /tmp/checkpoint.tar.gz
Signed-off-by: Adrian Reber <areber@redhat.com>
This commit adds an option to the checkpoint command to export a
checkpoint into a tar.gz file as well as importing a checkpoint tar.gz
file during restore. With all checkpoint artifacts in one file it is
possible to easily transfer a checkpoint and thus enabling container
migration in Podman. With the following steps it is possible to migrate
a running container from one system (source) to another (destination).
Source system:
* podman container checkpoint -l -e /tmp/checkpoint.tar.gz
* scp /tmp/checkpoint.tar.gz destination:/tmp
Destination system:
* podman pull 'container-image-as-on-source-system'
* podman container restore -i /tmp/checkpoint.tar.gz
The exported tar.gz file contains the checkpoint image as created by
CRIU and a few additional JSON files describing the state of the
checkpointed container.
Now the container is running on the destination system with the same
state just as during checkpointing. If the container is kept running
on the source system with the checkpoint flag '-R', the result will be
that the same container is running on two different hosts.
Signed-off-by: Adrian Reber <areber@redhat.com>
This adds a couple of function in structure members needed in the next
commit to make container migration actually work. This just splits of
the function which are not modifying existing code.
Signed-off-by: Adrian Reber <areber@redhat.com>
