Transfer of image data from ONE to the next ONE

Community Support
1

We’re trying to update our OpenNebula so that the NFS images could be reused. We have terabytes of images which use backing files, and we don’t want to recreate them.
I could reuse the NFS images, but OpenNebula doesn’t know about the new images at all, and I can’t register images with both SOURCE and PATH existing.
But a quick resolution seemed to be to just sqldump image_pool and then restore it on the new OpenNebula. This had minor implications… If I did it while I had the old one up and running, the data for STATE, VMS and RUNNING_VMS is wrong. But that’s something I could easily fix by 1) doing the dump after I shut down all VMs on the old ONE, or 2) run “sed” on the dump file and reset that data (basically doing the onedb update-body thing on all the images)

Then I created a template that uses this image…but this is where I hit a snag. The template keeps showing a red box for the disk when I try to instantiate it. If I go update it, I can select the disk just fine.
I can disable and enable the disk image itself from the images tab.

What’s preventing me from using that image within that template?

Versions of the related components and OS (frontend, hypervisors, VMs):

Steps to reproduce:

Current results:

Expected results:

2

Maybe the image is on STATE=ERROR. They go red on Sunstone like that. Alternatively try to instantiate the template with onetemplate instantiate <template_id> --disk <image_id>.

3

That works so that I can launch the VM. But I still can’t get rid of the red color in the template, and thus that it doesn’t work. Weird…

4

Can you reliably reproduce this ? If so, it would be nice if you can open a bug report.

5

Yes it is reproducible. I’ll spend some more time on this after I get things of my todo list and i’ll have a look at this. The update brought a lot on my plate to handle asap.
I could also point out that the other table “pool_control” also needs manual handling. The entry “image_pool” needs to be greater than the biggest ID number of the images I just imported from the other database. Otherwise adding new images will fail when stumbling upon an existing ID. I suppose there’s a reason why opennebula doesn’t just use auto_increment here.