1:10 p.m.
------=_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/&l...
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=
<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=
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--
1:24 p.m.
On Wed, Feb 28, 2018 at 2:10 PM, <suporte(a)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
1:45 p.m.
------=_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(a)redhat.com>
Para: suporte(a)logicworks.pt
Cc: "ovirt users" <users(a)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(a)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/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(a)logicworks.pt<br><b>Cc: </b>"ovirt user=
s" &lt;users(a)ovirt.org&gt;<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, &nbsp;&lt;suporte(a)logicworks.pt&gt; wrote:<br>>
Hi,<br>><br=
> 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 =
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--
3:44 p.m.
------=_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(a)logicworks.pt
Para: "Yedidyah Bar David" <didi(a)redhat.com>
Cc: "ovirt users" <users(a)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(a)redhat.com>
Para: suporte(a)logicworks.pt
Cc: "ovirt users" <users(a)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(a)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(a)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"=
</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(a)logicworks.pt<br><b>Para:
</b>"Yedidyah Bar David" &=
lt;didi(a)redhat.com&gt;<br><b>Cc: </b>"ovirt users"
&lt;users(a)ovirt.org&gt;<=
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(a)redhat.com&gt;<br><b>Para:
</b>suporte(a)logicworks.pt<br><b>Cc: </b>"o=
virt users" &lt;users(a)ovirt.org&gt;<br><b>Enviadas:
</b>Quarta-feira, 28 De=
Fevereiro de 2018 12:24:50<br><b>Assunto: </b>Re: [ovirt-users] Backup
&am=
p; Restore<br></div><br><div>On Wed, Feb 28, 2018 at 2:10 PM,
<sup=
orte(a)logicworks.pt&gt; 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>...
body></html>
------=_Part_20349653_1465707940.1519829079176--
8:28 a.m.
On Wed, Feb 28, 2018 at 4:44 PM, <suporte(a)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(a)logicworks.pt
Para: "Yedidyah Bar David" <didi(a)redhat.com>
Cc: "ovirt users" <users(a)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(a)redhat.com>
Para: suporte(a)logicworks.pt
Cc: "ovirt users" <users(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Didi
1:07 p.m.
------=_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(a)redhat.com>
To: suporte(a)logicworks.pt, "Eli Mesika" <emesika(a)redhat.com>
Cc: "ovirt users" <users(a)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(a)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(a)logicworks.pt
Para: "Yedidyah Bar David" <didi(a)redhat.com>
Cc: "ovirt users" <users(a)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(a)redhat.com>
Para: suporte(a)logicworks.pt
Cc: "ovirt users" <users(a)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(a)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(a)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" &lt;didi(a)redhat.com&gt;<br><b>To:
</b>suporte(a)logicworks.pt, "El=
i Mesika" &lt;emesika(a)redhat.com&gt;<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(a)logicworks.pt&gt; 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(a)logicworks.pt<br>&gt; Pa=
ra: "Yedidyah Bar David" &lt;didi(a)redhat.com&gt;<br>&gt; Cc:
"ovirt users" =
&lt;users(a)ovirt.org&gt;<br>&gt; 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"
&lt;didi(a)redhat.com&gt;<br>&gt=
; Para: suporte(a)logicworks.pt<br>&gt; Cc: "ovirt users"
&lt;users(a)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, &nbsp;&lt;suporte(a)logicworks.pt&gt;
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(a)ovirt.org<br>&gt;
http://lists.ovirt.org/mail=
man/listinfo/users<br><br><br><br>--
<br>Didi<br></div></div></body></html>
------=_Part_20566966_39555052.1519906078677--
11:32 a.m.
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
1:16 p.m.
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(a)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(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
7:54 a.m.
On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)ovirt.org
> To unsubscribe send an email to users-leave(a)ovirt.org
>
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
--
Didi
4:17 p.m.
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(a)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(a)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(a)ovirt.org
>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>
>
>
8:01 a.m.
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)ovirt.org
>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>
>
>
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
--
Didi
11:34 a.m.
On 19.12.2018 08:01, Yedidyah Bar David wrote:
On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)ovirt.org
>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>
>>>> _______________________________________________
>>>> Users mailing list -- users(a)ovirt.org
>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>
>>>
>>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>
>
>
11:54 a.m.
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)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(a)ovirt.org
>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>
>>>> _______________________________________________
>>>> Users mailing list -- users(a)ovirt.org
>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>
>>>
>>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>
>
>
--
Didi
12:35 p.m.
On 19.12.2018 11:54, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)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(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list -- users(a)ovirt.org
>>>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>>>
>>>
>>>
>
>
>
7:41 a.m.
On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)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(a)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(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list -- users(a)ovirt.org
>>>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>>>
>>>
>>>
>
>
>
--
Didi
7:23 p.m.
On 20.12.2018 07:41, Yedidyah Bar David wrote:
On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)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(a)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(a)ovirt.org
>>>>>>>>> To unsubscribe send an email to
users-leave(a)ovirt.org
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
9:07 a.m.
On Thu, Dec 20, 2018 at 8:23 PM Torsten Stolpmann
<torsten.stolpmann(a)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(a)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(a)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(a)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-te...
https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-te...
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(a)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(a)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(a)ovirt.org
>>>>>>>>> To unsubscribe send an email to
users-leave(a)ovirt.org
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>>> To unsubscribe send an email to users-leave(a)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/YMMFCYUMLCM...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>> To unsubscribe send an email to users-leave(a)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/FCN5WVAJOGF...
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
--
Didi
1951
days inactive
2253
days old
16 comments
4 participants
participants (4)
-
emmanuel.thetas＠obs-nancay.fr -
suporte＠logicworks.pt -
Torsten Stolpmann -
Yedidyah Bar David