
<br><div><span style=3D"font-size: 11pt; font-family: terminal, monaco;" d= ata-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">On the li= ve engine I run # engine-backup --scope=3Dall --mode=3Dbackup --file= =3Dfile_name --log=3Dlog_file_name</span></div><div><span style=3D"font-siz= e: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt;= font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></span></div><div= <span style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-s= tyle=3D"font-size: 11pt; font-family: terminal, monaco;">And try to restore= on a fresh installation:</span><br></div><div><span style=3D"font-size: 11=
------=_Part_20329569_1409874801.1519819859027 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I'm testing backup & restore on Ovirt 4.2. I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message: restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'. On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions Any Idea? Thanks -- Jose Ferradeira http://www.logicworks.pt ------=_Part_20329569_1409874801.1519819859027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: trebuchet ms,sans-serif; font-size: = 12pt; color: #000000"><div data-marker=3D"__QUOTED_TEXT__"><div style=3D"fo= nt-family: Times New Roman; font-size: 10pt; color: #000000;" data-mce-styl= e=3D"font-family: Times New Roman; font-size: 10pt; color: #000000;"><div>H= i,<br></div><br><div><span style=3D"font-size: 11pt; font-family: terminal,= monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;= ">I'm testing backup & restore on Ovirt 4.2.</span><br></div><div><span= style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style= =3D"font-size: 11pt; font-family: terminal, monaco;">I follow this doc http= s://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/</sp= an><br></div><div><span style=3D"font-size: 11pt; font-family: terminal, mo= naco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">T= ry to restore to a fresh installation but always get this error message:</s= pan><br></div><br><div><span style=3D"font-size: 11pt; font-family: termina= l, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monac= o;">restore-permissions</span><br><span style=3D"font-size: 11pt; font-fami= ly: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: term= inal, monaco;">Preparing to restore:</span><br><span style=3D"font-size: 11= pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font= -family: terminal, monaco;">- Unpacking file 'back_file'</span><br><span st= yle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"f= ont-size: 11pt; font-family: terminal, monaco;">Restoring:</span><br><span = style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D= "font-size: 11pt; font-family: terminal, monaco;">- Files</span><br><span s= tyle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"= font-size: 11pt; font-family: terminal, monaco;">Provisioning PostgreSQL us= ers/databases:</span><br><span style=3D"font-size: 11pt; font-family: termi= nal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, mon= aco;">- user 'engine', database 'engine'</span><br><span style=3D"font-size= : 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; = font-family: terminal, monaco;">Restoring:</span><br><span style=3D"font-si= ze: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt= ; font-family: terminal, monaco;">FATAL: Can't connect to database 'ovirt_e= ngine_history'. Please see '/usr/bin/engine-backup --help'.</span><br></div= pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font= -family: terminal, monaco;"># engine-backup --mode=3Drestore --file=3Dfile_= name --log=3Dlog_file_name --provision-db --restore-permissions</span></div=
<div><span style=3D"font-size: 11pt; font-family: terminal, monaco;" data-= mce-style=3D"font-size: 11pt; font-family: terminal, monaco;"><br data-mce-= bogus=3D"1"></span></div><div><span style=3D"font-size: 11pt; font-family: = terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal= , monaco;">Any Idea?<br data-mce-bogus=3D"1"></span></div><div><span style= =3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font= -size: 11pt; font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></spa= n></div><div><span style=3D"font-size: 11pt; font-family: terminal, monaco;= " data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">Thanks= <br data-mce-bogus=3D"1"></span></div><div><span style=3D"font-size: 11pt; = font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-fam= ily: terminal, monaco;"><br data-mce-bogus=3D"1"></span></div><div><span st= yle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"f= ont-size: 11pt; font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></= span></div><br><div>-- <br></div><div><hr style=3D"width: 100%; height: 2px= ;" data-mce-style=3D"width: 100%; height: 2px;">Jose Ferradeira<br>http://w= ww.logicworks.pt</div></div><br></div></div></body></html> ------=_Part_20329569_1409874801.1519819859027--

On Wed, Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote:
Hi,
I'm testing backup & restore on Ovirt 4.2. I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message:
restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'.
On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name
And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions
Any Idea?
Please try adding to restore command '--providion-dwh-db'. Thanks. -- Didi

