Sent from my iPhone

> On 17 Oct 2025, at 12:59, Peter Krempa <[email protected]> wrote:
> 
> > 
> Please don't top-post on technical lists.
> 
>> On Thu, Oct 16, 2025 at 18:47:36 +0000, Rogério Vinhal Nunes wrote:
>> 
>> We have some internal tools we need to setup/tear down on the time the
>> domain stops on the source and starts on the destination, so I don't
>> believe full native support would fit.
> 
> I've asked for clarification because libvirt already provides hooks that
> can fit your description.
> 
> Specifically on the source of the migration you'll get:
> 
> Two hook calls:
> 
> $VMNAME stopped end -
> $VMNAME release end migrated
> 
> Both of these happen when the VM is already running on the destination,
> but right after the migration.
> 
> On the destination you get:
> 
> $VMNAME migrate begin -
> $VMNAME prepare begin -
> $VMNAME start begin -
> $VMNAME started begin -
> 
> IIRC 'migrate' and 'prepare' happen when setting up the migration.
> 'start' happens right before starting the qemu process. At this point
> the migration will progress. 'started' happens after the migration was
> complete.
> 
> So this provides means to setup and tear down resources.
> 
> The open question still is whether you need that to happen precisely at
> switchover time. Thus the request for what you want to actually do.
> 
> A hook at switchover time is obviously possible but until now we didn't
> yet get a good reason to have one. A reason against is that it
> introduces latency for the switchover.

I need to synchronise our internal storage solution at the switchover time 
because I need to unmap the resource from source and map on the destination. It 
would be a behaviour similar to what happens with NBD, but it's backed by our 
internal backend.

> 
> 
>> An alternative could be to have an option to wait for a resume
>> operation to progress as a client-defined migration flag exposing the
>> pre-switchover state. This way maybe we could work it as a client
>> feature rather than a hook?
> 
> Once again specifying what you actually want to do would be helpful.
> 
> E.g. I can suggest that you can migrate the VM as paused, which ensures
> that once the migration completes it will not continue execution on the
> destination, which could give you the chance for additional
> synchronisation.

For us it's important to have the least amount of interruption as possible, so 
we're very keen on a live migration here.

> 
>> I'm happy to work on a patch and I'm open for guidance on what to do here.
>> 
>>>> On 16 Oct 2025, at 18:44, Peter Krempa <[email protected]> wrote:
>>> 
>>> >
>>>> On Thu, Oct 16, 2025 at 14:43:56 +0000, Rogério Vinhal Nunes via Devel 
>>>> wrote:
>>>> Hello,
>>>> 
>>>> I’m looking into the libvirt hooks that are available to make use of 
>>>> during a live migration, but there's only hooks on migration begin and 
>>>> migration end. On qemu directly I’m able to use pause-before-switchover 
>>>> migration capability to run a custom operation just before it moves to the 
>>>> destination, but within libvirt it seems that while this is leveraged 
>>>> internally, it’s not currently exposed to the client in a way I can use.
>>>> 
>>>> Does anyone have any suggestions on how I could expose this to the client 
>>>> in a generic and sensible way?
>>> 
>>> Yes this is currently not available.
>>> 
>>> Can you elaborate what you'd want to use it for? E.g. what we don't
>>> support that could be solved by this.
>>> 
>>> We prefer if things work without hooks as hooks are really clunky for
>>> users to setup properly and maybe your case can be improved by some
>>> native support.
>>> 
>> 
> 

Reply via email to