Proxmox VE / Basic: platform and guest foundations / Lesson 1
Platform architecture and evidence
Separate the host, guest, management plane and application when reasoning about a Proxmox VE system without operating a hypervisor.
On this page
Lesson goals
- Distinguish host resources, virtual machines and Linux containers.
- Trace management tasks separately from application requests.
- Define what an offline model can and cannot verify.
Identify the host boundary
Proxmox VE integrates virtualization management on a Linux host. QEMU/KVM virtual machines have their own guest operating-system kernels, while LXC containers share the host kernel. Storage and network services connect those guests to durable data and other systems. The host therefore carries responsibilities that are different from the application inside a guest. A healthy management page cannot prove that a guest filesystem is consistent or that an application returns correct results. Start an investigation by naming the failing boundary instead of treating the entire platform as one undifferentiated server.
Separate control and data paths
The web interface and API submit management work such as a planned guest configuration change. Background tasks report progress, while the actual guest executes through its assigned compute and device resources. Guest traffic can continue when a browser session fails, and a successful task can still leave an application unready. The first diagram describes responsibilities, not a physical topology or installation procedure. This course assumes familiar Proxmox VE 9.x concepts and synthetic x86-64 teaching hosts; exact features, device support and UI labels must be checked against the installed release.
management client -> API/task handling -> intended guest configuration
guest process -> virtual devices -> host storage/network paths
application request -> guest service -> application resultThe diagram does not imply synchronous completion or prove any running system exists.
Record identities and time
A guest identifier is meaningful with its platform context, guest type and collection time. Names are convenient labels and can be changed; they should not be the only join key in an incident record. The second example reads synthetic identities from memory. It illustrates why two independent teaching environments can use the same numeric guest ID without referring to the same workload. For a real review, also preserve the node and storage identities that matter to the symptom. An old screenshot without its timestamp cannot establish the present location or state of a guest.
a = ("training-a", "qemu", 210)
b = ("training-b", "qemu", 210)
print(a[2] == b[2])
print(a == b)True
FalseThe program compares public tuples only and never reads host or guest configuration.
Map ownership and dependencies
A workload can depend on a virtual disk, a host bridge, DNS, time synchronization and an external service. Assign an owner to each boundary before choosing a remedy. For example, a VM can be powered on while its application waits for unavailable storage; restarting the guest does not repair the storage path. Likewise, a storage snapshot does not automatically protect data held by an external service. Write the applicationโs expected behavior and data location first. That gives later backup, migration and high-availability discussions a concrete unit of responsibility.
State the learning boundary
All GUI records, configuration fragments and operational plans here are unexecuted illustrations. No Proxmox host, virtual machine, container, cluster, storage endpoint or credential is accessed. Complete Python programs run only as harmless calculations with synthetic in-memory values. This still supports useful learning: a reader can test identity comparisons, capacity arithmetic and decision logic without claiming a deployed result. A future authorized environment exercise needs its own release-specific procedures and recovery controls. Local editorial validation establishes JSON structure and example results, not hypervisor compatibility, isolation, availability or application correctness.
Common errors and fixes
A working GUI is reported as a healthy application
- Why it happens
- Management-plane evidence replaced guest and application checks.
- How to fix it
- Trace the user request and its storage/network dependencies separately.
- Prevent it next time
- Define health claims per boundary and timestamp them.
Two records are joined only by guest ID
- Why it happens
- Environment and guest-type context were discarded.
- How to fix it
- Use a composite identity and preserve node/location evidence.
- Prevent it next time
- Keep contextual identifiers in inventory exports.
A restart is proposed for every dependency failure
- Why it happens
- The failing layer was never identified.
- How to fix it
- Identify the owner and evidence of the failing dependency before choosing action.
- Prevent it next time
- Draw a workload dependency map before recovery planning.
Check your understanding
1. The task says completed but the application returns errors. What has been established?
Show worked solution
Only the reported management task outcome is established within its scope. Guest startup, device access, configuration, dependencies and application semantics remain separate questions. Preserve the task identity and time, then follow the user-facing failure to the responsible boundary instead of broadening the task status into a platform-wide health claim.
2. Why is training-a/qemu/210 different from training-b/qemu/210?
Show worked solution
The numeric ID is reused in independent contexts. The composite identities identify different objects even though one component matches. A reliable incident comparison must retain environment, type and time, and should add the relevant node and storage references when diagnosing placement or disk problems.
Key takeaways
- Management status, guest state and correct application behavior require distinct evidence.
- Context and ownership make virtualization diagnosis precise.