Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1942651

Summary:	[RFE] Add a "snapshots cleaner" for warm migration
Product:	Migration Toolkit for Virtualization	Reporter:	Ilanit Stein <istein>
Component:	Controller	Assignee:	Sam Lucidi <slucidi>
Status:	CLOSED ERRATA	QA Contact:	Amos Mastbaum <amastbau>
Severity:	medium	Docs Contact:	Avital Pinnick <apinnick>
Priority:	urgent
Version:	2.1.0	CC:	cnv-qe-bugs, dagur, fbladilo, fdupont
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	2.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-04-04 18:03:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2000298
Bug Blocks:

Description Ilanit Stein 2021-03-24 16:40:40 UTC

Description of problem:
In case a warm migration is started but the cut-off time is not set or not reached for many hours/days, there will be many snapshots gathered which can consume a lot of space.

Please consider implementing a "cleaner" that will remove past snapshots that are no longer needed.

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

Comment 1 Sam Lucidi 2021-05-07 17:37:47 UTC

https://github.com/kubevirt/vm-import-operator/pull/488

Comment 3 Fabien Dupont 2021-07-05 12:14:53 UTC

This RFE will be addressed directly in MTV 2.2.0. Changing product, component and target release.

Comment 4 Fabien Dupont 2021-07-05 12:16:36 UTC

I've dug a bit more into the incremental backup details to understand what we could do to safely clean snapshots. And I've found VMware KB#76082 [1] simply titled "Workflow of incremental backup based on changed block tracking". And the workflow is very simple and deletes the snapshots as soon as they have been used, not even keeping the previous one to get a delta.

After reading this workflow, I guess that our error is that we delete parent snapshots in a chain, breaking the chain and making any further access invalid. If we delete the snapshot right after the copy completion, we delete the whole chain, keeping all references clean.

We now need to set up a test protocol to verify that it works, i.e. that more than two iterations succeed and the VM is not corrupted after the migration.


[1] https://kb.vmware.com/s/article/76082

Comment 5 Fabien Dupont 2021-10-22 07:15:56 UTC

This cannot be enabled before CNV 4.9.1, since the required change in CDI will be in CNV 4.9.1.
The work is almost ready to be merged upstream, but we still don't have CNV 4.9.1 builds to test.

Comment 6 Fabien Dupont 2021-11-17 15:21:43 UTC

Please verify with mtv-operator-bundle-container-v2.2.0-88 / iib:135478, or later.

Comment 7 Fabien Dupont 2021-11-19 15:46:36 UTC

The feature is disabled by default in the controller, so it won't use Change IDs.
Moving the bug back to ASSIGNED.

Comment 8 Fabien Dupont 2021-11-20 07:38:14 UTC

Please verify with the mtv-operator-bundle-container-v2.2.0-90 / iib:136635, or later.

Comment 9 Fabien Dupont 2021-11-22 12:32:41 UTC

Somehow it fails. We need to review the process with Change IDs.
In the meantime, I'm moving the bug to ASSIGNED and reverting the PR to unblock other BZs.

Comment 10 Amos Mastbaum 2022-02-09 10:13:09 UTC

OCP 4.10.0-fc.2
CNV 4.10.0-617
MTV -2.3.0-23
Snapshot is removed immediately after the import is done.
Verified

Comment 13 errata-xmlrpc 2022-04-04 18:03:40 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (MTV 2.3.0 images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1183