Server

Introduction

Long-lived Proxmox VE installations often accumulate history.

A system may begin life on a rack server, later migrate to compact x86 hardware, change storage architecture, replace ZFS with LVM/ext4, and still retain traces of older configurations.

A major PVE upgrade can expose that history in logs and disk metadata.

The difficult part is not finding warnings.

The difficult part is deciding which warnings are still operationally relevant.

1. Confirm the PVE Stack

Useful commands:

pveversion
pveversion -v
cat /etc/os-release
uname -a

A fully upgraded PVE 9 system should consistently report:

  • PVE 9.x;
  • Debian 13 Trixie;
  • current Proxmox kernel;
  • matching PVE package generation.

2. Check the Core PVE Services

Review:

systemctl is-system-running
systemctl --failed

Then inspect:

systemctl status pve-cluster --no-pager
systemctl status pvedaemon --no-pager
systemctl status pveproxy --no-pager
systemctl status pvestatd --no-pager
systemctl status pvescheduler --no-pager
systemctl status qmeventd --no-pager

For a standalone node, the absence of an active Corosync cluster is normal.

Cluster-related warnings should be interpreted according to whether clustering is actually configured.

3. Verify pmxcfs and /etc/pve

The PVE configuration filesystem is critical:

findmnt /etc/pve
ls -la /etc/pve
ls -la /etc/pve/nodes/$(hostname)

A healthy standalone node should still have:

  • readable VM configuration;
  • readable storage configuration;
  • mounted pmxcfs;
  • intact node directory.

4. Audit VM and Guest Agent State

List VMs:

qm list

Inspect one VM:

qm status 101
qm config 101

If guest agent is enabled:

qm agent 101 ping

A useful broader check is:

for id in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do
    echo "----- VM $id -----"
    agent="$(qm config "$id" | sed -n 's/^agent:[[:space:]]*//p')"

    if [ -z "$agent" ]; then
        echo "QEMU Guest Agent: not configured"
    elif qm agent "$id" ping >/dev/null 2>&1; then
        echo "QEMU Guest Agent: PASS"
    else
        echo "QEMU Guest Agent: FAIL"
    fi
done

5. Interpreting a One-Time Guest Agent Timeout

A common startup sequence can look like this:

VM started
guest-ping timeout
guest-ping timeout
guest-ping timeout
forced stop
VM restarted
guest agent later responds normally

This is especially plausible when:

  • PVE itself has just booted;
  • an external disk enclosure is still becoming ready;
  • several VMs start simultaneously;
  • storage I/O is temporarily saturated;
  • a large VM resides on slower or externally attached storage.

If subsequent checks show:

QEMU Guest Agent: PASS

and the VM later completes a long backup successfully, then the historical timeout can be classified as a one-time startup condition.

A historical error does not remain a current fault indefinitely.

6. Storage Layouts Can Be More Complex Than PVE’s GUI Suggests

Consider a storage definition:

dir: local
    path /var/lib/vz
    content iso,backup,snippets,vztmpl,images,rootdir

Now consider that:

/var/lib/vz

resides on the root filesystem, while:

/var/lib/vz/images

is a separate 7 TB filesystem.

Then:

pvesm status

may report the capacity of /var/lib/vz itself, while VM images physically reside on the nested mount.

Verify with:

findmnt -T /var/lib/vz
findmnt -T /var/lib/vz/images
df -hT /var/lib/vz /var/lib/vz/images

This can produce:

/var/lib/vz         → root filesystem
/var/lib/vz/images  → separate large ext4 filesystem

That design is unusual but valid if intentional and stable.

The important point is that the PVE GUI’s local capacity may not represent the actual VM-image filesystem.

7. Old ZFS Signatures After Storage Migration

A disk that previously belonged to a ZFS pool may still contain ZFS labels after being repurposed for LVM.

For example:

wipefs -n /dev/sdb
wipefs -n /dev/sdb1

may show:

zfs_member

while:

blkid /dev/sdb1

shows:

TYPE="LVM2_member"

and:

pvs
vgs
lvs

confirm that the partition is actively used by LVM.

If:

zpool status

returns:

no pools available

then the old ZFS labels are historical metadata.

8. Why Old ZFS Labels Should Usually Be Left Alone

It may be tempting to remove stale signatures with wipefs.

That is rarely worth the risk on a live disk containing several terabytes of VM data.

The operational benefit is close to zero.

The potential cost of an incorrect metadata operation is very high.

A safer classification is:

Historical storage metadata
Inactive
Known
No current operational effect
Leave untouched

This is preferable to destructive cleanup for cosmetic reasons.

9. ACPI and Intel Graphics Warnings on Headless Hosts

After migration to compact hardware, kernel logs may contain:

ACPI BIOS Error
AE_ALREADY_EXISTS

and Intel graphics messages such as:

Failed to probe lspcon
Cannot find any crtc or sizes
crtc active state doesn't match with hw state

On a headless virtualization host, these messages may simply reflect firmware/display initialization that does not match the Linux graphics driver’s expectations.

If:

  • no display functionality is required;
  • the server boots successfully;
  • VMs run normally;
  • the errors occur only during boot;
  • no GPU hang appears later;

then disabling i915 or adding ACPI kernel parameters solely to suppress log messages is usually unjustified.

10. Verify That Warnings Do Not Recur

A powerful check is to inspect only the period after startup stabilization:

journalctl -b --since '30 minutes after boot' --no-pager | \
grep -Ei \
'qga command failed|guest-ping.*timeout|i915.*(error|fail|hang)|ACPI.*Error|I/O error|EXT4-fs error|corruption|OOM|out of memory'

If the output is empty, that provides stronger evidence than merely counting boot-time warnings.

11. Validate PVE-to-PBS Backup

A successful backup cycle proves several components simultaneously:

PVE scheduler
VM snapshot handling
QEMU integration
network path
PBS authentication
TLS
PBS datastore
disk read path
backup client

A completed task marked OK is strong evidence that the virtualization and backup stack survived the upgrade successfully.

12. Final Health Criteria

A migrated PVE host can reasonably be classified as healthy when:

  • PVE services are active;
  • /etc/pve is healthy;
  • VM inventory is intact;
  • running guests respond normally;
  • guest agents work after startup;
  • storage mounts are correct;
  • no active ZFS pool conflict exists;
  • no I/O or filesystem error persists;
  • PVE-to-PBS backup completes successfully;
  • repository and package state are correct;
  • no recurring kernel or service error remains after startup.

Historical firmware warnings and stale storage signatures do not invalidate that conclusion.

Conclusion

A mature PVE installation often contains traces of earlier hardware, storage, and operating decisions.

Those traces should be classified, not automatically erased.

A stable system with:

  • known benign ACPI messages;
  • inactive historical ZFS signatures;
  • a one-time VM startup timeout;
  • unusual but intentional storage mounts;

can still be fully healthy.

The more useful objective is not a perfectly empty log.

The more useful objective is a system with no unresolved operational fault.

Leave a Reply

Your email address will not be published. Required fields are marked *