; Regards,
>>
>> Glenn Wagner
>>
>> glenn.wag...@shapeblue.com
>> www.shapeblue.com
>> 2nd Floor, Oudehuis Centre, 122 Main Rd, Somerset West, Cape Town 7130South
>> Africa
>> @shapeblue
>>
>> -Original Message-
>> Fro
wn 7130South
> Africa
> @shapeblue
>
> -Original Message-
> From: christian.kir...@zv.fraunhofer.de
> [mailto:christian.kir...@zv.fraunhofer.de]
> Sent: Monday, 04 April 2016 9:21 AM
> To: users@cloudstack.apache.org
> Subject: Re: Secondary Storage VM overloaded
>
-Original Message-
From: christian.kir...@zv.fraunhofer.de
[mailto:christian.kir...@zv.fraunhofer.de]
Sent: Monday, 04 April 2016 9:21 AM
To: users@cloudstack.apache.org
Subject: Re: Secondary Storage VM overloaded
Hi Dag,
thanks for your reply.
Unfortunately we actually don’t have a clue what
Hi Dag,
thanks for your reply.
Unfortunately we actually don’t have a clue what kind of sessions are meant.
Do we need to monitor ssh sessions, linux processes or some kind of java
sessions?
Do you have any idea where we can start?
Kind Regards
Christian
> On 01 Apr 2016, at 12:19, Dag
Hi Christian,
I think to find the actual usage figures over time you would have to monitor
the sessions locally on the SSVM, I can't see anything in the API to query this.
One way to determine this is to lower the secstorage.sessions.max figure and
monitor how often a second SSVM is spawned.
Hi all,
I have a question regarding the scalability of the ssvm.
As I understood cloudstack is able to scale out the ssvm, so that a new one is
created when the load is to high.
To achieve this we have to edit the two global settings
secstorage.capacity.standby and secstorage.session.max, but
