[ovirt-users] New Certificate -> Image-IO-Proxy Errors

2019-10-13 Thread Markus Schaufler
Hi,

I've changed the cert to an official cert using the howto at 
https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html

Got two problems/questions now:
1. The image-io-proxy doesn't work now
2. I tried to upload an ISO image, which is stuck and locked now

@1: Which logs should I watch and are there any troubleshooting tips at front?
@2: I've already tried the "unlock_entity.sh" script, which didn't help. So I 
tried to login to the CLI to have a look, if there's some kind of "upload" job 
still active - but there's no more CLI. How can I check actual running or stuck 
jobs?

Many thanks in advance
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OHZFPNMRUO2Q45ARDWJQFQTDVCYURUGT/


[ovirt-users] Re: Clean up engine database?

2019-10-13 Thread Lucie Leistnerova

Hi Pavel,

you can use engine tools: engine-vacuum and dwh-vacuum.
It can do full vacuum with -f option and also it runs with engine-setup 
when you choose it.


On 10/11/19 4:36 PM, Pavel Šipoš wrote:

Hi!

We have similar problem and it looks like psql vacuuming isn't working 
properly.
I expect that this problem will be gone when we will upgrade ovirt to 
latest version.
Until then we are performing weekly vacuuming of top N (usualy 4) 
tables by "external size" in ovirt_engine_history database.


A little bit more about vacuuming: 
https://www.postgresql.org/docs/9.1/sql-vacuum.html
External size: 
https://wiki-bsse.ethz.ch/display/ITDOC/Check+size+of+tables+and+objects+in+PostgreSQL+database 
, https://matjaz.it/tutorial-sizes-of-tables-and-databases-in-postgresql/


Example which queries we are running in our case:

To get top 4 tables ordered by "external size":
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)), 
pg_size_pretty(pg_total_relation_size(relid) - 
pg_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables ORDER 
BY pg_total_relation_size(relid) DESC limit 4;


We use names from previous query and perform vacuum table by table:
VACUUM (VERBOSE, FULL) ${TABLE};

To get new size of table after vaccuming:
SELECT pg_size_pretty(pg_total_relation_size(relid) - 
pg_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables WHERE 
relname::text like '${TABLE}';


Note that ${TABLE} is variable with value for example: 
"vm_interface_samples_history"


I suggest to run few queries and check "external size" of your tables.

In our case vacuuming has huge effect on releasing disk space and it 
takes jus few seconds for database.


Oh yes, I almost forgot. As Strahi said, there is some ovirt tool 
(script) for cleaning up psql database but in our case it didn't have 
such huge effect as it didn't perform full vacuum.


Regards,
Pavel

On 11/10/2019 15:50, Strahil Nikolov wrote:
On October 11, 2019 3:43:55 PM GMT+03:00, Chris Adams 
 wrote:

On my oVirt 4.1.9 cluster, the hosted engine filled up its disk last
night (it was deployed from the engine appliance image and had a 20G
root and 5G swap).  I gained a little space by trimming down swap, but
I
need to clean it up.

It looks like the problem is the Postgres database -
/var/lib/pgsql/data
is using 16G.  Is there some cleanup I can do (and then some way to
keep
it from happening again)?

Also, is there a way to extend the hosted engine disk?  It's on iSCSI
storage, and the LUN has free space.
I have noticed during engine upgrade that the tool proposes database 
cleanup, but I have never used it.


Best Regards,
Strahil Nikolov
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YU6Y3M5EL6LO2RMIKTUN5CXFL2I6VKSL/



Best regards.

--
Lucie Leistnerova
Senior Quality Engineer, QE Cloud, RHVM
Red Hat EMEA

IRC: lleistne @ #rhev-qe
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HGSIVBAYE3G5LJFFTZ4DQSSX3GD6Q76F/


[ovirt-users] Re: Delete snapshots task hung

2019-10-13 Thread Leo David
Hi Everyone,
Im still not being able to start the vms... Could anyone give me an advice
on sorign this out ?
Still having th "Bad volume specification" error,  although the disk is
present on the storage.
This issue would force me to reinstall a 10 nodes Openshift cluster from
scratch,  which would not be so funny..
Thanks,

Leo.

On Fri, Oct 11, 2019 at 7:12 AM Strahil  wrote:

> Nah...
> It's done directly on the DB and I wouldn't recommend such action for
> Production Cluster.
> I've done it only once and it was based on some old mailing lists.
>
> Maybe someone from the dev can assist?
> On Oct 10, 2019 13:31, Leo David  wrote:
>
> Thank you Strahil,
> Could you tell me what do you mean by changing status ? Is this something
> to be done in the UI ?
>
> Thanks,
>
> Leo
>
> On Thu, Oct 10, 2019, 09:55 Strahil  wrote:
>
> Maybe you can change the status of the VM in order the engine to know that
> it has to blockcommit the snapshots.
>
> Best Regards,
> Strahil Nikolov
> On Oct 9, 2019 09:02, Leo David  wrote:
>
> Hi Everyone,
> Please let me know if any thoughts or recommandations that could help me
> solve this issue..
> The real bad luck in this outage is that these 5 vms are part on an
> Openshift deployment,  and now we are not able to start it up...
> Before trying to sort this at ocp platform level by replacing the failed
> nodes with new vms, I would rather prefer to do it at the oVirt level and
> have the vms starting since the disks are still present on gluster.
> Thank you so much !
>
>
> Leo
>
>

-- 
Best regards, Leo David
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NFBFOA6LF3JI4CMUO66D5W2I534B5HBP/