Bug 1323462 - Local export storage domain metadata states Version 3 instead of Version 0, making it impossible to re-attach.
Summary: Local export storage domain metadata states Version 3 instead of Version 0, m...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
low
low with 1 vote
Target Milestone: ovirt-3.6.6
: 3.6.6
Assignee: Allon Mureinik
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-03 09:27 UTC by Vered Volansky
Modified: 2016-05-30 10:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-30 10:52:33 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-3.6.z+
rule-engine: planning_ack+
amureini: devel_ack+
acanan: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 55836 0 master MERGED core: Don't overwrite local domain's format 2016-04-10 10:03:56 UTC
oVirt gerrit 56088 0 ovirt-engine-3.6 MERGED core: Don't overwrite local domain's format 2016-04-14 09:25:44 UTC

Description Vered Volansky 2016-04-03 09:27:45 UTC
Description of problem:
When an export storage domain is used on a local device, the metadata consists of version 3, where it should be version 0.
This causes later usage errors with this export domain.
When later trying to import this domain as a whole, an error occurs, saying V3 is not supported:
----------------------------------------------------------------
"Error while executing action: Cannot add Storage. Storage format V3 is not supported on the selected host version."
----------------------------------------------------------------
The metadata issue is the source of this error.


Version-Release number of selected component (if applicable):
ovirt 3.5

How reproducible:
100%

Steps to Reproduce:
1. Create a local export domain
2. Check the metadata in images/<image_id>/dom_md/metadata


Actual results:
metadata Version is 3

Expected results:
metadata Version is 0

Additional info:
This bug was always there, but was first noticed by a 3.5.0 system user.
It was reproduces on 4.0 .

Work around:
Change the metadata version to 0.
Note that checksum might cause issues, if so have a look at:
http://lists.ovirt.org/pipermail/users/2012-April/007149.html

Comment 1 Sven Kieske 2016-04-11 13:59:38 UTC
can you backport this to 3.6.5 (not yet released)?

afaik this is a regression from 3.5/3.4, isn't it?

kind regards

Sven

Comment 2 Allon Mureinik 2016-04-13 15:19:19 UTC
(In reply to Sven Kieske from comment #1)
> can you backport this to 3.6.5 (not yet released)?
> 
> afaik this is a regression from 3.5/3.4, isn't it?

3.5 presents the same problem (see Vered's original comment), and I don't recall if we allowed local ISO domains in 3.4.
I don't want to add noise to the 3.6.5 release so close to its due date, especially given the facts that the bug has been there for a pretty long times and that there's a relatively easy work-around (see Vered's opening comment on the BZ).
But there's no reason to have it in 3.6.6

Comment 3 Elad 2016-05-02 08:30:07 UTC
Local export domain metadata version is 0:


[root@blond-vdsh dom_md]# cat metadata
CLASS=Backup
DESCRIPTION=local-export
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
LOCKPOLICY=
LOCKRENEWALINTERVALSEC=5
POOL_UUID=
REMOTE_PATH=/mnt/lo/2
ROLE=Regular
SDUUID=11b37260-382c-4413-b3f1-35bdcff0859a
TYPE=LOCALFS
VERSION=0
_SHA_CKSUM=6538428e2c40f4111ecf491287c5f110951ab166

Tested against 3.6.3-0.1 where local export domain metadata is 3.

Used:
rhevm-3.6.6-0.1.el6.noarch
vdsm-4.17.27-0.el7ev.noarch


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