Bug 1151629 - blockcopy --keep-overlay ought to have --quiesce option
Summary: blockcopy --keep-overlay ought to have --quiesce option
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Han Han
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-10 20:44 UTC by Eric Blake
Modified: 2020-11-03 17:00 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-03 17:00:57 UTC
Embargoed:


Attachments (Terms of Use)

Description Eric Blake 2014-10-10 20:44:26 UTC
Description of problem:
When using live merge blockcopy to update the contents of a backing file to a known point in time while still keeping the active layer, it would be nice to be able to ensure the backing file is taken at a point in the guest operation where the filesystem is stable.  Similar to how we can involve the guest agent to quiesce the filesystem when taking an external snapshot, we should be able to use the agent to quiesce the filesystem right before breaking an active block commit.

Version-Release number of selected component (if applicable):
libvirt-1.2.8-5.el7

How reproducible:
100%

Steps to Reproduce:
1. start with a backing chain [base] <- [active] in a live guest with a guest agent connection
2. try: virsh blockcommit $dom vda --verbose --keep-overlay --quiesce
3. try: virsh blockcopy $dom vda /path/to/copy --verbose --abort --quiesce

Actual results:
--quiesce is not implemented; we need to add a flag to virDomainBlockJobAbort that supports guest-agent quiescing around the point where we end an active commit or block copy.

Expected results:
both commands should learn the --quiesce flag (really, as syntax sugar around the underlying virDomainBlockJobAbort learning the flag).  That way, when ending an active commit or block copy operation, the file that is no longer being modified will contain a stable snapshot of the disk at that time, rather than merely a crash-consistent state of the disk.


Additional info:

Comment 4 Daniel Berrangé 2020-11-03 17:00:57 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.