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? Thanks for your attention. Guy Godfroy
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
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é.