------=_Part_20337673_1603009670.1519821904170 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Still no luck: # engine-backup --mode=restore --file=back_futur --log=log_futur --provision-db --restore-permissions --provision-dwh-db Preparing to restore: - Unpacking file 'back_futur' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' - user 'ovirt_engine_history', database 'ovirt_engine_history' Restoring: - Engine database 'engine' FATAL: Errors while restoring database engine I did a engine-cleanup, try it again but still the same error. De: "Yedidyah Bar David" <didi@redhat.com> Para: suporte@logicworks.pt Cc: "ovirt users" <users@ovirt.org> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 Assunto: Re: [ovirt-users] Backup & Restore On Wed, Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote:
Hi,
I'm testing backup & restore on Ovirt 4.2. I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message:
restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'.
On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name
And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions
Any Idea?
> I'm testing backup & restore on Ovirt 4.2.<br>> I follow this = doc<br>> https://www.ovirt.org/documentation/admin-guide/chap-Backups_an= d_Migration/<br>> Try to restore to a fresh installation but always get =
Please try adding to restore command '--providion-dwh-db'. Thanks. -- Didi ------=_Part_20337673_1603009670.1519821904170 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: trebuchet ms,sans-serif; font-size: = 12pt; color: #000000"><div>Still no luck:<br></div><div><br data-mce-bogus= =3D"1"></div><div># engine-backup --mode=3Drestore --file=3Dback_futur --lo= g=3Dlog_futur --provision-db --restore-permissions --provision-dwh-db<br>Pr= eparing to restore:<br>- Unpacking file 'back_futur'<br>Restoring:<br>- Fil= es<br>Provisioning PostgreSQL users/databases:<br>- user 'engine', database= 'engine'<br>- user 'ovirt_engine_history', database 'ovirt_engine_history'= <br>Restoring:<br>- Engine database 'engine'<br>FATAL: Errors while restori= ng database engine<br></div><div><br data-mce-bogus=3D"1"></div><div>I did = a engine-cleanup, try it again but still the same error.<br data-mce-bogus= =3D"1"></div><div><br></div><hr id=3D"zwchr" data-marker=3D"__DIVIDER__"><d= iv data-marker=3D"__HEADERS__"><b>De: </b>"Yedidyah Bar David" <didi@red= hat.com><br><b>Para: </b>suporte@logicworks.pt<br><b>Cc: </b>"ovirt user= s" <users@ovirt.org><br><b>Enviadas: </b>Quarta-feira, 28 De Fevereir= o de 2018 12:24:50<br><b>Assunto: </b>Re: [ovirt-users] Backup & Restor= e<br></div><br><div data-marker=3D"__QUOTED_TEXT__">On Wed, Feb 28, 2018 at= 2:10 PM, <suporte@logicworks.pt> wrote:<br>> Hi,<br>><br= this error message:<br>><br>> restore-permissions<br>> Preparing t= o restore:<br>> - Unpacking file 'back_file'<br>> Restoring:<br>> = - Files<br>> Provisioning PostgreSQL users/databases:<br>> - user 'en= gine', database 'engine'<br>> Restoring:<br>> FATAL: Can't connect to= database 'ovirt_engine_history'. Please see<br>> '/usr/bin/engine-backu= p --help'.<br>><br>> On the live engine I run # engine-backup --scope= =3Dall --mode=3Dbackup<br>> --file=3Dfile_name --log=3Dlog_file_name<br>= ><br>> And try to restore on a fresh installation:<br>> # engine-b= ackup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name<br>> --p= rovision-db --restore-permissions<br>><br>> Any Idea?<br><br>Please t= ry adding to restore command '--providion-dwh-db'. Thanks.<br>-- <br>Didi<b= r></div></div></body></html> ------=_Part_20337673_1603009670.1519821904170--

