容器运行时云原生CLI【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址https://gitcode.com/gh_mirrors/po/podman点击查看免费下载本指南基于 Podman 仓库中的 QEMU 远程教程讲解如何在一台 Windows 机器上使用自定义 QEMU 虚拟机承载 Linux 环境让 Windows 上的podmanPodman-remote 客户端通过 SSH 隧道远程驱动虚拟机内的 Podman 服务。读完本文你将掌握从下载 QEMU 与 Fedora CoreOS 镜像、编写 Ignition 引导配置、启动 gvproxy 与虚拟机到注册podman system connection连接并运行真实容器工作负载的完整链路并理解每一步背后的源码级实现原理。方案定位实验性自定义虚拟机 vs 官方 Podman machine在进入具体步骤之前需要明确本方案在整个 Podman Windows 生态中的定位。原文档明确指出这是一个实验性experimental方案使用 QEMU 虚拟机为 Windows 上的 Podman-remote 客户端提供 Linux 后端而官方推荐且受支持的方式是 Podman for Windows 指南所描述的 Podman machine——即由podman machine命令统一管理的 Linux 后端Windows 上基于 WSLv2 或 Hyper-V。二者在架构上的本质区别在于维度Podman machine官方推荐本教程 QEMU 方案实验性虚拟机生命周期由podman machine init/start/stop/rm全权管理手工启动 QEMU关闭需自行 SSH 登录执行poweroff镜像分发内置容器镜像自动下载手工下载 Fedora CoreOS 的.qcow2镜像网络与端口转发gvproxy由 Podman 自动拉起并管理需要手工先启动gvproxy.exe适用人群大多数普通用户需要自定义 Linux VM、深度掌控底层行为的进阶用户需要强调的是原文档中的几个外部下载链接QEMU 官方 Windows 构建页面、Fedora 官网的 CoreOS 下载站、Podman 与 gvisor-tap-vsock 的发布页只是下载来源说明本教程给出的是操作路径而非依赖这些站点的托管内容。前置条件清单动手之前请确认 Windows 主机满足以下全部条件Windows 版本Windows 10 Build 18362 或更高官方建议使用 Build 19044Version 21H2或更高版本SSH 客户端系统已安装 OpenSSH 客户端功能虚拟化加速Hyper-V 加速即 WHPXWindows Hypervisor Platform在机器上处于可用状态用于 QEMU 的硬件加速若不可用则回退到 TCG 软件模拟性能会明显下降工作目录新建C:\qemu-remote\目录用于集中存放 QEMU 镜像、SSH 密钥、Ignition 配置等全部资产端口占用确认端口57561空闲该端口将用于经回环loopback接口的 SSH 转发。获取与安装QEMU、Fedora CoreOS 与 Podman安装 QEMU从 QEMU 官方 Windows 构建qemu.weilnetz.de 的 w64 目录下载QEMU 7.2.0最小化版解压后得到qemu-system-x86_64w.exe等可执行文件。后续启动命令会直接使用该程序。获取 Fedora CoreOSFCOS镜像前往 Fedora CoreOS 官方下载页选择metal_virtualized / testing 流 / x86_64 架构下载用于 QEMU 的镜像。教程示例使用版本为37.20221127.2.0的镜像文件fedora-coreos-37.20221127.2.0-qemu.x86_64.qcow2.xz下载得到的是.xz压缩包需要xz或 7-zip 等解压工具将其解压为.qcow2镜像并放到C:\qemu-remote\下。使用xz时在镜像所在目录执行xz -d fedora-coreos-37.20221127.2.0-qemu.x86_64.qcow2.xz解压完成后C:\qemu-remote\fedora-coreos-37.20221127.2.0-qemu.x86_64.qcow2即为 QEMU 的磁盘映像。安装 Podman for Windows下载并安装最新版本的 Podman for Windows安装包随每次 Podman 发布提供可从 Podman 官方发布渠道获取。安装后的podman.exe即为 Podman-remote 客户端——它本身不运行容器而是把命令转发给远程的 Podman 服务。旧版本 Podman 的 gvproxy 补充安装仅当使用 Podman 4.3.x 及更早版本时需要执行本步这些旧版本安装目录中缺少gvproxy.exe。此时需要从 gvisor-tap-vsock 项目发布页下载0.5.0或更新版本的gvproxy-windows.exe将其复制到 Podman 安装目录或任意已加入PATH环境变量的目录并重命名为gvproxy.exe。从源码角度看gvproxy 是 Podman machine 网络栈的核心组件在 gvproxy.go 中可以看到 Podman 会读取--pid-file指定的 PID 文件并据此清理 gvproxy 进程CleanupGVProxy该函数带 2 秒重试窗口50ms 间隔用于规避 gvproxy 退出时与 PID 文件删除之间的竞态而在 WSL 用户态网络实现 usermodenet.go 中Podman 以stdio:模式通过标准输入输出直接驱动 gvproxylisten-stdioaccept。本教程则直接以命令行方式手工拉起 gvproxy这正是实验性方案与托管方案的分水岭。生成 SSH 密钥对生成一对**空口令empty passphrase**的 ed25519 密钥用于 Windows 与虚拟机之间的 SSH 连接ssh-keygen -t ed25519 -f C:\qemu-remote\remote该命令会同时生成私钥C:\qemu-remote\remote与公钥C:\qemu-remote\remote.pub。公钥内容稍后要写入 Ignition 配置。编写 FCOS 的 Ignition 配置Fedora CoreOS 是不可变系统首次启动时通过 Ignition 机制完成所有初始化。创建文件C:\qemu-remote\remote.ign内容如下这是整篇教程中信息密度最高的部分建议逐段理解后再复制使用{ignition:{config:{replace:{verification:{}}},proxy:{},security:{tls:{}},timeouts:{},version:3.2.0},passwd:{users:[{name:core,sshAuthorizedKeys:[YOURSSHKEYHERE],uid:501},{name:root,sshAuthorizedKeys:[YOURSSHKEYHERE]}]},storage:{directories:[{group:{name:core},path:/home/core/.config,user:{name:core},mode:493},{group:{name:core},path:/home/core/.config/containers,user:{name:core},mode:493},{group:{name:core},path:/home/core/.config/systemd,user:{name:core},mode:493},{group:{name:core},path:/home/core/.config/systemd/user,user:{name:core},mode:493},{group:{name:core},path:/home/core/.config/systemd/user/default.target.wants,user:{name:core},mode:493},{group:{name:root},path:/etc/containers/registries.conf.d,user:{name:root},mode:493},{group:{name:root},path:/etc/systemd/system.conf.d,user:{name:root},mode:493},{group:{name:root},path:/etc/environment.d,user:{name:root},mode:493}],files:[{group:{name:core},path:/home/core/.config/systemd/user/linger-example.service,user:{name:core},contents:{source:data:,%5BUnit%5D%0ADescriptionA%20systemd%20user%20unit%20demo%0AAfternetwork-online.target%0AWantsnetwork-online.target%20podman.socket%0A%5BService%5D%0AExecStart%2Fusr%2Fbin%2Fsleep%20infinity%0A,verification:{}},mode:484},{group:{name:core},path:/home/core/.config/containers/containers.conf,user:{name:core},contents:{source:data:,%5Bcontainers%5D%0Anetns%22bridge%22%0A,verification:{}},mode:484},{group:{name:root},overwrite:true,path:/etc/subuid,user:{name:root},contents:{source:data:,core:100000:1000000,verification:{}},mode:484},{group:{name:root},overwrite:true,path:/etc/subgid,user:{name:root},contents:{source:data:,core:100000:1000000,verification:{}},mode:484},{group:{name:root},path:/etc/systemd/system/user.service.d/delegate.conf,user:{name:root},contents:{source:data:,%5BService%5D%0ADelegatememory%20pids%20cpu%20io%0A,verification:{}},mode:420},{group:{name:core},path:/var/lib/systemd/linger/core,user:{name:core},contents:{verification:{}},mode:420},{group:{name:root},path:/etc/containers/containers.conf,user:{name:root},contents:{source:data:,%5Bengine%5D%0Amachine_enabledtrue%0A,verification:{}},mode:420},{group:{name:root},path:/etc/containers/podman-machine,user:{name:root},contents:{source:data:,qemu%0A,verification:{}},mode:420},{group:{name:root},path:/etc/containers/registries.conf.d/999-podman-machine.conf,user:{name:root},contents:{source:data:,unqualified-search-registries%5B%22docker.io%22%5D%0A,verification:{}},mode:420},{group:{},path:/etc/tmpfiles.d/podman-docker.conf,user:{},contents:{source:data:,L%20%20%2Frun%2Fdocker.sock%20%20%20-%20%20%20%20-%20%20%20%20-%20%20%20%20%20-%20%20%20%2Frun%2Fpodman%2Fpodman.sock%0A,verification:{}},mode:420},{group:{name:root},path:/etc/profile.d/docker-host.sh,user:{name:root},contents:{source:data:,export%20DOCKER_HOST%22unix:%2F%2F$%28podman%20info%20-f%20%22%7B%7B.Host.RemoteSocket.Path%7D%7D%22%29%22%0A,verification:{}},mode:420}],links:[{group:{name:core},path:/home/core/.config/systemd/user/default.target.wants/linger-example.service,user:{name:core},hard:false,target:/home/core/.config/systemd/user/linger-example.service},{group:{name:root},overwrite:true,path:/usr/local/bin/docker,user:{name:root},hard:false,target:/usr/bin/podman},{group:{name:root},overwrite:false,path:/etc/localtime,user:{name:root},hard:false,target:\\usr\\share\\zoneinfo}]},systemd:{units:[{enabled:true,name:podman.socket},{contents:[Unit]\nRequiresdev-virtio\\\\x2dports-vport1p1.device\nAfterremove-moby.service sshd.socket sshd.service\nOnFailureemergency.target\nOnFailureJobModeisolate\n[Service]\nTypeoneshot\nRemainAfterExityes\nExecStart/bin/sh -c /usr/bin/echo Ready \u003e/dev/vport1p1\n[Install]\nRequiredBydefault.target\n,enabled:true,name:ready.service},{enabled:false,mask:true,name:docker.service},{enabled:false,mask:true,name:docker.socket},{contents:[Unit]\nDescriptionRemove moby-engine\n# Run once for the machine\nAftersystemd-machine-id-commit.service\nBeforezincati.service\nConditionPathExists!/var/lib/%N.stamp\n\n[Service]\nTypeoneshot\nRemainAfterExityes\nExecStart/usr/bin/rpm-ostree override remove moby-engine\nExecStart/usr/bin/rpm-ostree ex apply-live --allow-replacement\nExecStartPost/bin/touch /var/lib/%N.stamp\n\n[Install]\nWantedBydefault.target\n,enabled:true,name:remove-moby.service},{contents:[Unit]\nDescriptionEnvironment setter from QEMU FW_CFG\n[Service]\nTypeoneshot\nRemainAfterExityes\nEnvironmentFWCFGRAW/sys/firmware/qemu_fw_cfg/by_name/opt/com.coreos/environment/raw\nEnvironmentSYSTEMD_CONF/etc/systemd/system.conf.d/default-env.conf\nEnvironmentENVD_CONF/etc/environment.d/default-env.conf\nEnvironmentPROFILE_CONF/etc/profile.d/default-env.sh\nExecStart/usr/bin/bash -c /usr/bin/test -f ${FWCFGRAW} \u0026\u0026\\\n\techo \[Manager]\\n#Got from QEMU FW_CFG\\nDefaultEnvironment$(/usr/bin/base64 -d ${FWCFGRAW} | sed -e \s| g\)\\n\ \u003e ${SYSTEMD_CONF} ||\\\n\techo \[Manager]\\n#Got nothing from QEMU FW_CFG\\n#DefaultEnvironment\\n\ \u003e ${SYSTEMD_CONF}\nExecStart/usr/bin/bash -c /usr/bin/test -f ${FWCFGRAW} \u0026\u0026 (\\\n\techo \#Got from QEMU FW_CFG\\u003e ${ENVD_CONF};\\\n\tIFS\|\;\\\n\tfor iprxy in $(/usr/bin/base64 -d ${FWCFGRAW}); do\\\n\t\techo \$iprxy\ \u003e\u003e ${ENVD_CONF}; done ) || \\\n\techo \#Got nothing from QEMU FW_CFG\\u003e ${ENVD_CONF}\nExecStart/usr/bin/bash -c /usr/bin/test -f ${FWCFGRAW} \u0026\u0026 (\\\n\techo \#Got from QEMU FW_CFG\\u003e ${PROFILE_CONF};\\\n\tIFS\|\;\\\n\tfor iprxy in $(/usr/bin/base64 -d ${FWCFGRAW}); do\\\n\t\techo \export $iprxy\ \u003e\u003e ${PROFILE_CONF}; done ) || \\\n\techo \#Got nothing from QEMU FW_CFG\\u003e ${PROFILE_CONF}\nExecStartPost/usr/bin/systemctl daemon-reload\n[Install]\nWantedBysysinit.target\n,enabled:true,name:envset-fwcfg.service}]}}关键一步将文件中的两处YOURSSHKEYHERE替换为第 3 步生成的真实公钥即C:\qemu-remote\remote.pub的完整内容。这段 JSON 是整套方案的操作系统的配置逐段理解它有助于后续排障。Ignition 版本为3.2.0contents.source使用data:URI 以 URL 编码形式内联文件内容%0A为换行、%20为空格。用户与 SSH 授权passwdcore用户被固定uid: 501并注入你的 SSH 公钥。uid 501 是贯穿全教程的关键数字稍后 gvproxy 的-forward-dest /run/user/501/podman/podman.sock指向的正是 core 用户 rootless 模式下的 Podman 服务 socketrootless Podman 的 socket 默认位于/run/user/{uid}/podman/podman.sock这也与 connection add 命令 中--socket-path的默认值说明一致root用户同样注入公钥用于后续通过sudo poweroff等提权操作。预创建目录storage.directoriesmode: 493即八进制0755的目录/home/core/.config、/home/core/.config/containers、/home/core/.config/systemd及其user、user/default.target.wants子目录为 systemd 用户级单元和 containers 配置预留位置以及/etc/containers/registries.conf.d、/etc/systemd/system.conf.d、/etc/environment.d三个系统级配置目录。关键文件逐项解析storage.files目标路径文件内容解码后作用/home/core/.config/systemd/user/linger-example.service[Unit]After/Wantsnetwork-online.target podman.socketExecStart/usr/bin/sleep infinitysystemd 用户单元示例演示依赖网络就绪与 Podman socket 的用户级服务写法mode: 484即0744/home/core/.config/containers/containers.conf[containers]netnsbridge强制容器使用 bridge 网络命名空间保证容器网络可被外部访问/etc/subuid、/etc/subgidoverwritecore:100000:1000000为用户命名空间分配 100 万个子 UID/GID 映射rootless Podman 运行容器的基石/etc/systemd/system/user.service.d/delegate.conf[Service]Delegatememory pids cpu io将 cgroup 子树的 memory/pids/cpu/io 控制器委托给用户 systemd 实例rootless 容器资源统计的前提mode: 420即0644/var/lib/systemd/linger/core空文件为 core 启用 systemd linger使无用户登录时用户级 systemd 与 Podman 服务依然运行/etc/containers/containers.conf[engine]machine_enabledtrue告知 VM 内 Podman 引擎其处于 Podman machine 管理模式/etc/containers/podman-machineqemu标记该 VM 由 QEMU provider 创建管理Podman machine 支持多 provider此文件用于识别/etc/containers/registries.conf.d/999-podman-machine.confunqualified-search-registries[docker.io]配置不带仓库前缀的镜像默认从 docker.io 拉取/etc/tmpfiles.d/podman-docker.confL /run/docker.sock ... /run/podman/podman.sock开机时创建符号链接让 Docker API 客户端能访问 Podman socketDocker 兼容/etc/profile.d/docker-host.shexport DOCKER_HOSTunix://$(podman info -f {{.Host.RemoteSocket.Path}})为登录 shell 自动设置DOCKER_HOST环境变量Docker CLI 无需任何配置即可指向 Podman符号链接storage.linksdefault.target.wants/linger-example.service→/home/core/.config/systemd/user/linger-example.service启用上述示例用户单元/usr/local/bin/docker→/usr/bin/podmanoverwrite提供docker命令兼容入口/etc/localtime→\usr\share\zoneinfo时区链接注意 Ignition 中使用反斜杠形式。systemd 单元systemd.unitspodman.socketenabled: true启用 Podman 的 socket 激活远程客户端连接的入口ready.serviceRequiresdev-virtio\x2dports-vport1p1.device启动后向/dev/vport1p1写入Ready字符串。这是虚拟串口就绪信号——对应稍后 QEMU 命令行中的-chardev socket,pathC:\qemu-remote\ready.sock,...与-device virtserialport,...,nameorg.fedoraproject.port.0参数。Windows 侧通过该信号感知 VM 启动完成docker.service / docker.socketmask: true屏蔽原生 docker 服务避免与 Podman 冲突remove-moby.service一次性单元通过rpm-ostree override remove moby-engine移除 FCOS 预装的 moby-engine并用apply-live即时生效以 stamp 文件保证只运行一次envset-fwcfg.service从 QEMU 的 FW_CFG 固件配置项opt/com.coreos/environment/raw读取 base64 编码的环境变量|分隔分别写入 systemd 管理器默认环境、/etc/environment.d与/etc/profile.d实现宿主机向虚拟机注入代理等环境配置——对应 QEMU 命令中的-fw_cfg机制。启动虚拟机gvproxy 先行QEMU 随后第一步启动 gvproxy必须先运行 gvproxy使其监听就绪后再启动 QEMU 虚拟机。在C:\qemu-remote\下执行gvproxy.exe -listen-qemu unix://C:/qemu-remote/vlan_remote.sock -pid-file C:\qemu-remote\proxy.pid -ssh-port 57561 -forward-sock C:\qemu-remote\podman.sock -forward-dest /run/user/501/podman/podman.sock -forward-user core -forward-identity C:\qemu-remote\remote各参数含义参数值作用-listen-qemuunix://C:/qemu-remote/vlan_remote.sock以 Unix socket 形式监听 QEMU 虚拟网卡的连接这是与 QEMU-netdev stream对接的端点-pid-fileC:\qemu-remote\proxy.pid记录 gvproxy 自身 PID。Podman machine 的托管流程正是通过读取这类 PID 文件实现进程清理的见 gvproxy.go 的CleanupGVProxy-ssh-port57561在回环接口上暴露 SSH 服务的端口与前置条件中约定的端口一致-forward-sockC:\qemu-remote\podman.sockWindows 本地 socket 文件用于承载 Podman API 转发-forward-dest/run/user/501/podman/podman.sockVM 内 core 用户uid 501rootless Podman 服务的 socket 路径-forward-usercore转发所用 SSH 用户名-forward-identityC:\qemu-remote\remote转发所用 SSH 私钥gvproxy 在这里扮演了双面代理向 QEMU 一侧提供虚拟网络接入点-listen-qemu向 Windows 一侧提供 SSH 端口转发57561与 Podman API socket 转发podman.sock。第二步启动 QEMU在另一个终端窗口执行示例配置为 4 核 CPU、8 GB 内存可按需调小qemu-system-x86_64w.exe -m 8192 -smp 4 -fw_cfg nameopt/com.coreos/config,fileC:\qemu-remote\remote.ign -netdev stream,idvlan,serveroff,addr.typeunix,addr.pathC:\qemu-remote\vlan_remote.sock -device virtio-net-pci,netdevvlan,mac5a:94:ef:e4:0c:ee -device virtio-serial -chardev socket,pathC:\qemu-remote\ready.sock,serveron,waitoff,idapodman-machine-default_ready -device virtserialport,chardevapodman-machine-default_ready,nameorg.fedoraproject.port.0 -pidfile C:\qemu-remote\vm.pid -machine q35,accelwhpx:tcg -cpu max,vmxoff,monitoroff -drive ifvirtio,fileC:\qemu-remote\fedora-coreos-37.20221127.2.0-qemu.x86_64.qcow2参数逐项拆解-m 8192 -smp 48 GB 内存、4 个 vCPU-fw_cfg nameopt/com.coreos/config,fileremote.ign通过固件配置通道把 Ignition 文件注入 VM。opt/com.coreos/config是 FCOS 约定的 Ignition 投递路径而opt/com.coreos/environment则对应 Ignition 中envset-fwcfg.service读取的环境变量通道-netdev stream,...,serveroff,addr.pathvlan_remote.sock把虚拟网卡接到 gvproxy 的vlan_remote.sockserveroff表示作为客户端主动连接该 socket与 gvproxy 的-listen-qemu构成一对-device virtio-net-pci,netdevvlan,mac5a:94:ef:e4:0c:eevirtio 网卡及固定 MAC-device virtio-serial-chardev socket,pathready.sock,serveron,waitoff-device virtserialport,...,nameorg.fedoraproject.port.0建立宿主机与客户机之间的虚拟串口通道。ready.sock由 QEMU 作为服务端监听serveron,waitoff表示不阻塞等待连接客户机内ready.service在启动完成后向/dev/vport1p1写入ReadyWindows 侧即可从ready.sock读到该信号从而得知 VM 初始化完成-pidfile vm.pid记录 QEMU 进程 PID-machine q35,accelwhpx:tcgQ35 芯片组优先使用 WHPX 硬件加速不可用时回退 TCG 软件模拟-cpu max,vmxoff,monitoroff最大 CPU 特性集、关闭嵌套虚拟化vmxoff避免在已虚拟化环境中嵌套冲突-drive ifvirtio,filefedora-coreos-...qcow2virtio 接口挂载 FCOS 磁盘镜像。首次启动的额外步骤观察 QEMU 加载过程等待 VM 内部完成 SSH 密钥即 Ignition 注入的公钥的配置。在首次 SSH 连接之前需要先把 VM 的主机指纹加入 known_hosts。这里特意使用127.0.0.1而非localhost以强制走 IPv4ssh-keyscan -p 57561 127.0.0.1 %USERPROFILE%\.ssh\known_hosts将连接注册到 Podman添加命名连接创建名为qemuremote的连接指向通过端口57561暴露的 SSH 端点podman system connection add --identity C:\qemu-remote\remote -p 57561 qemuremote ssh://core127.0.0.1该命令的源码位于 cmd/podman/system/connection/add.go。从实现看add函数add.goDESTINATION支持ssh://、unix://、tcp://三种 scheme未显式带 scheme 时如server.fubar.com会被自动补全为ssh://前缀-p/--port默认值 22此处显式指定为 57561--identity指定 SSH 私钥路径此外还支持--socket-path覆盖远程 socket 路径、--tls-ca/--tls-cert/--tls-keyTLS 连接仅tcp://scheme 支持、--farm把连接加入 Podman farm等选项完整选项说明可参考 podman-system-connection-add 手册页连接信息最终被写入 Podman 的connections配置文件cfg.Connection.Connections映射若--default/-d被指定还会同步更新默认连接。可选设为默认连接为简化日常操作/测试可将qemuremote设为默认连接podman system connection default qemuremote对应实现见 cmd/podman/system/connection/default.go它会校验该连接名确实已定义否则报错destination is not defined然后将cfg.Connection.Default指向该连接。同目录下还提供了连接管理的完整命令族list、remove、rename详见 cmd/podman/system/connection/可随时用podman system connection list查看当前所有连接及其默认状态。使用 Podman 运行真实工作负载在每次使用前确认当前激活的连接是qemuremote若已设为默认则无需操作。运行一个带网络的基础工作负载——nginx 容器podman run -d --rm -p 8080:80 nginx该命令由 Windows 上的 Podman-remote 客户端经 SSH 转发到 VM 内 core 用户的 Podman 服务执行镜像从 docker.io 拉取得益于 Ignition 中配置的默认搜索仓库、以 bridge 网络命名空间运行containers.conf中netnsbridge、并把容器 80 端口映射到 VM 的 8080 端口。随后在 Windows 本地验证服务可达curl http -v http://localhost:8080这条请求链路是Windows curl → 回环接口 8080 端口 → gvproxy 端口转发 → VM 内 nginx 容器。能收到 HTTP 响应即证明 gvproxy 转发、虚拟机网络与容器端口映射全链路正常。之后可以在此基础上继续练习podman ps、podman logs等常用命令它们同样通过qemuremote连接转发执行。优雅关闭虚拟机自定义 QEMU 虚拟机不适用podman machine stop这类内置管理机制该机制只对 Podman machine 托管的 VM 生效需要自行通过 SSH 优雅关机。先建立 SSH 会话ssh -i C:\qemu-remote\remote -p 57561 core127.0.0.1登录成功后在 VM 内执行sudo poweroff等待 QEMU 进程退出后可同时清理 gvproxy在 Windows 侧终止其进程。再次使用时重复先 gvproxy、后 QEMU的启动顺序即可。总结与延伸阅读本教程展示了 Podman 远程客户端架构的完整形态Windows 上只运行客户端Linux 功能完全由 QEMU 虚拟机中的 Podman 服务承载二者通过 gvproxy 建立 SSH 隧道与 API 转发。其中 Ignition 配置集中体现了 rootless Podman 在不可变系统FCOS上运行所需的全部要素——子 UID/GID 映射、cgroup 委托、linger、socket 激活与 Docker 兼容层。值得重申的是这套方案属于实验性进阶用法日常使用更推荐官方支持的 Podman for WindowsPodman machineWSLv2/Hyper-V 后端。若想深入了解 Podman 远程客户端本身的连接模型可继续阅读 remote_client.mdWindows/macOS 客户端从零搭建的完整流程见 mac_win_client.md。理解本文中 gvproxy 与 socket 转发机制后再回看 gvproxy.go 与 usermodenet.go 的源码就能对 Podman machine 的托管网络栈形成更完整的认识。赞分享容器运行时云原生CLI【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址https://gitcode.com/gh_mirrors/po/podman点击查看免费下载相关推荐快速搭建macOS虚拟机QEMU-KVM完整配置指南快速搭建macOS虚拟机QEMU KVM完整配置指南 想要在Linux或Windows系统上体验macOS系统吗OneClick macOS Simple虚拟化在 macOS 上编译 Podman 远程客户端podman-remote完整构建指南在 macOS 上编译 Podman 远程客户端podman remote完整构建指南 导读 Podman 在 macOS 上以“远程客户端remote容器运行时云原生CLI如何快速掌握Electerm功能强大的跨平台终端客户端完整实战指南如何快速掌握Electerm功能强大的跨平台终端客户端完整实战指南 Electerm是一款开源的跨平台终端客户端支持SSH、SFTP、Telnet、串口、R桌面应用开发工具网络上一篇【亲测免费】 FreeRTOS_RH850 项目使用教程下一篇Quartz sync 命令完全指南用一条命令自动化 GitHub 内容推送与拉取创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考