Search results

could you try first running the "kvm" command printed by `qm showcmd 103`, if it also exits with that error, then run it under strace, it might shed some light..

this sounds like an instance of "hole" mishandling, which is often caused by devices lying about their support for discarding. changing the block size might just cause the data to be aligned differently by the guest OS and thus avoid the issue.. you could try running the clone under strace: 1...

those very much sound like two different issues. this thread here is about a single connections stalling, not the whole network no longer working.

thanks!

testing whether the https://kernel.ubuntu.com/mainline/v6.16/ and https://kernel.ubuntu.com/mainline/v6.16.12/ kernels are showing the issue on your system(s) would be highly appreciated to narrow down the cause. we still cannot reproduce any issues on kernels after 6.17.4 in our test lab..

the configs (storage and ceph) don't agree on the ports - the first mon has port 3300 in your ceph config, and 6789 in your storage.cfg. assuming qemu picks the first monitor, if it is not listening on 6789, that would explain the error ;)

thanks, that looks correct. can you also post a clone task log?

yes, that sounds like something is blocking waiting for I/O, and the next point for checking the abort state is not reached.. is it possible something is throttling network connections after a certain amount of traffic?

yes, you just need to ensure you give it enough privileges for the actions you want to do on the PDM side ;)

please post: - pveversion -v - cat /etc/pve/storage.cfg - cat /etc/pve/priv/ceph/ceph-metal.conf - cat /etc/ceph/ceph.conf please censor any sensitive data such as auth keys

okay, so this must be a different issue then! stopping the sync job does work here, FWIW. does the slow down happen at specific groups/snapshots?

it is slated for 19.2.4 upstream, not sure if we a backport on our end before that is planned..

sehr viel hat sich in dem betreffenden code zwischen 6.15 und 6.16 nicht getan.. vielleicht mal ein issue auf https://github.com/acpica/acpica/ aufmachen mit details zur hardware, log messages und betroffenen kernel versionen?

can the two can the two PVE systems talk to eachother? anything visible on the source PVE system (task log, journal)?

could you try booting both ends with the 6.14 kernel? there is a known regression that seems to affect some PBS setups and the 6.17 kernels: https://forum.proxmox.com/threads/super-slow-timeout-and-vm-stuck-while-backing-up-after-updated-to-pve-9-1-1-and-pbs-4-0-20.176444/

das sind mehr oder weniger vanilla upstream == kernel.org kernel. ich schau mal kurz ob sich mit den infos schon was eingrenzen laesst!

the processes inside the container are still unconfined as expected, whereas without that config line they are confined by the container profile: without unconfined (PID 1/systemd of the container): $ cat /proc/135279/attr/current lxc-3336_</var/lib/lxc>//&:lxc-3336_<-var-lib-lxc>:unconfined...

cloning the disk does not care about its contents at all.. is this a physical disk? or iSCSI? or ? please provide more data! could you also post "lvmconfig --typeconfig full | grep -e thin -e zero" and "pveversion -v", thanks!

API endpoints being root only is the default if nothing else is specified. seems like those two "index" endpoints are lacking the permissions attribute, which should be fixed. but like @gyptazy said, the information is already available via other endpoints as well!

could you post `proxmox-backup-manager versions --verbose` for both sides, and the sync task log?