We've lost our 3.1 VM servers and manager. I've recreated a brand new set of servers and 1 manager and we are now running 3.2.
1- How can I restore the repository (I see the LUNS) to the new server set ? Should I recreate one ? Will it detect it's already containing a repository made of OCFS ?
2- What kind of issue should I expect on the VM side ? Will the repository be named the same internally and my files referenced correctly ? Can I rediscover the disk and change the configuration from the Manager ?
Another way to look at this scenario (even though it has not been the case), is I've switch my repository to a remote site. I have a brand new set of servers/manager. How do I recover my repository without copying GB of VMs?
Thank you for your help. As you can imagine, you will be more than welcome to help in here. Best Regards,
I am sorry, but you won't get your server pool back, if you didn't noted down your OVMM's UUID, which would empower you to simply re-setup a new OVMM and rediscover your existing server pool along with your storage repo(s).
You might be able to successfully load the OCFS2 file systems by manually setting those up on another Non-OVM server, but you will be left with tons of files and folders that have UUIDs as their names and thus it will be very cumbersome to even find out which pieces belong together. Although it can be done, this will be a time-consuming and probably error-prone process.
1) You are absolutely right: I had to rebuild an OVM Manager with the same UUID from the original one. I've got the UUID from .ovsrepos file located in the repository. Other than that impossible to recover it! -Thank you very much for the hint...
2) I've also faced an issue due to the fact the pool UUID is different from the rebuilt one. I had to apply note "Rediscover an Existing Repository in Oracle VM 3.1.1 [ID 1469703.1]" to change the pool ID from the FS and remount the FS
IMPORTANT: Refresh the "Shared Filesystem" in the console AFTER you change the pool ID. If some inconsistent entries get registered in the OVS Repository, you'll get OVMRU_002037E errors. This is very annoying because this is the case even after you've fixed everything on the pool. The error actually comes from the repository check and doesn't seems to be able to recover by itself even if you refresh the Shared Filesystem.
3) To ease and speed up things, I would suggest to backup the manager once re-installed. This should be faster to recover it.
4) For some reasons, I could only recover the disks and not the VMs ! (No big deal since that was my primary concern). VMs appear in the Repository but not in the pool once the repository is published to the pool. The best solution I've found is to delete the VM directories first and recreate the VM manually from the screens once the directory restored.