Why the xterm.js console is greyed out, and which console you actually want

You open the console menu on a virtual machine, and one of the entries is greyed out. Nothing explains why. On the machine next to it, the same entry works.

This is not a fault. Proxmox VE offers several different doors into a running guest, they are not interchangeable, and one of them has prerequisites that are easy to miss because nothing announces them.

The doors, and what each one actually is

The graphical console. This is the one that always works for a virtual machine. It draws the guest's emulated screen in your browser, exactly as a monitor plugged into a physical machine would show it. It needs nothing configured because the emulated graphics card is always there.

SPICE. A richer remote display protocol, useful when you want better performance for a desktop guest, sound, or local device redirection. It needs a client application on your own computer and an appropriate display type on the guest, so it is a deliberate choice rather than a default.

The serial terminal. A plain text console, no graphics involved. This is the one that greys out.

The container console. Containers do not emulate hardware at all, so their console is a different mechanism entirely. That is why "console not working" for a container and for a virtual machine are two different problems with two different answers.

Why the text console is unavailable

It needs a serial port, and virtual machines do not have one unless somebody adds it. No serial port, no serial console, and the menu entry is simply dimmed.

On the host used to check this, four of eight virtual machines had no serial port at all. On those four the entry is greyed out permanently, and nothing on the screen says the word "serial".

The half that people add and still get a black screen

Adding the port to the virtual machine is the host side. There is a second side, and skipping it produces the most confusing outcome of all: the console opens, connects, and shows nothing.

The guest also has to be talking on that wire. On a modern Linux guest that means a login service attached to the serial device; on older init systems it is configured differently. Optionally the bootloader can be told to send boot messages there too, which is the whole point for the cases below.

A blank serial console usually does not mean broken. It means nobody inside is speaking on that port.

Why go to the trouble at all

The graphical console is easier, so the honest question is why anyone bothers. The reasons are specific, and each one is a moment where the graphical console lets you down.

Kernel panics and boot messages. When a guest fails before it finishes booting, the interesting text scrolls past a screen you cannot scroll back on. A serial console gives you the text as text.

Copy and paste that behaves like a terminal. Because it is text, not a picture of text.

A broken keyboard layout. When the graphical console maps your keys wrongly, a text console usually still works.

Lost network access. Both consoles survive this, but the text one stays usable when the guest is too unwell to draw a screen.

Which one to reach for

For a routine look at a running machine, take the graphical console; it is always there and needs nothing.

For a guest you expect to have to rescue, set up the serial console before you need it. Doing it during an incident means editing a configuration you cannot reach, on a machine you cannot log into. That order is the whole lesson.

For a desktop workload where the experience matters, SPICE is worth the client install.

For a container, use its own console and treat its troubleshooting as a separate subject.

What Atlas does

Atlas does not build a fifth console. When you open a guest's console from Atlas, it hands you to Proxmox VE's own graphical console, deliberately, because reimplementing that would mean a second thing to trust and a second thing to break.

Where Atlas helps is earlier: the tasks that normally send you to a console at all. A large share of console visits are not debugging sessions, they are one configuration change that had no screen. Those live in the interface instead.

The console is for the day something is genuinely wrong. The goal is that ordinary Tuesdays do not require one.