4 Commits

Author SHA1 Message Date
8532ecb710 fix wsl install workflow on machine init command
this patch changes how the detection of wsl works.
The old way of using wsl --status command output to detect some missing features required by WSL is not fully reliable.
WSL checks if the wsl feature is enabled and if the vmcompute service do exist. However, this is not enough to identify if the virtual machine platform feature is enabled. The vmcompute service could exist because it has been installed by other tools or it could exist but being stopped.

The way proposed by this patch is to try execute the import command and,
if it fails, check the error and if it is related to the Host Compute
Service try to install all features required by WSL.

The flow is the same as before, the user is asked to execute the podman
machine init command with elevated privileges. Eventually, after
enabling WSL and VMP features, the user is asked to reboot the machine.

When the machine restarts, the powershell gets invoked again and execute
the command init.

The code also fixes some issues that could cause misbehaviors when
invoking recursively the elevated shell, like an unreleased lock, or a
missing file.

Signed-off-by: lstocchi <lstocchi@redhat.com>
2025-06-04 14:26:48 +02:00
4eeaedfe13 Prevent two podman machines running on darwin
As issue #25112 points out, it was possible to start a machine on one of the darwin providers and then switch providers and start another one with a different name.  This PR firstly prevents that use which is a forbidden use case.

Secondarily, performed some minor cleanup on the error messages being used so that the error would be specific to this condition.

This bug fix is for darwin only.  In the case of Windows, we probably need to answer the question I raised in #24067 first, which is whether we want to stop allowing WSL to run multiple machines.

Fixes #25112

Signed-off-by: Brent Baude <bbaude@redhat.com>
2025-01-29 13:24:18 -06:00
d3328d4f32 Don't panic on podman4 machine configs
we should not panic podman when it has to deal with a podman4 machine
config.  instead, we throw a soft error for `machine ls` and in all
other cases, we throw a hard error stating that the machine config is
incompatible.

a future PR will provide instructions on how to recover from this.
current idea is something like `podman machine reset` which blows
everything away machine-wise.

Signed-off-by: Brent Baude <bbaude@redhat.com>
2024-02-12 09:10:46 -06:00
9bb191df51 [CI:MACHINE]Podman5 QEMU refactor
The following PR is the leading PR for refactoring podman machine with
the following goals:

* less duplication/more re-use
* common configuration file between providers
* more consistentency in how machines are handled by providers

The goal of this PR is the rough refactor.  There are still rough spots
for sure, specifically around the podman socket and pipe.  This
implemention is only for Linux. All other providers are still present
but will not compile or work.  This is why tests for them have been
temporarily suspended.

The ready socket code is another area that needs to be smoothed over.
Right now, the ready socket code is still in QEMU.  Preferably it would
be moved to a generic spot where all three approaches to readiness
socket use can be defined.

It should also be noted:

* all machine related tests pass.
* make validate for Linux passes
* Apple QEMU was largely removed
* More code pruning is possible; will become clearer when other
  providers are complete.

the dir pkg/machine/p5 is not permanent.  i had to seperate this from
machine initially due to circular import problems.  i think when all
providers are done (or nearly done), it can be placed and named
properly.

Signed-off-by: Brent Baude <bbaude@redhat.com>
2024-02-07 09:18:36 -06:00