Feature request: preserve container images across podman machine recreation

[avx-rchung]

/kind feature

Description

When using the podman machine setup today, every time the VM is recreated all the images (podman image) are lost. It would be nice if they are preserved, similar to how things work with Docker desktop.

Steps to reproduce the issue:

1. podman machine init --now

2. pull some image

~% podman pull alpine:latest
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob sha256:9b18e9b68314027565b90ff6189d65942c0f7986da80df008b8431276885218e
Copying config sha256:a6215f271958c760a2975a6765016044115dbae4b90f414eba3a448a6a26b4f6
Writing manifest to image destination
Storing signatures
a6215f271958c760a2975a6765016044115dbae4b90f414eba3a448a6a26b4f6
~% podman image list
REPOSITORY                TAG         IMAGE ID      CREATED       SIZE
docker.io/library/alpine  latest      a6215f271958  2 months ago  5.58 MB

3. podman machine stop; podman machine rm podman-machine-default
4. podman machine init --now
5. Observe that all images are gone

~% podman image list
REPOSITORY  TAG         IMAGE ID    CREATED     SIZE
~%

Describe the results you received:

After recreating the VM, pulled container images are lost.

Describe the results you expected:

Container image lifecycle is independent of VM lifecycle.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

~% podman version
Client:       Podman Engine
Version:      4.2.1
API Version:  4.2.1
Go Version:   go1.18.6
Built:        Tue Sep  6 12:16:02 2022
OS/Arch:      darwin/arm64

Server:       Podman Engine
Version:      4.2.1
API Version:  4.2.1
Go Version:   go1.18.5
Built:        Wed Sep  7 12:59:25 2022
OS/Arch:      linux/arm64

Output of podman info:

~% podman info
host:
  arch: arm64
  buildahVersion: 1.27.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.4-2.fc36.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: '
  cpuUtilization:
    idlePercent: 82.38
    systemPercent: 12.42
    userPercent: 5.2
  cpus: 4
  distribution:
    distribution: fedora
    variant: coreos
    version: "36"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.19.12-200.fc36.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 702210048
  memTotal: 2051194880
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.6-2.fc36.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.aarch64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 3m 6.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 106825756672
  graphRootUsed: 9617956864
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.2.1
  Built: 1662580765
  BuiltTime: Wed Sep  7 12:59:25 2022
  GitCommit: ""
  GoVersion: go1.18.5
  Os: linux
  OsArch: linux/arm64
  Version: 4.2.1

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

~% brew info podman
==> podman: stable 4.2.1 (bottled), HEAD
Tool for managing OCI containers and pods
https://podman.io/
/Users/randolphchung/homebrew/Cellar/podman/4.2.1 (178 files, 48MB) *
  Poured from bottle on 2022-10-09 at 17:03:09
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/podman.rb
License: Apache-2.0
==> Dependencies
Build: go-md2man ✘, go@1.18 ✘
Required: qemu ✔
==> Options
--HEAD
    Install HEAD version
==> Caveats
zsh completions have been installed to:
  /Users/randolphchung/homebrew/share/zsh/site-functions

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.): Physical M1Pro laptop

[mheon]

@baude PTAL

[afbjorklund]

The previous machine used separate disk images for this, one for os - one for storage

Both were still deleted on "rm" though. It was mostly for os updates

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[jdelker]

is there any workaround available for this? Like securing the images from the old machine and importing them into the new one?

[rhatdan]

You would need to save them locally on your host system perhaps through a podman image save and then when you have the new machine do a podman image load.