qemu hook: event for source host too
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é.
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é.
So, how likely is it possible to get this feature (two new events for the qemu hook)? Le 22/01/2020 à 10:56, Guy Godfroy a écrit :
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é.
On 1/23/20 1:43 PM, Guy Godfroy wrote:
So, how likely is it possible to get this feature (two new events for the qemu hook)?
I've started writing it, but then I realized we might need third hook - in confirm phase - which would be run on the source when quemu switches control over to the destination, or when migration failed. And this is what I need to figure out, how to differentiate these two states on the hook script level. Michal
I don't really understand what new hook this would be. Le 24/01/2020 à 14:05, Michal Privoznik a écrit :
On 1/23/20 1:43 PM, Guy Godfroy wrote:
So, how likely is it possible to get this feature (two new events for the qemu hook)?
I've started writing it, but then I realized we might need third hook - in confirm phase - which would be run on the source when quemu switches control over to the destination, or when migration failed. And this is what I need to figure out, how to differentiate these two states on the hook script level.
Michal
On 1/24/20 4:34 PM, Guy Godfroy wrote:
I don't really understand what new hook this would be.
Libvirt's migration happens in phases [1]. The last one is 'Confirm' where either the domain is either killed (because it's running on the destination successfully), or resumed (because there was an error). If you make a lock shared at the beginning of the migration, but migration doesn't succeed you want to make it exclusive again in the Confirm phase. Or release it, because the domain is being killed (in which case we already run a hook script, so might get away with this specific case). Basically, in the hook called from the confirm phase you want to undo everything that the hook script called at the beginning of the migration has done. BTW: I might have some time to work on this during weekend, but no promises. If you want to write patches though, I can give you some pointers and review them ;-) Michal 1: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt-domain.c;h=40743...
Cool :) Don't worry I'm not on a rush: I guess the feature will not be part of Debian before next major release anyway. Le ven., janv. 24, 2020 at 17:24, Michal Privoznik <mprivozn@redhat.com> a écrit :
On 1/24/20 4:34 PM, Guy Godfroy wrote:
I don't really understand what new hook this would be.
Libvirt's migration happens in phases [1]. The last one is 'Confirm' where either the domain is either killed (because it's running on the destination successfully), or resumed (because there was an error).
If you make a lock shared at the beginning of the migration, but migration doesn't succeed you want to make it exclusive again in the Confirm phase. Or release it, because the domain is being killed (in which case we already run a hook script, so might get away with this specific case). Basically, in the hook called from the confirm phase you want to undo everything that the hook script called at the beginning of the migration has done.
BTW: I might have some time to work on this during weekend, but no promises. If you want to write patches though, I can give you some pointers and review them ;-)
Michal
Hello, Any news on that feature? Le 27/01/2020 à 15:06, Guy Godfroy a écrit :
Cool :) Don't worry I'm not on a rush: I guess the feature will not be part of Debian before next major release anyway.
Le ven., janv. 24, 2020 at 17:24, Michal Privoznik <mprivozn@redhat.com> a écrit :
On 1/24/20 4:34 PM, Guy Godfroy wrote:
I don't really understand what new hook this would be.
Libvirt's migration happens in phases [1]. The last one is 'Confirm' where either the domain is either killed (because it's running on the destination successfully), or resumed (because there was an error). If you make a lock shared at the beginning of the migration, but migration doesn't succeed you want to make it exclusive again in the Confirm phase. Or release it, because the domain is being killed (in which case we already run a hook script, so might get away with this specific case). Basically, in the hook called from the confirm phase you want to undo everything that the hook script called at the beginning of the migration has done. BTW: I might have some time to work on this during weekend, but no promises. If you want to write patches though, I can give you some pointers and review them ;-) Michal 1: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt-domain.c;h=40743...
Hello, Is there any news about this feature ? Guy Godfroy Le 27/01/2020 à 15:06, Guy Godfroy a écrit :
Cool :) Don't worry I'm not on a rush: I guess the feature will not be part of Debian before next major release anyway.
Le ven., janv. 24, 2020 at 17:24, Michal Privoznik <mprivozn@redhat.com> a écrit :
On 1/24/20 4:34 PM, Guy Godfroy wrote:
I don't really understand what new hook this would be.
Libvirt's migration happens in phases [1]. The last one is 'Confirm' where either the domain is either killed (because it's running on the destination successfully), or resumed (because there was an error). If you make a lock shared at the beginning of the migration, but migration doesn't succeed you want to make it exclusive again in the Confirm phase. Or release it, because the domain is being killed (in which case we already run a hook script, so might get away with this specific case). Basically, in the hook called from the confirm phase you want to undo everything that the hook script called at the beginning of the migration has done. BTW: I might have some time to work on this during weekend, but no promises. If you want to write patches though, I can give you some pointers and review them ;-) Michal 1: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt-domain.c;h=40743...
OK. I created an issue about this feature. https://gitlab.com/libvirt/libvirt/-/issues/37 Guy Le 22/06/2020 à 13:06, Michal Privoznik a écrit :
On 6/19/20 8:24 AM, Guy Godfroy wrote:
Hello,
Is there any news about this feature ?
Unfortunately no news. Sorry.
Michal
participants (2)
-
Guy Godfroy -
Michal Privoznik