Bug 1793481
| Summary: | Able to set 'enable incremental backup' for raw disks | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Eyal Shenitzky <eshenitz> |
| Component: | BLL.Storage | Assignee: | Eyal Shenitzky <eshenitz> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ilan Zuckerman <izuckerm> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.4.0 | CC: | bugs, rdlugyhe, sgoodman, tnisan |
| Target Milestone: | ovirt-4.4.0 | Flags: | pm-rhel:
ovirt-4.4+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.4.0 gitb5b5c99ca2f | Doc Type: | Bug Fix |
| Doc Text: |
Before this update, you could enable a raw format disk for incremental backup from the Administration Portal or using the REST API, but because incremental backup does not support raw format disks, the backup failed.
With this update, you can only enable incremental backup for QCOW2 format disks, preventing inclusion of raw format disks.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-20 20:01:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Eyal Shenitzky
2020-01-21 12:59:52 UTC
Verified both with API and UI. Actual result: 'enable incremental backup' is grayed out for raw-preallocated disk API returns "Cannot edit Virtual Disk. Incremental backup is not supported for RAW format disks." Eyal, The doc text is missing some info. Please write it in the following form: "Before this update, <X problem> caused <Y situation> (OPTIONAL: under the following <Z conditions>). With this update, <fix> resolves the issue (OPTIONAL: and <agent> can <perform operation> successfully)." Example doc text: “Before this update, the loopback device for Cinder iSCSI/LVM backend was not recreated after a system restart, which prevented the cinder-volume service from restarting. With this update, a systemd service recreates the loopback device and the Cinder iSCSI/LVM backend persists after a restart.” I really just need to understand what happened when you enabled an existing raw disk for incremental backup: Before this update, you could enable existing RAW disks in the Administration Portal or with the REST API, which caused ???. With this update, you cannot enable incremental backup for an existing raw disk. (In reply to Steve Goodman from comment #3) > I really just need to understand what happened when you enabled an existing > raw disk for incremental backup: > > > Before this update, you could enable existing RAW disks in the > Administration Portal or with the REST API, which caused ???. > > With this update, you cannot enable incremental backup for an existing raw > disk. Before this change, RAW disks was able to set as 'incremental backup enabled', now the following behavior applied: Create a new disk: from the UI: The user has the option to select if the disk will be preallocated or thin-provisioned and according to the user selection and the storage type that the disk is based on the format of the disk determine (raw/sparse). after the change, if the user selects to create an 'Incremental backup enable' disk, the disk can still be preallocated or thin-provisioned but the format will always be sparse. from the REST-API: The user can create any disk he desired but in order to create a disk that supports 'incremental backup enabled' the user cannot select 'raw' as the disk format, only cow. Update an existing disk: from the UI / REST-API: If the disk format is 'raw' then the user will not be able to set the disk as 'incremental backup enabled' (in order to allow the user to perform that action, the user can create a snapshot for the VM then the disk format will be changed to sparse) This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 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. |