Hi Boudewijn, First of all, the wiki page you are referring to is a feature page that was never implemented. We are currently working on the same feature, this is the correct feature page: http://www.ovirt.org/Features/ImportStorageDomain . I will ask that the irrelevant page be removed to avoid any further confusion. Second, currently, the only way to import a domain is to create an export domain and import it. Can you get the old setup-up and create an export domain? If not, we'll try to help and work around this is issue, but this is going to be very complex, since this is not supported. Just to have a general understanding of your setup - your storage on the same machine as ovirt engine? I'm assuming you're using web-admin. What exactly are you doing there? We don't have the import option there as you mentioned, so I don't understand how you could import an SD that was not export. Adding the entry to /etc/exports is meaningless. Do you have the ovfs of the old VMs available? In the meantime checking for an easier solution than the above, will get back to you on that. Regards, Vered ----- Original Message -----

On 03/09/2014 06:04 PM, Boudewijn Ector wrote: hence the feature page you saw, to add this functionality (currently work in progress) change the domain into an export domain, attach it, and import the VMs from it (currently, you can only import an export domain) i think this thread has the relevant info: https://www.mail-archive.com/users@ovirt.org/msg04257.html

Interesting: i just tried readding it again (maybe rereading the storage domain takes a lot of time) but despite it not showing up in the storage domain list, ovirt's webadmin tells met the repo has already been added: Error while executing action: Cannot add Storage Connection. Storage connection already exists. Strange. Cheers, Boudewijn

On 03/10/2014 12:30 AM, Boudewijn Ector wrote: the bug is about a host with a cluster not associated with a DC. is your cluster associated with a DC?

On 10-03-14 07:48, Gadi Ickowicz wrote: Hi Gadi, My machine is indeed already in a DC, I missed that part of the bug completely yesterday night ;-). Regarding the storage connection: okay I'll have it removed. On the other hand, will readding it by hand (again) help me in getting my old VMs to work again? I really like ovirt, but having this amount of problems when reinstalling my hypervisor really spoils the party :(. Cheers, Boudewijn

On 10-03-14 16:55, Jason Brooks wrote: Hi Jason, Thanks! I'm going to try this after finishing my coffee! Can you explain to me *why* this will change the situation? I'd like to have a better understanding about the inner workings of ovirt. Cheers, Boudewijn

This is a multi-part message in MIME format. --------------090102060102070909090704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Guys, Thank you very much Jason, Itamar, Gadi! I'm almost there thanks to your help. My steps were: - remove the old storageconnection: $ curl -u "admin@internal:*****" -X DELETE https://192.168.1.44:443/api/storageconnections/5636a8c3-65b6-44a4-9ba4-e... -k I changed version 3 -> 0 in metadata file And did an import (export NFS): 192.168.1.44:/raid/ovirt-old/data Currently the box is importing the VMs from the old to the new repository. But, there's still a last challenge to overcome: I had this VM with about 2TB storage attached on both my storage domains (I had another one too). This poses two different problems: - I can't import the VM from the first storage domain, since not all disks did reside on this single storage domain. This error pops up (which is quite logical): Error while executing action: downloadbak: * Cannot import VM. VM's Image does not exist. Yeah I know I shouldn't have split the VMs resources over multiple storage domains... I won't make that mistake again. Is there a way to move these disks from the second "old domain" to the first "old domain" so the VM can be reimported? Furthermore, my storage machine has about 1.4TB free disk space left. While importing, a copy of a VM is being made... and this particular one is 2TB. So I'm going to run out of disk space while doing so; is there a way to move instead of copy a VM while importing it? Cheers (and thanks a lot for all the help, I really appreciate it!), Boudewijn --------------090102060102070909090704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Guys,<br> <br> <br> Thank you very much Jason, Itamar, Gadi! I'm almost there thanks to your help.<br> <br> My steps were:<br> <br> - remove the old storageconnection:<br> <br> $ curl  -u "admin@internal:*****" -X DELETE <a class="moz-txt-link-freetext" href="https://192.168.1.44:443/api/storageconnections/5636a8c3-65b6-44a4-9ba4-e598dc60a4e4">https://192.168.1.44:443/api/storageconnections/5636a8c3-65b6-44a4-9ba4-e598dc60a4e4</a> -k<br> <br> I changed version 3 -&gt; 0 in metadata file<br> <br> And did an import (export NFS):<br> 192.168.1.44:/raid/ovirt-old/data<br> <br> Currently the box is importing the VMs from the old to the new repository.<br> <br> But, there's still a last challenge to overcome:<br> <br> I had this VM with about 2TB storage attached on both my storage domains (I had another one too). This poses two different problems:<br> <br> - I can't import the VM from the first storage domain, since not all disks did reside on this single storage domain. This error pops up (which is  quite logical):<br> <br> <div class="GJJWYTYDJYB"> <div class="GJJWYTYDEVB GJJWYTYDKYB"> <div class="gwt-HTML">Error while executing action: <br> <br> downloadbak: <ul style="margin-top:0"> <li>Cannot import VM. VM's Image does not exist.</li> </ul> </div> </div> </div> Yeah I know I shouldn't have split the VMs resources over multiple storage domains... I won't make that mistake again. Is there a way to move these disks from the second "old domain" to the first "old domain" so the VM can be reimported?<br> <br> Furthermore, my storage machine has about 1.4TB free disk space left. While importing, a copy of a VM is being made... and this particular one is 2TB. So I'm going to run out of disk space while doing so; is there a way to move instead of copy a VM while importing it?<br> <br> <br> Cheers (and thanks a lot for all the help, I really appreciate it!),<br> <br> Boudewijn<br> </body> </html> --------------090102060102070909090704--

