Hi!
I'm using NFS at primary and secondary storage. I did graceceful shutdown at
KVM host A.
Thanks
Enviado via iPhone
Luciano
> Em 17/07/2015, às 19:00, Milamber escreveu:
>
>
>
>> On 17/07/2015 21:23, Somesh Naidu wrote:
>> Ok, so here are my findings.
>>
>> 1. Host ID 3 was shutdown ar
> Perhaps, the management server don't reconize the host 3 totally down
> (ping alive? or some quorum don't ok)
> The only way to the mgt server to accept totally that the host 3 has a
> real problem that the host 3 has been reboot (around 12:44)?
The host disconnect was triggered at 12:19 on ho
On 17/07/2015 21:23, Somesh Naidu wrote:
Ok, so here are my findings.
1. Host ID 3 was shutdown around 2015-07-16 12:19:09 at which point management
server called a disconnect.
2. Based on the logs, it seems VM IDs 32, 18, 39 and 46 were running on the
host.
3. No HA tasks for any of these V
Ok, so here are my findings.
1. Host ID 3 was shutdown around 2015-07-16 12:19:09 at which point management
server called a disconnect.
2. Based on the logs, it seems VM IDs 32, 18, 39 and 46 were running on the
host.
3. No HA tasks for any of these VMs at this time.
5. Management server restart
*Hello Buddy's,*
*Last Night on words am try to install the new cloud stack setup but not
succeed . I think repos are fail that means (The given URL is not access) .
Am trying this links*:
http://cloudstack.apt-get.eu/rhel/4.5/http://cloudstack.apt-get.eu/rhel/4.4/http://cloudstack.apt-get.eu/rhe
In case anyone runs into such a scenario in the future, here's what this
turned out to be. In /etc/sysconfig/network the GATEWAY from the source VM
was still present. Removing that allowed DHCP to set the default route
properly.
-tim
On Wed, Jul 15, 2015 at 4:26 PM, Tim Mackey wrote:
>
>
> On
No problems Somesh, thanks for your help.
Link of log:
https://dl.dropboxusercontent.com/u/6774061/management-server.log.2015-07-16.gz
Luciano
On Fri, Jul 17, 2015 at 12:00 PM, Somesh Naidu
wrote:
> How large is the management server logs dated 2015-07-16? I would like to
> review the logs. A
Hi, Rohit:
Thanks for the reply.
We have CS instances connecting to either a single RabbitMQ broker, or a
cluster of 2/3 brokers thru a load balancer VIP. The results are always the
same . And yes, the messages are published to brokers.
Yiping
From: Rohit Yadav mailto:rohit.ya...@shapeblue
How large is the management server logs dated 2015-07-16? I would like to
review the logs. All the information I need from that incident should be in
there so I don't need any more testing.
Regards,
Somesh
-Original Message-
From: Luciano Castro [mailto:luciano.cas...@gmail.com]
Sent:
I agree with this approach. But, the default shouldnt be GET but
configurable.
and each api call can have the additional requesttype=[POST|GET|PUT] to
overwrite the default
~Rajani
On Fri, Jul 17, 2015 at 5:30 PM, Pierre-Luc Dion wrote:
> Their is the possibility that sysadmin managing CloudSt
Özhan,
I'm not aware of users running the management server on CentOS 7. I haven't
tested it either but our release note for 4.5.x refer it as a supported OS
for the management servers.
On Thu, Jul 16, 2015 at 4:28 AM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:
> Hi Pierre;
> Do
Their is the possibility that sysadmin managing CloudStack would block
request type POST on their firewall. Because of that I would be tempted to
ask for a param in cloudmonkey for the request type. So when you use
"deploy virtualmachine userdata=ASDASHDAD name=..." we could add the param
"reques
Hi Somesh!
[root@1q2 ~]# zgrep -i -E
'SimpleIvestigator|KVMInvestigator|PingInvestigator|ManagementIPSysVMInvestigator'
/var/log/cloudstack/management/management-server.log.2015-07-16.gz |tail
-5000 > /tmp/management.txt
[root@1q2 ~]# cat /tmp/management.txt
2015-07-16 12:30:45,452 DEBUG [
sorry sent to soon
On Fri, Jul 17, 2015 at 11:38 AM, Daan Hoogland wrote:
> ad 1. The roll back procedure is
- restore the old db
- reinstall the old version of cloudstack
- recover the old etc dir (/etc/cloudstack)
that should do it
>
> ad 2. You only need to edit your cluster setting after t
ad 1. The roll back procedure is
ad 2. You only need to edit your cluster setting after the upgrade to
set them to 4
ad 3. yes they can remain running
On Fri, Jul 17, 2015 at 5:03 AM, wrote:
> Hello,
> My environment is cloudstack4.2.0+vmware5.0.I'm testing the upgrade process
> from cloudstac
On 17-Jul-2015, at 12:27 am, Yiping Zhang
mailto:yzh...@marketo.com>> wrote:
Hi, all:
We are in the process of upgrading our CloudStack from 4.3.2 to 4.5.1. I just
noticed that for CS 4.3.2, there are two TCP connections from
cloudstack-management java process to RabbitMQ cluster, but for
How about we add feature in CloudMonkey to do HTTP post for non-listing APIs?
Should we do it, or add a specific if-else for this API call?
On 16-Jul-2015, at 9:31 pm, Pierre-Luc Dion
mailto:pd...@cloudops.com>> wrote:
Martins,
post will work, if there is no feature request on cloudmonkey cou
17 matches
Mail list logo
