Itamar, I concur with you.
I am aware of the dangers here (I edited metadata once already to test recovering a storage domain in a test setup).
It took me a few tries and looking through the code that generate and manipulates that data to get it right.
However perhaps as a feature request it would be prudent to allow for the ability to choose or change which domain is the master without taking down all the other domains. If you have a-lot of domains this really becomes problematic to play musical chairs with the domains to get the one you want to be master elected. This also requires you to take down VM's which makes it even more problematic. Can we get a "make this domain the master" feature added to the UI/Cli?
-DHC
On 11/01/2012 03:01 AM, Dead Horse wrote:i heartly suggest to not try and mess with that on your own.
This is good info. Given that the metadata can be edited is there a way
to redesignate which storage domain should be the master? I have run
into a couple of times in which for various reasons the master domain
could not be reached and another storage domain was elected as master.
Is there a way to force an election or edit the metadata to redesignate
the original master domain back "as master" again?
you can move other storage domains to maint, to force engine to reconstruct the master on another domain.
(again, do *not* do it on your own via metadata)
<mailto:iheim@redhat.com>> wrote:From: "Itamar Heim" <iheim@redhat.com <mailto:iheim@redhat.com>>
On 10/31/2012 07:36 PM, Simon Grinberg wrote:
----- Original Message -----
To: "Michael Ayers" <ayersmj@redhat.com
<mailto:ayersmj@redhat.com>>
Cc: users@ovirt.org <mailto:users@ovirt.org>------------------------------__--------------------
Sent: Tuesday, October 30, 2012 10:57:52 PM
Subject: Re: [Users] Documentation: Storage Domain
conversion from Data Domain to Export Domain
On 10/30/2012 09:29 PM, Michael Ayers wrote:
Hey All,
I ran into this issue myself where I needed to convert a
data
domain to
an export domain in order to recover virtual guests from a
corrupted
ovirt/rhevm instance into a new ovirt/rhevm instance.
This wasn’t
documented anywhere that I saw but with the help of
Itamar Heim and
an
well timed email to the list from Igor Lvovsky last
night I was
able to
do this and wanted to send to the list a documented
procedure for
how to
modify the metadata of the data domain prior to import
as an export
domain. This procedure works for both RHEV-M and Ovirt.
Let me
know if
you have any questions.
glad it worked.
Will this work if the recovered storage domain was not the master?
no. only for nfs storage domain, only if it was master.
care to wikify for others?
thanks,
Itamar
Original Data Domain Metadata File
POOL_DOMAINS=dd8bc200-6e28-__4185-bfe0-f0affb94f283:Active,__ddefdf6c-ef68-419c-9f72-__76d27bf7d788:Active,66b3b243-__6cc6-465f-b130-6f2cd0b70514:__Active
CLASS=Data
DESCRIPTION=vm-storage
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
LOCKPOLICY=
LOCKRENEWALINTERVALSEC=5
MASTER_VERSION=2
POOL_DESCRIPTION=MyPool
POOL_SPM_ID=2
POOL_SPM_LVER=17
POOL_UUID=a207f052-f4bf-44a3-__b637-c6d2020a7c41
REMOTE_PATH=nfsserver:/ovirt/__vm-storage
ROLE=Master
SDUUID=66b3b243-6cc6-465f-__b130-6f2cd0b70514
TYPE=NFS
VERSION=0
_SHA_CKSUM=__009fa538321ac56749669127f43cc7__54aa59d398------------------------------__--------------------
Diff between Original DD Metadata File and ED Metadata File
-POOL_DOMAINS=dd8bc200-6e28-__4185-bfe0-f0affb94f283:Active,__ddefdf6c-ef68-419c-9f72-__76d27bf7d788:Active,66b3b243-__6cc6-465f-b130-6f2cd0b70514:__Active
--- metadata-data-storage 2012-10-30
12:24:52.484006958 -0700
+++ metadata-exp-storage 2012-10-30
12:14:59.043807789 -0700
@@ -1,5 +1,5 @@
-CLASS=Data
-DESCRIPTION=vm-storage
+CLASS=Backup
+DESCRIPTION=export-storage
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
@@ -7,13 +7,12 @@
LOCKRENEWALINTERVALSEC=5
MASTER_VERSION=2
POOL_DESCRIPTION=MyPool
+POOL_DOMAINS=
POOL_SPM_ID=2
POOL_SPM_LVER=17
-POOL_UUID=a207f052-f4bf-44a3-__b637-c6d2020a7c41
-REMOTE_PATH=nfsserver:/ovirt/__vm-storage
-ROLE=Master
+POOL_UUID=
+REMOTE_PATH=nfsserver:/ovirt/__export-storage
+ROLE=Regular
SDUUID=66b3b243-6cc6-465f-__b130-6f2cd0b70514
TYPE=NFS
VERSION=0
-_SHA_CKSUM=__009fa538321ac56749669127f43cc7__54aa59d398
Thanks,
Michael
------------------------------__------- <mailto:ayersmj@redhat.com <mailto:ayersmj@redhat.com>>
w: www.redhat.com <http://www.redhat.com>
<http://www.redhat.com/>
_________________________________________________
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
_________________________________________________
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
_________________________________________________
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>