--- Begin Message ---
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
very helpful.
On 22.05.25 г. 9:30 ч., Fabian Grünbichler wrote:
Denis Kanchev via pve-devel hat am 21.05.2025
15:13 CEST geschrieben:
Hello,
We had an issue with a customer migrating a VM between nodes using our
shared storage solution.
On the target host the OOM killer killed the main migration
--- Begin Message ---
Hello,
We had an issue with a customer migrating a VM between nodes using our
shared storage solution.
On the target host the OOM killer killed the main migration process, but
the child process (which actually performs the migration) kept on
working, which we did not ex
--- Begin Message ---
> I thought your storage plugin is a shared storage, so there is no storage
migration at all, yet you keep talking about storage migration?
It's a shared storage indeed, the issue was that the migration process on
the destination host got OOM killed and the migration failed, m
--- Begin Message ---
My bad :) in terms of Proxmox it must be hand-overing the storage control -
the storage plugin function activate_volume() is called in our case, which
moves the storage to the new VM.
So no data is moved across the nodes and only the volumes get re-attached.
Thanks for the ple
--- Begin Message ---
We tend to prevent having a volume active on two nodes, as may lead to data
corruption, so we detach the volume from all nodes ( except the target one
) via our shared storage system.
In the sub activate_volume() our logic is to not detach the volume from
other hosts in case o
--- Begin Message ---
The issue here is that the storage plugin activate_volume() is called after
migration cancel which in case of network shared storage can make things
bad.
This is a sort of race condition, because migration_cancel wont stop the
storage migration on the remote server. As you can
--- Begin Message ---
> how are you hooking the migration state to know whether deactivation
should be done or not?
By using the VM property "lock" which must be "migrate":
PVE::Cluster::get_guest_config_properties(['lock']);
> qm start (over SSH, is this being killed?)
> -> start_vm task worker (
