Problem when re-attaching domain - some vms disapered

Hello all, Due to a maintenance in our glusterfs infrastructure, I moved the domain data to a different location (but before I took care of shutdown all machines and detach it from the manager). After the upgrade, I created a new glusterfs volume to hold the vms and attached the old one, using NFS, in order to move the vms to this new storage location. Out of 38 machines, 2 of them didn't appear in the list to be imported back. Analysing the storage I managed to find they volumes but Ovirt insists in not import them. I found an old thread that talks about a similar problem: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/MF5IUXURKIQZNNG... but their solution didn't help. Those VMs were imported from Virtualbox in the past. This is the meta file: cat 80f95e3e-f92b-497a-aec5-440ba5282682.meta CAP=53687091200 CTIME=1665328113 DESCRIPTION=generated by virt-v2v 1.42.0rhel_8,release_19.module+el8.6.0+998+252a5635 DISKTYPE=2 DOMAIN=1102600c-eee7-40cc-86b2-ee90b3c4df6b FORMAT=RAW GEN=0 IMAGE=00e13c7f-d0e9-4d5b-8862-a28f0b91acfe LEGALITY=LEGAL PUUID=00000000-0000-0000-0000-000000000000 TYPE=SPARSE VOLTYPE=INTERNAL EOF I could get the disk manually and import, but it has 2 snapshots (two other volumes in the same directory) which I don't know how to "merge" them into the original disk (if it's possible). tree 00e13c7f-d0e9-4d5b-8862-a28f0b91acfe 00e13c7f-d0e9-4d5b-8862-a28f0b91acfe ├── 2e698005-d7f0-4387-a9ce-9d1f14a7c18c ├── 2e698005-d7f0-4387-a9ce-9d1f14a7c18c.lease ├── 2e698005-d7f0-4387-a9ce-9d1f14a7c18c.meta ├── 618c5a68-3c34-42e1-b6cb-4d22f6a605f7 ├── 618c5a68-3c34-42e1-b6cb-4d22f6a605f7.lease ├── 618c5a68-3c34-42e1-b6cb-4d22f6a605f7.meta ├── 80f95e3e-f92b-497a-aec5-440ba5282682 ├── 80f95e3e-f92b-497a-aec5-440ba5282682.lease └── 80f95e3e-f92b-497a-aec5-440ba5282682.meta The Ovirt is 4.5.4 and the host Rocky 8, all updated to the latest version. On the vdsm.log, this is the only 2 lines related to this disk I could find. 2023-04-24 13:39:25,812-0300 INFO (jsonrpc/3) [vdsm.api] FINISH getImagesList return={'imageslist': ['d03f371f-0b86-4a06-b8e3-bbd602a81442', 'f1425fd4-fb4f-48ae-8df1-1bd44b026848', '9d52bfa9-d2dd-49c3-8a98-66cf950a7bcb', 'f7c69f63-c3a8-447c-baf2-751021fb7c26', 'bc76e648-e09d-448e-86f1-b3ae47509837', '00e13c7f-d0e9-4d5b-8862-a28f0b91acfe', '88b53eb4-9ca9-4162-9e91-f00b4f41f278', '0bd13065-cb21-4db3-9eb0-7582c65c4ca9', '06444eb3-52bf-48af-84fe-36baf1531853', '7ea966f8-72ed-421b-be71-e20b3dcc4e5a', '2e9dee7c-131b-427b-9e7a-33a49af7c6f0', 'e58171dc-5135-4462-b1f3-49d98785907e', 'f5d2e866-1d53-4243-8a6e-f5031c4be33d', 'ad5fe94a-4880-4dcf-af36-4a36ede9a6ab', '72a047f4-6546-4750-845f-ceb74c6503c8', '36d0ec3d-482b-4c90-a169-8b2b9abee158', '6e5afad2-5de0-463f-b04b-34b4828b7aa3', '565c2418-d43f-4138-8d31-50e8bd9c5c4e', '0d128f2c-3962-4f91-8231-a5772132d241', '0b9cbbc5-316c-453a-aab0-a3e6805796e9', 'b43bc279-000b-40dc-8c00-cc22b8caab5d', '6a401413-d2ae-4c14-b028-a7fc953d08f2', 'aa3b6e24-1b74-4890-897a-13f858844b3a', '20ae1e1f-fccd-40e8-a1b4-90339e6c7ca1', '8e9050ad-82a1-4a23-a461-5d1eca7c9d80', 'fc2e4d0b-c092-4e74-b69e-da5020ac396e', '4c5c3c74-307f-49a9-ae66-60dddfc1db67', 'd8463e92-5495-4e59-8d2f-bcfcdfa59987', '0342e096-cf34-4a8c-a9f6-36b13c3e39c3', 'f6714bec-37df-4aad-8b21-2ae146b0fa19', 'd4c77a6b-dfcf-424c-9025-cbc8795b2f46', 'f42cb81b-058b-4bd6-b55e-5b3ae3601ade', 'fe052d41-8e94-4145-8c8b-7fdf8d8adc37', '1fc4c7b8-d7c8-4c32-88ce-6cf5c9e65aa0', '3aef6a30-8757-4f65-b989-c1b40236f4cb', '2e9fc88d-e5c0-4a97-b590-481a1508c155', 'dcedf2e9-5e92-44bc-9113-5263dd0dda96', '393e02b4-5765-4ea5-8008-e7d3a3995794', 'b895f40b-17a2-4f08-9126-c25d8858601f', '1c9a3ff9-7434-4867-8880-7d11548aca53', 'fa64e6eb-7aad-4548-b944-1bc04b719256', 'f912af5e-9c51-45a6-8b01-6d9224c48893', '6611aba7-e201-4702-842a-4089deeb306d', '00098322-3ba9-4af9-9e6d-54cb07ec3d77', '666fd481-07e5-45ed-be2e-bd3cd78df7dc', '13eb4b21-2134-48ae-84b6-164d6a8141cc', '50c3d0b9-a850-487a-a213-fd9b87db91b3', '3573b171-2980-47a2-96c2-55d39fddda55', '9b3a156f-3cb4-485a-b357-f5c7ed1bb890']} from=::ffff:192.168.5.52,52296, flow_id=a2fe8beb-4f0a-4d71-bf08-3a0d0c3b6403, task_id=39d06e06-2b25-4a94-b3f7-15dc60a44164 (api:37) 2023-04-24 13:39:26,220-0300 INFO (jsonrpc/4) [vdsm.api] START getVolumesList(sdUUID='1102600c-eee7-40cc-86b2-ee90b3c4df6b', spUUID='f04dd188-b214-11ea-845b-00163e4ad29b', imgUUID='00e13c7f-d0e9-4d5b-8862-a28f0b91acfe') from=::ffff:192.168.5.52,52296, flow_id=a2fe8beb-4f0a-4d71-bf08-3a0d0c3b6403, task_id=387e8181-764b-47d7-aa4d-13abf66fd94b (api:31) Does anyone have an idea?? Thank you Best regards Ricardo

You could possibly create a new disk image if qemu recognizes the backing files. Check if qemu detects the backing files: #qemu-img info path/to/snapshot If it shows the previous snapshot or full disk image as "backing file", you can try to create a new image which inclused changes in snapshots: 1. Create a new image file that has same properties and size as original full disk image: #qemu-img create -f qcow2 -b full/disk/image/file new/disk/image 2. The following command should automatically detect backing files and merge them into the new image file: #qemu-img convert -U -p -O qcow2 -c new/disk/image new/image/with_no_backing_files Hope this helps.

Thank you Andreas. Exploring the data, I tried with the qemu-img convert and worked fine (before seen you message :-) ). Cheers
participants (2)
-
andreas_nikiforou@hotmail.com
-
Ricardo Alonso