there is a new addon called addon-opennebula-hybrid. have a look into that. it kind of let’s you add a remote hypervisor and use it in your local cloud.
there is a video about it from this years conf. starts at around minute 20.
i am not really sure if this will help you with migrating your vms off your old hypervisors to the new cloud, really just a quick thought…
what always has worked for me in the past, no matter which virtualization or cloud platform, certainly is the manual way plus coding some kind of helper scripts.
i think i would start by trying to find a convinient way to read out the xml of the vms and bring in to your new cloud. script around onevm show -x (or maybe its even sufficient without the -x??) on the other side use scripted onetemplate create.
then for smaller vms, depending on how far your two clouds are away, use dd and netcat to copy your vms disk to the new cloud. well, i know this is a very basic explaination, but ask again if you really need to go the classic oldschool way for bigger vms and long distances that’s probably not an option.
what also could help you is a tool called virt-v2v, it can access vms that are running on libvirt + qemu-kvm hosts (which opennebula hypervisors are). this tool can transfer the vms definition (xml) plus the virtual disks to remote libvirt locations. just install it and read the manpage. it tells you exactely what it can do. it’s available on redhat/centos based systems but also on the newest ubuntu16.04
just some random thoughts about what helped me in the past to migrate from x to y virtualization solution
probably there are more convinient opennebula-like ways, i would also be interested in stuff like that. looking forward to this discussion.
Hi, you could use the image import function for your vms disks, like described here (first export/just copy all of them to some disk that you could literally carry to the site with the 5.2 installation):
what you still need would be a script that exports and imports your vm definitions.
and therefore I think that importing directly into the database is not the way to go!
i would write some script that is exporting all the vms definitions to “one template files” in text format.
so you would have one template file for each vm.
certainly you would have to add the correct names of the images (in the new 5.2 store) also to these template files.
on the new site you then would have to instantiate every template.
with some helper scripts this should be doable.
what do you think? still quite tedious right?
We are going to undeplo all VMs from old 4.2 opennebula. Then we are going to move the 4.x one.db to the 5.2. Then then upgrade the db, and then simpy synch the 4.2 datastore (0,1,2) to the new 5.2 storage.
I think the templates are in the one.db and hence the onedb upgrade will solve the template problem.
I am not sure if we need to old (remnant) deployment.xml files from the old version. But If so are they going to be compatible?
The next, even more important question, is “are the 4.x VM images compatible with 5.2?”
My hope is that one of the developers might see this thread and say “hey goofy, what are you thinkingg? this is not possible because it will break x, y and z!!” or better yet., they might say “the reason we did not chime in earlier is because this is such a no-brainer that we thought we would let you discover how-to on your own”