Recent content by Moayad

Hi, have you checked the syslog when the VM shutdown? you can check using journalctl with specific time if you know the exact time e.g: journalctl --since "2026-07-09 13:00" --until "2026-07-09 14:00" > /tmp/$(hostname)-syslog.txt Modify the date/time in the above command. I would also check...

The logs run normally then immediately starts a new boot, without the usual systemd, pve-guests, or shutdown messages. I would check the hardware. So please check the UPS log and any BIOS, IPMI, or iDRAC event logs around that time. The LXC error for container 103 is likely a separate. However...

You can open an enhancement request in our BugZilla [0] [0] https://bugzilla.proxmox.com/

yeah, full clone only setups reduce the risk, but templates can back linked clones, so the API stays conservative. Editing config files may work, but it bypasses normal checks and it unsupported.

You can clone or convert to a regular VM, perform the disk import or move there, then convert the result back into a template with `qm template <VMID>`. Because templates are treated as immutable base images for cloning.

Please open the Web UI via the failing node's IP and test `mail-to-root` again, during running the following command: journalctl -f

Go to `Datacenter` -> `Notifications` -> `Notification Targets` then click `Test` button.

Hi, This is likely node specific, since the default mail is handled locally on each node. Could you please run `mail-to-root` test on the failing node and share the relevant mail logs from that time, e.g., journalctl or `/var/log/mail.log`. I would also compare `/etc/postfix/main.cf` with...

Hi, The SPF reject usually means the service is still submitting mail to PMG on the external SMTP port 25, where SPF checks are applied. Could you please configure the internal service to use PMG as smarthost on the internal SMTP port, default 26 [0], and retest? If it must use port 25, add...

Hi @Chronos.Song I would check the `/etc/hostname` and see if contains only the short node name and that it resolves correctly, then restart or reboot hte affected node.

Hi, Thank you for sharing the soltuion. For your informaiton I set your thread as [SOLVED] to help other people who have the same issue.

Thank you for the output! The pool can perform well, but the affected VM image itself is slow. That is the important distinction. For the recreate, I would a temporary second RBD storage ID pointing to the same pool. That avoids direct manual renames in RBD and keeps PVE in control of the VM...

Thank you for the output! The `rbd bench` numbers are from a scratch image. That confirms the pool cluster can deliver high throughput, but it does not fully rule out an issue specific to the actual VM image object layout. We recently had a case where pool-level tests looked fine, but the...

Thank you for the test! Could you please run the following read-only benchmarks on the same RBD image used for VM 701? rbd bench --io-type read --io-size 64K --io-threads 1 --io-total 1G pool_nvme_vm/vm-701-disk-0 rbd bench --io-type read --io-size 1M --io-threads 1 --io-total 4G...

Thank you for the test and the output! At this point, this looks more like the Ceph RBD access path on the PVE side than a generic PBS side issue. Before going deeper into tracing, could you please test one non-critical ceph backend VM with `krbd` enabled and then rerun one backp there? If you...