Anaconda and Kickstart are dangerous in FC environments and have been known to wipe all kinds of data if zoning wasn't properly done prior to os deployment to new hosts.
Nothing to do with oVirt, it's a common mistake people make at least once before they step on this specific rake.
In a traditional installation of an ovirt host, it seems that provisionning the OS is the first step before talking about vdsm. I didn't go further, the problem is that this host saw the production LUN and the kickstart took all the lun into the same VG with a XFS format.
Yes it is an error from myself for not having dissociated the lun.
Yes it is an error from myself for not having taken care of having snapshot lun level backup.
But now what should I do?
My idea was to use pvreduce to unlabel the LUN, and then using the /etc/lvm/backup/lun for recovering physical volume metadata on that lun (http://www.tldp.org/HOWTO/LVM-HOWTO/recovermetadata.html)
Le 21/06/2015 12:02, mots a écrit :
Let me get this straight:
You added a new host and instead of letting VDSM manage the VM storage you added it manually, completely independent from oVirt, during an unattended installation of the host OS? In a production environment?
Why?
-----Ursprüngliche Nachricht-----
Von:Nathanaël Blanchet <blanchet@abes.fr>
Gesendet: Fre 19 Juni 2015 14:09
An: users@ovirt.org
Betreff: [ovirt-users] disaster recovery
Hello all,
Here is what can happen as a nightmare for a sysadmin:
I installed a new host to my pool of pre existing ovirt hosts with a
kickstart file and a default partitionning. I used to do this with vms
that usually get one local disk.
But..
This time this host was attached to several existing ovirt (production)
lun and anaconda gathered all existing disk (local and lun) into the
same VG (lv_home) et formatted them with XFS....
In the webadmin, the domain storage became unvailaible, vms were still
up (thankgoodness), but it was impossible to interact with them. If I
stopped them, it was impossible to reboot them. If I launch lvs command,
some hosts can still see the ovirt LV, but other see only the lv_home
while /dev/[idofvms] are still present.
So it was my chance that vms were still present, and I began to export
them with a tar at file system level so as to import them in a new
domain storage.
It seems that data are still present because the vms are still running.
So my question is really : instead of this difficult export step, is
there a way to recover the initial format of the ovirt lun so as to make
the lvm index come back on the disk?
Any help or disaster experience would be much appreciated.
--
Nathanaël Blanchet
Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet@abes.fr
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users