[ovirt-users] Storage domain not in pool issue

[VONDRA Alain]

Hi Adam,
Thanks a lot for your solution, I understand the way.
I will try it the next week, I'll wait for the return of Maor on 12th, to know his advice.
Kind regards
Alain





Alain VONDRA
Chargé d'exploitation des Systèmes d'Information
Direction Administrative et Financière
+33 1 44 39 77 76
UNICEF France
3 rue Duguay Trouin  75006 PARIS
www.unicef.fr




-----Message d'origine-----
De : Adam Litke [mailto:alitke at redhat.com]
Envoyé : vendredi 10 avril 2015 17:56
À : VONDRA Alain
Cc : users at ovirt.org
Objet : Re: [ovirt-users] Storage domain not in pool issue

On 10/04/15 08:46 +0000, VONDRA Alain wrote:
>Hi Adam,
>Ok, if it's a safe solution, I can try it.
>Can you give me the commands to do the job, I am not so familiar with LVM.

Here is a start.  This will help you scrape off your VM disks into files.  I don't have time to write up the process of importing them back into oVirt but you'll likely have to use virt-manager to create a libvirt VM using the disks you've extracted and then use virt-v2v to import it into an oVirt storage domain.  This process will leave your storage domain in-tact so it's safe and if someone comes up with an easier solution you can try that later.

0. Place one vdsm host into maintenance mode

1. (ENGINE HOST) Determine which imageIDs correspond to which VMs in your storage domain

psql -U <dbUser> <dbName> -c "select storage_id, image_group_id, vm_names from all_disks where storage_id = 'd7b9d7cc-f7d6-43c7-ae13-e720951657c9';"

2. (VDSM HOST) Connect to the storage

sudo vdsClient -s 0 connectStorageServer 3 <old SPUUID> \
         id=`uuidgen`,connection=<iSCSI_IP>,iqn=<iqn>,tpgt=<tpgt>,port=3260,user=,password=

3. (VDSM HOST) Wait for connection to complete by checking for your domain with the command:

sudo vdsClient -s 0 getStorageDomainInfo
d7b9d7cc-f7d6-43c7-ae13-e720951657c9

4. (VDSM HOST) Activate all LVs for the storage domain

sudo lvm lvchange --config 'global {use_lvmetad=0}' -aay
d7b9d7cc-f7d6-43c7-ae13-e720951657c9

... Repeat the following steps for each image you want to recover ...

5. (VDSM HOST) Get the list of volumes in the image

sudo vdsClient -s 0 getVolumesList
d7b9d7cc-f7d6-43c7-ae13-e720951657c9 <old-SP> <imageID from step 1>

6. (VDSM HOST) Determine the LEAF volume (if the image has only ony volume, it is the leaf)

sudo vdsClient 0 getVolumeInfo d7b9d7cc-f7d6-43c7-ae13-e720951657c9
<old-SP> <imageID> <volumeID>

Look for 'voltype = LEAF'

7. (VDSM HOST) Copy the volume to a new file

sudo qemu-img convert -p -O raw
/dev/d7b9d7cc-f7d6-43c7-ae13-e720951657c9/<volID> <volID>.new





>I am right with you, and I don't understand why nobody else from your colleagues doesn't suggest anything...
>It's weird.
>Anyway thanks for your help.
>Regards
>Alain
>
>
>
>Alain VONDRA
>Chargé d'exploitation des Systèmes d'Information Direction
>Administrative et Financière
>+33 1 44 39 77 76
>UNICEF France
>3 rue Duguay Trouin  75006 PARIS
>www.unicef.fr
>
>
>
>
>-----Message d'origine-----
>De : Adam Litke [mailto:alitke at redhat.com] Envoyé : jeudi 9 avril 2015
>19:35 À : VONDRA Alain Cc : users at ovirt.org Objet : Re: [ovirt-users]
>Storage domain not in pool issue
>
>On 09/04/15 14:16 +0000, VONDRA Alain wrote:
>>Hi,
>>What do you about my last email, do you have a non destructive option to solve my problem ?
>
>The approach I suggest would leave the original data on the broken storage domain so it's non-destructive.  That's really all I am able to offer as a path forward.  I think we've given others ample time to respond.
>
>--
>Adam Litke

--
Adam Litke