Proxmox qm CLI VM Build, Part 3: Jumping Between pve and the VM

Two VMs exist at this point in the series: 103, built from the netinst ISO in Part 1, and 104, built from a cloud image in Part 2. Three ways exist to reach either of them from pve: qm terminal over a serial console, noVNC through the web GUI, and SSH once the network’s up. This post tests all three against both VMs and finds a genuine quirk in how two of them interact.

qm terminal needs a serial device that isn’t always there

VM 103 never got a --serial0 device. Part 1 built it against plain VGA, the only display an interactive netinst installer ever talks to:

$ sudo qm terminal 103
unable to find a serial interface

Clean, immediate, no ambiguity. Nothing to attach to.

VM 104 got --serial0 socket --vga serial0 in Part 2, specifically because cloud images ship expecting a serial console by default:

$ sudo qm terminal 104
starting serial terminal on interface serial0 (press Ctrl+O to exit)
debian13-cloudinit login:

A real login prompt, no noVNC involved at all. Except there’s nothing to type at it. The cloud-init config in Part 2 was deliberately key-only, --sshkeys with no --cipassword, which is the sensible default for a VM meant to be reached over SSH. A console login prompt needs a local password (or another PAM-backed mechanism), and public key auth doesn’t apply outside SSH. The prompt is real and reachable; there’s just nothing that can log into it as configured. Worth keeping as an observed limitation rather than “fixing” by adding a password purely for the demo, since key-only is the actual right call for this VM.

noVNC and qm terminal turn out to share one channel, not two

Checking VM 104’s console over noVNC while qm terminal was still attached surfaced something not obvious from the documentation alone: the GUI console showed a blank screen. Pressing Enter a few times did nothing visible. Only after detaching the qm terminal session with Ctrl+O did those queued Enter presses suddenly land in the GUI session.

The reason is the --vga serial0 flag from Part 2. It doesn’t add a second display alongside the serial console, it redirects the VM’s display output to be the serial console. There’s one underlying stream, and both qm terminal and noVNC are just two different clients attaching to it. With qm terminal already holding that connection, the GUI’s own input had nowhere to go until the competing client let go. This isn’t a bug in either tool, it’s a direct consequence of a VM built with no separate framebuffer at all.

Contrast with VM 103, which never redirected its display anywhere. Its noVNC console is a normal VGA framebuffer, entirely independent of any serial device, because none exists. No contention is possible there since there’s nothing to contend over.

Practical takeaway: don’t run qm terminal and noVNC against the same --vga serial0 VM at the same time. Pick one.

SSH is the one method unaffected by any of this

SSH doesn’t touch the QEMU chardev layer at all, it’s a completely separate path over the guest’s own network stack. Both VMs took it cleanly in Parts 1 and 2, and neither the serial-vs-VGA distinction nor the noVNC/qm terminal contention has any bearing on it. For VM 104 specifically, given the console login prompt is unusable by design, SSH isn’t just the most convenient method, it’s the only one that actually gets you in.

Which method for which VM

	VM 103 (ISO)	VM 104 (cloud-init)
qm terminal	No serial device, fails immediately	Reaches a real prompt, but nothing to log in with as configured
noVNC	Independent VGA framebuffer, works standalone	Same stream as qm terminal, don’t run both at once
SSH	Works, needs the VM’s IP found manually	Works, the only usable login path on this VM

Part 4 puts VM 103 to actual use: standing up a DNS resolver on it, the real workload this whole build has been heading toward.