Hi, I wrote a hook for opennebula. And I need that hook to be executed every time before the vm going to SUSPEND state.
I configured it as:
VM_HOOK = [
name = "my_hook",
on = "CUSTOM",
state = "ACTIVE",
lcm_state = "SAVE_SUSPEND",
command = "my_hook.sh",
arguments = "$ID $TEMPLATE" ]
But sometimes vm is turning off faster than my hook is finished work,
I have not yet come up how to do it:
How can I slow vm suspending that would exec the hook before?
As far as I know you can’t do that. Hooks are asynchronous, and they are triggered on events, so it’s easy to run into this kind of race conditions.
Your approach is the best one, instead of using the hook subsystem, tune kvm/save and call your hook from there. After all, they driver actions are written in bash precisely because they should be customized to your needs
But still, it seems to me that it would be right to enhance the hook system by little modification:
Add additional parameter into hook system: BEFORE and AFTER state. Example I want do like in config:
VM_HOOK = [
name = "my_hook",
on = "CUSTOM",
state = "ACTIVE",
lcm_state = "SAVE_SUSPEND",
condition = "BEFORE"
command = "my_hook.sh",
arguments = "$ID $TEMPLATE" ]
And hook will be executed before suspend state, only after this status of vm will change.
In case AFTER condition, the hook will be executed at once after the change of status, regardless of what status will be after.
I dont know it’s a good idea or not, because I ask you about this. if you like, I can create a feature request in redmine.
The vmm/kvm/* scripts are called on the hypervisor node. Sometimes there is a need to implement datastore operations there (vmm/kvm/{save,restore}.<system_tm_mad>) but for security measures it is wise to disable the datastore management from the hypervisor. This way if a rogue manage to escape the virtualization(escape from the KVM to the HV) it will have impact only on the given HV and the attached locally storage drives. With access to the datastore management - the impact will be spread on the entire storage. So in the given example with the save/restore scripts I prefer the management of the storage(create,attach,detach and delete the checkpoint entity) to be on the front-end even be a hooks and only reads/writes to be on the hypervisor.
Makes sense, but this would involve a major architecture change in the hook subsystem, not easy at all to implement.
@kvaps, do open a feature request if you want, and reference this thread in the description. I think it’is a good idea that should be revised more carefully, although I’m a bit skeptical as to whether it’s going to be way too much effort.
@jmelis, as I understand this can be implemented as optional feature.
You may set the condition option, and hooks will be executed before or after changing state of vm.
Or not set the condition option, in this case, and hooks will be executed as is.
The problem with that, is that the hooks are asynchronous. Even if it’s triggered before, you may run into this race condition. You can only avoid the race condition entirely if you wait for the hook to return, that is, if we change it to an sync call. And that’s a major change in the code.
I think we need to enhance opennebula’s hook system by adding non-asynchronic hook’s too.
You leave no choice except changing default vmm scripts.
In my opinion this is wrong. What if I needed to run some actions before vm will be touched? Before deploy or before suspend…
For to do this at now I need to add this code directly into the vmm script.
This is really wrong, because vmm script will be overridden after update, and I need to track any changes on it.
You do not even consider the possibility of the creation of a vmm script bound to a specific tm driver. (see #5081)
Non-asynchronic hook system would solve all these problems.
In addition I’m convinced that it’s quite easy to implement, it is just needed to have check for these hooks before and after every action.
If someone thinks so, please type about it.
I hope for your understanding, thanks!
Opennebula has always been famous for its flexibility.
manage to escape the virtualization(escape from the KVM to the HV) it will have impact only on the given HV and the attached locally storage drives. With access to the datastore management - the impact will be spread on the entire storage. So in the given example with the save/restore scripts I prefer the management of the storage(create,attach,detach and delete the checkpoint entity) to be on the front-end even be a hooks and only reads/writes to be on the hypervisor.