We have an production OpenNebula 4.12 with lots of VMs. Persistent and non-persistent images.
We have built a NEW OpenNew OpenNebula 5.2 ecosystem on a different hardware group. (different Hypervisors, Storage, network)
Is there a process for passing (copying via sneaker net or otherwise) VMs (persistent and non-persistent) between two totally different OpenNebula ecosystems?
Ideally we would like to SCP the images (and possibly XML) between from the old data store areas to the new datastore area and then have the new OpenNebula “import” them into the new ecosystem.
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.
Sorry for the delay in getting back to you on this.
Thanks for the info you have provided. As you suggested this plugin is not really applicable as it seems to really be for a system that needs to burst to an identified and linked remote system.
In our case, the two systems reside on two isolated LANs taht do not communicate.
So we must use some type of sneaker net to move the IMG and associated template to the new 5.2 system.
I imagine that there are others that have faced similar dilemmas and it seems there must be a way to manually copy an image and make it play on a different system.
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?
best
Jojo
Hi,
I just had to export all my onetemplates to textfiles, so I could easily import them in a fresh opennebula installation. this is what I came up with:
onetemplate list --csv | tail -n+2 | cut -d"," -f4 | while read i ; do onetemplate show "$i" | sed '1,/TEMPLATE CONTENTS/d'> "$i.tmpl" ; done
maybe it gives you some ideas for you vm export/import project
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”
for bigger vms and long distances that’s probably not an option.