------=_Part_20349653_1465707940.1519829079176 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit If I run # engine-backup --mode=restore --file=back_futur --log=log_futur --provision-db --restore-permissions --provision-dwh-db --log=/root/rest-log to create a log, I found these errors: 2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -h localhost -p 5432 ovirt_engine_history -t -c show lc_messages 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_history -h localhost -p 5432 ovirt_engine_history -s 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' 2018-02-28 14:36:31 6339: Restoring engine database backup at /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db 2018-02-28 14:36:31 6339: restoreDB: backupfile /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user engine host localhost port 5432 database engine orig_user compressor format custom jobsnum 2 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h localhost -p 5432 -d engine -j 2 /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION uuid_generate_v1() engine pg_restore: [archiver (db)] could not execute query: ERROR: function "uuid_generate_v1" already exists with same argument types Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid LANGUAGE plpgsql STABLE AS ' DECLARE v_val BIGINT; v_4_1_par... pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of function uuid_generate_v1 Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine; pg_restore: WARNING: column "user_role_title" has type "unknown" DETAIL: Proceeding with relation creation anyway. pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges were granted for "public" pg_restore: WARNING: no privileges were granted for "public" WARNING: errors ignored on restore: 3 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine De: suporte@logicworks.pt Para: "Yedidyah Bar David" <didi@redhat.com> Cc: "ovirt users" <users@ovirt.org> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04 Assunto: Re: [ovirt-users] Backup & Restore Still no luck: # engine-backup --mode=restore --file=back_futur --log=log_futur --provision-db --restore-permissions --provision-dwh-db Preparing to restore: - Unpacking file 'back_futur' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' - user 'ovirt_engine_history', database 'ovirt_engine_history' Restoring: - Engine database 'engine' FATAL: Errors while restoring database engine I did a engine-cleanup, try it again but still the same error. De: "Yedidyah Bar David" <didi@redhat.com> Para: suporte@logicworks.pt Cc: "ovirt users" <users@ovirt.org> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 Assunto: Re: [ovirt-users] Backup & Restore On Wed, Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote:
Hi,
I'm testing backup & restore on Ovirt 4.2. I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message:
restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'.
On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name
And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions
Any Idea?
</div><div># engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlo= g_futur --provision-db --restore-permissions --provision-dwh-db --log=3D/ro= ot/rest-log</div><div><br data-mce-bogus=3D"1"></div><div>to create a log, = I found these errors:<br data-mce-bogus=3D"1"></div><div><br data-mce-bogus= =3D"1"></div><div>2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovir= t_engine_history -h localhost -p 5432 ovirt_engine_history -t -c show lc_me= ssages<br>2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_eng= ine_history -h localhost -p 5432 ovirt_engine_history -s<br>2018-02-28 14:3= 6:31 6339: OUTPUT: - Engine database 'engine'<br>2018-02-28 14:36:31 6339: = Restoring engine database backup at /tmp/engine-backup.VVkcNuYAkV/db/engine= _backup.db<br>2018-02-28 14:36:31 6339: restoreDB: backupfile /tmp/engine-b= ackup.VVkcNuYAkV/db/engine_backup.db user engine host localhost port 5432 d= atabase engine orig_user compressor format custom jobsnum 2<br>2018-02-28 1= 4:36:31 6339: pg_cmd running: pg_restore -w -U engine -h localhost -p 5432 = -d engine -j 2 /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db<br>pg_rest= ore: [archiver (db)] Error while PROCESSING TOC:<br>pg_restore: [archiver (= db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSION plpgsql <br>pg_restor= e: [archiver (db)] could not execute query: ERROR: must be owner of extensi= on plpgsql<br> Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL proce= dural language';<br><br><br><br>pg_restore: [archiver (db)] Error from TOC = entry 693; 1255 211334 FUNCTION uuid_generate_v1() engine<br>pg_restore: [a= rchiver (db)] could not execute query: ERROR: function "uuid_generate_v1" a= lready exists with same argument types<br> Command was: CREATE FUNCTION uui= d_generate_v1() RETURNS uuid<br> LANGUAGE plpgsql STABLE<br> AS '<br>DECLAR= E<br> v_val BIGINT;<br> v_4_1_par...<br>pg_restore: [archiver (db)] could n= ot execute query: ERROR: must be owner of function uuid_generate_v1<br> Com= mand was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine;<br><br>= <br>pg_restore: WARNING: column "user_role_title" has type "unknown"<br>DET= AIL: Proceeding with relation creation anyway.<br>pg_restore: WARNING: no p= rivileges could be revoked for "public"<br>pg_restore: WARNING: no privileg= es could be revoked for "public"<br>pg_restore: WARNING: no privileges were= granted for "public"<br>pg_restore: WARNING: no privileges were granted fo= r "public"<br>WARNING: errors ignored on restore: 3<br>2018-02-28 14:37:23 = 6339: FATAL: Errors while restoring database engine<br></div><div><br></div= <hr id=3D"zwchr" data-marker=3D"__DIVIDER__"><div data-marker=3D"__HEADERS= __"><b>De: </b>suporte@logicworks.pt<br><b>Para: </b>"Yedidyah Bar David" &= lt;didi@redhat.com><br><b>Cc: </b>"ovirt users" <users@ovirt.org><= br><b>Enviadas: </b>Quarta-feira, 28 De Fevereiro de 2018 12:45:04<br><b>As= sunto: </b>Re: [ovirt-users] Backup & Restore<br></div><br><div data-ma= rker=3D"__QUOTED_TEXT__"><div style=3D"font-family: trebuchet ms,sans-serif= ; font-size: 12pt; color: #000000"><div>Still no luck:<br></div><br><div># = engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur --prov= ision-db --restore-permissions --provision-dwh-db<br>Preparing to restore:<= br>- Unpacking file 'back_futur'<br>Restoring:<br>- Files<br>Provisioning P= ostgreSQL users/databases:<br>- user 'engine', database 'engine'<br>- user = 'ovirt_engine_history', database 'ovirt_engine_history'<br>Restoring:<br>- = Engine database 'engine'<br>FATAL: Errors while restoring database engine<b= r></div><br><div>I did a engine-cleanup, try it again but still the same er= ror.<br></div><br><hr id=3D"zwchr"><div><b>De: </b>"Yedidyah Bar David" <= ;didi@redhat.com><br><b>Para: </b>suporte@logicworks.pt<br><b>Cc: </b>"o= virt users" <users@ovirt.org><br><b>Enviadas: </b>Quarta-feira, 28 De= Fevereiro de 2018 12:24:50<br><b>Assunto: </b>Re: [ovirt-users] Backup &am=
Please try adding to restore command '--providion-dwh-db'. Thanks. -- Didi _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ------=_Part_20349653_1465707940.1519829079176 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: trebuchet ms,sans-serif; font-size: = 12pt; color: #000000"><div>If I run <br></div><div><br data-mce-bogus=3D"1"= p; Restore<br></div><br><div>On Wed, Feb 28, 2018 at 2:10 PM, <sup= orte@logicworks.pt> wrote:<br>> Hi,<br>><br>> I'm testing backu= p & restore on Ovirt 4.2.<br>> I follow this doc<br>> https://www= .ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/<br>> Tr= y to restore to a fresh installation but always get this error message:<br>= ><br>> restore-permissions<br>> Preparing to restore:<br>> - Un= packing file 'back_file'<br>> Restoring:<br>> - Files<br>> Provisi= oning PostgreSQL users/databases:<br>> - user 'engine', database 'engine= '<br>> Restoring:<br>> FATAL: Can't connect to database 'ovirt_engine= _history'. Please see<br>> '/usr/bin/engine-backup --help'.<br>><br>&= gt; On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup<= br>> --file=3Dfile_name --log=3Dlog_file_name<br>><br>> And try to= restore on a fresh installation:<br>> # engine-backup --mode=3Drestore = --file=3Dfile_name --log=3Dlog_file_name<br>> --provision-db --restore-p= ermissions<br>><br>> Any Idea?<br><br>Please try adding to restore co= mmand '--providion-dwh-db'. Thanks.<br>-- <br>Didi<br></div></div><br>_____= __________________________________________<br>Users mailing list<br>Users@o= virt.org<br>http://lists.ovirt.org/mailman/listinfo/users<br></div></div></= body></html> ------=_Part_20349653_1465707940.1519829079176--

On Wed, Feb 28, 2018 at 4:44 PM, <suporte@logicworks.pt> wrote:
If I run
# engine-backup --mode=restore --file=back_futur --log=log_futur --provision-db --restore-permissions --provision-dwh-db --log=/root/rest-log
to create a log, I found these errors:
2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -h localhost -p 5432 ovirt_engine_history -t -c show lc_messages 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_history -h localhost -p 5432 ovirt_engine_history -s 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' 2018-02-28 14:36:31 6339: Restoring engine database backup at /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db 2018-02-28 14:36:31 6339: restoreDB: backupfile /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user engine host localhost port 5432 database engine orig_user compressor format custom jobsnum 2 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h localhost -p 5432 -d engine -j 2 /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION uuid_generate_v1() engine pg_restore: [archiver (db)] could not execute query: ERROR: function "uuid_generate_v1" already exists with same argument types
This is the error that fails you. I have a pending patch to make this more visible in the log [1], need to find time to verify it... Does this happen on a clean machine? Perhaps 'engine-cleanup' after such a failed restore is not enough. Please try reinstalling the OS and trying again. If it's not an important machine (test/dev/etc), this will probably be enough, as a faster replacement for a full OS reinstall: engine-cleanup systemctl stop postgresql systemctl stop rh-postgresql95-postgresql rm -rf /var/lib/pgsql/data /var/opt/rh/rh-postgresql95/lib/pgsql/data Then try restore again. [1] https://gerrit.ovirt.org/86395
Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid LANGUAGE plpgsql STABLE AS ' DECLARE v_val BIGINT; v_4_1_par... pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of function uuid_generate_v1 Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine;
Adding also Eli. Eli - perhaps we need to patch engine-backup to ignore also this error? I think the minimal flow to reproduce is: engine-setup engine-backup --mode=backup --file=f1 --log=l1 engine-cleanup engine-backup --mode=restore --file=f1 --provision-db --provision-dwh-db --log=l2 Didn't try this myself.
pg_restore: WARNING: column "user_role_title" has type "unknown" DETAIL: Proceeding with relation creation anyway. pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges were granted for "public" pg_restore: WARNING: no privileges were granted for "public" WARNING: errors ignored on restore: 3 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine
________________________________ De: suporte@logicworks.pt Para: "Yedidyah Bar David" <didi@redhat.com> Cc: "ovirt users" <users@ovirt.org> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04
Assunto: Re: [ovirt-users] Backup & Restore
Still no luck:
# engine-backup --mode=restore --file=back_futur --log=log_futur --provision-db --restore-permissions --provision-dwh-db Preparing to restore: - Unpacking file 'back_futur' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' - user 'ovirt_engine_history', database 'ovirt_engine_history' Restoring: - Engine database 'engine' FATAL: Errors while restoring database engine
I did a engine-cleanup, try it again but still the same error.
________________________________ De: "Yedidyah Bar David" <didi@redhat.com> Para: suporte@logicworks.pt Cc: "ovirt users" <users@ovirt.org> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 Assunto: Re: [ovirt-users] Backup & Restore
On Wed, Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote:
Hi,
I'm testing backup & restore on Ovirt 4.2. I follow this doc
https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message:
restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'.
On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name
And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions
Any Idea?
Please try adding to restore command '--providion-dwh-db'. Thanks. -- Didi
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi

