12:48 p.m.
On Thu, Mar 9, 2017 at 12:30 PM, Nelson Lameiras <
nelson.lameiras(a)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
<https://gerrit.ovirt.org/#/c/71965/3/src/plugins/gr-he-upgradeappliance/v...>)
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,
<https://www.lyra-network.com/>
Nelson LAMEIRAS
Ingénieur Systèmes et Réseaux / Systems and Networks engineer
Tel: +33 5 32 09 09 70 <+33%205%2032%2009%2009%2070>
nelson.lameiras(a)lyra-network.com
www.lyra-network.com | www.payzen.eu <https://payzen.eu>
<https://www.youtube.com/channel/UCrVl1CO_Jlu3KbiRH-tQ_vA>
<https://www.linkedin.com/company/lyra-network_2>
<https://twitter.com/LyraNetwork>
<https://payzen.eu>
------------------------------
Lyra Network, 109 rue de l'innovation, 31670 Labège, FRANCE
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Didi
