Proxmox VE / Basic: platform and guest foundations / Lesson 6

Virtual hardware and guest lifecycle

Review CPU, firmware, device and boot assumptions while distinguishing guest-aware shutdown from abrupt power removal.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain virtual CPU and device compatibility choices.
Separate configured resources from guest driver readiness.
Model startup ordering and guest-aware lifecycle evidence.

Treat virtual hardware as a contract

A VM configuration defines virtual CPU features, memory, firmware, controllers, disks and network adapters. The guest operating system needs compatible drivers and a boot layout that matches those choices. Changing a controller can make a previously bootable disk inaccessible even though the disk bytes remain intact. Likewise, UEFI and legacy firmware have different boot expectations. Review the guest’s installed configuration before altering virtual hardware. A convenient creation wizard selects defaults, but those defaults are not proof that an imported guest or specialized application supports the resulting devices.

Balance CPU compatibility and features

A CPU model controls which features the guest sees. Exposing host-specific features can suit one machine while restricting migration to another with a different feature set. A common baseline can support portability at the cost of omitting some capabilities. Do not select a model solely because its name sounds fastest. The first record captures a design tradeoff without setting a CPU model. Include software licensing, guest compatibility and destination hosts in the review, and remember that vCPU count is scheduling demand rather than a guarantee of dedicated physical cores.

text Unexecuted CPU compatibility review

guest requirement: documented instruction-set baseline
source and destination: compare supported CPU features
review tradeoff: portability versus host-specific features
separate checks: guest drivers, firmware, application licensing

This is an architectural record and contains no qm command or real host feature output.

Understand devices and guest-agent scope

Paravirtual devices can reduce emulation overhead when supported drivers are installed, but selecting a device does not install its driver inside the guest. The QEMU Guest Agent is another explicit integration: its service must run in the guest and its channel must be enabled appropriately. It can provide useful guest-aware operations and information, yet it is not a complete application health monitor. A reported address can be stale or unrelated to the client path. Treat host-side settings, guest software and observed behavior as three pieces of evidence instead of one enabled checkbox.

Separate startup order from readiness

Startup ordering and delays can sequence guest starts, but a delay does not prove that a database or application is ready. Shutdown ordering often reverses startup dependencies, yet applications still need graceful handling of requests and durable writes. The second program sorts a synthetic list by desired startup order. It does not start processes or model Proxmox’s complete scheduler. Use the result to ask which dependency checks belong inside application startup, and what should happen when one component never becomes ready instead of relying on a fixed sleep as a correctness mechanism.

python Synthetic startup dependency order

guests = [(30, "frontend"), (10, "data"), (20, "api")]
for order, name in sorted(guests):
    print(name)

Expected output

data
api
frontend

The output is ordering only. It does not establish that data is ready before api or that any guest exists.

Define graceful and abrupt outcomes

A guest-aware shutdown asks the operating system to stop cleanly; an abrupt stop resembles power removal and can interrupt writes. The correct choice depends on the incident and application recovery design, not impatience with a progress indicator. Preserve task and guest evidence before deciding. This course performs no lifecycle operation and tests no driver, firmware or agent. Its ordering calculation verifies a small sort only. A later authorized procedure must include expected guest behavior, time bounds, data-consistency requirements and recovery evidence rather than treating a power-state transition as application success.

Common errors and fixes

A new disk controller prevents guest boot

Why it happens: The required guest driver and boot layout were not checked.
How to fix it: Review compatible virtual hardware and the guest’s installed boot contract.
Prevent it next time: Record devices and firmware before importing or changing a guest.

A host CPU model is assumed portable everywhere

Why it happens: Destination feature differences were ignored.
How to fix it: Assess source and destination feature compatibility before migration planning.
Prevent it next time: Choose a documented CPU baseline for the intended mobility contract.

Startup delay is treated as application readiness

Why it happens: Elapsed time replaced an actual dependency condition.
How to fix it: Define application-aware readiness and bounded failure behavior.
Prevent it next time: Separate guest order, power state and application checks.

Check your understanding

1. Why can enabling the guest-agent option fail to provide useful agent responses?

Show worked solution

The guest service or driver/channel setup may be absent, stopped or incompatible. The host-side flag expresses an intended integration only. Verify the guest-side installation and observed operation through an authorized procedure, and keep application health checks separate even after agent communication works.

2. A frontend starts ten seconds after an API. What remains unknown?