------=_Part_20566966_39555052.1519906078677 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Yes, it happens in a clean machine. I try it twice and restore always fails. From: "Yedidyah Bar David" <didi@redhat.com> To: suporte@logicworks.pt, "Eli Mesika" <emesika@redhat.com> Cc: "ovirt users" <users@ovirt.org> Sent: Thursday, March 1, 2018 7:28:13 AM Subject: Re: [ovirt-users] Backup & Restore On Wed, Feb 28, 2018 at 4:44 PM, <suporte@logicworks.pt> wrote: > If I run > > # engine-backup --mode=restore --file=back_futur --log=log_futur > --provision-db --restore-permissions --provision-dwh-db --log=/root/rest-log > > to create a log, I found these errors: > > 2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -h > localhost -p 5432 ovirt_engine_history -t -c show lc_messages > 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_history > -h localhost -p 5432 ovirt_engine_history -s > 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' > 2018-02-28 14:36:31 6339: Restoring engine database backup at > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db > 2018-02-28 14:36:31 6339: restoreDB: backupfile > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user engine host localhost > port 5432 database engine orig_user compressor format custom jobsnum 2 > 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h > localhost -p 5432 -d engine -j 2 > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSION > plpgsql > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of > extension plpgsql > Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; > > > > pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION > uuid_generate_v1() engine > pg_restore: [archiver (db)] could not execute query: ERROR: function > "uuid_generate_v1" already exists with same argument types This is the error that fails you. I have a pending patch to make this more visible in the log [1], need to find time to verify it... Does this happen on a clean machine? Perhaps 'engine-cleanup' after such a failed restore is not enough. Please try reinstalling the OS and trying again. If it's not an important machine (test/dev/etc), this will probably be enough, as a faster replacement for a full OS reinstall: engine-cleanup systemctl stop postgresql systemctl stop rh-postgresql95-postgresql rm -rf /var/lib/pgsql/data /var/opt/rh/rh-postgresql95/lib/pgsql/data Then try restore again. [1] https://gerrit.ovirt.org/86395 > Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid > LANGUAGE plpgsql STABLE > AS ' > DECLARE > v_val BIGINT; > v_4_1_par... > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of > function uuid_generate_v1 > Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine; Adding also Eli. Eli - perhaps we need to patch engine-backup to ignore also this error? I think the minimal flow to reproduce is: engine-setup engine-backup --mode=backup --file=f1 --log=l1 engine-cleanup engine-backup --mode=restore --file=f1 --provision-db --provision-dwh-db --log=l2 Didn't try this myself. > > > pg_restore: WARNING: column "user_role_title" has type "unknown" > DETAIL: Proceeding with relation creation anyway. > pg_restore: WARNING: no privileges could be revoked for "public" > pg_restore: WARNING: no privileges could be revoked for "public" > pg_restore: WARNING: no privileges were granted for "public" > pg_restore: WARNING: no privileges were granted for "public" > WARNING: errors ignored on restore: 3 > 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine > > ________________________________ > De: suporte@logicworks.pt > Para: "Yedidyah Bar David" <didi@redhat.com> > Cc: "ovirt users" <users@ovirt.org> > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04 > > Assunto: Re: [ovirt-users] Backup & Restore > > Still no luck: > > # engine-backup --mode=restore --file=back_futur --log=log_futur > --provision-db --restore-permissions --provision-dwh-db > Preparing to restore: > - Unpacking file 'back_futur' > Restoring: > - Files > Provisioning PostgreSQL users/databases: > - user 'engine', database 'engine' > - user 'ovirt_engine_history', database 'ovirt_engine_history' > Restoring: > - Engine database 'engine' > FATAL: Errors while restoring database engine > > I did a engine-cleanup, try it again but still the same error. > > ________________________________ > De: "Yedidyah Bar David" <didi@redhat.com> > Para: suporte@logicworks.pt > Cc: "ovirt users" <users@ovirt.org> > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 > Assunto: Re: [ovirt-users] Backup & Restore > > On Wed, Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote: >> Hi, >> >> I'm testing backup & restore on Ovirt 4.2. >> I follow this doc >> >> https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ >> Try to restore to a fresh installation but always get this error message: >> >> restore-permissions >> Preparing to restore: >> - Unpacking file 'back_file' >> Restoring: >> - Files >> Provisioning PostgreSQL users/databases: >> - user 'engine', database 'engine' >> Restoring: >> FATAL: Can't connect to database 'ovirt_engine_history'. Please see >> '/usr/bin/engine-backup --help'. >> >> On the live engine I run # engine-backup --scope=all --mode=backup >> --file=file_name --log=log_file_name >> >> And try to restore on a fresh installation: >> # engine-backup --mode=restore --file=file_name --log=log_file_name >> --provision-db --restore-permissions >> >> Any Idea? > > Please try adding to restore command '--providion-dwh-db'. Thanks. > -- > Didi > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- Didi ------=_Part_20566966_39555052.1519906078677 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: trebuchet ms,sans-serif; font-size: = 12pt; color: #000000"><div>Yes, it happens in a clean machine. I try it twi= ce and restore always fails.</div><div><br></div><hr id=3D"zwchr" data-mark= er=3D"__DIVIDER__"><div data-marker=3D"__HEADERS__"><b>From: </b>"Yedidyah = Bar David" <didi@redhat.com><br><b>To: </b>suporte@logicworks.pt, "El= i Mesika" <emesika@redhat.com><br><b>Cc: </b>"ovirt users" <users@= ovirt.org><br><b>Sent: </b>Thursday, March 1, 2018 7:28:13 AM<br><b>Subj= ect: </b>Re: [ovirt-users] Backup & Restore<br></div><div><br></div><di= v data-marker=3D"__QUOTED_TEXT__">On Wed, Feb 28, 2018 at 4:44 PM, &l= t;suporte@logicworks.pt> wrote:<br>> If I run<br>><br>> # engin= e-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur<br>> --p= rovision-db --restore-permissions --provision-dwh-db --log=3D/root/rest-log= <br>><br>> to create a log, I found these errors:<br>><br>> 201= 8-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -h<b= r>> localhost -p 5432 ovirt_engine_history -t -c show lc_messages<br>>= ; 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_hist= ory<br>> -h localhost -p 5432 ovirt_engine_history -s<br>> 2018-02-28= 14:36:31 6339: OUTPUT: - Engine database 'engine'<br>> 2018-02-28 14:36= :31 6339: Restoring engine database backup at<br>> /tmp/engine-backup.VV= kcNuYAkV/db/engine_backup.db<br>> 2018-02-28 14:36:31 6339: restoreDB: b= ackupfile<br>> /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user en= gine host localhost<br>> port 5432 database engine orig_user compressor = format custom jobsnum 2<br>> 2018-02-28 14:36:31 6339: pg_cmd running: p= g_restore -w -U engine -h<br>> localhost -p 5432 -d engine -j 2<br>> = /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db<br>> pg_restore: [arch= iver (db)] Error while PROCESSING TOC:<br>> pg_restore: [archiver (db)] = Error from TOC entry 7314; 0 0 COMMENT EXTENSION<br>> plpgsql<br>> pg= _restore: [archiver (db)] could not execute query: ERROR: must be owner of<= br>> extension plpgsql<br>> Command was: COMMENT ON EXTENSION plpgsql= IS 'PL/pgSQL procedural language';<br>><br>><br>><br>> pg_rest= ore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION<br>>= uuid_generate_v1() engine<br>> pg_restore: [archiver (db)] could not ex= ecute query: ERROR: function<br>> "uuid_generate_v1" already exists with= same argument types<br><br>This is the error that fails you. I have a pend= ing patch to make this more<br>visible in the log [1], need to find time to= verify it...<br><br>Does this happen on a clean machine? Perhaps 'engine-c= leanup' after such<br>a failed restore is not enough. Please try reinstalli= ng the OS and trying<br>again.<br><br>If it's not an important machine (tes= t/dev/etc), this will probably be<br>enough, as a faster replacement for a = full OS reinstall:<br><br>engine-cleanup<br>systemctl stop postgresql<br>sy= stemctl stop rh-postgresql95-postgresql<br>rm -rf /var/lib/pgsql/data /var/= opt/rh/rh-postgresql95/lib/pgsql/data<br><br>Then try restore again.<br><br= >[1] https://gerrit.ovirt.org/86395<br><br>> Command was: CREATE FUNCTIO= N uuid_generate_v1() RETURNS uuid<br>> LANGUAGE plpgsql STABLE<br>> A= S '<br>> DECLARE<br>> v_val BIGINT;<br>> v_4_1_par...<br>> pg_r= estore: [archiver (db)] could not execute query: ERROR: must be owner of<br= >> function uuid_generate_v1<br>> Command was: ALTER FUNCTION public.= uuid_generate_v1() OWNER TO engine;<br><br>Adding also Eli. Eli - perhaps w= e need to patch engine-backup to ignore<br>also this error? I think the min= imal flow to reproduce is:<br><br>engine-setup<br>engine-backup --mode=3Dba= ckup --file=3Df1 --log=3Dl1<br>engine-cleanup<br>engine-backup --mode=3Dres= tore --file=3Df1 --provision-db<br>--provision-dwh-db --log=3Dl2<br><br>Did= n't try this myself.<br><br>><br>><br>> pg_restore: WARNING: colum= n "user_role_title" has type "unknown"<br>> DETAIL: Proceeding with rela= tion creation anyway.<br>> pg_restore: WARNING: no privileges could be r= evoked for "public"<br>> pg_restore: WARNING: no privileges could be rev= oked for "public"<br>> pg_restore: WARNING: no privileges were granted f= or "public"<br>> pg_restore: WARNING: no privileges were granted for "pu= blic"<br>> WARNING: errors ignored on restore: 3<br>> 2018-02-28 14:3= 7:23 6339: FATAL: Errors while restoring database engine<br>><br>> __= ______________________________<br>> De: suporte@logicworks.pt<br>> Pa= ra: "Yedidyah Bar David" <didi@redhat.com><br>> Cc: "ovirt users" = <users@ovirt.org><br>> Enviadas: Quarta-feira, 28 De Fevereiro de = 2018 12:45:04<br>><br>> Assunto: Re: [ovirt-users] Backup & Resto= re<br>><br>> Still no luck:<br>><br>> # engine-backup --mode=3D= restore --file=3Dback_futur --log=3Dlog_futur<br>> --provision-db --rest= ore-permissions --provision-dwh-db<br>> Preparing to restore:<br>> - = Unpacking file 'back_futur'<br>> Restoring:<br>> - Files<br>> Prov= isioning PostgreSQL users/databases:<br>> - user 'engine', database 'eng= ine'<br>> - user 'ovirt_engine_history', database 'ovirt_engine_history'= <br>> Restoring:<br>> - Engine database 'engine'<br>> FATAL: Error= s while restoring database engine<br>><br>> I did a engine-cleanup, t= ry it again but still the same error.<br>><br>> _____________________= ___________<br>> De: "Yedidyah Bar David" <didi@redhat.com><br>>= ; Para: suporte@logicworks.pt<br>> Cc: "ovirt users" <users@ovirt.org= ><br>> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50<br>&g= t; Assunto: Re: [ovirt-users] Backup & Restore<br>><br>> On Wed, = Feb 28, 2018 at 2:10 PM, <suporte@logicworks.pt> wrote:<br>>= > Hi,<br>>><br>>> I'm testing backup & restore on Ovirt = 4.2.<br>>> I follow this doc<br>>><br>>> https://www.ovir= t.org/documentation/admin-guide/chap-Backups_and_Migration/<br>>> Try= to restore to a fresh installation but always get this error message:<br>&= gt;><br>>> restore-permissions<br>>> Preparing to restore:<b= r>>> - Unpacking file 'back_file'<br>>> Restoring:<br>>> = - Files<br>>> Provisioning PostgreSQL users/databases:<br>>> - = user 'engine', database 'engine'<br>>> Restoring:<br>>> FATAL: = Can't connect to database 'ovirt_engine_history'. Please see<br>>> '/= usr/bin/engine-backup --help'.<br>>><br>>> On the live engine I= run # engine-backup --scope=3Dall --mode=3Dbackup<br>>> --file=3Dfil= e_name --log=3Dlog_file_name<br>>><br>>> And try to restore on = a fresh installation:<br>>> # engine-backup --mode=3Drestore --file= =3Dfile_name --log=3Dlog_file_name<br>>> --provision-db --restore-per= missions<br>>><br>>> Any Idea?<br>><br>> Please try addin= g to restore command '--providion-dwh-db'. Thanks.<br>> --<br>> Didi<= br>><br>> _______________________________________________<br>> Use= rs mailing list<br>> Users@ovirt.org<br>> http://lists.ovirt.org/mail= man/listinfo/users<br><br><br><br>-- <br>Didi<br></div></div></body></html> ------=_Part_20566966_39555052.1519906078677--

