The instructions provided here should be used as a last resort. You really must ensure that your backup strategy is adequate and that the database backups are available on storage that is suitable for this purpose. Typically, these backups should be stored on some form of network attached storage, preferably with a RAID that provides some form of mirroring. To change the backup path to a suitable location, see Section 5.1.2, “Backing up the MySQL Database Repository”.
If you have reinstalled Oracle VM Manager from scratch, using the
runInstaller.sh --uuid
uuid command and have
provided the UUID from the previous manager installation, but
you do not have a database backup, a certain level of recovery
is possible based on the information stored on the Oracle VM Servers and
in your attached storage. It is important that you follow a set
order of actions to ensure that the server pools that your
Oracle VM Servers are members of are able to be properly recovered.
These steps are outlined as follows:
Discover one Oracle VM Server from each server pool.
Discover the storage that contains the server pool file system. Present it to the newly discovered Oracle VM Server. Refresh the storage.
Refresh the file system or physical disks that contain the server pool file system.
Refresh the file systems or physical disks that contain the repositories used by server pool. If you get an error, when refreshing a physical disk, similar to the following:
OVMAPI_7281E Cannot perform operation on file system...
then take ownership of the repositories and try to perform the physical disk refresh again.
Present the repositories to the Oracle VM Server.
Refresh the repositories.
Discover the remaining Oracle VM Servers in the server pool.
Refresh all Oracle VM Servers in the server pool to discover the virtual machines.
When you perform a restore in this manner, the names and descriptions of all objects in Oracle VM Manager are lost. You need to manually rename each object in your environment.