summaryrefslogtreecommitdiff
path: root/libpod/stats.go
diff options
context:
space:
mode:
authorBurt Holzman <burt@fnal.gov>2022-03-23 10:42:05 -0500
committerMatthew Heon <mheon@redhat.com>2022-03-30 15:36:05 -0400
commit8bc2f6cd8486c893c292da3aa64965d10cd8ffe8 (patch)
tree402b140b87bd2b9a4148b309bf6a3bed83b86543 /libpod/stats.go
parent82c01341f792462c78e9390c3c92b5487e26cdf3 (diff)
downloadpodman-8bc2f6cd8486c893c292da3aa64965d10cd8ffe8.tar.gz
podman-8bc2f6cd8486c893c292da3aa64965d10cd8ffe8.tar.bz2
podman-8bc2f6cd8486c893c292da3aa64965d10cd8ffe8.zip
Explicitly use IPv4 to check if podman-machine VM is listening
When starting a VM that has been configured with volume mounts, the podman client attempts to connect via TCP to localhost, which runs gvproxy to proxy an ephemeral port to the VM's ssh port. Previously, gvproxy was listening on all interfaces and IP addresses, but this behavior has changed to listening only on the IPv4 loopback address. Without this change, if a newer build of gvproxy is used, a podman machine configured with volume mounts will hang forever after "podman machine start" with "Waiting for VM ...". [NO NEW TESTS NEEDED] Signed-off-by: Burt Holzman <burt@fnal.gov>
Diffstat (limited to 'libpod/stats.go')
0 files changed, 0 insertions, 0 deletions