hi, I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ? Emmanuel

I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7. The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup: must be owner of function uuid_generate_v1 Hope this helps, Torsten On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org

On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report! Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)? Thanks! More details: This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error. If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1515635 Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
-- Didi

Hi Yedidyah, please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz Let me know once you received them safely so I can remove them again. I also added the restore.log containing the actual error which occured during the restore. Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway. Please let me know if there is anything I can add to this. Cheers, Torsten On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...

On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance? Indeed, I can't see anything wrong in the logs above.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc. If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it. Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks. That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird. Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...
-- Didi

On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense. I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz Again, please let me know once I can remove them.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release. There was indeed one glitch during updates which was connected to the Postgres version in use: The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly). Other than that I have no idea which might have introduced this. If you find something in the logs you need more information on, please let me know. Best regards Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...

On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense.
I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz
Again, please let me know once I can remove them.
Done.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release.
The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since? The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1. Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like: engine-setup fails after restoring a backup taken with 4.2.0 Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.: yum install ovirt-engine-4.2.0.2-1.el7 (meaning, after you remove existing 4.2.7, or you can try yum downgrade). I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff. Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone...
There was indeed one glitch during updates which was connected to the Postgres version in use:
The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly).
Other than that I have no idea which might have introduced this.
All of this sounds irrelevant to current problem. Thanks for recalling :-) Best regards,
If you find something in the logs you need more information on, please let me know.
Best regards
Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote:
hi,
I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ?
Emmanuel _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...
-- Didi

