On Thu, Mar 9, 2017 at 12:30 PM, Nelson Lameiras <nelson.lameiras@lyra-network.com> wrote:

Hello,

I'm trying to upgrade our ovirt-engine from 4.0 (centos manually installed) to 4.1.0 (appliance) using "hosted-engine --upgrade-appliance".

IIRC we do not support this flow currently. I agree it might be useful. Would you like to open an RFE bz?

Our test setup :
2 hosts with centos 7.3 with ovirt4.0 (latest updates)
1 ovirt-engine 4.0 (latest update)

This method uses a manual backup from current engine and injects it to new appliance. Since "old" ovirt-engine is a manually installed 4.0 (latest version) as opposed to an appliance, upgrade process warns that it doesn't recognise the current engine with a somewhat deprecated message :

[WARNING] Unable to detect engine version
[WARNING] Unsupported upgrade path
          This procedure has been designed and tested only for upgrading the engine VM from ['3.6'] to ['4.0'].
          Any other usage is highly experimental and potentially dangerous:
            Current engine: unknown
            Selected appliance: 4.1-20170201.1.el7.centos
          Do you want to abort the upgrade process? (Yes, No) [Yes]: no
[WARNING] Proceeding on an unsupported and highly experimental path

Indeed.

This fails, according to a bug already posted on https://bugzilla.redhat.com/show_bug.cgi?id=1420283 which is resolved in future 4.1.1

It might not be clear from the bug content, but:

1. It only affects RHV, not oVirt.

2. It does not fix your problem. It only allows the upgrade tool in version 4.1 to migrate a 3.6 engine to a _4.0_ appliance (not 4.1).

So I tried to manually patch the file corrected in gerrit https://gerrit.ovirt.org/#/c/71965/ and - after multiple tries - it still fails at the end with the following error :

...
[ INFO ] Running engine-setup on the appliance
          |- Preparing to restore:
          |- - Unpacking file '/root/engine_backup.tar.gz'
          |- FATAL: Backup was created by version '4.0' and can not be restored using the installed version 4.1

This is your real problem.

          |- HE_APPLIANCE_ENGINE_RESTORE_FAIL
[ ERROR ] Engine backup restore failed on the appliance
[ ERROR ] Failed to execute stage 'Closing up': engine-backup failed restoring the engine backup on the appliance Please check its log on the appliance.

When checking upgrade log, there's not much more error information other than :

2017-03-08 18:08:30 INFO otopi.plugins.gr_he_common.engine.health health._closeup:127 Running engine-setup on the appliance
2017-03-08 18:08:44 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- Preparing to restore:
2017-03-08 18:08:44 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- - Unpacking file '/root/engine_backup.tar.gz'
2017-03-08 18:08:44 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- FATAL: Backup was created by version '4.0' and can not be restored using the installed version 4.1
2017-03-08 18:08:44 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- HE_APPLIANCE_ENGINE_RESTORE_FAIL
2017-03-08 18:08:44 ERROR otopi.plugins.gr_he_common.engine.health health._closeup:154 Engine backup restore failed on the appliance
2017-03-08 18:08:44 DEBUG otopi.context context._executeMethod:142 method exception
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod
    method['method']()
File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-common/engine/health.py", line 158, in _closeup
    'engine-backup failed restoring the engine backup '
RuntimeError: engine-backup failed restoring the engine backup on the appliance

Please check its log on the appliance.
2017-03-08 18:08:44 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Closing up': engine-backup failed restoring the engine backup on the appliance
Please check its log on the appliance.

Indeed.

If you want to "fix" that, you can try to patch engine-backup - search in it for VALID_BACKUP_RESTORE_PAIRS, there is a comment about enabling 4.0->4.1 upgrade. But as I wrote, this is not supported, and I am not aware of anyone testing it - so things might break later on.

2017-03-08 18:08:44 DEBUG otopi.context context.dumpEnvironment:760 ENVIRONMENT DUMP - BEGIN

In "new" engine setup log, the only thing which catched my eye is :

2017-03-08 18:08:45 DEBUG otopi.context context.dumpEnvironment:774 ENVIRONMENT DUMP - END
2017-03-08 18:08:45 DEBUG otopi.context context._executeMethod:128 Stage boot METHOD otopi.plugins.otopi.packagers.dnfpackager.Plugin._boot
2017-03-08 18:08:45 DEBUG otopi.plugins.otopi.packagers.dnfpackager dnfpackager._boot:163 Cannot initialize minidnf
Traceback (most recent call last):
File "/usr/share/otopi/plugins/otopi/packagers/dnfpackager.py", line 150, in _boot
    constants.PackEnv.DNF_DISABLED_PLUGINS
File "/usr/share/otopi/plugins/otopi/packagers/dnfpackager.py", line 60, in _getMiniDNF
    from otopi import minidnf
File "/usr/lib/python2.7/site-packages/otopi/minidnf.py", line 16, in <module>
    import dnf
ImportError: No module named dnf

This is just unrelated noise, will be cleared by bz 1404253.

2017-03-08 18:08:45 DEBUG otopi.context context.dumpEnvironment:760 ENVIRONMENT DUMP - BEGIN

I'm not sure if my patched file (runvm.py) should be enough to make it work, but maybe this can bring some new information to you.
Really hopping that 4.1.1 oVirt will resolve this issue as we are eager to start using appliances.

Please note that the engine appliance is not really an appliance in the most strict sense of the word, such as e.g. ovirt-node. Once you install it, it behaves like a normal machine. To upgrade it, you follow normal upgrade procedures. So even if you somehow manage to do what you want (by patching engine-backup and probably fixing other things as needed, or by opening an RFE bz and waiting for it to be handled), it will not help you much when you eventually want to upgrade to 4.2 and later. You are of course welcome to open an RFE for this as well, but it will likely require quite a lot more work, and not sure it's worth it.

Best,

(I can provide you with more/full log files if necessary)

cordialement, regards,

Nelson LAMEIRAS
Ingénieur Systèmes et Réseaux / Systems and Networks engineer
Tel: +33 5 32 09 09 70
nelson.lameiras@lyra-network.com
www.lyra-network.com | www.payzen.eu

Lyra Network, 109 rue de l'innovation, 31670 Labège, FRANCE

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Didi