Hi Jason, Thanks, although that's quite an ugly option, although better than not being able to do it at all... I'll keep it in mind anyway if everything else fails. Well I was wondering: Can't I just copy those images and vm's from the second storage domain to the first and add those in the metadata? I might give that a shot tonight. Cheers, Boudewijn

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

----- Original Message ----- 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.

On 11-03-14 16:39, Liron Aravot wrote: 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 Guys, Thank you for the elaborate information. I'll try to restore the DB indeed and make sure all the mounts I previously (when creating the DB-dump) had will be there too. I also just had a look in my old DB, which I've just restored: engine=# select vm_name from vm_static; vm_name ----------------- Blank template mail nagios bacula debian-template jabber downloadbak vpn (9 rows) That's looking great. Actually the most important VMs to restore (the rest are re-created in about 2-3 hours so having to re-create those instead of restoring would be okayish): - bacula - downloadbak Problem is that both of those are the VMs with the most of the disks attached. Just had a look in the databasedump for the vm id's and found this: I created my dump using pg_dumpall > blah.sql and reimported using psql -f blah.sql . Despite this : Schema | Name | Type | Owner --------+-----------------------------------+-------+-------- public | action_version_map | table | engine public | ad_groups | table | engine public | async_tasks | table | engine public | async_tasks_entities | table | engine public | audit_log | table | engine public | base_disks | table | engine public | bookmarks | table | engine public | business_entity_snapshot | table | engine public | cluster_policies | table | engine public | cluster_policy_units | table | engine public | custom_actions | table | engine public | disk_image_dynamic | table | engine public | disk_lun_map | table | engine public | dwh_history_timekeeping | table | engine public | dwh_osinfo | table | engine public | event_map | table | engine That table doesn't exist at all... weird. I'm not a postgres guru so maybe there's some foo involved I haven't seen :). The mountpoints I created in my initial setup: Seems great too, I indeed created those. When restarting ovirt-engine I get in my logs: Also the webinterface stays blank. Okay that sounds like database permissions: [root@Xovirt-engine]# cat /etc/ovirt-engine/engine.conf.d/10-setup-database.conf ENGINE_DB_HOST="localhost" ENGINE_DB_PORT="5432" ENGINE_DB_USER="engine" ENGINE_DB_PASSWORD="********" ENGINE_DB_DATABASE="engine" ENGINE_DB_SECURED="False" ENGINE_DB_SECURED_VALIDATION="False" ENGINE_DB_DRIVER="org.postgresql.Driver" ENGINE_DB_URL="jdbc:postgresql://${ENGINE_DB_HOST}:${ENGINE_DB_PORT}/${ENGINE_DB_DATABASE}?sslfactory=org.postgresql.ssl.NonValidatingFactory" I tried to reset the database's password using this in the psql shell: alter user engine WITH password '********'; (the same password as above) Still authentication fails, but when I do this: psql -h localhost -p 5432 -U engine engine It works fine... O gosh more debugging ;). Any clue where I should have a look? I just tried copying the old /etc/ovirt* stuff over /etc/overt* so both configs and db are sync'ed again. To no avail. Thanks guys! Boudewijn

