Migrate OpenNebula Front-end to Another VM

Current front-end server:
RHEL 7, OpenNebula v6.4

Goal
New front-end server:
RHEL 8, OpenNebula v6.4

I am trying to migrate the front-end from my current RHEL 7 server to a new RHEL 8 server. I know I have to backup /etc/one, /var/lib/one and /var/log/one (which I have done using tar) and backup the current DB (onedb backup…). My back-end storage is NFS, so that is easy and can be re-mounted on the new server.

My issue is that after I restore the DB (using Mysql) on the new server and try to start up the OpenNebula services, it either fails and complains about some of the “_auth” files existing under /var/lib/one/.one (ex. sunstone_auth) or when it does start (removed the _auth files which I have seen people do and it works), I try to login and it fails to authenticate any user (oneadmin or LDAP accounts).

I’m not sure if I am doing the migration correctly (backup and restore) or if there is another issue along the way that I am missing. Any help is appreciated!

Hi Alex

We did this several times (restoring backups and also installing OpenNebula server with a new RHEL version).
As you said you should make a db backup or dump opennebula db and restore it in the new server and install the same rpm packages version for OpenNebula in the new server as well. The most important files to backup are the conf in /etc/one and remotes but also the passwords. OpenNebula include your oneadmin and sunstone service passwords hashed in the DB but those should match with the passwords that you have in /var/lib/one/.one, if not the service clients will not able to authenticate with the API. Make sure you did a copy of those as well. Also check if oneadmin user has the rights to access to those passwords files inside this directory in the new machine.

I hope this will help you.

Cheers
Álvaro

Not having much luck. I copied everything over from the RHEL 7 server as mentioned. I can see the VMs, hosts, etc. if I run commands like “onevm show” on the RHEL 8 server, but I can’t login to the Web UI no matter what I do.

This is normally the error:

Mon Jul 15 12:35:36 2024 [Z0][AuM][I]: Command execution failed (exit code: 255): /var/lib/one/remotes/auth/server_cipher/authenticate
Mon Jul 15 12:35:36 2024 [Z0][AuM][I]: bad decrypt
Mon Jul 15 12:35:36 2024 [Z0][AuM][D]: _authenticate: bad decrypt
Mon Jul 15 12:35:36 2024 [Z0][Lis][I]: Stopping
Mon Jul 15 12:35:36 2024 [Z0][AuM][E]: Auth Error: bad decrypt
Mon Jul 15 12:35:36 2024 [Z0][ReM][D]: Req:9552 UID:-1 IP:127.0.0.1 one.user.info invoked , -1, false
Mon Jul 15 12:35:36 2024 [Z0][ReM][E]: Req:9552 UID:- one.user.info result FAILURE [one.user.info] User couldn’t be authenticated, aborting call.

If you can issue commands and they appear, it means the oneadmin user API calls are being authenticated successfully. If the issue is with sunstone, then it likely means auth issues with the serveradmin user. Similar to oneadmin, this system user stores its passwords on /var/lib/one/.one as Alvaro mentions. But instead of the one_auth file, there is a file for each of the complementary opennebula services. You either

  • update the password entry on the database to match what is on those files right now
  • sync the files from the old frontend as those should match what you have on the database

https://docs.opennebula.io/6.8/management_and_operations/users_groups_management/manage_users.html?highlight=serveradmin#change-credentials-for-oneadmin-or-serveradmin

Here are the steps I took to make it work:

  1. Synced the /var/lib/one/.ssh, /var/lib/one/.one/one_auth (ONLY one_auth) and /etc/one/oned.conf from the old server with the new server.
  2. Started the opennebula.service to link with mysql.
  3. Stopped all opennebula services.
  4. Restored the DB (onedb restore -f mysql…) from my old server.
  5. Synced /var/lib/one/.one from the old server with the new one to include all of the *_auth files.
  6. Started the OpenNebula services (opennebula, sunstone, fireedge).

Hi Alex,

You should have a look at Replace failing front-end — OpenNebula 6.4.6 documentation
It is for high-availability setup but I found it useful when I was doing a similar migration. (I think the step that you are missing is syncing “/var/lib/one/remotes”.)

Sincere regards,

…Lowel.