Bug 1318580 - [RFE] restore: ensure that 3.6 backup can be restored on clean 4.0
Summary: [RFE] restore: ensure that 3.6 backup can be restored on clean 4.0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backup-Restore.Engine
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ovirt-4.0.0-beta
: 4.0.0
Assignee: Yedidyah Bar David
QA Contact: Jiri Belka
URL:
Whiteboard:
: 1323220 (view as bug list)
Depends On: 1323201 1332088
Blocks: RHEV_from_3_6_to_4_0_Migration_Tracker 1332463 1351435
TreeView+ depends on / blocked
 
Reported: 2016-03-17 09:46 UTC by Sandro Bonazzola
Modified: 2016-08-15 03:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this update, Red Hat Virtualization 4.0 can now restore backups taken of Red Hat Enterprise Virtualization 3.6. Red Hat Virtualization 4.0 does not support Red Hat Enterprise Linux 6 and, previously, this meant that users could not upgrade from Red Hat Enterprise Virtualization 3.6. Now, users can back up their Red Hat Enterprise Virtualization 3.6 and restore it on Red Hat Virtualization 4.0. To backup Red Hat Enterprise Virtualization 3.6 run, engine-backup --mode=backup --file=engine-3.6.bck --log=backup.log. Other options for engine-backup, including remote databases, can be found in the engine-backup documentation, https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/Administration_Guide/index.html#sect-Backing_Up_and_Restoring_the_Red_Hat_Enterprise_Virtualization_Manager To migrate to Red Hat Virtualization 4.0, install Red Hat Virtualization 4.0 then copy engine-3.6.bck to the Red Hat Enterprise Linux machine. Run engine-backup --mode=restore --file=engine-3.6.bck --log=restore.log --provision-db --no-restore-permissions to restore the backup then run engine-setup.
Clone Of:
: 1332463 (view as bug list)
Environment:
Last Closed: 2016-07-05 07:51:43 UTC
oVirt Team: Integration
rule-engine: ovirt-4.0.0+
pnovotny: testing_plan_complete+
mgoldboi: planning_ack+
sbonazzo: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 55046 0 master MERGED packaging: engine-backup: Allow restoring to a different version 2016-04-18 06:11:35 UTC
oVirt gerrit 56033 0 master MERGED packaging: setup: asynctasks: do not start/stop engine 2016-04-18 06:11:12 UTC
oVirt gerrit 56272 0 master MERGED packaging: engine-backup: Fix apache reconfiguration 2016-04-18 11:10:38 UTC

Description Sandro Bonazzola 2016-03-17 09:46:12 UTC
Description of problem:
Since we're not supporting el6 anymore on 4.0 we should ensure that a migration from el6 to el7 can be done easily.
- backup 3.6 engine running on el6
- install 4.0 engine on el7
- restore engine in the new environment

Comment 1 Yedidyah Bar David 2016-03-17 10:18:49 UTC
One potential problem I noticed re this (thanks to testing by nsednev) is that engine-setup starts the engine *before* the upgrade in asynctasks.py . Not sure how well this will work.

Comment 2 Mike McCune 2016-03-28 22:28:36 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 3 Yedidyah Bar David 2016-04-07 05:45:36 UTC
*** Bug 1323220 has been marked as a duplicate of this bug. ***

Comment 4 Yedidyah Bar David 2016-04-12 10:23:14 UTC
(In reply to Yedidyah Bar David from comment #1)
> One potential problem I noticed re this (thanks to testing by nsednev) is
> that engine-setup starts the engine *before* the upgrade in asynctasks.py .
> Not sure how well this will work.

Two problems I currently see with this:

1. we'll need to patch the new jboss location prior to starting the engine. We can decide that this isn't a major issue and do it during restore (not setup, where we try hard to not touch the system before STAGE_TRANSACTION_BEGIN ("Stage: Transaction setup").

2. The inherent issue is that we start a new engine code with an old engine db. This is different from an upgrade flow, where this stage runs with the old engine code installed.

Some solutions/ideas:

1. Seems like we can already optionally skip this action by passing 'OVESETUP_ASYNC/clearTasks=bool:False'. This will also prevent running the taskcleaner, need to think about making either optional (but the core problem still applies to both of them, although taskcleaner is a much smaller piece of code, hopefully easier to make it compatible with older db).

2. We can add to engine-backup --mode=backup, a check whether there are pending tasks etc., and if so, abort, unless an option (say '--force-backup-pending-tasks') is passed. Or perhaps the opposite ('--prevent-backup-pending-tasks'), assuming that the normal flow is routine backup, and migration is the special case.

Sandro, what do you think?

Comment 5 Yedidyah Bar David 2016-04-12 11:34:48 UTC
Ignore this. I now realized that we clean these on restore anyway, so should never need to handle them. The only problem is that we always start the engine. I'll fix.

Comment 6 Jiri Belka 2016-04-25 16:46:57 UTC
Can this be merged to 3.6? Otherwise migration from 3.6 EL6 to 3.6 EL7 does fail.

Comment 7 Yedidyah Bar David 2016-05-01 06:50:18 UTC
This is not a clean cherry-pick, but should be simple enough. But see my comment on bug 1323201 .

Comment 8 Jiri Belka 2016-06-01 09:50:28 UTC
ok, 4.0.0-10

tested many times for migration between 3.6 EL6 and 4.0 EL7

Comment 9 Sandro Bonazzola 2016-07-05 07:51:43 UTC
oVirt 4.0.0 has been released, closing current release.


Note You need to log in before you can comment on or make changes to this bug.