Virtual machines¶

A virtual machine is a first-class object next to devices: it carries its own interfaces, IP addresses, disks and services, so monitoring, IPAM, config context and change history all work the same way they do for physical hardware - a virtual router is checked and SNMP-polled exactly like a switch.

Every VM can be created by hand. If you run Proxmox VE or VMware vCenter, a sync can import them instead.

Fields¶

Field	Notes
Name, status	As for a device - the same status catalog.
Power	Read-only, from the hypervisor - see Power state.
Role, platform	Also the device catalogs, so one role can span physical and virtual.
Cluster	The cluster it runs on.
Group	Its VM group - a vApp, resource pool, folder or one of your own - on the same cluster. Optional.
Host device	The physical host inside that cluster - see Placement.
Site	Its own location, independent of the cluster's - see Placement.
vCPUs, Memory, Disk	Resource sizing. Memory is entered in MB, disk in GB.
Primary IP	The address the VM is reached on; monitoring uses it.
Description, tags, custom fields	Free-form notes, labels and your own attributes.

The detail page¶

Overview carries the attribute cards, the disk list and the VM's Topology card - its networks as rails, the same drawing as the Virtual topology. With none mapped, the card says No virtual networks yet. and what to do: run a sync, turn on Sync virtual switches & networks on its source, or give one of its interfaces a VLAN. Then:

Tab	What's on it
Components	The VM's interfaces (and their IPs), with a count on the tab.
Services	Services running on it, from your service templates.
Routing	Static routes and BGP, OSPF, IS-IS and EIGRP instances on the VM - a virtual router's routing, the same as a device's. See Routing on virtual machines.
Monitoring	Checks against its addresses, same engine as devices.
SNMP	Facts, the interface table, LLDP neighbours and the ARP table, when the VM answers SNMP. Each SNMP interface is read against the VM's own NICs by name; when the guest names a NIC differently from the hypervisor (`ether1` for `nic0`), set SNMP name on the interface and the row maps.
Certificates	TLS certificates seen on its endpoints.
Config	The rendered config context for this VM, and the Oxidized backup of a virtual router when that is on.
Journal, Change log	Notes you write, and the automatic change record.

Power state¶

For a VM a sync tracks, Danbyte shows the hypervisor's reported power state - Powered on, Powered off or Suspended - on the VM's hero, in its Overview with the time the reading was taken, and as a filterable Power column in VM tables.

It is deliberately separate from Status, and the distinction matters:

Status is yours. It's the lifecycle - staged, active, decommissioning - and nothing overwrites it.
Power is the hypervisor's. It changes whenever someone shuts a machine down.

A VM is routinely Active and powered off at the same time; collapsing the two would make a nightly-shutdown dev box look decommissioned. A VM no sync tracks shows no power state at all, rather than an unknown-looking dash.

Placement: site and host device¶

Two different questions, two different fields:

Site - where in the world. This is the VM's own field: a cluster in your datacentre can host VMs whose site is a branch office, which is usually what you want to record, so a cluster's site is not inherited by default. When the two really are the same place, tick Give VMs on this cluster its site on the cluster and it is filled in for VMs that have none. A synced VM can also get its site from placement, which reads the hypervisor's own datacenter/folder/cluster structure. Either way, a site's page lists the VMs placed there.
Host device - which physical machine. Model the ESXi host or Proxmox node as a Device, then pick it as the VM's Host device. The device's own page lists the VMs it hosts.

Host devices link themselves during a sync

A sync sets Host device automatically whenever a Device exists whose name matches the host the hypervisor reports.

You can create those hosts yourself, or tick Create hosts as devices on the source and let the sync add each hypervisor node as a Device - name, cluster, status and, when placement resolves one, a site. A Hypervisor role is created on demand. It still leaves device type empty: nothing the hypervisor reports says what the hardware is. A host you already model is matched case-insensitively and adopted, never duplicated or restyled.

Interfaces and IP addresses¶

A VM interface mirrors a device interface: name, enabled flag, MAC address, MTU, speed, and an 802.1Q VLAN with an access/trunk mode. Add them from the VM's Components tab. A Type distinguishes what it is: a regular Virtual NIC (the default), or a Tunnel (WireGuard, GRE, VXLAN, tun), Bridge, or Loopback - tunnels and loopbacks carry no MAC or speed, so the form drops those fields for them. Interfaces can also nest: pick a Parent interface (same VM, loops refused) and wg0 rides under eth0 - the table indents children beneath their parent.

IP addresses attach to an interface exactly as on a device. From the VM's Components tab:

the + on an interface row opens the IP form with that VM and interface already filled in - use it to record a new address;
Assign IP attaches an existing address to the VM instead.

You can also set it from the address itself: the IP form has Virtual machine and VM interface pickers next to the device ones. Assigning to the VM without naming an interface is allowed when you only care that the address belongs to that VM.

A VM interface's ip_addresses lists only the addresses the caller may view, as on a device interface: IP view permission in the active tenant, with its site scope and row constraints.

The first private IPv4 becomes the VM's primary IP when it has none, and that is what monitoring checks. To choose a different one, tick Make this the VM's primary IP on the address's own form, or set Primary IP on the VM. Unticking the box clears it again.

A synced IP needs its prefix to exist first

When a hypervisor reports a guest address, Danbyte records it only if a prefix containing it already exists - the sync never invents address space, because nothing in the guest data says what the subnet is. Create the prefix, sync again, and the address attaches to its interface.

Which VRF it looks in is the source's Address VRF, overridden per NIC by a VRF you set on the VM interface - sync reads that field and never writes it. See where synced addresses land.

The sync result says how many addresses it couldn't place, so a missing prefix shows up as "2 addresses unplaced" rather than as addresses that quietly never appear.

Guest addresses also depend on the in-guest agent (VMware Tools or the QEMU guest agent) and only appear for running VMs.

Disks¶

Virtual disks are listed on the VM's Overview: name, size, the storage pool or datastore they live on, and their controller. They're descriptive - the VM's own Disk figure is its own field, not a total of these. A sync imports them when Sync disks is enabled on the source.

What a sync owns, and what you own¶

For a VM that came from a hypervisor:

The hypervisor owns its existence, its host, its power state, and - in Automatic mode - its specs (vCPU / RAM / disk).
You own everything else: role, platform, site, tags, custom fields, description and the primary-IP choice. A sync never overwrites those, in any mode.

VMs, interfaces and IPs you created are linked and blank-filled, never overwritten, and never deleted by a sync.