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