On 17-03-14 06:31, Gianluca Cecchi wrote: Okay I've finally found some time to fix my problems with the old storage domains. I reinstalled the box and it's running fine but I'd love to recover the old domain I used for downloading stuff. I just reread your email from march 16th and I'm going to try the thing you've suggested, so I hope you're still willing to help me :). In order to get the disks attached to a VM, I need to move them into a new import domain. How should I determine which files to get? There were multiple VMs in the directory, each having multiple LVM-based storage domains so I just had a look, I 'm only interested in images from "Downloadbak". I found: engine=# select image_guid,size,parentid,imagestatus,volume_type,volume_format,active from images order by parentid; image_guid | size | parentid | imagestatus | volume_type | volume_format | active --------------------------------------+--------------+--------------------------------------+-------------+-------------+---------------+-------- 1d304cb5-67bd-4e21-aa2c-2470c19af885 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t aca392f5-8395-46fe-9111-8a3c4812ff72 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 182ce48c-59d0-4883-8265-0269247d22e0 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t cadcce7f-53ff-4735-b5ff-4d8fd1991d51 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 2cd8d3dc-e92f-4be5-88fa-923076aba287 | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t 5e56a396-8deb-4c04-9897-0e4f6582abcc | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t 0ad131d7-2619-42a2-899f-d25c33969dc6 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t caecf666-302d-426c-8a32-65eda8d9e5df | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t 8633fb9b-9c08-406b-925e-7d5955912165 | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t b2c5d2d5-636c-408b-b52f-b7f5558c0f7f | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t e66b18a7-e2c5-4f6c-9884-03e5c7477e3d | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 988f90f6-a37d-4dfd-8477-70aa5d2db5b6 | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | f e1c098fe-4b5d-4728-81d0-7edfdd3d0ec8 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 179ad90d-ed46-467d-ad75-aea6e3ea115e | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 4d583a7a-8399-4299-9799-dec33913c20a | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 9e5be41b-c512-4f22-9d7c-81090d62dc31 | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t f613aa23-4831-4aba-806e-fb7dcdcd704d | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 76749503-4a8b-4e8f-a2e4-9d89e0de0d71 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t c46bb1c0-dad9-490c-95b4-b74b25b80129 | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 8b511fc2-4ec5-4c82-9faf-93da8490adc9 | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t 88a7d07b-b4a3-497d-b2e5-3e6ebc85d83e | 8589934592 | 00000000-0000-0000-0000-000000000000 | 1 | 1 | 5 | t 829348f3-0f63-4275-92e1-1e84681a422b | 268435456000 | 00000000-0000-0000-0000-000000000000 | 1 | 2 | 5 | t 38eee7d5-9fd1-44b0-876c-b24e4bc0085b | 8589934592 | 988f90f6-a37d-4dfd-8477-70aa5d2db5b6 | 1 | 2 | 4 | t 00000000-0000-0000-0000-000000000000 | 85899345920 | | 0 | 2 | 4 | t engine=# select * from base_disks where disk_alias like 'download%'; disk_id | disk_interface | wipe_after_delete | propagate_errors | disk_alias | disk_description | shareable | boot | sgio | alignment | last_alignment_scan --------------------------------------+----------------+-------------------+------------------+--------------------+------------------+-----------+------+------+-----------+--------------------- a33a673d-751f-4287-a655-e84dfcfcd005 | VirtIO | f | Off | downloadbak_Disk1 | test | f | t | | 0 | 5e28342e-2e90-491b-a6c3-49b2443092fd | VirtIO | f | Off | downloadbak_Disk2 | | f | f | | 0 | 907f3071-69eb-4167-8e34-22d3985f63cf | VirtIO | f | Off | downloadbak_Disk3 | | f | f | | 0 | 26628bb8-a057-4fab-af65-20258f083ab0 | VirtIO | f | Off | downloadbak_Disk4 | | f | f | | 0 | 666b1602-6979-4b17-a7fe-6524a1bf603b | VirtIO | f | Off | downloadbak_Disk5 | | f | f | | 0 | cf5371aa-2cbe-4edc-a876-2b503208b0e6 | VirtIO | f | Off | downloadbak_Disk6 | | f | f | | 0 | d718155e-eaf2-41e0-aebd-799a31af18bc | VirtIO | f | Off | downloadbak_Disk7 | | f | f | | 0 | 8616828d-e3f3-4e55-863f-387df2110ebc | VirtIO | f | Off | downloadbak_Disk8 | | f | f | | 0 | 40909eb8-be4c-4280-b9ef-51f3fa36340e | VirtIO | f | Off | downloadbak_Disk9 | | f | f | | 0 | 8483a1b6-4d79-4675-8433-eb03dcd5f53d | VirtIO | f | Off | downloadbak_Disk10 | | f | f | | 0 | eb32f782-7b29-4f54-bd3e-a736ae8c5476 | VirtIO | f | Off | downloadbak_Disk11 | | f | f | | 0 | 85d7448a-ad17-4a77-86a9-6a55c1baf1a6 | VirtIO | f | Off | downloadbak_Disk12 | | f | f | | 0 | b5a5411b-b234-4340-8338-1f2b860e4265 | VirtIO | f | Off | downloadbak_Disk13 | | f | f | | 0 | 6055a0a2-a6e9-4466-b0eb-3928c5c84d99 | VirtIO | f | Off | downloadbak_Disk14 | | f | f | | 0 | (14 rows) What's the best way of getting those attached to another VM? Moving them into an import repo? Cheers, Boudewijn