On 19.12.2018 11:54, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense.
I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz
Again, please let me know once I can remove them.
Done.
Thanks, removed.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release.
The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since?
20171231170651 is most probably the date when we installed the last major release (4.2.0). We did a lot more updates since and I now have a suspicion what went wrong here. We naively assumed that a yum update is sufficient for a minor upgrade of the engine installation. Rereading the documentation I think we were missing explicit engine-setup calls after each minor upgrade. It may be the case, that the extra call to engine-setup is required to not be part of the yum update. I think in this case it would be a good idea to warn users that this step has not yet been taken and the update is not completed yet. Could this be the cause for the missing logs and behavior discrepancies? If yes, would another call to engine-setup in the current state fix this and allow us to produce correct backups in the future?
The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1.
Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like:
engine-setup fails after restoring a backup taken with 4.2.0
I currently fear that would only cure the symptom.
Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.:
yum install ovirt-engine-4.2.0.2-1.el7
(meaning, after you remove existing 4.2.7, or you can try yum downgrade).
I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff.
I don't think this is necessary.
Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone...
You are right, we did this. Best regards Torsten
There was indeed one glitch during updates which was connected to the Postgres version in use:
The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly).
Other than that I have no idea which might have introduced this.
All of this sounds irrelevant to current problem. Thanks for recalling :-)
Best regards,
If you find something in the logs you need more information on, please let me know.
Best regards
Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
I experienced the same issue while restoring a full backup (engine & dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7.
The issue went away when adding the following line to the IGNORED_ERRORS list starting at 1944 in engine-backup:
must be owner of function uuid_generate_v1
Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
Torsten
On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote: > hi, > > I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) > Have you a solution ? > > Emmanuel > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-leave@ovirt.org > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...

