> Denis Kanchev <denis.kanc...@storpool.com> hat am 28.05.2025 08:13 CEST > geschrieben: > > > Here is the task log > 2025-04-11 03:45:42 starting migration of VM 2282 to node 'telpr01pve05' > (10.10.17.5) > 2025-04-11 03:45:42 starting VM 2282 on remote node 'telpr01pve05' > 2025-04-11 03:45:45 [telpr01pve05] Warning: sch_htb: quantum of class 10001 > is big. Consider r2q change. > 2025-04-11 03:45:46 [telpr01pve05] Dump was interrupted and may be > inconsistent. > 2025-04-11 03:45:46 [telpr01pve05] kvm: failed to find file > '/usr/share/qemu-server/bootsplash.jpg' > 2025-04-11 03:45:46 start remote tunnel > 2025-04-11 03:45:46 ssh tunnel ver 1 > 2025-04-11 03:45:46 starting online/live migration on > unix:/run/qemu-server/2282.migrate > 2025-04-11 03:45:46 set migration capabilities > 2025-04-11 03:45:46 migration downtime limit: 100 ms > 2025-04-11 03:45:46 migration cachesize: 4.0 GiB > 2025-04-11 03:45:46 set migration parameters > 2025-04-11 03:45:46 start migrate command to > unix:/run/qemu-server/2282.migrate > 2025-04-11 03:45:47 migration active, transferred 152.2 MiB of 24.0 GiB > VM-state, 162.1 MiB/s > ... > 2025-04-11 03:46:49 migration active, transferred 15.2 GiB of 24.0 GiB > VM-state, 2.0 GiB/s > 2025-04-11 03:46:50 migration status error: failed > 2025-04-11 03:46:50 ERROR: online migrate failure - aborting > 2025-04-11 03:46:50 aborting phase 2 - cleanup resources > 2025-04-11 03:46:50 migrate_cancel > 2025-04-11 03:46:52 ERROR: migration finished with problems (duration > 00:01:11) > TASK ERROR: migration problems
okay, so no local disks involved.. not sure which process got killed then? ;) the state transfer happens entirely within the Qemu process, perl is just polling it to print the status, and that perl task worker is not OOM killed since it continues to print all the error handling messages.. > > that has weird implications with regards to threads, so I don't think that > > is a good idea.. > What you mean by that? Are any threads involved? not intentionally, no. the issue is that the whole "pr_set_deathsig" machinery works on the thread level, not the process level for historical reasons. so it actually would kill the child if the thread that called pr_set_deathsig exits.. I think we do want to improve how run_command handles the parent disappearing. but it's not that straight-forward to implement in a race-free fashion (in Perl). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
