Bug 1317850

Summary:

make QCOW2_COMPAT configurable

Product:

[oVirt] vdsm

Reporter:

Pavel Gashev <pax>

Component:

General

Assignee:

Nir Soffer <nsoffer>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Raz Tamir <ratamir>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

4.17.23

CC:

amureini, bugs, mgoldboi, michal.skrivanek, nsoffer, pax, tnisan, ylavi

Target Milestone:

ovirt-3.6.7

Flags:

rule-engine: ovirt-3.6.z+
ylavi: planning_ack+
tnisan: devel_ack+
acanan: testing_ack+

Target Release:

4.17.31

Hardware:

Unspecified

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2016-07-04 12:31:29 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:

Attachments:

Description	Flags
the patch	none

Description Pavel Gashev 2016-03-15 11:09:35 UTC

Created attachment 1136544 [details]
the patch

It's worth to make QCOW2 compatibility version configurable. It would allow to early adopt compat=1.1 in el7 environments.

https://www.mail-archive.com/users@ovirt.org/msg31469.html

Please find attached the patch.

Comment 1 Nir Soffer 2016-03-15 13:08:12 UTC

Thanks Pavel!

I applied to patch to master and uploaded it to gerrit for you, can you check
that the patch in gerrit?
https://gerrit.ovirt.org/54759

Comment 2 Red Hat Bugzilla Rules Engine 2016-03-15 13:25:58 UTC

Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.

Comment 3 Nir Soffer 2016-03-15 13:38:03 UTC

Tal, can we add this to 3.6.5?

Comment 4 Tal Nisan 2016-03-15 14:02:18 UTC

I don't see any reason why not if as a VDSM maintainer you don't see a risk in doing that, setting target accordingly

Comment 5 Allon Mureinik 2016-03-16 10:46:56 UTC

Note that once you have an image in compat level of 1.1 it may never be used with and old EL6 host.
Are we SURE we want to allow that?

Comment 6 Yaniv Lavi 2016-03-16 16:13:14 UTC

I don't have problems with allowing config as long as the default remains as the current one.

Comment 7 Mike McCune 2016-03-28 23:14:23 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 8 Allon Mureinik 2016-04-21 12:44:37 UTC

Nir, this bug is in MODIFIED for 3.6.7, but has patches on the master branch only.

If you are planning to backport them, please set the status to POST.
If you aren't, please set the target milestone to ovirt-4.0.0 and fix the flags accordingly.

Comment 9 Nir Soffer 2016-04-21 15:14:55 UTC

(In reply to Allon Mureinik from comment #8)
> Nir, this bug is in MODIFIED for 3.6.7, but has patches on the master branch
> only.
> 
> If you are planning to backport them, please set the status to POST.
> If you aren't, please set the target milestone to ovirt-4.0.0 and fix the
> flags accordingly.

I'll backport the patches, keeping the target.

Comment 10 Nir Soffer 2016-04-23 19:12:30 UTC

How to test:

1. By default there is no change in system behavior, and we still create
   qcow2 disks using compat 0.10. We can do general sanity tests for 
   thin provisioning disks.
   To check qcow version you can run qemu-img info /path/to/volume

   Example configuration:
   [irs]
   qcow2_compat = 0.10

2. When setting irs:qcow2_compat to 1.1, all new volumes will use qcow2 compat
   1.1 (e.g. new disk, snapshot).
   We can do general sanity tests for thin provisioned disks with this setting.

   Example configuration:
   [irs]
   qcow2_compat = 1.1

3. When setting irs:qcow2_compat to unsupported value (e.g 1.2), creating
   new volumes (e.g. new disk, snapshot) will fail with InvalidConfiguration
   exception in vdsm log.

   Example configuration:
   [irs]
   qcow2_compat = 1.2

Comment 11 Michal Skrivanek 2016-05-09 11:30:07 UTC

(In reply to Allon Mureinik from comment #5)
> Note that once you have an image in compat level of 1.1 it may never be used
> with and old EL6 host.
> Are we SURE we want to allow that?

if we keep this for 4.0 (the current state) - how do we expect to move away from it? Don't we want to switch to 1.1 in 4.0? We maintain compatibility with 3.6 only which is RHEL 7.2 only so it should be ok, right?

Comment 12 Nir Soffer 2016-05-09 13:14:16 UTC

(In reply to Michal Skrivanek from comment #11)
> (In reply to Allon Mureinik from comment #5)
> > Note that once you have an image in compat level of 1.1 it may never be used
> > with and old EL6 host.
> > Are we SURE we want to allow that?
> 
> if we keep this for 4.0 (the current state) - how do we expect to move away
> from it? Don't we want to switch to 1.1 in 4.0? We maintain compatibility
> with 3.6 only which is RHEL 7.2 only so it should be ok, right?

I don't think we will change anything in 4.0, as we did not start to work on this
yet.

When we move to qcow2 compat 1.1, we will have a new storage domain version:

- version 3: qcow2 compat=0.10
- version 4: qcow2 compat=1.1

3.6 system would not be able to use new storage domain format.

Comment 13 Nir Soffer 2016-05-15 12:47:14 UTC

Added a new patch adding missing validation in the merged patch, moving back
to post.

Comment 14 Raz Tamir 2016-06-15 10:12:52 UTC

Verified on ovirt-engine-4.0.0.4-0.1.el7ev.noarch using the steps in comment #10