What the QEMU Guest Agent is, and why your VM shows no IP

Looking at a virtual machine in the Proxmox panel and finding the IP field empty is a common moment. A missing or disconnected QEMU Guest Agent is the first thing to check, although an agent can also omit addresses that the guest itself does not report.

What the channel looks like

The guest agent is a channel between the hypervisor and the inside of the machine. It does not talk over the network but over a virtual serial port. That distinction matters: the channel stays up even when the machine's networking is broken, and no network port is opened for it.

What is lost without it

With no agent, Proxmox cannot ask the guest for its interfaces, operating-system details or filesystem state. Agent-assisted shutdown and filesystem freeze/thaw are unavailable too. This does not mean every graceful shutdown becomes a hard power-off: a guest may still respond to the emulated ACPI power button. The missing part is the explicit guest-agent path and the confirmation it can provide.

Install both halves

First enable the device on the Proxmox host:

qm set <VMID> --agent 1
qm config <VMID> | grep '^agent:'

If the agent device was just added, fully stop and start the VM once so the guest sees the new virtual port. A reboot inside the guest is not always enough for a newly added device.

Then install and start the service inside the guest. On Debian or Ubuntu:

apt update
apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

On RHEL, Rocky Linux or AlmaLinux:

dnf install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Package installation alone is not the success condition. Check the service in the guest and the channel from the host:

# inside the guest
systemctl is-active qemu-guest-agent

# on the Proxmox host
qm agent <VMID> ping
qm agent <VMID> get-osinfo

You want active inside and a response to both host commands. If the service is active but the host times out, check that /dev/virtio-ports/org.qemu.guest_agent.0 exists in the guest and inspect journalctl -u qemu-guest-agent. That separates a missing virtual port from a service failure.

Is it a new attack surface

It does not open a network port, but it is still a privileged host-to-guest control channel and should not be described as risk-free. Anyone with sufficient Proxmox host or API rights already has powerful control over the VM; the agent makes some of that control orderly and scriptable. Keep host and API access narrow, keep the package updated, and enable it because you need its capabilities rather than because an empty IP field looks untidy.