This content has been marked as final. Show 9 replies
My previous experience migrating between releases wasn't very sucessful.
Once, migrating from 3.03 to 3.1.1 manager got lost. I had to re-import the pool. I didn't loose any VM's and I could use xm commands until manager got operational again.
I would create new installation and migrate vm's as soon you got your ENV stable.
I'm just in the midst of a failed 3.1.1 -> 3.2.1 uppgrade on my VM Manager. I mounted the upgrade ISO and ran the install/upgrade script. Everything looked OK to the user, but I couldn't log into the Manager GUI afterwards as the "ovmm start" hung. Checking through the logs I found over 9MB of Java/DB operation errors. Suffice it to say I have an SR open with Oracle about it, but it's slow going.
Can I ask, if I do a fresh install of VM Manager. and connect it to the pre-existing OracleDB OVS database, will I be able to not only rediscover all of my servers, pools, and guests, but also the local repositories on those VM Servers?
Sorry to hijack this thread, but to answer your question regarding "update Vs fresh install", thus far I'd say a fresh install seems more hopeful. Let us know how you get on, please.
we've upgraded our 3 environments (TEST, DEV, PROD) from 3.1.1 to 3.2.1. 3 managers 10 servers.
None of the upgrade went well and all three showed up different problems....
Fortunately the underlying XEN is robust and we've not lost anything and had no service interruption.
Upgrading the manager is OK (but 3.2.1 is no better than 3.1.1).
Upgrading servers was never OK. Every time after the upgrade, a server would show up with a warning and was unusable. The manager was unable to rediscover it and says " if the ip has changed delete and rediscover".
Then things are going crazy. Sometime you can delete the server and rediscover, sometimes not. We've tried various sequences but couldn't figure out a valid one :
We tried letting the manager doing the whole job (delete nfs exporst - unpresent repositories - remove from pool)
We've tried to do it manually (also because the manager did not always perform the whole job entirely. Namely, after deletion, you rediscover a server and he popups again into the pool even though he's supposed to have been removed.
What about "Release ownership"? Sometime it did the trick, sometime not.
Sometime you can't rediscover and can't add it to the pool either, because the manager says "the server is 3.1.1, older that 3.2.1"...
Once we did a fresh install of a server and the Manager was refusing to add it to the pool because it still believed his (outdated) database information instead of what the actual server was ; a fresh, clean, unowned, not clustered server.
Needless to say that the manager refused to delete it because it believed that that server was still using some resources, which was clearly and firmly a wrong assumption.
All I can say is good luck.
3.2.1 is as crappy as 3.1.1 was and you will probably have to do a clean installs of the Manager at the end (using the same uuid). Note that this is quite straightforward and in the process you can rediscover everything (Pool, networks, etc), you're only loosing VirtualDisk names.
Edited by: lolix on Apr 8, 2013 5:44 AM
3.2.1 is slightly better than 3.1.1 as it's now possible to delete a no-more-existing disk and then cleanup removed repository. All in all it worths the upgrade.
Yeah, your experience mirrors my own somewhat. Except, as I said, that I completely broke my Manager doing the upgrade, and it was the Servers which upgraded (via yum) perfectly (I actually did them first, not realising). However, I did notice that in every case the same error message you got about IPs changing happened and I had to rediscover them.
I'm now on 3.2.2 and everything is as good/bad as it was before. I try not do to much with it for fear of discovering another bug or issue. The one that's biting me at the moment is that you can't delete references to physical disks (in Manager) which have been removed/changed on a Server. They just sit there, saying they're offline, even though they've been removed physically from the server (or in this case, the RAID card is now presenting up a RAID10 rather than a RAID5 volume.
Oracle suggest the only way to fix this (remove the references) is to delete the server and pool and rediscover it. Joy.
I tried to upgrade the OVM manager & OVS servers (I think they were 3.1.1) that were part of the VirtualBox templates to 3.2.1 and the upgrade had issues. I had done a snapshot in virtual box (as well as manually copying the directories just to be safe) and so reverted to the snapshots. Installed native 3.2.1 on bare metal and not looking forward to the idea of upgrading to 3.2.2 but hopefully 3.2.1->3.2.2 is much cleaner than what you all are seeing.
That's unhelpful (-: I'm on 3.2.2. But other than it seeming to work, I can confirm the bugginess. Here's one: It's impossible to delete entries for defunct/removed local storage volumes from the OVM GUI (or even with the commandline). If you reconfigure your RAID (for example) underneath an Oracle VM Server, the old entries to local storage volumes will hang around forever. Not an issue, but it is annoying.