libvirt users - Jan 2020 - Re: qemu hook: event for source host too

I could launch `lvchange -asy` on the source host manually, but the aim of hooks
is to automatically execute such commands and avoid human errors.

Le 22 janvier 2020 09:18:54 GMT+01:00, Michal Privoznik
<mprivozn@redhat.com> a écrit :
>On 1/21/20 9:10 AM, Guy Godfroy wrote:
>> Hello, this is my first time posting on this mailing list.
>> 
>> I wanted to suggest a addition to the qemu hook. I will explain it 
>> through my own use case.
>> 
>> I use a shared LVM storage as a volume pool between my nodes. I use 
>> lvmlockd in sanlock mode to protect both LVM metadata corruption and 
>> concurrent volume mounting.
>> 
>> When I run a VM on a node, I activate the desired LV with exclusive
>lock 
>> (lvchange -aey). When I stop the VM, I deactivate the LV, effectively
>
>> releasing the exclusive lock (lvchange -an).
>> 
>> When I migrate a VM (both live and offline), the LV has to be
>activated 
>> on both source and target nodes, so I have to use a shared lock 
>> (lvchange -asy). That's why I need a hook event on the source host
>too 
>> (as far as I know after my tests, the migration event is only
>triggered 
>> on the target host).
>> 
>> Is such a feature a possibility?
>
>In theory yes. But since you are the one initiating migration, can't
>you 
>also issue the lvchange command?
>On the other hand, we already have startup hooks so the argument is
>only 
>partially valid - anybody starting up a domain can run the hook too.
>
>Michal
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.

On 1/22/20 9:23 AM, Guy Godfroy wrote:
> I could launch `lvchange -asy` on the source host manually, but the aim 
> of hooks is to automatically execute such commands and avoid human errors.
Agreed. However, you would need two hooks actually. One that is called 
on the source when the migration is started, and the other that is 
called on the destination when the migration is finished (so that you 
can promote the shared lock to the exclusive again). Just out of 
curiosity - how do you handle the lock promoting?

Michal

That's right, I need also that second hook event.

For your information, for now I manage locks manually or via Ansible. To make
hook manage locks, I still need to find out a secure way to run LVM commands
from a non-root account, but this is another problem.

Le 22 janvier 2020 10:24:53 GMT+01:00, Michal Privoznik
<mprivozn@redhat.com> a écrit :
>On 1/22/20 9:23 AM, Guy Godfroy wrote:
>> I could launch `lvchange -asy` on the source host manually, but the
>aim 
>> of hooks is to automatically execute such commands and avoid human
>errors.
>
>Agreed. However, you would need two hooks actually. One that is called 
>on the source when the migration is started, and the other that is 
>called on the destination when the migration is finished (so that you 
>can promote the shared lock to the exclusive again). Just out of 
>curiosity - how do you handle the lock promoting?
>
>Michal
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.