[ovirt-users] Re: [ovirt-announce] Re: oVirt 4.4.8 Async update #4

[Marina Kalinin]

Hi Diggy,

If you have updated to oVirt 4.4.8 prior to 4.4.8.6 async release, it means
your system got impacted.
To fix it, you need to set some value to HEVM timezone and then try again
(at least how I understand it).

Regards,
Marina.

On Sun, Sep 26, 2021 at 3:00 PM Diggy Mc  wrote:

> I'm not sure you fixed the compatibility version problem.  I upgraded the
> HE to 4.4.8.6 and rebooted it.  Still cannot upgrade compatibility.
> ___
> Announce mailing list -- annou...@ovirt.org
> To unsubscribe send an email to announce-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/annou...@ovirt.org/message/IKNF4V6MT5ATNJPTAK6V3QU6UDFICCEZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/G37HOIOUORULXS2LKIIV7XO5J36IHAFL/

Re: [ovirt-users] Storage Domain sizing

[Marina Kalinin]

Hi Christian,

Indeed, lvm adds some overhead when scanning the domains, so there is a
limit around 300 lvs per domain, where each snapshot of each disk counts as
a new lv.
On the other hand, having too many domains can also affect on overall
performance required for oVirt to manage all of them.
I suggest, if you have 7 now and they work fine - try sticking to them.
Or, reduce to 3 or 5 and monitor your performance.
Also, afaik, there should be a lot of performance improvements coming in
the new release, so try 4.1 and see.
I hope this helps.

Marina.

On Mon, Jan 23, 2017 at 9:53 AM, Maor Lipchuk  wrote:

> I know that there is a monitoring process which monitors each Storage
> Domain, so I guess that if you will have multiple storage domains this will
> make the monitor runs every time multiple times, but I think that the
> affect is insignificant on the Host or the Storage Domain.
>
> You should also consider the limitation of logical volumes in a volume
> group,
> IINM LVM has a default limit of 255 volumes (I'm not sure how it behaves
> regarding efficiency if you use more volumes)
> oVirt uses LV also for snapshots so with one storage domain you might get
> to this limit pretty quick
>
> On Mon, Jan 23, 2017 at 4:35 PM, Grundmann, Christian <
> christian.grundm...@fabasoft.com> wrote:
>
>> Hi,
>>
>> thx for you input
>>
>> both aren’t problems for me, all domains are from the same storage and so
>> can’t be maintained independently.
>>
>>
>>
>> Are there performance problems with only one Domain (like waiting for
>> locks etc.) which I don’t have that much with multiple?
>>
>>
>>
>> Thx Christian
>>
>>
>>
>>
>>
>> *Von:* Maor Lipchuk [mailto:mlipc...@redhat.com]
>> *Gesendet:* Montag, 23. Jänner 2017 15:32
>> *An:* Grundmann, Christian 
>> *Cc:* users@ovirt.org
>> *Betreff:* Re: [ovirt-users] Storage Domain sizing
>>
>>
>>
>> There are many factors that can be discussed on this issue,
>>
>> two things that pop up on my mind are that many storage domains will make
>> your Data Center be more robust and flexible, since you can maintain part
>> of the storage domains which could help with upgrading your storage server
>> in the future or fixing issues that might occur in your storage, without
>> moving your Data Center to a non operational state.
>>
>>
>>
>> One storage domain is preferrable if you want to use large disks with
>> your VMs that small storage domains does not have the capacity to do so
>>
>>
>>
>> Regards,
>>
>> Maor
>>
>>
>>
>> On Mon, Jan 23, 2017 at 9:52 AM, Grundmann, Christian <
>> christian.grundm...@fabasoft.com> wrote:
>>
>> Hi,
>>
>> Ii am about to migrate to a new storage.
>>
>> Whats the best practice in sizing?
>>
>> 1 big Storage Domain or multiple smaller ones?
>>
>>
>>
>> My current Setup:
>>
>> 11 Hosts
>>
>> 7 FC Storage Domains 1 TB each
>>
>>
>>
>> Can anyone tell me the pro and cons of 1 vs. many?
>>
>>
>>
>>
>>
>> Thx Christian
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 
Thanks,
Marina.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] audit_log table performance tuning

[Marina Kalinin]

