podman
podman copied to clipboard
containers
Cannot create and start HyperV Podman machine if there is already one running
Issue Description
I created and started a first HyperV Podman machine (h1). When I do the same for a second one (h2), it gets created but start is rejected with the error message:
Error: unable to start "h2": machine h1: VM already running or starting
Steps to reproduce the issue
Steps to reproduce the issue
podman machine init h1 --rootful --nowpodman machine init h2 --rootful --now
Describe the results you received
podman machine init h2 --rootful --now
Looking up Podman Machine image at quay.io/podman/machine-os:5.1 to create VM
Extracting compressed file: h2-amd64.vhdx: done
Machine init complete
Starting machine "h2"
Error: unable to start "h2": machine h1: VM already running or starting
Describe the results you expected
Both podman machines running
podman info output
host:
arch: amd64
buildahVersion: 1.36.0
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
- misc
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.10-1.fc40.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.10, commit: '
cpuUtilization:
idlePercent: 99.01
systemPercent: 0.62
userPercent: 0.37
cpus: 6
databaseBackend: sqlite
distribution:
distribution: fedora
variant: coreos
version: "40"
eventLogger: journald
freeLocks: 2048
hostname: localhost.localdomain
idMappings:
gidmap: null
uidmap: null
kernel: 6.8.11-300.fc40.x86_64
linkmode: dynamic
logDriver: journald
memFree: 301465600
memTotal: 809566208
networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns-1.11.0-1.20240628130058229856.main.10.g5ad6420.fc40.x86_64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.12.0-dev
package: netavark-1.11.0-1.20240702123536284903.main.32.g49fb0c2.fc40.x86_64
path: /usr/libexec/podman/netavark
version: netavark 1.12.0-dev
ociRuntime:
name: crun
package: crun-1.15-1.20240708144150212138.main.51.g6c158dd.fc40.x86_64
path: /usr/bin/crun
version: |-
crun version UNKNOWN
commit: 3d4f083b67cc1a967482cd6110b678be991b9ab3
rundir: /run/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
pasta:
executable: /usr/bin/pasta
package: passt-0^20240624.g1ee2eca-1.fc40.x86_64
version: |
pasta 0^20240624.g1ee2eca-1.fc40.x86_64
Copyright Red Hat
GNU General Public License, version 2 or later
<https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
remoteSocket:
exists: true
path: /run/podman/podman.sock
rootlessNetworkCmd: pasta
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.2-2.fc40.x86_64
version: |-
slirp4netns version 1.2.2
commit: 0ee2d87523e906518d34a6b423271e4826f71faf
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.5
swapFree: 0
swapTotal: 0
uptime: 0h 4m 13.00s
variant: ""
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
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.imagestore: /usr/lib/containers/storage
overlay.mountopt: nodev,metacopy=on
overlay.use_composefs: "false"
graphRoot: /var/lib/containers/storage
graphRootAllocated: 106769133568
graphRootUsed: 4211679232
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "false"
Supports d_type: "true"
Supports shifting: "true"
Supports volatile: "true"
Using metacopy: "true"
imageCopyTmpDir: /var/tmp
imageStore:
number: 0
runRoot: /run/containers/storage
transientStore: false
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 5.1.2
Built: 1720569600
BuiltTime: Wed Jul 10 00:00:00 2024
GitCommit: ""
GoVersion: go1.22.5
Os: linux
OsArch: linux/amd64
Version: 5.1.2
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
This is expected, there can only ever be one running VM (WSL is the exception), see https://github.com/containers/podman/issues/18415
This is expected, there can only ever be one running VM (WSL is the exception), see #18415
The error message is kinda cryptic then and I can start several HyperV machines:
podman machine init h1 --nowpodman machine init h2podman machine start h2
I don't have access to a windows system but looking at the code this should be impossible, it fails correctly for we with qemu and it uses the exact same code with hyperV as well. Are you sure your didn't create WSL machines there?
How should the error look in your opinion then?
I don't have access to a windows system but looking at the code this should be impossible, it fails correctly for we with qemu and it uses the exact same code with hyperV as well. Are you sure your didn't create WSL machines there?
No I switched to provider=hyperv in containers.conf so WSL is not in the scenario
How should the error look in your opinion then?
Either can't create 2 HyperV machines or can't start 2 HyperV machines
you can create as many machines as you want you just cannot have more than one running at the same time.
No I switched to provider=hyperv in containers.conf so WSL is not in the scenario
I am not sure I can follow here. You reported this bug saying it does not work but now you are saying it does work? What is the difference?
you can create as many machines as you want you just cannot have more than one running at the same time.
No I switched to provider=hyperv in containers.conf so WSL is not in the scenario
I am not sure I can follow here. You reported this bug saying it does not work but now you are saying it does work? What is the difference?
I was just answering that WSL was not involved in the scenario as I switched containers.conf and I made sure I had no existing WSL machines
Right but you reported this issue saying you cannot start more than one hyperV machine which as I said is expected.
Then you answered that in fact you can start more than one hyperV machine so that just leaves me totally confused. Which is it now? I can just look at the code here and say it works the same way on qemu, applehv, hyperV and libkrun so it should rightfully error out when you try to start another VM when one is already running.
If I create and start the machines in 1 step then it fails. If I create the machines then start them, then it works. That's why I think multi machines are supported but the error reported is a bug