Bug 1464792 - Allow to migrate a paused VM with Post-copy policy
Summary: Allow to migrate a paused VM with Post-copy policy
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-25 19:55 UTC by Shmuel Melamud
Modified: 2024-12-17 12:21 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-12-17 12:21:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Shmuel Melamud 2017-06-25 19:55:55 UTC
Description of problem:

Libvirt does not allow to migrate a paused VM with post-copy migration. If migration policy of a oVirt cluster contains a "postcopy" action, every attempt to migrate a paused VM fails because libvirt returns an error, not allowing migration to start:

libvirtError: argument unsupported: post-copy migration is not supported with n
on-live or paused migration

On the other side, the current oVirt Post-copy migration policy uses post-copy only as last resort, when a regular migration stalls. It is unlikely that migration will be stalling when migrating a paused VM, so it is safe to use a Post-copy policy with it.

I propose to allow migration to start with such migration policy. If migration stalls and "postcopy" action is reached, libvirt may cancel the migration at that moment.

Comment 1 Daniel Berrangé 2017-06-26 08:16:55 UTC
The benefit of post-copy, over traditional pre-copy mode, is that it can guarantee migration completion no matter how heavily the guest is dirtying RAM. If the VM is paused, then obviously the guest isn't dirtying RAM at all, at which point using post-copy instead of pre-copy is pointless.  That said, I don't see a particular reason why libvirt must forbid post-copy in this case.

Comment 2 Daniel Berrangé 2024-12-17 12:21:23 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.