[ovirt-users] Storage domain not in pool issue

Adam Litke alitke at redhat.com
Fri Apr 10 11:56:16 EDT 2015


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


More information about the Users mailing list