Management Hypervisor #

Purpose #

The management hypervisor hosts infrastructure-critical services for the substrate. This is Proxmox Node 1 in the two-hypervisor architecture, dedicated to management-plane workloads that must remain stable and available to support recovery operations.

Hardware Platforms #

Operating System #

Both management hypervisors run Proxmox VE.

Automation Capability #

• Installation: Unattended ISO install from deevnet-image-factory (embedded answer file, install disk pinned by serial), then two bootstrap scripts rendered from inventory
• Post-install: Ansible: deevnet.builder (proxmox_node_base, proxmox_node_storage) and deevnet.net (proxmox_node_network, bridge only on this node)
• VM provisioning: Ansible-only (no Terraform for management plane)
• Templates: Packer-built Fedora templates stored locally

Proxmox is treated as an API surface for management workloads, not a declarative state engine.

Roles #

The management hypervisor hosts these workload categories:

Note: Core network services (DNS, DHCP, NAT) run on the Core Router, not as VMs on the management hypervisor.

This is about resolution, and it is unchanged. The core router remains the resolver every substrate client asks, and remains authoritative for substrate names.

It is not a rule against authority. Per ADR-0004, tenant DNS zones are served by a PowerDNS Authoritative instance on the management hypervisor and delegated to from the core router’s Unbound. That is an extended management service, not a core network service — a class that did not exist when the rule above was written. Losing it costs tenant name resolution and nothing else.

VM Templates #

Templates are built using Packer and stored locally on each hypervisor. New VMs clone from templates for rapid, consistent deployment.

Deterministic MAC Addressing #

For management-plane VMs, network identity must be stable and reproducible.

Policy #

• Proxmox does not generate deterministic MAC addresses automatically
• All management-plane VMs explicitly define MAC addresses
• A MAC is derived from the VM’s Proxmox VMID inside the locally administered 02:de:<site octet> namespace, then written into version-controlled inventory
• DHCP and DNS rely on these fixed MACs

“Generated outside Proxmox” is not by itself enough — any hand-typed value satisfies it, including one copied off a running guest that carries Proxmox’s own vendor OUI. The rule is that the value is derived, and the derivation is a pure function of a declared VMID. See the MAC Namespace Specification for the encoding and its rationale.

Because the VMID is the sole source of the MAC, changing a VMID is a renumbering: the MAC, the DHCP reservation and the address move together.

Since this node is not clustered (below), VMID uniqueness across the substrate is not something Proxmox can enforce. It is enforced by the allocator in Allocate VM Identity, which surveys every hypervisor before issuing one.

This enables:

• Stable DHCP reservations
• Predictable IP addressing
• Safe VM rebuilds without network reconfiguration
• Clear mapping between hostnames, MACs, and VMIDs

Non-Clustered Design #

The management hypervisor operates independently without Proxmox clustering:

Rationale #

For a two-node lab environment:

• Clustering adds complexity without meaningful HA
• Two-node clusters introduce quorum challenges
• Local storage is simpler and faster
• Manual VM placement is acceptable at this scale

Provisioning Workflow #

1. Unattended install from the image factory’s ISO
2. Bootstrap: the node’s netconfig script at the console, then its configure script
3. Ansible post-config: node baseline, data-disk storage, API token (manual), VLAN-aware bridge
4. Template build: Packer, straight onto the node
5. VM creation: identity allocated, then cloned from the template via Ansible

The full procedure is Build Management Plane.

Management VMs are created using Ansible only — simplicity and recoverability are prioritized over drift detection.

Network Position #

graph LR
    A[Core Router] <--> B[Management Hypervisor
Proxmox Node 1] <--> C[Management VMs
observability, automation]

Guest VMs receive network configuration from Core Router DHCP, using static mappings for known management-plane hosts.

Separation from Tenant Compute #

The management hypervisor is intentionally separate from tenant workloads:

This separation reduces blast radius and ensures that tenant experimentation cannot impact platform stability.