- Original Message -
> On 15.04.2016 00:12, Marina Kalinin wrote:
> > Hi,
> > 
> > Any suggestions or maybe already available features in the pipeline for
> > tuning the database, and specifically the audit_log table?
> > 
> > The problem today is that with multiple applications accessing the engine
> > through the RestAPI, especially deployments with CloudForms, create huge
> > amount of login records in the audit_table. Which, in turns, consumes most
> > of the available memory on the machine running the engine and the database
> > and results in a terrible performance of engine and inaccessible Web UI.
> > 
> > The solution today is to delete those records from the table [1]:
> > => delete from audit_log where message like '%logged%';
> > 
> > 
> > Are there any current tunings we can apply to the database?
> > And if not - do we have any RFEs on limiting the records entered to the
> > database or a way to delete/filter those records somehow from the WebUI?
> > All I could find was RFE#1120659 [2], but it does not describe the exact
> > issue.
> > 
> > 
> 
> Hi,
> 
> I remember filing a BZ about this topic some years ago.
> 
> I will mail it tomorrow to this thread as I had this exact issue, as a
> user of the rest api (without any persistent authentication).
Sven, Did you find anything?

I still cannot put my head around the right solution for this case. So I would 
appreciate to see your bug.
> 
> the answer, as I recall (I haven't access to this BZ atm), was to simply
> truncate the event log, which is far from a "solution" at all.
> 
> kind regards
> 
> Sven
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 

-- 
--
 mku
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] audit_log table performance tuning

[Marina Kalinin]

Hi all, 

So far I created this solution for immediate remedy: 
https://access.redhat.com/solutions/721423 

I created this general RFE, that would help in our situation: 
https://bugzilla.redhat.com/show_bug.cgi?id=1329793 

However, this RFE is not all what I have in my mind. 
I am thinking if there is anyway we can limit the number of identical records 
in audit_log? 
Or, as Oved suggested, something to do with RestAPI and CFME to reduce the 
amount of logging? 
BTW, does current version of CFME already contains this feature: 
http://old.ovirt.org/Features/RESTSessionManagement 
? 

Thank you, 
Marina. 

- Original Message -

> On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali < oourf...@redhat.com > wrote:

> > Juan - we should try to reduce this number consumed by CFME, if possible.
> 
> > CC-ing Eli for DB related tips.
> 

> Reminds me of https://gerrit.ovirt.org/#/c/55743/ .

This commit is great, however not relevant for my case, since 
event_notification_hist is empty. 

> Y.

> > On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin < mkali...@redhat.com >
> > wrote:
> 

> > > Hi,
> > 
> 

> > > Any suggestions or maybe already available features in the pipeline for
> > > tuning the database, and specifically the audit_log table?
> > 
> 

> > > The problem today is that with multiple applications accessing the engine
> > > through the RestAPI, especially deployments with CloudForms, create huge
> > > amount of login records in the audit_table. Which, in turns, consumes
> > > most
> > > of the available memory on the machine running the engine and the
> > > database
> > > and results in a terrible performance of engine and inaccessible Web UI.
> > 
> 

> > > The solution today is to delete those records from the table [1]:
> > 
> 
> > > => delete from audit_log where message like '%logged%';
> > 
> 

> > > Are there any current tunings we can apply to the database?
> > 
> 
> > > And if not - do we have any RFEs on limiting the records entered to the
> > > database or a way to delete/filter those records somehow from the WebUI?
> > 
> 
> > > All I could find was RFE#1120659 [2], but it does not describe the exact
> > > issue.
> > 
> 

> > > --
> > 
> 
> > > Thanks,
> > 
> 
> > > Marina.
> > 
> 

> > > [1] https://access.redhat.com/solutions/2110011
> > 
> 
> > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
> > 
> 
> > > ___
> > 
> 
> > > Users mailing list
> > 
> 
> > > Users@ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 

> > ___
> 
> > Users mailing list
> 
> > Users@ovirt.org
> 
> > http://lists.ovirt.org/mailman/listinfo/users
> 

-- 
-- 
mku 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] audit_log table performance tuning

[Marina Kalinin]

Hi,

Any suggestions or maybe already available features in the pipeline for tuning 
the database, and specifically the audit_log table? 

The problem today is that with multiple applications accessing the engine 
through the RestAPI, especially deployments with CloudForms, create huge amount 
of login records in the audit_table. Which, in turns, consumes most of the 
available memory on the machine running the engine and the database and results 
in a terrible performance of engine and inaccessible Web UI.

The solution today is to delete those records from the table [1]:
=> delete from audit_log where message like '%logged%';


Are there any current tunings we can apply to the database? 
And if not - do we have any RFEs on limiting the records entered to the 
database or a way to delete/filter those records somehow from the WebUI?
All I could find was RFE#1120659 [2], but it does not describe the exact issue.


-- 
Thanks,
Marina.


[1] https://access.redhat.com/solutions/2110011
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users