Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't start HyperV machine #25500

Open
jeffmaury opened this issue Mar 7, 2025 · 2 comments
Open

Can't start HyperV machine #25500

jeffmaury opened this issue Mar 7, 2025 · 2 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. machine windows issue/bug on Windows

Comments

@jeffmaury
Copy link

Issue Description

I can't start HyperV podman machines got an error each time I start it. The VM is started but the initialization process is errored.
Might be cause by my Windows user name (thus home dirrectory) containing space

Steps to reproduce the issue

Steps to reproduce the issue

  1. create an HyperV podman machine
  2. start it

Describe the results you received

VM is started, error messages in the console:

podman machine start h1
Starting machine "h1"

This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:

        podman machine set --rootful h1

Error: accepts 2 arg(s), received 3
Error: Process exited with status 125

Describe the results you expected

Machine should be started successfully

podman info output

OS: windows/amd64
provider: hyperv
version: 5.4.0

Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:59529: connectex: No connection could be made because the target machine actively refused it.

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Win11Pro

Additional information

podman machine start --log-level debug h1
time="2025-03-07T09:10:00+01:00" level=info msg="podman filtering at log level debug"
time="2025-03-07T09:10:00+01:00" level=debug msg="Using Podman machine with `hyperv` virtualization provider"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\hyperv is 60"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\hyperv is 65"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\hyperv\\cache is 71"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\JEFFMA~1\\AppData\\Local\\Temp\\podman is 43"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\hyperv\\h1.json is 68"
Starting machine "h1"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\wsl is 57"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\wsl is 62"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\wsl\\cache is 68"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\JEFFMA~1\\AppData\\Local\\Temp\\podman is 43"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\wsl\\podman-machine-default.json is 85"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\hyperv is 60"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\hyperv is 65"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.local\\share\\containers\\podman\\machine\\hyperv\\cache is 71"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\JEFFMA~1\\AppData\\Local\\Temp\\podman is 43"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\hyperv\\h1.json is 68"
time="2025-03-07T09:10:00+01:00" level=debug msg="socket length for C:\\Users\\Jeff Maury\\.config\\containers\\podman\\machine\\hyperv\\h3.json is 68"
Error: unable to start "h1": already running
time="2025-03-07T09:10:00+01:00" level=debug msg="Shutting down engines"
@jeffmaury jeffmaury added the kind/bug Categorizes issue or PR as related to a bug. label Mar 7, 2025
@Luap99 Luap99 added machine windows issue/bug on Windows labels Mar 7, 2025
@Luap99
Copy link
Member

Luap99 commented Mar 7, 2025

My guess would be that this is coming from mounting the volumes via our own 9p process.

If you init the VM with --volume= to not use any volumes or specify a custom volume with a path with spaces does it work?

The thing is we do handle argv properly as array so spaces do not matter for us. However the issue is that ssh cannot deal with argv array at all and just joins the args with spaces. So when we exec into the machine via ssh to start the client9p process it gets the wrong arguments now because ssh is unable to actually correctly handle multiple arguments which is well known:

A complete command line may be specified as command, or it may have additional arguments. If supplied, the arguments will be appended to the command, separated by spaces, before it is sent to the server to be executed.

So the only fix for us would be to escape the arguments before giving them to ssh.

@jeffmaury
Copy link
Author

My guess would be that this is coming from mounting the volumes via our own 9p process.

If you init the VM with --volume= to not use any volumes or specify a custom volume with a path with spaces does it work?

The thing is we do handle argv properly as array so spaces do not matter for us. However the issue is that ssh cannot deal with argv array at all and just joins the args with spaces. So when we exec into the machine via ssh to start the client9p process it gets the wrong arguments now because ssh is unable to actually correctly handle multiple arguments which is well known:

A complete command line may be specified as command, or it may have additional arguments. If supplied, the arguments will be appended to the command, separated by spaces, before it is sent to the server to be executed.

So the only fix for us would be to escape the arguments before giving them to ssh.

I confirm the machine can start if it has been created with --volume=

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. machine windows issue/bug on Windows
Projects
None yet
Development

No branches or pull requests

2 participants