Is the topology drawn automatically?

Yes. The agent reads the host and the map is generated from live state. It updates as the host changes; nothing is drawn or maintained by hand.

Does it show which VM is on which network?

Yes. Each guest NIC is drawn to its bridge and each bridge to its bond or physical NIC, with VLAN tags visible on the path.

Does it cover storage too?

Yes. The storage flow map connects disks, pools and datasets to the guests using them, including redundancy state and degraded pools.

Does it work with clusters?

Yes. Multi node setups appear on the same map: each node carries its own guests, and shared storage is drawn across the nodes that use it.

Is this a monitoring dashboard?

No. The map is a management surface, not a metrics wall. Watch adds health findings onto it, but the point is relationships and impact, not graphs.

Does the map leave my infrastructure?

No. Atlas runs on the host and the topology is drawn locally. Machine and storage names, addresses and the details of the layout are not sent anywhere. When the optional usage statistics setting is switched on, only aggregate information such as count ranges and storage types goes out; the full content is listed on the Privacy screen inside the product.

Proxmox topology: the whole host as one map

Proxmox holds the pieces: VMs, containers, bridges, bonds, disks, pools. What it does not show is how they connect. Atlas draws the host as a live map, so the chain from a physical NIC to a bridge to a VM, or from a disk to a pool to a workload, is readable on one screen.

Why a topology view matters

On a stock Proxmox host, relationships live in separate screens and config files. Which guests share vmbr0, which disks carry the pool a container writes to, which bond a VLAN rides on: each answer means another tab or another shell command.

Most breakage on a host is relationship breakage. A bridge edit that drops guests offline, a disk that degrades a pool feeding three VMs, a firewall rule on the wrong interface. The pieces were fine; the connection was the problem.

A map is not decoration. When topology is visible, impact becomes visible with it: what a change touches can be read from the map before it is applied.

Mapping a host by hand

Without a live map, topology gets rebuilt manually. The usual pass looks like this:

List bridges and bonds from the network config and note which physical NICs feed them.

Match each VM and container NIC to its bridge with qm config and pct config, guest by guest.

Map disks to pools with zpool status or LVM tools, then match storages to the guests using them.

Note VLAN tags per bridge and per guest to see which segments overlap.

Draw the result on a whiteboard or in a diagram tool so the team can see it.

Repeat the whole pass after every change, because the drawing goes stale the moment something moves.

How Atlas draws the host

Atlas reads the host and keeps the map alive. Nothing is drawn by hand and nothing goes stale.

Live infrastructure map

Hosts, VMs and containers appear as a living topology. Start, stop and migrate show up on the map as they happen.

Network chain, end to end

The path from physical NIC to bond to bridge to guest is drawn as one line. VLANs and their members are readable without opening a config file.

Storage relationships

Disks, pools and datasets connect to the guests living on them. A degraded pool shows exactly which workloads it carries.

Impact before changes

Critical flows show affected resources before anything is applied. What a bridge edit or a pool operation touches is visible on the map first.

Access topology

Users, groups, roles and API tokens are drawn against the resources they reach, mirroring Proxmox permissions.

Watch on the map

The built-in Watch sentinel plots its findings on a mini topology, so an alert points at the exact node it concerns.

Frequently asked

Is the topology drawn automatically?: Yes. The agent reads the host and the map is generated from live state. It updates as the host changes; nothing is drawn or maintained by hand.
Does it show which VM is on which network?: Yes. Each guest NIC is drawn to its bridge and each bridge to its bond or physical NIC, with VLAN tags visible on the path.
Does it cover storage too?: Yes. The storage flow map connects disks, pools and datasets to the guests using them, including redundancy state and degraded pools.
Does it work with clusters?: Yes. Multi node setups appear on the same map: each node carries its own guests, and shared storage is drawn across the nodes that use it.
Is this a monitoring dashboard?: No. The map is a management surface, not a metrics wall. Watch adds health findings onto it, but the point is relationships and impact, not graphs.
Does the map leave my infrastructure?: No. Atlas runs on the host and the topology is drawn locally. Machine and storage names, addresses and the details of the layout are not sent anywhere. When the optional usage statistics setting is switched on, only aggregate information such as count ranges and storage types goes out; the full content is listed on the Privacy screen inside the product.

Related entries

Understanding a server you inherited: read before you change A Proxmox you did not build has landed in your lap and you are responsible for it now. The first instinct is to change something in order to understand it, and that is exactly the thing not to do first.
The server's name: choose it at install time, then leave it alone The name is not a label, it is an address. Configuration lives in a folder named after it, graph files are named after it, and cluster members are known by it.
Configuration went read-only: why the place it lives is different If you cannot write even as root, the disk is not full. Proxmox does not keep configuration in a normal directory, and that place refuses writes on purpose.
How to read the network map: where does a machine’s traffic go There is a question a list view answers badly: where exactly does this machine’s traffic pass. It can be answered, but only by assembling the chain in your head every time.