Overview of the process:

Start with a 3.5 engine/dwh/reports setup on a single host (from clean or upgraded)

* service ovirt-engine-dwhd stop
* Keep somewhere the db credentials (can be found at /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf)
* yum remove ovirt-engine-dwh (or rhevm-dwh)

On the new dwh machine:
* yum install ovirt-engine-dwh
* engine-setup - supply existing credentials

I didn't try that myself.

This process was not tested fully and should be tested.

I tested this scenario and it worked.

Start with a 3.5 engine/dwh/reports setup on a single host (from clean or upgraded)

On the new dwh machine:
* yum install ovirt-engine-dwh

On the engine machine:
* service ovirt-engine-dwhd stop

On the new dwh machine:
* engine-setup - supply existing credentials
  * User should choose to use Remote DWH database.
  * Get DWH and engine database credentials from the engine machine at:
    /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
  * Allow to change the DWH to the new one.

On the engine machine:
* yum remove ovirt-engine-dwh (or rhevm-dwh)- Must (or after an hour the service will try to restart).

This is the scenario for etl process migration to a separate host.
The ovirt_engine_history database remains on the same host as the engine.

If the user also wants to migrate the ovirt_engine_history database then he should create database backup using pg_dump , create a new database in the new location and restore using the backup file. 
Then provide the correct credentials for it during the engine-setup.

Updated:

Start with a 3.5 engine/dwh/reports setup on a single host (from clean or upgraded)

On the new dwh machine:
* yum install ovirt-engine-dwh

On the engine machine:
* service ovirt-engine-dwhd stop

* If the ovirt_engine_history database remains on the same host as the engine,
  then before running engine-setup:

  Edit on Engine machine the file /var/lib/pgsql/data/postgresql.conf

  Find there the line containing 'listen_addresses' and change it to be:

  listen_addresses = '*'

  If there is no such line there, or only a commented one, add a new such line.

  Restart postgresql with:

  service postgresql restart 


On the new dwh machine:
* engine-setup - supply existing credentials
  * User should choose to use Remote DWH database.
  * Get DWH and engine database credentials from the engine machine at:
    /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
  * Allow to change the DWH to the new one.

On the engine machine:
* yum remove ovirt-engine-dwh (or rhevm-dwh)- Must (or after an hour the service will try to restart).

This is the scenario for etl process migration to a separate host.
The ovirt_engine_history database remains on the same host as the engine.

If the user also wants to migrate the ovirt_engine_history database then he should create database backup using pg_dump , create a new database in the new location and restore using the backup file. 
Then provide the correct credentials for it during the engine-setup.

Moving this bug back to assigned while I work on this content.

(In reply to Lucinda Bopf from comment #14)
> I tested this procedure today, and have updated the migration content with
> additional steps. I have one more question to add to the list:
> 
> 4. During engine-setup, the following option is given:
> "Setup can backup the existing database. The time and space required for the
> database backup depend on its size. This process takes time, and in some
> cases (for instance, when the size is few GBs) may take several hours to
> complete.
>           If you choose to not back up the database, and Setup later fails
> for some reason, it will not be able to restore the database and all DWH
> data will be lost.
>           Would you like to backup the existing database before upgrading
> it? (Yes, No) [Yes]: "
> Later in the setup script, the location of the file is given:
> "[ INFO  ] Backing up database
> lbopf-rhevm35.usersys.redhat.com:ovirt_engine_history to
> '/var/lib/ovirt-engine-dwh/backups/dwh-20150217042352.IPHlBP.dump'."
> In that case, do we need a separate pg_dump procedure, or can users
> migrate/restore their DWH database using this .dump file?

In principle it can be used, but will require changing a bit the instructions, as it uses a different pg_dump format ("custom" vs "plain" (which is the default)).

In practice this is not generally useful because it's up-to-date only for the moment of running engine-setup (usually for an upgrade). So if you want to migrate a month later, and use this dump, you loose a month's worth of history.

(In reply to Yedidyah Bar David from comment #16)
> (In reply to Lucinda Bopf from comment #14)
> > I tested this procedure today, and have updated the migration content with
> > additional steps. I have one more question to add to the list:
> > 
> > 4. During engine-setup, the following option is given:
> > "Setup can backup the existing database. The time and space required for the
> > database backup depend on its size. This process takes time, and in some
> > cases (for instance, when the size is few GBs) may take several hours to
> > complete.
> >           If you choose to not back up the database, and Setup later fails
> > for some reason, it will not be able to restore the database and all DWH
> > data will be lost.
> >           Would you like to backup the existing database before upgrading
> > it? (Yes, No) [Yes]: "
> > Later in the setup script, the location of the file is given:
> > "[ INFO  ] Backing up database
> > lbopf-rhevm35.usersys.redhat.com:ovirt_engine_history to
> > '/var/lib/ovirt-engine-dwh/backups/dwh-20150217042352.IPHlBP.dump'."
> > In that case, do we need a separate pg_dump procedure, or can users
> > migrate/restore their DWH database using this .dump file?
> 
> In principle it can be used, but will require changing a bit the
> instructions, as it uses a different pg_dump format ("custom" vs "plain"
> (which is the default)).
> 
> In practice this is not generally useful because it's up-to-date only for
> the moment of running engine-setup (usually for an upgrade). So if you want
> to migrate a month later, and use this dump, you loose a month's worth of
> history.

Right. I understand. So it's still a good idea to keep the separate pg_dump procedure (which actually appears in a more logical place, BEFORE running engine-setup). Looking again, I think it's clear in the topic that the backup is just a fail-safe in case engine-setup fails.

Included in the latest async release.

*** Bug 1159612 has been marked as a duplicate of this bug. ***