On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 11:54, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense.
I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz
Again, please let me know once I can remove them.
Done.
Thanks, removed.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release.
The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since?
20171231170651 is most probably the date when we installed the last major release (4.2.0). We did a lot more updates since and I now have a suspicion what went wrong here.
We naively assumed that a yum update is sufficient for a minor upgrade of the engine installation.
:-(
Rereading the documentation I think we were missing explicit engine-setup calls after each minor upgrade.
Indeed
It may be the case, that the extra call to engine-setup is required to not be part of the yum update.
engine-setup might need to ask the user questions, so we do not run it inside yum update.
I think in this case it would be a good idea to warn users that this step has not yet been taken and the update is not completed yet.
Do you think you would have noticed? It's not that hard to add such a message during yum update, but not sure it's that helpful. Perhaps we can also make the engine check e.g. if the setup package is newer than itself, and warn the user in the admin ui.
Could this be the cause for the missing logs and behavior discrepancies?
If yes, would another call to engine-setup in the current state fix this and allow us to produce correct backups in the future?
If you still have the source machine, then yes, it should be enough. Run engine-setup, then engine-backup again to backup, then restore on the new machine.
The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1.
Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like:
engine-setup fails after restoring a backup taken with 4.2.0
I currently fear that would only cure the symptom.
Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.:
yum install ovirt-engine-4.2.0.2-1.el7
(meaning, after you remove existing 4.2.7, or you can try yum downgrade).
I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff.
I don't think this is necessary.
Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone...
You are right, we did this.
OK. I assume this discussion is theoretical, right? That you already patched engine-backup manually and restored. Best regards,
Best regards
Torsten
There was indeed one glitch during updates which was connected to the Postgres version in use:
The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly).
Other than that I have no idea which might have introduced this.
All of this sounds irrelevant to current problem. Thanks for recalling :-)
Best regards,
If you find something in the logs you need more information on, please let me know.
Best regards
Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote:
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote: > > I experienced the same issue while restoring a full backup (engine & > dwh) on a clean machine. Both machines are running CentOS 7.6 and > oVirt 4.2.7. > > The issue went away when adding the following line to the IGNORED_ERRORS > list starting at 1944 in engine-backup: > > must be owner of function uuid_generate_v1 > > Hope this helps,
It does, and thanks for the report!
Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)?
Thanks!
More details:
This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error.
If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1515635
Best regards,
> > Torsten > > On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote: >> hi, >> >> I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) >> Have you a solution ? >> >> Emmanuel >> _______________________________________________ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to users-leave@ovirt.org >> > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-leave@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...
-- Didi

On 20.12.2018 07:41, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 11:54, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
Hi Yedidyah,
please find the logs at the following URL: http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz
Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
I also added the restore.log containing the actual error which occured during the restore.
Since this was a clean system I restored on, the setup has been executed after the database restore, so the setup logs probably contain nothing of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense.
I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz
Again, please let me know once I can remove them.
Done.
Thanks, removed.
Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release.
The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since?
20171231170651 is most probably the date when we installed the last major release (4.2.0). We did a lot more updates since and I now have a suspicion what went wrong here.
We naively assumed that a yum update is sufficient for a minor upgrade of the engine installation.
:-(
Rereading the documentation I think we were missing explicit engine-setup calls after each minor upgrade.
Indeed
It may be the case, that the extra call to engine-setup is required to not be part of the yum update.
engine-setup might need to ask the user questions, so we do not run it inside yum update.
As long as it clear to users that this is required this is totally ok for me.
I think in this case it would be a good idea to warn users that this step has not yet been taken and the update is not completed yet.
Do you think you would have noticed? It's not that hard to add such a message during yum update, but not sure it's that helpful.
Yes, I would probably have noticed that. Sooner or later ... :)
Perhaps we can also make the engine check e.g. if the setup package is newer than itself, and warn the user in the admin ui.
I think that both is a good idea. Some applications even go the way to lock out users from the GUI until a necessary database migration has been executed by an administrator. Your mileage may vary here but this is the solution I would favor.
Could this be the cause for the missing logs and behavior discrepancies?
If yes, would another call to engine-setup in the current state fix this and allow us to produce correct backups in the future?
If you still have the source machine, then yes, it should be enough. Run engine-setup, then engine-backup again to backup, then restore on the new machine.
Thanks, will do.
The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1.
Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like:
engine-setup fails after restoring a backup taken with 4.2.0
I currently fear that would only cure the symptom.
Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.:
yum install ovirt-engine-4.2.0.2-1.el7
(meaning, after you remove existing 4.2.7, or you can try yum downgrade).
I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff.
I don't think this is necessary.
Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone...
You are right, we did this.
OK. I assume this discussion is theoretical, right? That you already patched engine-backup manually and restored.
Yes it is. Thanks a lot for your patience and support. Torsten
Best regards,
Best regards
Torsten
There was indeed one glitch during updates which was connected to the Postgres version in use:
The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly).
Other than that I have no idea which might have introduced this.
All of this sounds irrelevant to current problem. Thanks for recalling :-)
Best regards,
If you find something in the logs you need more information on, please let me know.
Best regards
Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
Cheers,
Torsten
On 18.12.2018 07:54, Yedidyah Bar David wrote: > On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > <torsten.stolpmann@verit.de> wrote: >> >> I experienced the same issue while restoring a full backup (engine & >> dwh) on a clean machine. Both machines are running CentOS 7.6 and >> oVirt 4.2.7. >> >> The issue went away when adding the following line to the IGNORED_ERRORS >> list starting at 1944 in engine-backup: >> >> must be owner of function uuid_generate_v1 >> >> Hope this helps, > > It does, and thanks for the report! > > Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)? > > Thanks! > > More details: > > This function should not normally be included in a 4.2 backup, and I do > not yet understand why you get this error. > > If it's a clean 4.2 setup, it should never have been defined. > Earlier versions did create it, and the upgrade process should have > dropped it, if it's an upgraded setup. See also: > > https://bugzilla.redhat.com/show_bug.cgi?id=1515635 > > Best regards, > >> >> Torsten >> >> On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote: >>> hi, >>> >>> I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) >>> Have you a solution ? >>> >>> Emmanuel >>> _______________________________________________ >>> Users mailing list -- users@ovirt.org >>> To unsubscribe send an email to users-leave@ovirt.org >>> >> _______________________________________________ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to users-leave@ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O... > > > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...

