Bug 1901835 - [RFE][CBT] Redefine VM checkpoint without using the VM domain XML
Summary: [RFE][CBT] Redefine VM checkpoint without using the VM domain XML
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.4.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.4.5
: ---
Assignee: Eyal Shenitzky
QA Contact: Ilan Zuckerman
URL:
Whiteboard:
Depends On: 1901830 1904486
Blocks: 1891470
TreeView+ depends on / blocked
 
Reported: 2020-11-26 08:01 UTC by Eyal Shenitzky
Modified: 2022-02-01 11:33 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-03-18 15:12:54 UTC
oVirt Team: Storage
Embargoed:
pm-rhel: planning_ack?
pm-rhel: devel_ack?
pm-rhel: testing_ack?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 112573 0 master MERGED core: drop checkpoint_xml from vm_checkpoints table 2021-02-16 10:48:42 UTC
oVirt gerrit 112574 0 master MERGED core: remove checkpoint XML update when deleting a VM checkpoint 2021-02-16 10:48:42 UTC
oVirt gerrit 112575 0 master MERGED core: redefine checkpoints without checkpoint XML 2021-02-16 10:48:42 UTC
oVirt gerrit 112576 0 master MERGED backup.py: allow redefine checkpoints using backup configuration 2021-02-16 10:48:42 UTC
oVirt gerrit 113777 0 master MERGED core: refactor delete VM checkpoint to not use CoCo framework 2021-03-10 09:26:36 UTC

Description Eyal Shenitzky 2020-11-26 08:01:55 UTC
Description of problem:

When redefining a VM checkpoint, Libvirt requires the VM domain XML.
After bug 1901830 will be solved, the domain XML is not needed when the checkpoint is redefined and the engine could drop the need to persist the checkpoint XML in his database.

The flow for starting a backup will not include the need to get the created checkpoint XML and persist it in the database + we will be able to remove all the recovery flows that handles the cases when the checkpoint XML is missing.
The engine only needs to keep the backup ID that was part of the checkpoint creation.

When redefining the checkpoint, the engine can now send to VDSM all the data for generating the checkpoint XML so VDSM will create it and sent it to Libvirt.

This will reduce the code in the engine and in VDSM, it will reduce the amount of data that we keep in the engine database, also, it will reduce the number of errors that may occur during the backup process since the number of calls between the engine, VDSM and Libvirt reduced also,


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

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Shir Fishbain 2021-01-26 11:39:23 UTC
Hi Eyal,
Please provide info on how to verify it correctly.

Comment 2 Eyal Shenitzky 2021-01-26 12:14:22 UTC
(In reply to Shir Fishbain from comment #1)
> Hi Eyal,
> Please provide info on how to verify it correctly.

Can be verified by running the regular tiers in the automation.

Comment 3 Ilan Zuckerman 2021-02-08 07:14:15 UTC
Can this be verified by repeating those steps from existing TC (TestCase27319)?

    1. Create a VM from template and start it
    2. Make a full backup of its disks X amount of times (defined by config.CHECKPOINTS_AMOUNT).
        a. Per each backup:
            - Check that a checkpoint is created.
            - Check that total amount of checkpoints matches the amount of times backup was executed.
    3. Run SDK example script for removing the root checkpoint X amount of times (defined by config.CHECKPOINTS_AMOUNT).
        a. Per each checkpoint removal:
            - Check that its ID matches the actual root checkpoint.
            - Check that actual amount of checkpoints on the vm matches the expected amount.

Comment 4 Eyal Shenitzky 2021-02-08 11:57:56 UTC
(In reply to Ilan Zuckerman from comment #3)
> Can this be verified by repeating those steps from existing TC
> (TestCase27319)?
> 
>     1. Create a VM from template and start it
>     2. Make a full backup of its disks X amount of times (defined by
> config.CHECKPOINTS_AMOUNT).
>         a. Per each backup:
>             - Check that a checkpoint is created.
>             - Check that total amount of checkpoints matches the amount of
> times backup was executed.
>     3. Run SDK example script for removing the root checkpoint X amount of
> times (defined by config.CHECKPOINTS_AMOUNT).
>         a. Per each checkpoint removal:
>             - Check that its ID matches the actual root checkpoint.
>             - Check that actual amount of checkpoints on the vm matches the
> expected amount.

Yes
Also, please verify that all the automation passed and there are no regressions.

Comment 5 RHEL Program Management 2021-02-09 07:17:35 UTC
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

Comment 6 Ilan Zuckerman 2021-02-09 11:51:19 UTC
Moving this on verified based on the tier1 and tier2  (tier3 doesnt exist) Automated test cases of CBT which were executed on latest rhv-4.4.5-4
tier2 was executed locally, tier1 is "RHV-4.4-tier1 #154" and can be found in Polarion.
No regression was spotted, or suspicious behavior. All test cases passed (except for known issues BZ 1914636 and BZ 1849861)

Comment 7 Sandro Bonazzola 2021-03-18 15:12:54 UTC
This bugzilla is included in oVirt 4.4.5 release, published on March 18th 2021.

Since the problem described in this bug report should be resolved in oVirt 4.4.5 release, it has been closed with a resolution of CURRENT RELEASE.

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

Comment 8 Sandro Bonazzola 2021-03-22 12:55:32 UTC
This bugzilla is included in oVirt 4.4.5 release, published on March 18th 2021.

Since the problem described in this bug report should be resolved in oVirt 4.4.5 release, it has been closed with a resolution of CURRENT RELEASE.

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


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