Recent content by robm

fstrim manually takes a few seconds at most (SSD). Storage is ZFS. Each cluster has standalone VMs, both cluster are running latest Proxmox 7.4 with all packages updated. Same CPU in both servers (e3-1230).

Tasklog for the migration attached

Also, just did another test with a test VM, and the same sort of thing happened. It stopped at the fstrim, but this time it locked up the VM at 100% CPU (1 core), timed out after 10 minutes, and the VM was unresponsive on console. Had top stop/start it, at which point it was running on the new...

Sure, I PM'ed you the full journal entries. Thanks.

Old: Nov 09 09:07:39 swtrading-pve qm[1298464]: <root@pam> starting task UPID:swtrading-pve:0013D041:00755213:654CF5BB:qmigrate:123:root@pam: Nov 09 09:39:28 swtrading-pve qm[1298497]: migration problems Nov 09 09:39:28 swtrading-pve qm[1298504]: migration aborted Nov 09 09:39:28 swtrading-pve...

Latest 7.4 proxmox, was moving a VM from one cluster to another using the "qm remote-migrate" command. First VM moved fine, second one got hung up: 2023-11-09 09:29:28 stopping NBD storage migration server on target. tunnel: -> sending command "nbdstop" to remote tunnel: <- got reply tunnel: ->...

We're seeing the timeouts too with a local PBS backup server for many standalone Proxmox servers (no NFS). We think it's because when the backups run on the PBS, the server can be slow to respond (GUI sometimes takes 15-20 seconds to load a new page), and this is tripping that 3 second timeout...

Thank you for looking into it. I wonder if there is a way to set an "ionice" setting on the disk zeroing to lessen its I/O impact when zeroing the disk. Since it's a live migration, a few extra minutes would not be an issue on the initial zeroing...

Sure, here are the task logs for the same VM being migrated 3 different ways. Also attached is the image of I/O load for these 3 tests (discard on first, discard off second, VM offline migration 3rd). The live migration with discard on really impacts other VMS performance during the zeroing of...

Sure. Task log with discard on: Migrate with discard enabled: ----------------------------- Proxmox Virtual Environment 7.0-11 Logs 2021-10-09 22:14:05 use dedicated network address for sending migration traffic (10.10.23.81) 2021-10-09 22:14:06 starting migration of VM 214 to node 'vps16'...

When doing a live VM migration (latest proxmox enterprise 7) from one server to another where both servers use local disks with lvm-thin (ext4 hardware SSD RAID-10), if the VM hard disk has "Discard" enabled, we find that the migration hammers the I/O of the target node until the first copy...

When we perform an offline VM clone, we see a very high I/O for 1-2 minutes, which causes other VMs to slow down considerably. Running the latest Proxmox 7. RAID-10 is using Intel VROC. SSDs are: Crucial/Micron Micron_1100_MTFDDAK2T0TBN Intel(R) Xeon(R) CPU E5-2680 v4 dual CPUs 512 GB RAM ext4...

Ah ok, thanks for the explanation. We'll put kernelcare on the host, and we should be good then. :)

I thought with LXC, since we can install any OS, that we have to manage each LXC's kernel with updates, etc... We are trying to apply kernelcare to each LXC so we do not have to reboot the container each time a new kernel is released for the OS of the container. For example, if the container is...

Using centOS 7 LXC as "unprivileged containers" and trying to install kernelcare for rebootless kernel updates, and running into this error: insmod: ERROR: could not insert module /var/cache/kcare/modules/none-abcd/kcare.ko: Operation not permitted Unable to load kmod...