Terribly slow web consile post migration of oVirt Engine from one host to another host
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--
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:
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.
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.
--
Thanks & Regards,
Anantha Raghava
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--------------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://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </body> </html> --------------4E79D83BB3F9B1CA903BCE15--
--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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldYytoACgkQ7/fVLLY1mngh+wCdHDkyseQOX3JrKZAV6NKr3PPn x2kAn2HeLAt7O99AHCfrkXTiLs7nMkEu =VMtA -----END PGP SIGNATURE----- --Sig_/_PM0=kVmNc7Uf8r_bE5Rwtf--
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.
Hi, I will try both options tomorrow & revert back here. Regards, Anantha Raghava On Jun 8, 2016 10:04 PM, "Alexander Wels" <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.
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:
Hi,
I will try both options tomorrow & revert back here.
Regards, Anantha Raghava
On Jun 8, 2016 10:04 PM, "Alexander Wels" <awels@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.
--------------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--
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@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.
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:
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@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.
--------------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--
On Thu, Jun 9, 2016 at 3:33 PM, Anantha Raghava <raghav@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi
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@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@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@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">https://bugzilla.redhat.com/show_bug.cgi?id=1217402</a> <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1220791">https://bugzilla.redhat.com/show_bug.cgi?id=1220791</a> 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://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <br> </body> </html> --------------000705080309010305090703--
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in /etc/hosts file, the problem got resolved.
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
On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in /etc/hosts file, the problem got resolved.
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.
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.
Le 09/06/2016 15:31, Alexander Wels a écrit :
On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in /etc/hosts file, the problem got resolved.
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.
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)?
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?
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.
I recall correctly. I'm also witnessing memory leaks, that I think were fixed recently. -- Nicolas ECARNOT
On Thursday, June 09, 2016 03:47:17 PM Nicolas Ecarnot wrote:
Le 09/06/2016 15:31, Alexander Wels a écrit :
On Thursday, June 09, 2016 03:11:07 PM Nicolas Ecarnot wrote:
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in /etc/hosts file, the problem got resolved.
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.
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)?
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 asked him, he said 3.6.5 and 4.0. So if your 3.6.5 is the same then it didn't solve your issue obviously. I am completely out of things to try or see that could possibly be the problem.
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.
I recall correctly.
I'm also witnessing memory leaks, that I think were fixed recently.
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:
Le 09/06/2016 08:58, Anantha Raghava a écrit :
Hello Alexander,
You are right. The FQDN was the culprit. Once I entered the FQDN in /etc/hosts file, the problem got resolved.
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.
--------------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--
participants (6)
-
Alexander Wels -
Anantha Raghava -
Brett I. Holcomb -
Nicolas Ecarnot -
Robert Story -
Yedidyah Bar David