Bug 768054 - RFE: qemu: pass "migrate" string to Prepare hook so apps can distinguish migration
Summary: RFE: qemu: pass "migrate" string to Prepare hook so apps can distinguish migr...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-15 16:26 UTC by agt
Modified: 2020-11-03 16:31 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-03 16:31:06 UTC
Embargoed:


Attachments (Terms of Use)
1-line patch which implements requested feature (852 bytes, patch)
2011-12-15 16:26 UTC, agt
no flags Details | Diff
libvirt-migrate-qemu-hook.patch (1.12 KB, patch)
2012-01-03 09:32 UTC, Roman
no flags Details | Diff

Description agt 2011-12-15 16:26:09 UTC
Created attachment 547329 [details]
1-line patch which implements requested feature

Description of problem:

It would be useful for the QEMU "prepare" hook to be told whether it's being called in the context of a migration.

(In our case, we use that hook to manage shared DRBD storage, and only permit Primary/Primary mode in the context of a migration.)

Attached 1-line patch supplies the hook with an additional argument "migration-target" when appropriate. 

Version-Release number of selected component (if applicable):

0.9.4 (rhel6.2) as well as git-current.

Additional info:

>From: Eric Blake <eblake redhat com>
>Subject: Re: [libvirt-users] Wanted: method for qemu hook script to know if called for migration
>Date: Mon, 25 Jul 2011 14:17:08 -0600
>
>>As a feature suggestion, it would be nice if that fourth input variable,
>>currently "-", was something like "migrate" in this instance.
>
>Yes, that is probably a bug worth fixing.

Comment 1 Roman 2012-01-03 09:32:34 UTC
Created attachment 550383 [details]
libvirt-migrate-qemu-hook.patch

A more general solution for the problem

Comment 2 Cole Robinson 2016-03-23 15:04:53 UTC
Sorry this never received a response. Since several people seem interested in this, I encourage someone to formally send a patch to libvir-list where this is more likely to be discussed

Comment 3 Daniel Berrangé 2020-11-03 16:31:06 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.


Note You need to log in before you can comment on or make changes to this bug.