----- Original Message -----
> From: "Boudewijn Ector" <boudew...@boudewijnector.nl>
> To: "Liron Aravot" <lara...@redhat.com>
> Cc: "Jason Brooks" <jbro...@redhat.com>, users@ovirt.org
> Sent: Saturday, March 15, 2014 5:01:55 PM
> Subject: Re: [Users] Reimporting storage domains after reinstalling ovirt
> 
> On 11-03-14 16:39, Liron Aravot wrote:
> >
> > ----- Original Message -----
> >> From: "Boudewijn Ector" <boudew...@boudewijnector.nl>
> >> To: "Jason Brooks" <jbro...@redhat.com>
> >> Cc: users@ovirt.org
> >> Sent: Tuesday, March 11, 2014 1:32:00 AM
> >> Subject: Re: [Users] Reimporting storage domains after reinstalling ovirt
> >>
> >>
> >>> Some people have reported success creating an image of the desired
> >>> size, then noting the name of this new image, and copying the old
> >>> image into the place of the new one, with the new name. Something
> >>> like that might work, but I don't have first-hand experience w/
> >>> it.
> >>>
> >>> Jason
> >> Hi Jason,
> >>
> >>
> >> Due to lack of viable alternative, I've decided to go and try this
> >> approach. I just had a look at my datafiles:
> >>
> >> - these are either 8gb (OS) or 250gb (LVM images)
> >> - can't mount those directly in my host OS (tried because of the next
> >> point)
> >> - I don't know to what VM this image/VM belongs . They're all quite
> >> the same (basic debian install), so determining it just by running
> >> strings etc on those will not be easy
> >> - I can't import the old VMs from the old storage. If I create new
> >> images and dd the old information into those new images the metadata
> >> will not be copied too.
> >>
> >> So the only option is not reusing the VM's  but creating completely
> >> new ones and determining which disk images are required for these VMs.
> >> Then creating the new image structure and dd'ing the corresponding
> >> images from the old VMs into the new ones. In order to do so I need to
> >> know what data belongs to what VM.
> >> Is there a trick for doing this?
> >>
> >> I still do have the database from the old ovirt machine, this might
> >> save me. Will have a look into that one tomorrow.
> >>
> >> Cheers,
> >>
> >> Boudewijn
> > Hi Boudewijn,
> > So we can proceed and recover your data i'd like to know -
> > 1. can you use the db backup? will you lose any important data if you chose
> > to use it?
> > 2, did you have snapshots for your vm?
> >
> > please answer so we can proceed with it, we can find methods for restoring
> > without having to perform images copy (and to restore with copying) - but
> > each way has it's implications.
> > thanks,
> > Liron.
> >
> Hi Liron,
> 
> 
> 
> Have you already been able to look at my reply on the list? It would be
> great for me to be able to make some decent progress this weekend.
> 
> Cheers,
> 
> Boudewijn

Hi Boudewijn,
if you have db backup and you won't lose any data using it - it would be the 
simplest approach.

Please read carefully the following options and keep backup before attempting 
any of it -
for vm's that you don't have space issue with - you can try to previously 
suggested approach, but it'll obviously take longer as it requires copying of 
the data.

Option A -
*doesn't require copying the disks
*if your vms had snapshots involving disks - it won't work currently.

let's try to restore a specific vm and continue from there - i'm adding here 
info - if needed i'll test it on my own deployment.
A. first of all, let's get the disks attached to some vm : some options to do 
that.
*under the webadmin ui, select a vm listed under the "export" domain, there 
should be a disks tab indicating what disks are attached to the vm - check if 
you can see the disk id's there.
B. query the storage domain content using rest-api - afaik we don't return that 
info from there. so let's skip that option.
1. under the storage domain storage directory (storage) enter the /vms 
directory - you should see bunch of OVF files there - that's a file containing 
a vm configuration.
2. open one specific ovf file - that's the vm that we'll attempt to restore - 
the ovf file is a file containing the vm configuration
*within the ovf file look for the following string: "diskId" and copy those ids 
aside, these should be the vm attached disks.
*copy the vm disk from the other storage domain, edit the metadata accordingly 
to have the proper storage domain id listed
*try to import the disks using the method specified here:  
https://bugzilla.redhat.com/show_bug.cgi?id=886133
*after this, you should see the disks as "floating", then you can add the vm 
using the OVF file we discussed in stage 2 using the method specified here:
http://gerrit.ovirt.org/#/c/15894/


Option B -
*Replace the images data files with blank files
*Initiate Import for the vm, should be really quick obviously.
*As soon as the import starts, you can either:
1. let the import be done and replace the data, not that in that case the info 
saved in the engine db won't be correct (for example, the actual image 
size..etc)
2. after the tasks for importing are created (you'll see that in the engine 
log), turn the engine down immediately (immediately means within few seconds) 
and after the copy tasks completes on the host replace the data files and then 
start the engine - so that when the engine will start it'll update the db 
information according to the updated data files.


> 
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to