Bug 1712784 - [RFE] Disk incremental backup setting is not persistent to VM template
Summary: [RFE] Disk incremental backup setting is not persistent to VM template
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 4.3.3.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-22 09:07 UTC by Ilan Zuckerman
Modified: 2021-11-12 09:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-24 10:15:51 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)

Description Ilan Zuckerman 2019-05-22 09:07:26 UTC
Description of problem:
Disk property backup=incremental is not persistent in the template created from that vm. Meaning that if a template created out of vm with such disk property, this setting will not persist in the vm which will be created from that template.


Version-Release number of selected component (if applicable):
rpm -qa | grep '^ovirt-engine-[0-9]'	ovirt-engine-4.3.3.3-0.1.el7.noarch
rpm -qa | grep rhv-release	rhv-release-4.3.3-3-001.noarch
uname -r	3.10.0-957.12.1.el7.x86_64
cat /etc/redhat-release	Red Hat Enterprise Linux Server release 7.6 (Maipo)
rpm -q vdsm	vdsm-4.30.13-1.el7ev.x86_64



How reproducible:
100%

Steps to Reproduce:
1. Pick a disk attached to a vm (doesnt matter if its thin or pre-allocated), and make it backup=incremental. Currently this setting can not be done from the UI, so i do it with API call:

PUT
https://<engine fqdn>/ovirt-engine/api/vms/<vm uuid>/diskattachments/<disk id>

<disk_attachment>
	<disk>
		<backup>incremental</backup>
	</disk>
</disk_attachment>


2. Check that the disk backup property was set to incremental:

GET
https://<engine fqdn>/ovirt-engine/api/disks/<disk id>

	<disk>
                ...
		<backup>incremental</backup>
                ...
	</disk>


3. Make a template out of this vm
4. Make a new vm out of created template
5. Check the disk properties by GET API call. You will see that disk backup property was set back to "none"

Actual results:
	<disk>
                ...
		<backup>none</backup>
                ...
	</disk>


Expected results:
	<disk>
                ...
		<backup>incremental</backup>
                ...
	</disk>


Additional info:
log collector logs are attached in a private message

Comment 2 Nir Soffer 2019-05-22 09:51:57 UTC
I wonder why we need the backup=incremental on a template. Templates
are read-only, so we cannot do incremental backups of the template.

I think creating a template from disk with backup=incremental should drop
the backup property.

If you want to enable incremental backup you need to select
"enable incremental backup" when creating a vm from a template.

One issue with this is how do you enable incremental backup when cloning
a template.

Comment 3 Ilan Zuckerman 2019-05-22 09:58:35 UTC
(In reply to Nir Soffer from comment #2)
> I wonder why we need the backup=incremental on a template. Templates
> are read-only, so we cannot do incremental backups of the template.
> 
> I think creating a template from disk with backup=incremental should drop
> the backup property.
> 
> If you want to enable incremental backup you need to select
> "enable incremental backup" when creating a vm from a template.
> 
Thank you Nir, this isnt related directly to the BZ i opened, but there is no option in the UI to "enable incremental backup". Our env rpms versions are specified above.

Comment 4 Nir Soffer 2019-05-22 10:45:33 UTC
(In reply to Ilan Zuckerman from comment #3)
> Thank you Nir, this isnt related directly to the BZ i opened, but there is
> no option in the UI to "enable incremental backup". 

"Enable incremental backup" is the UI allowing you to create a disk with
backup=incremental. It was not backported to 4.3 since incremental backup
feature is not ready yet.

It is related, because the expected behaviour may be to drop backup=incremental
when we export. If the template does not have a backup=incremental property,
there is no bug here.

The question remain if there should be a way to create a VM with incremental
backup enabled by using a template, or the user need to create a vm and then
enable the feature for the relevant disks.

I don't think this use case was discussed when we design the feature.

Comment 5 Tal Nisan 2019-05-27 14:17:55 UTC
Daniel, your thoughts?

Comment 6 Daniel Erez 2019-05-28 11:17:29 UTC
Bot (In reply to Nir Soffer from comment #4)
> (In reply to Ilan Zuckerman from comment #3)
> > Thank you Nir, this isnt related directly to the BZ i opened, but there is
> > no option in the UI to "enable incremental backup". 
> 
> "Enable incremental backup" is the UI allowing you to create a disk with
> backup=incremental. It was not backported to 4.3 since incremental backup
> feature is not ready yet.
> 
> It is related, because the expected behaviour may be to drop
> backup=incremental
> when we export. If the template does not have a backup=incremental property,
> there is no bug here.
> 
> The question remain if there should be a way to create a VM with incremental
> backup enabled by using a template, or the user need to create a vm and then
> enable the feature for the relevant disks.
> 
> I don't think this use case was discussed when we design the feature.

Not sure how interesting is the use-case of preserving the incremental backup property in a template,
but it's probably a good idea to keep it consistent with the behaviour of other VM properties.
So as supporting it with would require some effort (adding to the UI, REST, etc), setting the BZ
as an RFE to prioritize.

Comment 7 Michal Skrivanek 2020-06-23 12:34:18 UTC
This request is not currently committed to 4.4.z, moving it to 4.5

Comment 8 Eyal Shenitzky 2021-06-24 10:15:51 UTC
Disk with "Enable incremental backup" set to true (backup=incremental) is not a mandatory condition for the 
disk to be a part of an incremental backup.

It is now kept for backward compatibility purposes and can be used mainly by backup applications to mark the disk they want to backup
and filter those disks according to that field. 

There is no point in persisting this field to a template created from a VM.


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