12:19 a.m.
This is a multi-part message in MIME format.
--------------050505040201020408000404
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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.
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.
--
Thanks & Regards,
Anantha Raghava
--------------050505040201020408000404
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Liberation Serif">Hi,<br>
<br>
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.<br>
<br>
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.<br>
</font><br>
<font face="Liberation Serif">But if I enable old server and
connect, every thing works quickly.<br>
<br>
Note:<br>
<br>
1. We do not have DNS in our environment.<br>
2. Engine name & even the IP is retained the same.<br>
3. Before migration, we stopped ovirt-engine on old server, took
the backup, shutdown & disconnected the old server.<br>
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.<br>
<br>
Result is terribly slow Web Console.<br>
<br>
First, we attempted to setup ovirt-reports and later removed it
thinking that may be slowing down the engine server. Yet the same
result.<br>
<br>
Commands used to backup from old server: </font><font
face="Liberation Serif">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
"engine-backup --mode=backup --file=<filename> --log=<log
file name> --provision-db"<br>
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"<br>
<br>
The command executed without any errors, resulting in a terribly
slow web console.<br>
<br>
Note: Without --restore-permissions, the restore fails. Did not
understand what to give as restore permissions. Hence used
--no-restore-permissions.<br>
<br>
<b>Hardware configuration:</b><br>
<b><br>
</b><b>Old Server:</b> i3 Processor, 4 GB Memory, 1 Gbps
NIC<br>
<b>New Server :</b> Lenovo x3250 M5 Server with Intel Xeon
Processor, 16 GB RAM, 2 X 1 Gbps NIC.<br>
<br>
Just unable to understand why it is terribly slow.<br>
</font>
<div class="moz-signature">
<p>-- </p>
<p style="margin-bottom: 0cm; line-height: 100%"><font
face="Times
New Roman, serif"><font face="Times New Roman,
serif">T</font>hanks
&
Regards,</font></p>
<address style="line-height: 100%"><font face="Times New
Roman,
serif">Anantha
Raghava</font></address>
<br>
</div>
</body>
</html>
--------------050505040201020408000404--
1:15 a.m.
This is a multi-part message in MIME format.
--------------4E79D83BB3F9B1CA903BCE15
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
On 06/08/2016 11:19 AM, Anantha Raghava wrote:
What version of oVirt are you running. Before 3.6.5 there was an issue
because of the generation of random numbers. Many hosts and VMs don't
have much mouse and keyboard activity so it takes forever to generate
the entropy needed for the connection process. I was told to check the
entropy level with
cat /proc/sys/kernel/random/entropy_avail
I installed haveged and that fixed it but I'm now on 3.6.5.
--------------4E79D83BB3F9B1CA903BCE15
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 06/08/2016 11:19 AM, Anantha Raghava
wrote:<br>
</div>
<blockquote cite="mid:57583774.5050604@exzatechconsulting.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<font face="Liberation Serif">Hi,<br>
<br>
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.<br>
<br>
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.<br>
</font><br>
<font face="Liberation Serif">But if I enable old server and
connect, every thing works quickly.<br>
<br>
Note:<br>
<br>
1. We do not have DNS in our environment.<br>
2. Engine name & even the IP is retained the same.<br>
3. Before migration, we stopped ovirt-engine on old server, took
the backup, shutdown & disconnected the old server.<br>
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.<br>
<br>
Result is terribly slow Web Console.<br>
<br>
First, we attempted to setup ovirt-reports and later removed it
thinking that may be slowing down the engine server. Yet the
same result.<br>
<br>
Commands used to backup from old server: </font><font
face="Liberation Serif">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
"engine-backup --mode=backup --file=<filename>
--log=<log file name> --provision-db"<br>
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"<br>
<br>
The command executed without any errors, resulting in a terribly
slow web console.<br>
<br>
Note: Without --restore-permissions, the restore fails. Did not
understand what to give as restore permissions. Hence used
--no-restore-permissions.<br>
<br>
<b>Hardware configuration:</b><br>
<b><br>
</b><b>Old Server:</b> i3 Processor, 4 GB Memory, 1 Gbps
NIC<br>
<b>New Server :</b> Lenovo x3250 M5 Server with Intel Xeon
Processor, 16 GB RAM, 2 X 1 Gbps NIC.<br>
<br>
Just unable to understand why it is terribly slow.<br>
</font>
<div class="moz-signature"> </div>
</blockquote>
<br>
What version of oVirt are you running. Before 3.6.5 there was an
issue because of the generation of random numbers. Many hosts and
VMs don't have much mouse and keyboard activity so it takes forever
to generate the entropy needed for the connection process. I was
told to check the entropy level with <br>
<br>
<pre wrap="">cat /proc/sys/kernel/random/entropy_avail
I installed haveged and that fixed it but I'm now on 3.6.5.
</pre>
<br>
<blockquote cite="mid:57583774.5050604@exzatechconsulting.com"
type="cite">
<div class="moz-signature">
<p>-- </p>
<p style="margin-bottom: 0cm; line-height: 100%"><font
face="Times New Roman, serif"><font face="Times New
Roman,
serif">T</font>hanks
& Regards,</font></p>
<address style="line-height: 100%"><font face="Times New
Roman,
serif">Anantha Raghava</font></address>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<br>
</body>
</html>
--------------4E79D83BB3F9B1CA903BCE15--
10:48 a.m.
--Sig_/_PM0=kVmNc7Uf8r_bE5Rwtf
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Wed, 8 Jun 2016 12:15:20 -0400 Brett wrote:
BIH> > I was able to migrate the oVirt Engine from one host to another usin=
g=20
BIH> > engine-backup utility. On the new host, the data is loaded properly=
=20
BIH> > but the Administration Portal is terribly slow.
BIH> >
BIH> > It take about 2 to 3 minutes to allow me to enter user name &=20
BIH> > password.
BIH> [...]
BIH> What version of oVirt are you running. Before 3.6.5 there was an issu=
e=20
BIH> because of the generation of random numbers. Many hosts and VMs don't=
=20
BIH> have much mouse and keyboard activity so it takes forever to generate=
=20
BIH> the entropy needed for the connection process. I was told to check th=
e=20
BIH> entropy level with
BIH>=20
BIH> cat /proc/sys/kernel/random/entropy_avail
BIH>=20
BIH> I installed haveged and that fixed it but I'm now on 3.6.5.
I was having this issue on 3.5.x and thought it was because I didn't have
enough memory. Checked my entropy, and it was less than 200. Installed
haveged on my hosted-engine, and now entropy is over 2000 and it takes less
than 10 seconds to log in. Thank you!
Robert
--=20
Senior Software Engineer @ Parsons
--Sig_/_PM0=kVmNc7Uf8r_bE5Rwtf
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
--Sig_/_PM0=kVmNc7Uf8r_bE5Rwtf--
1:34 a.m.
On Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:
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.
3:58 p.m.
This is a multi-part message in MIME format.
--------------090506010306080601060001
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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?
--
Thanks & Regards,
Anantha Raghava
On Wednesday 08 June 2016 10:28 PM, Anantha Raghava wrote:
--------------090506010306080601060001
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">Hello Alexander,<br>
<br>
You are right. The FQDN was the culprit. Once I entered the FQDN
in /etc/hosts file, the problem got resolved.<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><br>
Thanks for your guidance.<br>
<br>
By the way any document that explains what is
--restore-permissions in engine-backup process?<br>
<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 Wednesday 08 June 2016 10:28 PM, Anantha Raghava wrote:<br>
</div>
<blockquote
cite="mid:CAF_HQmV2u6cP_gJmrSjcKjUhZ=W8DTZpQCtuz9UqK739Wk_Trw@mail.gmail.com"
type="cite">
<p dir="ltr">Hi,</p>
<p dir="ltr">I will try both options tomorrow & revert back
here.</p>
<p dir="ltr">Regards,<br>
Anantha Raghava</p>
<div class="gmail_quote">On Jun 8, 2016 10:04 PM, "Alexander
Wels"
<<a moz-do-not-send="true"
href="mailto:awels@redhat.com">awels@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
Wednesday, June 08, 2016 08:49:16 PM Anantha Raghava wrote:<br>
> Hi,<br>
><br>
> I was able to migrate the oVirt Engine from one host to
another using<br>
> engine-backup utility. On the new host, the data is
loaded properly but<br>
> the Administration Portal is terribly slow.<br>
><br>
> It take about 2 to 3 minutes to allow me to enter user
name & password.<br>
> Once logged in, it takes hell a lot of time to show up
the data. Click<br>
> on a tab, we need to wait for a good amount of time to
see the actual<br>
> data. Even the refresh is taking time to execute although
it is set to 5<br>
> Seconds.<br>
><br>
> But if I enable old server and connect, every thing works
quickly.<br>
><br>
> Note:<br>
><br>
> 1. We do not have DNS in our environment.<br>
> 2. Engine name & even the IP is retained the same.<br>
> 3. Before migration, we stopped ovirt-engine on old
server, took the<br>
> backup, shutdown & disconnected the old server.<br>
> 4. We installed the ovirt-engine on new server, run
engine setup, noted<br>
> down the DB password, did engine-cleanup, restored the
data using<br>
> engine-backup utility and executed engine-setup again. It
did recognize<br>
> restored data and only httpd configuration was sought and
we selected<br>
> the defaults.<br>
><br>
<br>
It is highly likely 1 of 2 things:<br>
<br>
1. The entropy mentioned by Brett, however that is mostly
applicable on hosted<br>
engine as VMs don't usually have good entropy.<br>
2. The engine cannot resolve itself (which looking at your
description is the<br>
likely culprit). Since you don't have DNS, you need to add the
fqdn to<br>
/etc/hosts so it can resolve itself.<br>
<br>
> Result is terribly slow Web Console.<br>
><br>
> First, we attempted to setup ovirt-reports and later
removed it thinking<br>
> that may be slowing down the engine server. Yet the same
result.<br>
><br>
> Commands used to backup from old server: "engine-backup
--mode=backup<br>
> --file=<filename> --log=<log file name>
--provision-db"<br>
> Command used to restore on new server: "engine-backup
--mode=restore<br>
> --file=<backup-file-name>
--log=<log-file-name> --change-db-credentials<br>
> --db-host=localhost --db-user=engine --db-name=engine<br>
> --db-password=<password noted down in step 4>
--no-restore-permissions"<br>
><br>
> The command executed without any errors, resulting in a
terribly slow<br>
> web console.<br>
><br>
> Note: Without --restore-permissions, the restore fails.
Did not<br>
> understand what to give as restore permissions. Hence
used<br>
> --no-restore-permissions.<br>
><br>
> *Hardware configuration:*<br>
> *<br>
> **Old Server:* i3 Processor, 4 GB Memory, 1 Gbps NIC<br>
> *New Server :* Lenovo x3250 M5 Server with Intel Xeon
Processor, 16 GB<br>
> RAM, 2 X 1 Gbps NIC.<br>
><br>
> Just unable to understand why it is terribly slow.<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
--------------090506010306080601060001--
9:17 p.m.
On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava wrote:
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.
9:33 p.m.
This is a multi-part message in MIME format.
--------------000801050104030100090108
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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.
However not sure.
--
Thanks & Regards,
Anantha Raghava
On Thursday 09 June 2016 05:47 PM, Alexander Wels wrote:
--------------000801050104030100090108
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Liberation Serif">Hi,<br>
<br>
Thanks for taking time and reverting back to me.<br>
<br>
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.<br>
<br>
However not sure.<br>
</font>
<div class="moz-signature">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<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>
</div>
<div class="moz-cite-prefix">On Thursday 09 June 2016 05:47 PM,
Alexander Wels wrote:<br>
</div>
<blockquote cite="mid:2043255.Gr6fjucEjz@awels"
type="cite">
<pre wrap="">On Thursday, June 09, 2016 12:28:41 PM Anantha Raghava
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
--------------000801050104030100090108--
10:11 p.m.
On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava
<raghav(a)exzatechconsulting.com> wrote:
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,
--
Didi
2:51 a.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:
--------------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--
10:11 p.m.
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello,
I have not understood clearly whether your were using hosted engine or
bare-metal?
I'm asking that because - as Alex knows it - I'm facing this terribly
slowness since months, and we took a lot a time trying to figure it out,
to no avail.
We're using 3.6.5 and bare-metal engine.
I triple checked DNS resolution, added (anyway) relevant fqdn in
/etc/hosts, install (anyway) haveged and rebooted.
We checked all that with Alex, but seeing nothing obvious.
So far, the web gui usage is still a real daily pain.
--
Nicolas ECARNOT
10:31 p.m.
On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
And we verified the ping between your browser machine and the engine was low.
The load on the engine was near 0. That your browser was either Chrome/FF and
that the machine running the browser is plenty powerful.
Did you ever disable the repos besides the 3.6 one and run a yum update (on
the engine)? Greg one of the other maintainers recently did some performance
improvements, I just don't remember which version they go into. either 3.6.5
or 3.6.6. If I remember correctly for some reason it takes a long time to get
data from the engine to your browser, we just don't know why it takes so long
as we profiled the engine running in your environment and that was all fine as
well.
10:47 p.m.
Le 09/06/2016 15:31, Alexander Wels a écrit :
Yes, I did.
Two DC are still running on 3.6.3, and four others are running on 3.6.5.
Amongst the 3.6.5, some were updated from below, and some were installed
from scratch (so no negative legacy nor prehistoric RPMs or repos).
Greg one of the other maintainers recently did some performance
improvements, I just don't remember which version they go into. either 3.6.5
or 3.6.6.
May you Cc: to Greg?
I recall correctly.
I'm also witnessing memory leaks, that I think were fixed recently.
--
Nicolas ECARNOT
2:53 a.m.
This is a multi-part message in MIME format.
--------------090408030707060009030604
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Hello Nicholas,
We are using bare-metal server with CentOS 7 OS and oVirt version is
3.6.6 GA.
--
Thanks & Regards,
Anantha Raghava
On Thursday 09 June 2016 06:41 PM, Nicolas Ecarnot wrote:
--------------090408030707060009030604
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Liberation Serif">Hello Nicholas,</font><br>
<div class="moz-cite-prefix">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<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 style="margin-bottom: 0cm">We are using bare-metal server with
CentOS 7 OS and oVirt version is 3.6.6 GA. <br>
</p>
<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, Nicolas Ecarnot wrote:<br>
</div>
<blockquote cite="mid:57596AEB.4000805@ecarnot.net"
type="cite">Le
09/06/2016 08:58, Anantha Raghava a écrit :
<br>
<blockquote type="cite">Hello Alexander,
<br>
<br>
You are right. The FQDN was the culprit. Once I entered the FQDN
in
<br>
/etc/hosts file, the problem got resolved.
<br>
</blockquote>
<br>
Hello,
<br>
<br>
I have not understood clearly whether your were using hosted
engine or bare-metal?
<br>
<br>
I'm asking that because - as Alex knows it - I'm facing this
terribly slowness since months, and we took a lot a time trying to
figure it out, to no avail.
<br>
We're using 3.6.5 and bare-metal engine.
<br>
I triple checked DNS resolution, added (anyway) relevant fqdn in
/etc/hosts, install (anyway) haveged and rebooted.
<br>
We checked all that with Alex, but seeing nothing obvious.
<br>
<br>
So far, the web gui usage is still a real daily pain.
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------090408030707060009030604--
3269
days inactive
3270
days old
14 comments
6 participants
participants (6)
-
Alexander Wels -
Anantha Raghava -
Brett I. Holcomb -
Nicolas Ecarnot -
Robert Story -
Yedidyah Bar David