8:51 p.m.
This is a multi-part message in MIME format.
--------------000705080309010305090703
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
We need to understand Postgress backup & restore process to understand
these properly. Not having such an expertise with Postgress.
Any way, interesting discussions..worth spending time to understand it
properly. That answers many questions....
--
Thanks & Regards,
Anantha Raghava
On Thursday 09 June 2016 06:41 PM, Yedidyah Bar David wrote:
On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava
<raghav(a)exzatechconsulting.com> wrote:
> Hi,
>
> Thanks for taking time and reverting back to me.
>
> I have seen this explanation from engine-backup help and realise that it is
> something to do with Postgres DB restore activity. But not much said about
> it. I feel it instructs Postgress DB to restore the DB without privileges
> with which the object was created, but use new permissions & privileges
> passed along with --change-db-credentials and others passed during
> engine-backup --mode=restore.
Exactly.
And if you do not pass --change-db-credentials, you'll simply get the
default, which is to just give permissions to the user creating the
schema.
Bottom line: If you used only defaults, and did not create users
and give them grants, there is no difference between the options.
They'll create the exact same database. If you did add grants, you
must choose.
I agree it's not very user-friendly to require choice, but please
take into consideration that if you had a large setup (say hundreds
of VMs or more) with dwh history included over some time, you'll have
a large database, and I think it will be much less friendly if we
"just try" restoring (which can take several hours then) and fail
in the end due to missing users.
Please also see the discussion on these bugs for more details:
https://bugzilla.redhat.com/show_bug.cgi?id=1217402
https://bugzilla.redhat.com/show_bug.cgi?id=1220791
Best,
> However not sure.
>
> --
>
> Thanks & Regards,
>
> Anantha Raghava
> On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:
>
> On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:
>
> Hello Alexander,
>
> You are right. The FQDN was the culprit. Once I entered the FQDN in
> /etc/hosts file, the problem got resolved.
>
> Thanks for your guidance.
>
> By the way any document that explains what is --restore-permissions in
> engine-backup process?
>
> If you type engine-backup --help you will get a list and explanation of all
> the possible options.
>
> Affects only the custom dump format. Will not pass to pg_restore '--no-owner
> --
> no-privileges'. Might not work as expected with the --*db-user options.
>
> Is what the --help says, not sure what that means though.
>
> Hi,
>
> I will try both options tomorrow & revert back here.
>
> Regards,
> Anantha Raghava
>
> On Jun 8, 2016 10:04 PM, "Alexander Wels" <awels(a)redhat.com
>
> <mailto:awels@redhat.com>> wrote:
> On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
> > Hi,
> >
> > I was able to migrate the oVirt Engine from one host to another
>
> using
>
> > engine-backup utility. On the new host, the data is loaded
>
> properly but
>
> > the Administration Portal is terribly slow.
> >
> > It take about 2 to 3 minutes to allow me to enter user name &
>
> password.
>
> > Once logged in, it takes hell a lot of time to show up the data.
>
> Click
>
> > on a tab, we need to wait for a good amount of time to see the
>
> actual
>
> > data. Even the refresh is taking time to execute although it is
>
> set to 5
>
> > Seconds.
> >
> > But if I enable old server and connect, every thing works quickly.
> >
> > Note:
> >
> > 1. We do not have DNS in our environment.
> > 2. Engine name & even the IP is retained the same.
> > 3. Before migration, we stopped ovirt-engine on old server, took the
> > backup, shutdown & disconnected the old server.
> > 4. We installed the ovirt-engine on new server, run engine
>
> setup, noted
>
> > down the DB password, did engine-cleanup, restored the data using
> > engine-backup utility and executed engine-setup again. It did
>
> recognize
>
> > restored data and only httpd configuration was sought and we
>
> selected
>
> > the defaults.
>
> It is highly likely 1 of 2 things:
>
> 1. The entropy mentioned by Brett, however that is mostly
> applicable on hosted
> engine as VMs don't usually have good entropy.
> 2. The engine cannot resolve itself (which looking at your
> description is the
> likely culprit). Since you don't have DNS, you need to add the fqdn to
> /etc/hosts so it can resolve itself.
>
> > Result is terribly slow Web Console.
> >
> > First, we attempted to setup ovirt-reports and later removed it
>
> thinking
>
> > that may be slowing down the engine server. Yet the same result.
> >
> > Commands used to backup from old server: "engine-backup
>
> --mode=backup
>
> > --file=<filename> --log=<log file name> --provision-db"
> > Command used to restore on new server: "engine-backup --mode=restore
> > --file=<backup-file-name> --log=<log-file-name>
>
> --change-db-credentials
>
> > --db-host=localhost --db-user=engine --db-name=engine
> > --db-password=<password noted down in step 4>
>
> --no-restore-permissions"
>
> > The command executed without any errors, resulting in a terribly
>
> slow
>
> > web console.
> >
> > Note: Without --restore-permissions, the restore fails. Did not
> > understand what to give as restore permissions. Hence used
> > --no-restore-permissions.
> >
> > *Hardware configuration:*
> > *
> > **Old Server:* i3 Processor, 4 GB Memory, 1 Gbps NIC
> > *New Server :* Lenovo x3250 M5 Server with Intel Xeon Processor,
>
> 16 GB
>
> > RAM, 2 X 1 Gbps NIC.
> >
> > Just unable to understand why it is terribly slow.
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
--------------000705080309010305090703
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Liberation Serif">Hi,<br>
<br>
We need to understand Postgress backup & restore process to
understand these properly. Not having such an expertise with
Postgress.<br>
<br>
Any way, interesting discussions..worth spending time to
understand it properly. That answers many questions....<br>
</font>
<div class="moz-cite-prefix">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<title></title>
<meta name="generator" content="LibreOffice 5.0.3.2
(Linux)">
<meta name="created" content="00:00:00">
<meta name="changedby" content="Anantha Raghava">
<meta name="changed"
content="2016-01-05T17:20:50.677541300">
<meta name="created" content="00:00:00">
<meta name="changedby" content="Anantha Raghava">
<meta name="changed"
content="2015-12-20T09:03:26.251763811">
<meta name="created" content="2015-02-21T00:00:00">
<meta name="changedby" content="Anantha Raghava">
<meta name="changed"
content="2015-12-20T09:02:11.666821134">
<style type="text/css">
@page { margin: 2cm }
p { margin-bottom: 0.25cm; color: #000000; line-height: 120% }
address { color: #000000 }
a:link { so-language: zxx }
</style>
<p>-- </p>
<p style="margin-bottom: 0cm; line-height: 100%"><font
face="Times
New Roman, serif">Thanks
& Regards,</font></p>
<address style="line-height: 100%"><font face="Times New
Roman,
serif">Anantha
Raghava</font></address>
<br>
On Thursday 09 June 2016 06:41 PM, Yedidyah Bar David wrote:<br>
</div>
<blockquote
cite="mid:CAHRwYXtKQktXyHRHoTEQO_95VmbmyF_2K1zR3NbHSd13-avYMw@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava
<a class="moz-txt-link-rfc2396E"
href="mailto:raghav@exzatechconsulting.com"><raghav@exzatechconsulting.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
Thanks for taking time and reverting back to me.
I have seen this explanation from engine-backup help and realise that it is
something to do with Postgres DB restore activity. But not much said about
it. I feel it instructs Postgress DB to restore the DB without privileges
with which the object was created, but use new permissions & privileges
passed along with --change-db-credentials and others passed during
engine-backup --mode=restore.
</pre>
</blockquote>
<pre wrap="">
Exactly.
And if you do not pass --change-db-credentials, you'll simply get the
default, which is to just give permissions to the user creating the
schema.
Bottom line: If you used only defaults, and did not create users
and give them grants, there is no difference between the options.
They'll create the exact same database. If you did add grants, you
must choose.
I agree it's not very user-friendly to require choice, but please
take into consideration that if you had a large setup (say hundreds
of VMs or more) with dwh history included over some time, you'll have
a large database, and I think it will be much less friendly if we
"just try" restoring (which can take several hours then) and fail
in the end due to missing users.
Please also see the discussion on these bugs for more details:
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1217402">h...
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1220791">h...
Best,
</pre>
<blockquote type="cite">
<pre wrap="">
However not sure.
--
Thanks & Regards,
Anantha Raghava
On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:
On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in
/etc/hosts file, the problem got resolved.
Thanks for your guidance.
By the way any document that explains what is --restore-permissions in
engine-backup process?
If you type engine-backup --help you will get a list and explanation of all
the possible options.
Affects only the custom dump format. Will not pass to pg_restore '--no-owner
--
no-privileges'. Might not work as expected with the --*db-user options.
Is what the --help says, not sure what that means though.
Hi,
I will try both options tomorrow & revert back here.
Regards,
Anantha Raghava
On Jun 8, 2016 10:04 PM, "Alexander Wels" <<a
class="moz-txt-link-abbreviated"
href="mailto:awels@redhat.com">awels@redhat.com</a>
<a class="moz-txt-link-rfc2396E"
href="mailto:awels@redhat.com"><mailto:awels@redhat.com></a>>
wrote:
On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
> Hi,
>
> I was able to migrate the oVirt Engine from one host to another
using
> engine-backup utility. On the new host, the data is loaded
properly but
> the Administration Portal is terribly slow.
>
> It take about 2 to 3 minutes to allow me to enter user name &
password.
> Once logged in, it takes hell a lot of time to show up the data.
Click
> on a tab, we need to wait for a good amount of time to see the
actual
> data. Even the refresh is taking time to execute although it is
set to 5
> Seconds.
>
> But if I enable old server and connect, every thing works quickly.
>
> Note:
>
> 1. We do not have DNS in our environment.
> 2. Engine name & even the IP is retained the same.
> 3. Before migration, we stopped ovirt-engine on old server, took the
> backup, shutdown & disconnected the old server.
> 4. We installed the ovirt-engine on new server, run engine
setup, noted
> down the DB password, did engine-cleanup, restored the data using
> engine-backup utility and executed engine-setup again. It did
recognize
> restored data and only httpd configuration was sought and we
selected
> the defaults.
It is highly likely 1 of 2 things:
1. The entropy mentioned by Brett, however that is mostly
applicable on hosted
engine as VMs don't usually have good entropy.
2. The engine cannot resolve itself (which looking at your
description is the
likely culprit). Since you don't have DNS, you need to add the fqdn to
/etc/hosts so it can resolve itself.
> Result is terribly slow Web Console.
>
> First, we attempted to setup ovirt-reports and later removed it
thinking
> that may be slowing down the engine server. Yet the same result.
>
> Commands used to backup from old server: "engine-backup
--mode=backup
> --file=<filename> --log=<log file name>
--provision-db"
> Command used to restore on new server: "engine-backup --mode=restore
> --file=<backup-file-name> --log=<log-file-name>
--change-db-credentials
> --db-host=localhost --db-user=engine --db-name=engine
> --db-password=<password noted down in step 4>
--no-restore-permissions"
> The command executed without any errors, resulting in a terribly
slow
> web console.
>
> Note: Without --restore-permissions, the restore fails. Did not
> understand what to give as restore permissions. Hence used
> --no-restore-permissions.
>
> *Hardware configuration:*
> *
> **Old Server:* i3 Processor, 4 GB Memory, 1 Gbps NIC
> *New Server :* Lenovo x3250 M5 Server with Intel Xeon Processor,
16 GB
> RAM, 2 X 1 Gbps NIC.
>
> Just unable to understand why it is terribly slow.
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
--------------000705080309010305090703--