[pve-devel] Storage::Plugin::deactivate_volume not executed, when VM does shutdown

Jasmin J. jasmin at anw.at
Sun Dec 11 12:08:23 CET 2016


Hi!

 >> It seems the storage plugin function "deactivate_volume" will be not
 >> executed, when the VM stops by issuing a "poweroff" command.
 > That is by design ...
So there is NO interface between the code who already detects this
(eg.: "pvedaemon[6695]: client closed connection") to the storage and this
behaviour is intended?
I don't know all the concepts behind Proxmox, but is there really no way to
execute "deactivate_volume" from pvedaemon in that case? pvedaemon does also
execute "activate_volume" and "filesystem_path" so it seems to be the right
tool to implement also this.

I noticed the problem with the LVM plugin also. The volume keeps activated
after issuing a shutdown from within the VM. In my opinion this should be
fixed.
If you point me in the right direction, I can try to fix it, even I have nearly
no time left for this due the near vacation and the need for a working cluster
til end of next week. And a fix from me wouldn't be that smart like a fix
from a perl guru at Proxmox would!

 > You should not rely on such behavior, because you can never really know
 > exactly when a VM stops.
Even the Proxmox LVM plugin does deactivate the volume after using it. OK,
it doesn't rely on this but other lower level drivers (DRBD9/drbdmanage using
auto-promote) do.

For a DRBD8 plugin, which I want to write, it is essential to switch the volume
back to secondary after using it. Otherwise it can't be used on the other
machine and you need manual intervention to solve this issue.

But I can also check all the present VMs in "activate_storage" if they are
running on the machine and execute "deactivate_volume", if not. But this seems
to be more a hack than a concept for me. And even the cyclical execution of
"activate_storage" might not be intended (see 
http://pve.proxmox.com/pipermail/pve-devel/2016-December/024471.html).

BR,
    Jasmin



More information about the pve-devel mailing list