On Thu, Dec 20, 2018 at 8:23 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 20.12.2018 07:41, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 11:54, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote:
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann <torsten.stolpmann@verit.de> wrote: > > Hi Yedidyah, > > please find the logs at the following URL: > http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz > > Let me know once you received them safely so I can remove them again.
Done.
Thanks, removed.
> > I also added the restore.log containing the actual error which occured > during the restore. > > Since this was a clean system I restored on, the setup has been executed > after the database restore, so the setup logs probably contain nothing > of interest. I added them anyway.
Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance?
Indeed, I can't see anything wrong in the logs above.
Sorry for misunderstanding, this totally makes sense.
I added the setup logs i found at: http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz
Again, please let me know once I can remove them.
Done.
Thanks, removed.
> > Please let me know if there is anything I can add to this.
If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc.
We started with one of the first 4.0 releases and updated the system on a regular basis since then. We almost never skipped a release.
The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since?
20171231170651 is most probably the date when we installed the last major release (4.2.0). We did a lot more updates since and I now have a suspicion what went wrong here.
We naively assumed that a yum update is sufficient for a minor upgrade of the engine installation.
:-(
Rereading the documentation I think we were missing explicit engine-setup calls after each minor upgrade.
Indeed
It may be the case, that the extra call to engine-setup is required to not be part of the yum update.
engine-setup might need to ask the user questions, so we do not run it inside yum update.
As long as it clear to users that this is required this is totally ok for me.
I think in this case it would be a good idea to warn users that this step has not yet been taken and the update is not completed yet.
Do you think you would have noticed? It's not that hard to add such a message during yum update, but not sure it's that helpful.
Yes, I would probably have noticed that. Sooner or later ... :)
OK, now finished verifying this patch in CI: https://gerrit.ovirt.org/96446 https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests... https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests... Total output of: 2018-12-27 06:58:03,392::ssh.py::ssh::58::lago.ssh::DEBUG::Running c14e276c on lago-upgrade-from-release-suite-master-engine: yum -y update ovirt-*setup* Is 220 lines. Among these, line 134-136 are: Updating : ovirt-engine-setup-4.3.0-0.4.master.20181226121322.gitfe 17/33 Updating ovirt-engine-setup. To update the engine, you need to run: engine-setup Updating : ovirt-engine-setup-plugin-websocket-proxy-4.3.0-0.4.mast 18/33 and lines 151-153 are: Erasing : ovirt-engine-lib-4.2.8.2-0.0.master.20181220151741.git31 33/33 Updated ovirt-engine-setup. To update the engine, you need to run: engine-setup Verifying : ovirt-engine-dwh-setup-4.3.0-0.4.master.20181210085817.e 1/33 I looked at yum's sources, and do not see a way to make it output something closer to the end. Comments are welcome (here or on gerrit).
Perhaps we can also make the engine check e.g. if the setup package is newer than itself, and warn the user in the admin ui.
I think that both is a good idea. Some applications even go the way to lock out users from the GUI until a necessary database migration has been executed by an administrator. Your mileage may vary here but this is the solution I would favor.
Also filed (but am not going to try working on, it's not my expertise): https://bugzilla.redhat.com/show_bug.cgi?id=1662109 Best regards,
Could this be the cause for the missing logs and behavior discrepancies?
If yes, would another call to engine-setup in the current state fix this and allow us to produce correct backups in the future?
If you still have the source machine, then yes, it should be enough. Run engine-setup, then engine-backup again to backup, then restore on the new machine.
Thanks, will do.
The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1.
Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like:
engine-setup fails after restoring a backup taken with 4.2.0
I currently fear that would only cure the symptom.
Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.:
yum install ovirt-engine-4.2.0.2-1.el7
(meaning, after you remove existing 4.2.7, or you can try yum downgrade).
I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff.
I don't think this is necessary.
Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone...
You are right, we did this.
OK. I assume this discussion is theoretical, right? That you already patched engine-backup manually and restored.
Yes it is.
Thanks a lot for your patience and support.
Torsten
Best regards,
Best regards
Torsten
There was indeed one glitch during updates which was connected to the Postgres version in use:
The initial install was (accidentally) done under Postgres 9.4 which happened to be present on the machine at that point of time. oVirt 4.0 was allowing this way back then. I think in 4.1 Postgres 9.2 has been enforced, so there had been workarounds to allow updates under 9.4. This got resolved with the migration to 4.2 which brought the Postgres 9.5 installation (if I recall that correctly).
Other than that I have no idea which might have introduced this.
All of this sounds irrelevant to current problem. Thanks for recalling :-)
Best regards,
If you find something in the logs you need more information on, please let me know.
Best regards
Torsten
If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it.
Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks.
That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird.
Thanks and best regards,
> > Cheers, > > Torsten > > > On 18.12.2018 07:54, Yedidyah Bar David wrote: >> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann >> <torsten.stolpmann@verit.de> wrote: >>> >>> I experienced the same issue while restoring a full backup (engine & >>> dwh) on a clean machine. Both machines are running CentOS 7.6 and >>> oVirt 4.2.7. >>> >>> The issue went away when adding the following line to the IGNORED_ERRORS >>> list starting at 1944 in engine-backup: >>> >>> must be owner of function uuid_generate_v1 >>> >>> Hope this helps, >> >> It does, and thanks for the report! >> >> Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)? >> >> Thanks! >> >> More details: >> >> This function should not normally be included in a 4.2 backup, and I do >> not yet understand why you get this error. >> >> If it's a clean 4.2 setup, it should never have been defined. >> Earlier versions did create it, and the upgrade process should have >> dropped it, if it's an upgraded setup. See also: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1515635 >> >> Best regards, >> >>> >>> Torsten >>> >>> On 24.05.2018 11:32, emmanuel.thetas@obs-nancay.fr wrote: >>>> hi, >>>> >>>> I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) >>>> Have you a solution ? >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> Users mailing list -- users@ovirt.org >>>> To unsubscribe send an email to users-leave@ovirt.org >>>> >>> _______________________________________________ >>> Users mailing list -- users@ovirt.org >>> To unsubscribe send an email to users-leave@ovirt.org >>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YMMFCYUMLCM47O... >> >> >> > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-leave@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCN5WVAJOGFBUT...
-- Didi
participants (4)
-
emmanuel.thetas@obs-nancay.fr
-
suporte@logicworks.pt
-
Torsten Stolpmann
-
Yedidyah Bar David