Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1323462

Summary:	Local export storage domain metadata states Version 3 instead of Version 0, making it impossible to re-attach.
Product:	[oVirt] ovirt-engine	Reporter:	Vered Volansky <vered>
Component:	Backend.Core	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	low	Docs Contact:
Priority:	low
Version:	3.5.0	CC:	acanan, amureini, bugs, s.kieske, tnisan
Target Milestone:	ovirt-3.6.6	Flags:	rule-engine: ovirt-3.6.z+ rule-engine: planning_ack+ amureini: devel_ack+ acanan: testing_ack+
Target Release:	3.6.6
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-05-30 10:52:33 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 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