cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Partha Goswami <par...@tulisoft.co.in>
Subject Re: Secondary Storage VM & Console Proxy creation failure
Date Fri, 06 Mar 2015 12:12:29 GMT
Daniel,

I have faced same problem. i had just installed Cloudstack and add "Basic
Zones" Then I have changed in Zones> Physical Networking
And I have faced same issue, for quick solution, i just delete db and run
cloudstack-management commnad for setup and setup zones again with wizards,
I have not any issue anymore.

On Fri, Mar 6, 2015 at 5:27 PM, Gopalakrishnan S <gopal@assistanz.com>
wrote:

> Daniel,
>
> Management traffic only communicate with each other and it can be tried to
> create SSVM and secondary storeage, etc.,  You may check with management
> subnet range.
>
> Thank You.
> Gopalakrishnan.S
>
>
> ----- Original Message ----- From: "Daniel Kollmer" <
> Daniel.Kollmer@tomtom.com>
> To: <users@cloudstack.apache.org>
> Sent: Friday, March 06, 2015 5:18 PM
> Subject: Re: Secondary Storage VM & Console Proxy creation failure
>
>
>
>  -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello and thank you for your replies.
>>
>> Allow me to address them individually.
>>
>> On 03/06/2015 10:34 AM, Partha Goswami wrote:
>>
>>> just keep basic default networking and try i had same issue solved
>>> that way
>>>
>>>
>> Hello Partha
>>
>> May I ask you to elaborate what you mean by that. Which kind of
>> default networking I would have to use?
>>
>> On 03/06/2015 10:50 AM, Timothy Lothering wrote:
>>
>>  I suggest you have a look further in the logs, the "
>>> InsufficientServerCapacityException" usually indicates that the
>>> server you are trying to provision to does not meet your templates
>>> requirements. There are 2 parts to this and I will explain by way
>>> of an example:
>>>
>>> You have a 2 Socket, 16 Core Server with 64GB RAM, the server
>>> cores are rated at 2.0GHz, if you have a template which has been
>>> defined
>>>
>> as > 2.0GHz, theoretically, this should work, but if you look at what the
>>
>>> Host system says is available (i.e. 1999MHz), the server will be
>>> deemed as having insufficient capacity.
>>>
>>> With this said, have you modified the default service offering for
>>> your Console Proxy and/or Secondary storage? Also, I suggest you
>>> look to see if the Host is in maintenance Mode. Logs will be your
>>> best bet
>>>
>>
>> Hi Timothy
>>
>> Everything is "out-of-the-box" and unmodified. The hypervisor host is
>> up and in the agent logs there is nothing that indicates any warnings.
>> At this time I only have the default "small" and "medium" service
>> offerings which are way below system specs albeit the CPU frequency is
>> indeed not the same as what the system offers (it is lower) should it
>> be the same?
>>
>>
>> On 03/06/2015 11:48 AM, Gopalakrishnan S wrote:
>>
>>  Your server have enough capacity but cloudstack server error
>>> indicates that your cluster and pod load as null value.  My
>>> suggestion is you should recheck your management traffic ip
>>> configuration. Is that ips are communicate properly ?
>>>
>>> Please make sure your management traffic ip cofiguration in
>>> cloudstack zone ->pod settings.
>>>
>>
>> Hello Gopalakrishnan
>>
>> Do you mean I should make sure the hypervisor host can communicate
>> with the management server and vice versa? That is definitely the
>> case, otherwise I would not be able to see the host in my
>> infrastructure overview, right?
>>
>> They are on different subnets though which also have different VLANS,
>> is there something I need to set there?
>>
>> Kind regards and thanks for your feedback everyone.
>>
>> - --
>> Daniel Kollmer | Sr. System Engineer - OTS |
>> daniel.kollmer@tomtom.com | Phone: +31 20 75 75 084 | Mobile: +31
>> (0)6 29 13 96 47
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJU+ZQBAAoJEAFpCdELSZ7ZG5EP/jKJNyj4dVPhOJ9PT8t3yvG6
>> TQUgxohGhUfKktORfuLQ/0ulpmXBmxtU/MNBb3qpyoWm986M2s5jCZYx9LSW4ucq
>> +JeAhqxKSLDJtqJVLJ+kVjBewuXdnc/l2PzYP0w7KzUBRpFIrbk4SuxESZXl9ofG
>> ah0RJ46Yy8qeNXfmOERHnVdo1OT/dXPVkP5TuPdsyEa6jBVB1FTcaM1MqNFGj1+K
>> TdnwrvSjhJUQK34w4BJON0/qDUgPjBoznaQzYVFgsMqow68goQ0/BmcKlC92Mb6F
>> 5wusOG98p3TpgOHViGBHUH+FRJnjydRWQA+kPTOz5EqAU7iWW4JGiqhG/ALUrUEv
>> Hc2n+BPzpJWB/ZIQgFQ9uJm/ZwkMj3oC2aDEWOaJI78c4O+mPD2sKkLQyKmqgLga
>> 7AYnOzRYCycHBf+PNqW/6/ZkEoiugX7BvvmuZv1HAT5wYqQGrx2Kfng1cYyh2V03
>> owsxrQ7w1zL9qwU6GmeXmSBEEQY4bVpKbHrC2eVTRfyaZOQtExFOahIbwAGjddtl
>> PZ+CNZLMaIZClpH2SqRxa28uXWYNSBEwiF2I2seImRQNrVJCbHN5U7ItKsEuCRPy
>> 0pqcc3wq0dCGws/2P5sP5daHQaGmKgYIYGMDfukTOqmCuXJTqVPfA64dtBtTWUbq
>> UIlSOqUuZTjBy3Y6jWpb
>> =nEUw
>> -----END PGP SIGNATURE-----
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message