Proxmox VE Fundamentals

First, you place the components of Proxmox VE in their technical context: host, QEMU/KVM, LXC, storage, Linux bridges, and management access. You then apply these relationships to the prepared lab environment and develop a justified single-host plan. The exercise shows which decisions belong together before installation and which dependencies will affect later operations.

A Proxmox installation establishes management access, host identity, and local storage. You discuss the information required by the installer and how the disk and addressing plans affect each other. Working in the prepared lab environment, you install the host, sign in through the web interface and shell, and compare the result with your host plan.

After the first login, the baseline state determines whether VMs and containers can run reliably. You map DNS, time synchronisation, package sources, update state, KVM support, Proxmox services, and storage targets to their operational roles. In a guided exercise, you compare the interface and shell, investigate discrepancies, and derive the required corrections.

A QEMU/KVM VM encapsulates a complete guest operating system. Firmware, virtual devices, and the Guest Agent determine how well it fits the intended operation. You compare the available options, use them to create a small Linux guest, and configure the Guest Agent. During the functional test, you observe the effects on networking, resource reporting, and controlled shutdown.

LXC system containers share the host kernel and therefore have different isolation and operational boundaries from VMs. You classify common use cases and the implications of unprivileged containers before creating one with defined CPU and memory limits. Using a prepared service, you compare startup, resource use, and the security boundary with the VM created earlier.

A Proxmox storage target suits different tasks depending on its content types and supported operations; free capacity is only one criterion. You distinguish file storage from thin block storage and relate both to images, VM disks, containers, and backups. You apply this distinction to the available targets through the interface and pvesm, then justify where each content type belongs.

During an offline import, the source image and target configuration must be compatible: firmware, storage, boot order, and virtual hardware affect whether the guest starts. You first map these dependencies for a prepared Linux guest. With that model in place, you import the powered-off image, start the VM, and verify how the target configuration affects service reachability without repairing an unknown source system.

A Linux bridge acts as a software switch between the host, physical uplinks, and virtual guests. You first trace a packet through vmbr0 and distinguish the management network from an isolated guest segment. You put the model into practice by creating a lab bridge, attaching a VM and LXC container, and explaining the observed connectivity and management-access risks.

VLANs separate broadcast domains reliably only when bridge VLAN awareness, tag assignment on the virtual guest interface, and the uplink where applicable are configured consistently. You determine where a VLAN tag is added, forwarded, or removed. In the lab, you connect the VM and container to prepared segments, introduce an incorrect assignment, and use reachability plus configuration to derive the cause and correction.

The Proxmox permission model combines realms, users, groups, roles, ACL paths, and inheritance. You place these layers in context and derive the minimum permissions for one clearly bounded VM task. To implement the delegation, you create a user and group in the local PVE realm and compare an allowed VM action with a denied storage action.

The Proxmox firewall operates at several levels. Scope, enable flags, and rule order jointly determine its effect. Before changing rules, you place host, guest, and interface protection in context and define a recovery path. Using a prepared service, you apply the model by allowing one connection, rejecting another, and explaining the observation through the configuration and log entry.

When connectivity is lost, diagnosis must distinguish the network path, the service, and the firewall effect. You develop an ordered diagnostic approach and apply it to a prepared misconfiguration. Through the console, you trace the cause, restore the intended state, and record which observation led to the correct hypothesis.

For a backup, consistency requirements, mode, and destination must fit the workload. You compare the available modes for VMs and containers and select a justified option for a prepared guest. Using the selected mode, you run the backup to separate storage and use the job log and artifact to determine which data and configuration were actually captured.

A restore reveals whether backup data can support recovery. You first consider why a new guest ID, a known test value, and separation from the source guest make the recovery exercise meaningful. For the exercise, you modify the original guest, restore the backup, and compare the configuration, startup behaviour, and service data of both instances.

Systematic troubleshooting links observation, hypothesis, and a targeted change instead of altering several settings at once. Starting from a prepared storage or network fault, you follow tasks and status in the interface, correlate pvesm, qm, or pct with service and system logs, and test a justified correction. The resulting diagnostic path provides a method for further guest failures.