Previously the WSL user-mode networking distribution was only installed as part
of a change, when it should have been also applied installs. This mean that the
init flag usage only worked after a previous set command.
[NO NEW TESTS NEEDED]
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
Setup and execute podman machine testing on bare-metal M1 Macs
using a pool of shared and semi-persistent hosts. Automated
and manual processes outside this repository are responsible
for providing and maintaining all hosts. Ref.
https://github.com/containers/automation/tree/main/mac_pw_pool
Update the `localmachine` make target to standardize execution
across platforms. Update/simplify podman-machine e2e README to
reflect current reality.
Warning: This CI setup and supporting infrastructure was developed
in favor of expediency vs reliability and stability. There are
many possible failure-modes (known and unknown) which may lead
to undefined test behaviors. Future work may address some of
these as they are encountered or discovered.
[NO NEW TESTS NEEDED]
Signed-off-by: Chris Evich <cevich@redhat.com>
Fixed a bug where `podman machine rm -f` would cause a deadlock when
running with WSL.
The deadlock is caused by the Remove() function calling the Stop()
function after Remove() locks the VM. Stop() also has a lock call, which
fails and deadlocks because Remove() already claimed lock. Fix this by
moving the stop call before the lock
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
Commit f48a706abc added a new API endpoint to remove exec session
correctly. And the bindings try to call that endpoint for exec every
time. Now since client and server must not be the same version this
causes a problem if a new 4.8 client calls an older 4.7 server as it has
no idea about such endpoint and throws an ugly error. This is a common
scenario for podman machine setups.
The client does know the server version so it should make sure to not
call such endpoint if the server is older than 4.8.
I added a exec test to the machine tests as this can be reproduced with
podman machine as at the moment at least the VM image does not contain
podman 4.8. And it should at least make sure podman exec keeps working
for podman machine without regressions.
Fixes#20821
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
1. Set the marker to the current virtual machine type instead of fixed qemu.
2. Update containers/common
[NO NEW TESTS NEEDED]
Signed-off-by: Black-Hole1 <bh@bugs.cc>
It makes more sense to key off the hypervisor/provider when pulling
disks from oci registries.
i.e. quay.io/libpod/podman-machine-images:5.0-qemu
Also, now that we are in 5.0-dev, I also removed the overrides always
making the podman version 4.6.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
If gvproxy or vfkit exit we can error right away, so while we wait for
the socket to get ready we also keep checking the process status with
wait4() and WNOHANG so it does not block forever.
This is completely untested as I do not have acces to apple machine.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
<MH: Added no new tests needed to pass CI>
[NO NEW TESTS NEEDED]
Signed-off-by: Matt Heon <mheon@redhat.com>
Removes the `MachineVMV1` and `MonitorV1` structures that have been
deprecated for a long enough period of time that it makes sense to no
longer support them.
Results in the removal of deprecated `getSocketAndPid` as well.
The migration code was added in commit
`6e0e1cbddd5e1c5dff51215ad2b41a99d890fad8` and made it into release `v4.1.0`
[NO NEW TESTS NEEDED]
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
florent found a bug where he used "applehv" as a machine name. it turns out when we use a vmtype name, esp. the active type, it really messes up directory structures for configuration and images alike.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Fixes nits that were suggested in #20420. The caller of
`ListenAndWaitOnSocket` did not use the value returned by the conn
channel, therefore it was better to just close the conn in the
`ListenAndWaitOnSocket` function instead.
[NO NEW TESTS NEEDED]
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
QEMU usb-host driver which is the one for passthrough, supports two
options for selecting an USB devices in the host to provide it to the
VM:
- Bus and Device number the device is plugged
- Vendor and Product information of the USB devices
https://qemu-project.gitlab.io/qemu/system/devices/usb.html
This commit allows a user to configure podman machine with either of
options, with new --usb command line option for podman machine init.
Examples
podman machine init tosovm4 --usb vendor=13d3,product=5406
podman machine init tosovm3 --usb bus=1,devnum=4 --usb bus=1,devnum=3
This commit also allows a user to change the USBs configured with
--usb command line option for podman machine set.
Note that this commit does not handle host device permissions nor
verify that the USB devices exists.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Creates a common SetIgnitionFile function in pkg/machine/ignition.go which
creates the new VMFile that will represent the machine's ignition file. It
assigns the VMFile to the provided location.
Creates an IgnitionBuilder type to generate the ignition configuration for a
given virt provider.
[NO NEW TESTS NEEDED]
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
In #20538, I was asked to consider refactoring the new OCI pull code
from within the generic machine directory. This is something I had
tried when originally coding it but it became apparent that a much
larger refactor to prevent circular deps was needed. Because I did not
want to pollute the initial PR with that refactor, I asked for the PR to
merge first. This is the refactor that needed to be done.
Signed-off-by: Brent Baude <bbaude@redhat.com>
FCOS has a security limitation where new directories cannot be added to the root / directory of its filesystem. This PR uses the work-around discussed in https://github.com/coreos/rpm-ostree/issues/337#issuecomment-1000923022 to temporarily disable the limitation, perform the mkdir, and then re-enable the limitation.
This PR allows mounts on the applehv to actually work.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
we should exit early if a system connection name exists with the name of
the proposed podman machine (i.e. podman-machine-default).
Signed-off-by: Brent Baude <bbaude@redhat.com>
allow podman machine to extract its disk image from an oci registry or
oci-dir locally. for now, the image must be relatively inflexible. it
must have 1 layer. the layer must possess one image. so a dockerfile
like:
FROM scratch
COPY ./myimage.xz /myimage.xz
when using an oci dir, the directory structure must adhere to the
typical directory structure of a an oci image (with one layer).
── blobs
│ └── sha256
│ ├── 53735773573b3853bb1cae16dd21061beb416239ceb78d4ef1f2a0609f7e843b
│ ├── 80577866ec13c041693e17de61444b4696137623803c3d87f92e4f28a1f4e87b
│ └── af57637ac1ab12f833e3cfa886027cc9834a755a437d0e1cf48b5d4778af7a4e
├── index.json
└── oci-layout
in order to identify this new input, you must use a transport/schema to
differentiate from current podman machine init --image-path behavior. we
will support `oci-dir://` and `docker://` as transports.
when using the docker transport, you can only use an empty transport for
input. for example, `podman machine init --image-path docker://`. A
fully quailified image name will be supported in the next iteration.
the transport absent anything means, i want to pull the default fcos
image stored in a registry. podman will determine its current version
and then look for its correlating manifest. in this default use case,
it would look for:
quay.io/libpod/podman-machine-images:<version>
that manifest would then point to specific images that contain the
correct arch and provider disk image. i.e.
quay.io/libpod/podman-machine-images:4.6-qcow2
this PR does not enable something like
docker://quay.io/mycorp/myimage:latest yet.
names, addresses, andf schema/transports are all subject to change. the
plan is to keep this all undocumented until things firm up.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Refactors machine socket mapping to prevent using similar/the same code
paths. Moves the shared code to `pkg/machine/sockets.go`.
[NO NEW TESTS NEEDED]
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Logging to os.Stdout and os.Stderr does not seem to work in
Powershell. I am not entirely certain why.
Logfiles are the best alternative I can think of.
Signed-off-by: Matt Heon <mheon@redhat.com>
Instead of trying to write out own code to do basic process
operations (e.g. checking if a PID is still running in a multi-OS
friendly manner), use shirou/gopsutil, a multi-platform library
that should abstract all the complexity away. Unlike our previous
approach on Windows, this one should actually work.
Signed-off-by: Matt Heon <mheon@redhat.com>
This includes two new hidden commands: a 9p server,
`podman machine server9p`, and a 9p client,
`podman machine client9p` with `server9p` currently only
configured to run on Windows and serve 9p via HyperV vsock, and
`client9p` only configured to run on Linux. The server is run by
`podman machine start` and has the same lifespan as gvproxy
(waits for the gvproxy PID to die before shutting down). The
client is run inside the VM, also by `podman machine start`, and
mounts uses kernel 9p mount code to complete the mount. It's
unfortunately not possible to use mount directly without the
wrapper; we need to set up the vsock and pass it to mount as an
FD.
In theory this can be generalized so that the server can run
anywhere and over almost any transport, but I haven't done this
here as I don't think we have a usecase other than HyperV right
now.
[NO NEW TESTS NEEDED] This requires changes to Podman in the VM,
so we need to wait until a build with this lands in FCOS to test.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
In the unusual case where the `runtimeDir` is not already created, we
should do so on `machine init`.
When starting gvproxy from podman, we now ensure it is running (for
applehv) but waiting for the unixgram socket to appear in the filesystem
before moving on.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>