On the same topic, different circumstances, I faced the exact same issue as
well. Mine was
changing cloudstack to use server-ssl.xml rather than server-nossl.xml,
then this issue
happened when reverted back to nossl.
I haven't had the chance to investigate further though.
On Tue, May 22, 2018
On 05/22/2018 06:36 PM, Dag Sonstebo wrote:
> You may want to try a update cloud.configuration set value='true' where
> name='dynamic.apichecker.enabled' and see if that lets you login.
Thanks updated to entry, restarted management service, didn't help.
Below you find the screen shot of
You may want to try a update cloud.configuration set value='true' where
name='dynamic.apichecker.enabled' and see if that lets you login.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 22/05/2018, 17:25, "Rene Moser" wrote:
On 05/22/2018 06:08 PM, Dag Sonstebo
Hi Natalia,
Thanks for the update. We missed that context for root causing the issue.
-Suresh
On Tue, May 22, 2018 at 4:38 PM, Natalia Costas Lago
wrote:
>
> Hi,
>
> We finally were able to recover the manager :/
>
> The problem was due to a database modification made by
Hi Rohit
Thanks for responding.
I have not had much luck with HA at all. I crash a server and nothing happens
in terms of VMs migrating to another host. Monitoring the management log file
it seems the management server recognises the host has stopped responding to
pings but doesn't think
Hi Jon,
Yes, Host-HA is different from VM-HA and without Host HA enabled a HA enabled
VM should be recovered/run on a different host when it crashes. Historically
the term 'HA' in CloudStack is used around high availability of a VM.
Host HA as the name tries to imply is around HA of a
Hi,
We finally were able to recover the manager :/
The problem was due to a database modification made by hand a couple of
months ago in order to eliminate one of the zombie virtual machines
(machines that cannot be expunged because they are dependent on a
network that was deleted before).