Hi Michael, The reason why VMs have to be shut down is because the storage model has changed quite a bit in this last version, and we couldn't come up with a migration process that felt solid enough for any deployment.
But, since you said you are ready for lots of manual work, let's try this: First, edit /usr/lib/one/ruby/onedb/3.3.0_to_3.3.80.rb and comment out lines 35 to 60 [1] to disable the VM status check. Then upgrade the opennebula DB with the onedb command [2] Before you start opennebula again, you need to adapt the previous VM storage directories to the new 3.4 hierarchy. Assuming you don't have VM_DIR nor DATASTORE_LOCATION defined in oned.conf, this is how the VM directories look in both versions: 3.2: /var/lib/one/<vm_id>/images/disk.i /var/lib/images/abcde 3.4: /var/lib/one/datastores/0/<vm_id>/disk.i /var/lib/one/datastores/1/abcde So what you need to do in the front-end *and each host* is to individually link each existing VM dir: ln -s /var/lib/one/<vm_id>/images /var/lib/one/datastores/0/<vm_id> Let me stress that this must be done in all the hosts. Please take into account that this is just the basic idea, and that *we haven't tested this*. You may run into problems depending on your infrastructure configuration. For instance, if you were using the tm_shared drivers, VMs containing persistent Images will have links like this one: /var/lib/one/7/images/disk.1 -> /var/lib/images/qwerty If you move the image files to their new destination in /var/lib/one/datastores/1, like the documentation says, you will break those VM disk links. Another problem that may be important to you is that VMs over which you executed saveas [3] won't be able to save the changes back to the locked Image once the VM is shut down. In the best scenario, you will find the files inside /var/lib/one/<vm_id>/images/, but I'm not sure about this, you may lose your changes... You can locate these VMs looking for VM/DISK/SAVE_AS, and the Images all have "-" as the value of IMAGE/SOURCE. As I said, this is not a tested or recommended procedure. Good luck, Carlos [1] http://dev.opennebula.org/projects/opennebula/repository/revisions/one-3.4/entry/src/onedb/3.3.0_to_3.3.80.rb [2] http://opennebula.org/documentation:rel3.4:upgrade [3] http://opennebula.org/documentation:archives:rel3.2:img_guide#save_changes -- Carlos Martín, MSc Project Engineer OpenNebula - The Open-source Solution for Data Center Virtualization www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmar...@opennebula.org> On Thu, Apr 12, 2012 at 2:41 PM, Michael Kutzner <michael.kutz...@virtion.de > wrote: > Hello, > > first of all congratulations to the final 3.4 and many thanx for the hard > work! > > I just wanted to upgrade to 3.4 and started reading. > I noticed reading the upgrade guide that all active VMs have to be shut > down. > > Is there any chance to upgrade without powering down all VMs? Even with > lots of > manual work? > > > Many thanx, > Michael > > > _______________________________________________ > Users mailing list > Users@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
