Vex is a lightweight host-to-guest VM communication tool over vsock. It provides a CLI ( vex ), an HTTP daemon ( vexd ), a golang embedable HTTP client ( api/client) and a cross-platform guest agent ( vex-agent ) for reliable command execution inside VMs
Why Vex?
We need to run end-to-end automation tests against ephemeral VMs spawned from Proxmox templates: installing software, running commands, and verifying integrations across different operating systems. QEMU Guest Agent worked initially, but as we scaled up (more VMs, more concurrent commands) we kept hitting timeout errors that no amount of tuning could fix.
Research led us to vsock as a faster, more stable transport. However, qemu-ga doesn't support binding to vsock on Windows guests, which was a dealbreaker for our multi-OS test matrix. Rather than maintaining a fork of qemu-ga or relying on another opaque tool where failures are hard to diagnose, we built Vex: a minimal, purpose-built tool that does one thing well: reliable host↔guest communication over vsock.
The HTTP daemon ( vexd ) exists so our test orchestrator can run on a separate machine and drive everything through a simple REST API.
Install or update vex , vexd , and the systemd service in one command:
curl -sSfL https://github.com/ghraw/JimberSoftware/vex/main/scripts/install.sh | sudo bashPin a specific version:
curl -sSfL https://github.com/ghraw/JimberSoftware/vex/main/scripts/install.sh | sudo bash -s -- -v v1.2.3Download binaries directly from the GitHub Releases page.
# vex CLI client
curl -fsSL https://github.com/JimberSoftware/vex/releases/latest/download/vex_linux_amd64.tar.gz | tar xz
sudo mv vex /usr/local/bin/
# vexd HTTP daemon
curl -fsSL https://github.com/JimberSoftware/vex/releases/latest/download/vexd_linux_amd64.tar.gz | tar xz
sudo mv vexd /usr/local/bin/
# vex-agent (Linux guest)
curl -fsSL https://github.com/JimberSoftware/vex/releases/latest/download/vex-agent_linux_amd64.tar.gz | tar xz
sudo mv vex-agent /usr/local/bin/Download the appropriate archive for your architecture:
- amd64:
vex-agent_windows_amd64.zip - arm64:
vex-agent_windows_arm64.zip
Extract and place vex-agent.exe somewhere on your PATH .
vex --version
vex-agent --version
vexd --versionProxmox VMs need a vsock device before vex can communicate with the guest agent.
- Stop the VM (or template).
- SSH into the Proxmox node and edit the VM config:
nano /etc/pve/qemu-server/<VMID>.conf- Add the following line:
args: -device vhost-vsock-pci,guest-cid=<CID>
Replace <CID> with a unique number ≥ 3 for each VM (e.g. use VMID ).
- Start the VM.
If the VM already has an args: line, append the vsock device to it:
args: <existing args> -device vhost-vsock-pci,guest-cid=<CID>
VMs cloned from a template inherit the vsock device, but each clone must have a unique CID so make sure to update the args: line for each clone.
Guest-side agent that listens for incoming vsock connections.
go build ./cmd/vex-agent/vex-agent [--cid <uint32>] [--port <uint32>]| Flag | Default | Description |
|---|---|---|
--port |
1024 |
vsock port to listen on |
--cid |
4294967295 |
Context ID to bind ( 4294967295 = VMADDR_CID_ANY , binds all CIDs) |
sudo modprobe vsock_loopback
vex-agent --cid 1 --port 1024In a second terminal:
socat - VSOCK-CONNECT:1:1024Shut down with Ctrl+C .
