API Global Settings Tweaking

2014-04-10 Thread Anoop Mohan
CS Management Server is overloaded ( load getting increased ) when  run
some custom scripts to list virtual machines remotely  which connects the
Management Server every 15 minutes.

Suggest  if I need to modify some API related Global settings?

-- 
Thanks & Regards,
Anoop Mohan


Re: Mgmt server dows before complete its tasks

2014-04-10 Thread Rafael Weingartner
thanks ;)


On Thu, Apr 10, 2014 at 9:53 PM, Michael Phillips
wrote:

> I had a similar issue the other day and I had to manually remove the mgmt
> server from the DB. I found 3 tables
> mshostmshost_peerop_it_work.
> The tables are linked so you have to remove the data from the bottom two
> before you can remove the host from the mshost table. The tables are linked
> via the msid column.
> **Side note
> Reasons like yours are why I brought this up in the dev group as to why we
> need an option in the GUI to cleanly remove a mgmt server. Seems like we
> are gaining some traction on it so feel free to +1 this need to the dev
> group.
>
> > Date: Thu, 10 Apr 2014 21:46:24 -0300
> > Subject: Re: Mgmt server dows before complete its tasks
> > From: rafaelweingart...@gmail.com
> > To: users@cloudstack.apache.org
> >
> > yeap
> >
> >
> > On Thu, Apr 10, 2014 at 9:34 PM, Michael Phillips
> > wrote:
> >
> > > Meaning how can you stop the other mgmt servers from looking for the
> > > disabled mgmt server?
> > >
> > > > Date: Thu, 10 Apr 2014 21:00:12 -0300
> > > > Subject: Mgmt server dows before complete its tasks
> > > > From: rafaelweingart...@gmail.com
> > > > To: users@cloudstack.apache.org
> > > >
> > > > Hi folks,
> > > > I have the following situation, one of my management server went down
> > > > before completing some jobs that were assigned to it. It is not
> possible
> > > to
> > > > recover that node, what can I do to make the others mgmt servers
> stop to
> > > > try to connect into the mgmt server that is down?
> > > >
> > > > --
> > > > Rafael Weingärtner
> > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
>
>



-- 
Rafael Weingärtner


RE: Mgmt server dows before complete its tasks

2014-04-10 Thread Michael Phillips
I had a similar issue the other day and I had to manually remove the mgmt 
server from the DB. I found 3 tables
mshostmshost_peerop_it_work.
The tables are linked so you have to remove the data from the bottom two before 
you can remove the host from the mshost table. The tables are linked via the 
msid column.
**Side note
Reasons like yours are why I brought this up in the dev group as to why we need 
an option in the GUI to cleanly remove a mgmt server. Seems like we are gaining 
some traction on it so feel free to +1 this need to the dev group.

> Date: Thu, 10 Apr 2014 21:46:24 -0300
> Subject: Re: Mgmt server dows before complete its tasks
> From: rafaelweingart...@gmail.com
> To: users@cloudstack.apache.org
> 
> yeap
> 
> 
> On Thu, Apr 10, 2014 at 9:34 PM, Michael Phillips
> wrote:
> 
> > Meaning how can you stop the other mgmt servers from looking for the
> > disabled mgmt server?
> >
> > > Date: Thu, 10 Apr 2014 21:00:12 -0300
> > > Subject: Mgmt server dows before complete its tasks
> > > From: rafaelweingart...@gmail.com
> > > To: users@cloudstack.apache.org
> > >
> > > Hi folks,
> > > I have the following situation, one of my management server went down
> > > before completing some jobs that were assigned to it. It is not possible
> > to
> > > recover that node, what can I do to make the others mgmt servers stop to
> > > try to connect into the mgmt server that is down?
> > >
> > > --
> > > Rafael Weingärtner
> >
> >
> 
> 
> 
> -- 
> Rafael Weingärtner
  

Re: Mgmt server dows before complete its tasks

2014-04-10 Thread Rafael Weingartner
yeap


On Thu, Apr 10, 2014 at 9:34 PM, Michael Phillips
wrote:

> Meaning how can you stop the other mgmt servers from looking for the
> disabled mgmt server?
>
> > Date: Thu, 10 Apr 2014 21:00:12 -0300
> > Subject: Mgmt server dows before complete its tasks
> > From: rafaelweingart...@gmail.com
> > To: users@cloudstack.apache.org
> >
> > Hi folks,
> > I have the following situation, one of my management server went down
> > before completing some jobs that were assigned to it. It is not possible
> to
> > recover that node, what can I do to make the others mgmt servers stop to
> > try to connect into the mgmt server that is down?
> >
> > --
> > Rafael Weingärtner
>
>



-- 
Rafael Weingärtner


RE: 4.3 Vmware Support

2014-04-10 Thread Michael Phillips
Here is the screen shot I was talking about
http://imgur.com/zteayhN

If you notice it says "Apache Cloudstack Vmware Base" and Apache Cloudstack 
Plugin - Hypervisor Vmware" both are built successfully. However once I 
installed the RPM's built from this source I do not have VMware support.
This is 4.3.0 running on Centos 6.5
Surely someone out there has this working??



> Date: Wed, 9 Apr 2014 08:20:45 +0200
> Subject: Re: 4.3 Vmware Support
> From: terbol...@gmail.com
> To: users@cloudstack.apache.org
> 
> On Wed, Apr 9, 2014 at 1:17 AM, Michael Phillips 
> wrote:
> 
> >  If I see the following "Apache Cloudstack Plugin - Hypervisor
> > VMware..Success" when building, shouldn't I have vmware support in my
> > packaged RPM's ?
> >
> > Check the attached screenshot...
> >
> >
> >
> 
> I think attachments are stripped away on the mailing list, try uploading it
> to imgurl or similar.
> 
> -- 
> Erik Weber
  

RE: Mgmt server dows before complete its tasks

2014-04-10 Thread Michael Phillips
Meaning how can you stop the other mgmt servers from looking for the disabled 
mgmt server?

> Date: Thu, 10 Apr 2014 21:00:12 -0300
> Subject: Mgmt server dows before complete its tasks
> From: rafaelweingart...@gmail.com
> To: users@cloudstack.apache.org
> 
> Hi folks,
> I have the following situation, one of my management server went down
> before completing some jobs that were assigned to it. It is not possible to
> recover that node, what can I do to make the others mgmt servers stop to
> try to connect into the mgmt server that is down?
> 
> -- 
> Rafael Weingärtner
  

Mgmt server dows before complete its tasks

2014-04-10 Thread Rafael Weingartner
Hi folks,
I have the following situation, one of my management server went down
before completing some jobs that were assigned to it. It is not possible to
recover that node, what can I do to make the others mgmt servers stop to
try to connect into the mgmt server that is down?

-- 
Rafael Weingärtner


Re: System vm's with wrong network routing

2014-04-10 Thread Matthew Midgett
Geoff can you provide me with a route from a centos kvm host? This is 
mine and I do not see cloudbr1 or 2 in the routing table. Shouldn't I 
see this on the host?


[root@cst2 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.122.0   0.0.0.0 255.255.255.0   U 0 00 virbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 cloud0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 cloudbr0
0.0.0.0 172.16.0.1  0.0.0.0 UG0 00 eth0


On 04/10/2014 01:54 PM, Geoff Higginbottom wrote:

Matthew

You say your system VMs can ping the public gateway but nothing further, have 
you checked the configuration on your gateway to ensure it is setup correctly 
to route the return traffic back to the VMs public IPs.

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581

geoff.higginbot...@shapeblue.com

-Original Message-
From: Matthew Midgett [mailto:supp...@trickhosting.biz]
Sent: 10 April 2014 18:48
To: users@cloudstack.apache.org
Subject: Re: System vm's with wrong network routing

Geoff,
   I added a ip to cloudbr0 and now I see a ARP in my management router for 
the private address. I still can't ping them from the management lan. Still the 
same issue as before except I notice that my console proxy and ssvm have 
different routes. Neither of the system vm's can reach the internet but can 
ping the public gateway but nothing farther. Note I tried with GRE instead of 
vlans to see if this made a difference. Is there firewall setting on the 
bridges / physicals that I am missing? Really lost now.

cloudbr0 = private 172.16.0.0/16
cloudbr1 = guest
cloudbr2 = public 216.249.111.0/24


ssvm

root@s-2-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth3
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2

Console Proxy

root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2



Yes I will add a ip to the cloudbr0 and see if that fixes the problem. It's a 
good time since I just reset the db to start over. I don't want to vlan so can 
I use advanced networking with GRE instead? GRE takes no switch configuration 
right?


Sent from my Galaxy S®III

 Original message 
From: Geoff Higginbottom 
Date:04/08/2014  4:17 PM  (GMT-05:00)
To: "" 
Subject: Re: System vm's with wrong network routing

Matthew,

Your Bridge configs look OK, but we normally see the management IP on the 
bridge.

Can you move your clustered file system onto a dedicated nic, allowing 
management IP to be placed on the bridge, this may stop the self fencing issues.

It seems too much of a coincidence that the management IP is not on the bridge 
and it's the management traffic which is failing.

Regards

Geoff Higginbottom
CTO / Cloud Architect


D: +44 20 3603 0542 | S: +44 20 3603
0540 | M: +447968161581

geoff.higginbot...@shapeblue.com | www.shapeblue.com

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N
4HS



On 8 Apr 2014, at 19:56, "Matthew Midgett" 
mailto:supp...@trickhosting.biz>> wrote:

Here are my interfaces and I am sure the labels are correct.  Any other ideas?

This is for my management ip, I couldn't put it on the bridge as my clustered 
file system would keep fencing it self.

cat ifcfg-eth0
DEVICE="eth0"
BOOTPROTO=static
HWADDR="78:E7:D1:8E:2F:AE"
NM_CONTROLLED="none"
ONBOOT=yes
TYPE="Ethernet"
IPADDR=172.16.0.11
NETMASK=255.255.0.0
GATEWAY=172.16.0.1

This is where the physicals for my bridges start

cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
HWADDR=78:E7:D1:8E:2F:B0
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BRIDGE=cloudbr0

cat ifcfg-cloudbr0
DEVICE=cloudbr0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
NAME=cloudbr0

cat ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
HWADDR=78:E7:D1:8E:2F:B2
ONBOOT=yes
USERCTL=no
BRIDGE=cloudb

RE: System vm's with wrong network routing

2014-04-10 Thread Matthew Midgett
I just found this, it talks about making routes for bridges. I don't have 
anything like this for my bridges. Should I?

http://www.cyberciti.biz/faq/rhel-linux-kvm-virtualization-bridged-networking-with-libvirt/
Sent from my Galaxy S®III

 Original message 
From: Matthew Midgett  
Date:04/10/2014  2:04 PM  (GMT-05:00) 
To: users@cloudstack.apache.org 
Subject: RE: System vm's with wrong network routing 

Yes I plugged my laptop in to the switch put a public on it and all is well. I 
have put the use . external.dns to true so I'm not sure why the dns is even in 
the route table. 


Sent from my Galaxy S®III

 Original message 
From: Geoff Higginbottom  
Date:04/10/2014  1:54 PM  (GMT-05:00) 
To: users@cloudstack.apache.org 
Subject: RE: System vm's with wrong network routing 

Matthew

You say your system VMs can ping the public gateway but nothing further, have 
you checked the configuration on your gateway to ensure it is setup correctly 
to route the return traffic back to the VMs public IPs.

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581

geoff.higginbot...@shapeblue.com

-Original Message-
From: Matthew Midgett [mailto:supp...@trickhosting.biz]
Sent: 10 April 2014 18:48
To: users@cloudstack.apache.org
Subject: Re: System vm's with wrong network routing

Geoff,
  I added a ip to cloudbr0 and now I see a ARP in my management router for 
the private address. I still can't ping them from the management lan. Still the 
same issue as before except I notice that my console proxy and ssvm have 
different routes. Neither of the system vm's can reach the internet but can 
ping the public gateway but nothing farther. Note I tried with GRE instead of 
vlans to see if this made a difference. Is there firewall setting on the 
bridges / physicals that I am missing? Really lost now.

cloudbr0 = private 172.16.0.0/16
cloudbr1 = guest
cloudbr2 = public 216.249.111.0/24


ssvm

root@s-2-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG    0 0    0 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0    0 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth1
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth3
216.249.111.0   0.0.0.0 255.255.255.0   U 0 0    0 eth2

Console Proxy

root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG    0 0    0 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0    0 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth1
216.249.111.0   0.0.0.0 255.255.255.0   U 0 0    0 eth2


> Yes I will add a ip to the cloudbr0 and see if that fixes the problem. It's a 
> good time since I just reset the db to start over. I don't want to vlan so 
> can I use advanced networking with GRE instead? GRE takes no switch 
> configuration right?
>
>
> Sent from my Galaxy S®III
>
>  Original message 
> From: Geoff Higginbottom 
> Date:04/08/2014  4:17 PM  (GMT-05:00)
> To: "" 
> Subject: Re: System vm's with wrong network routing
>
> Matthew,
>
> Your Bridge configs look OK, but we normally see the management IP on the 
> bridge.
>
> Can you move your clustered file system onto a dedicated nic, allowing 
> management IP to be placed on the bridge, this may stop the self fencing 
> issues.
>
> It seems too much of a coincidence that the management IP is not on the 
> bridge and it's the management traffic which is failing.
>
> Regards
>
> Geoff Higginbottom
> CTO / Cloud Architect
>
>
> D: +44 20 3603 0542 | S: +44 20 3603
> 0540 | M: +447968161581
>
> geoff.higginbot...@shapeblue.com om> | www.shapeblue.com
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N
> 4HS
>
>
>
> On 8 Apr 2014, at 19:56, "Matthew Midgett" 
> mailto:supp...@trickhosting.biz>> wrote:
>
> Here are my interfaces and I am sure the labels are correct.  Any other ideas?
>
> This is for my management ip, I couldn't put it on the bridge as my clustered 
> file system would keep fencing it self.
>
> cat ifcfg-eth0
> DEVICE="eth0"
> BOOTPROTO=static
> HWADDR="78:E7:D1:8E:2F:AE"
> NM_CONTROLLED="none"
> ONBOOT=yes
> TYPE="Ethernet"
> IPADDR=172.16.0.11
> NETMASK=255.255.0.0
> GATEWAY=172.16.0.1
>
> This is where the physicals for my bridges start
>
> cat ifcfg-eth1
> DEVICE=eth1
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B0
> ONBOOT=yes
> USERCTL=n

RE: System vm's with wrong network routing

2014-04-10 Thread Matthew Midgett
Yes I plugged my laptop in to the switch put a public on it and all is well. I 
have put the use . external.dns to true so I'm not sure why the dns is even in 
the route table. 


Sent from my Galaxy S®III

 Original message 
From: Geoff Higginbottom  
Date:04/10/2014  1:54 PM  (GMT-05:00) 
To: users@cloudstack.apache.org 
Subject: RE: System vm's with wrong network routing 

Matthew

You say your system VMs can ping the public gateway but nothing further, have 
you checked the configuration on your gateway to ensure it is setup correctly 
to route the return traffic back to the VMs public IPs.

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581

geoff.higginbot...@shapeblue.com

-Original Message-
From: Matthew Midgett [mailto:supp...@trickhosting.biz]
Sent: 10 April 2014 18:48
To: users@cloudstack.apache.org
Subject: Re: System vm's with wrong network routing

Geoff,
  I added a ip to cloudbr0 and now I see a ARP in my management router for 
the private address. I still can't ping them from the management lan. Still the 
same issue as before except I notice that my console proxy and ssvm have 
different routes. Neither of the system vm's can reach the internet but can 
ping the public gateway but nothing farther. Note I tried with GRE instead of 
vlans to see if this made a difference. Is there firewall setting on the 
bridges / physicals that I am missing? Really lost now.

cloudbr0 = private 172.16.0.0/16
cloudbr1 = guest
cloudbr2 = public 216.249.111.0/24


ssvm

root@s-2-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG    0 0    0 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0    0 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth1
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth3
216.249.111.0   0.0.0.0 255.255.255.0   U 0 0    0 eth2

Console Proxy

root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG    0 0    0 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 0    0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0    0 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 0    0 eth1
216.249.111.0   0.0.0.0 255.255.255.0   U 0 0    0 eth2


> Yes I will add a ip to the cloudbr0 and see if that fixes the problem. It's a 
> good time since I just reset the db to start over. I don't want to vlan so 
> can I use advanced networking with GRE instead? GRE takes no switch 
> configuration right?
>
>
> Sent from my Galaxy S®III
>
>  Original message 
> From: Geoff Higginbottom 
> Date:04/08/2014  4:17 PM  (GMT-05:00)
> To: "" 
> Subject: Re: System vm's with wrong network routing
>
> Matthew,
>
> Your Bridge configs look OK, but we normally see the management IP on the 
> bridge.
>
> Can you move your clustered file system onto a dedicated nic, allowing 
> management IP to be placed on the bridge, this may stop the self fencing 
> issues.
>
> It seems too much of a coincidence that the management IP is not on the 
> bridge and it's the management traffic which is failing.
>
> Regards
>
> Geoff Higginbottom
> CTO / Cloud Architect
>
>
> D: +44 20 3603 0542 | S: +44 20 3603
> 0540 | M: +447968161581
>
> geoff.higginbot...@shapeblue.com om> | www.shapeblue.com
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N
> 4HS
>
>
>
> On 8 Apr 2014, at 19:56, "Matthew Midgett" 
> mailto:supp...@trickhosting.biz>> wrote:
>
> Here are my interfaces and I am sure the labels are correct.  Any other ideas?
>
> This is for my management ip, I couldn't put it on the bridge as my clustered 
> file system would keep fencing it self.
>
> cat ifcfg-eth0
> DEVICE="eth0"
> BOOTPROTO=static
> HWADDR="78:E7:D1:8E:2F:AE"
> NM_CONTROLLED="none"
> ONBOOT=yes
> TYPE="Ethernet"
> IPADDR=172.16.0.11
> NETMASK=255.255.0.0
> GATEWAY=172.16.0.1
>
> This is where the physicals for my bridges start
>
> cat ifcfg-eth1
> DEVICE=eth1
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B0
> ONBOOT=yes
> USERCTL=no
> NM_CONTROLLED=no
> BRIDGE=cloudbr0
>
> cat ifcfg-cloudbr0
> DEVICE=cloudbr0
> NM_CONTROLLED=no
> ONBOOT=yes
> TYPE=Bridge
> NAME=cloudbr0
>
> cat ifcfg-eth2
> DEVICE=eth2
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B2
> ONBOOT=yes
> USERCTL=no
> BRIDGE=cloudbr1
> NM_CONTROLLED=no
>
> cat ifcfg-cloudbr1
> DEVICE=cloudbr1
> NM_CONTROLLED=no
> ONBOOT=yes
> TYPE=Bridge
> NAME=cloudbr1
>
> cat ifcfg-eth3
> DEVICE=eth3
> BOOTP

RE: System vm's with wrong network routing

2014-04-10 Thread Geoff Higginbottom
Matthew

You say your system VMs can ping the public gateway but nothing further, have 
you checked the configuration on your gateway to ensure it is setup correctly 
to route the return traffic back to the VMs public IPs.

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581

geoff.higginbot...@shapeblue.com

-Original Message-
From: Matthew Midgett [mailto:supp...@trickhosting.biz]
Sent: 10 April 2014 18:48
To: users@cloudstack.apache.org
Subject: Re: System vm's with wrong network routing

Geoff,
  I added a ip to cloudbr0 and now I see a ARP in my management router for 
the private address. I still can't ping them from the management lan. Still the 
same issue as before except I notice that my console proxy and ssvm have 
different routes. Neither of the system vm's can reach the internet but can 
ping the public gateway but nothing farther. Note I tried with GRE instead of 
vlans to see if this made a difference. Is there firewall setting on the 
bridges / physicals that I am missing? Really lost now.

cloudbr0 = private 172.16.0.0/16
cloudbr1 = guest
cloudbr2 = public 216.249.111.0/24


ssvm

root@s-2-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth3
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2

Console Proxy

root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2


> Yes I will add a ip to the cloudbr0 and see if that fixes the problem. It's a 
> good time since I just reset the db to start over. I don't want to vlan so 
> can I use advanced networking with GRE instead? GRE takes no switch 
> configuration right?
>
>
> Sent from my Galaxy S®III
>
>  Original message 
> From: Geoff Higginbottom 
> Date:04/08/2014  4:17 PM  (GMT-05:00)
> To: "" 
> Subject: Re: System vm's with wrong network routing
>
> Matthew,
>
> Your Bridge configs look OK, but we normally see the management IP on the 
> bridge.
>
> Can you move your clustered file system onto a dedicated nic, allowing 
> management IP to be placed on the bridge, this may stop the self fencing 
> issues.
>
> It seems too much of a coincidence that the management IP is not on the 
> bridge and it's the management traffic which is failing.
>
> Regards
>
> Geoff Higginbottom
> CTO / Cloud Architect
>
>
> D: +44 20 3603 0542 | S: +44 20 3603
> 0540 | M: +447968161581
>
> geoff.higginbot...@shapeblue.com om> | www.shapeblue.com
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N
> 4HS
>
>
>
> On 8 Apr 2014, at 19:56, "Matthew Midgett" 
> mailto:supp...@trickhosting.biz>> wrote:
>
> Here are my interfaces and I am sure the labels are correct.  Any other ideas?
>
> This is for my management ip, I couldn't put it on the bridge as my clustered 
> file system would keep fencing it self.
>
> cat ifcfg-eth0
> DEVICE="eth0"
> BOOTPROTO=static
> HWADDR="78:E7:D1:8E:2F:AE"
> NM_CONTROLLED="none"
> ONBOOT=yes
> TYPE="Ethernet"
> IPADDR=172.16.0.11
> NETMASK=255.255.0.0
> GATEWAY=172.16.0.1
>
> This is where the physicals for my bridges start
>
> cat ifcfg-eth1
> DEVICE=eth1
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B0
> ONBOOT=yes
> USERCTL=no
> NM_CONTROLLED=no
> BRIDGE=cloudbr0
>
> cat ifcfg-cloudbr0
> DEVICE=cloudbr0
> NM_CONTROLLED=no
> ONBOOT=yes
> TYPE=Bridge
> NAME=cloudbr0
>
> cat ifcfg-eth2
> DEVICE=eth2
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B2
> ONBOOT=yes
> USERCTL=no
> BRIDGE=cloudbr1
> NM_CONTROLLED=no
>
> cat ifcfg-cloudbr1
> DEVICE=cloudbr1
> NM_CONTROLLED=no
> ONBOOT=yes
> TYPE=Bridge
> NAME=cloudbr1
>
> cat ifcfg-eth3
> DEVICE=eth3
> BOOTPROTO=none
> HWADDR=78:E7:D1:8E:2F:B4
> ONBOOT=yes
> USERCTL=no
> BRIDGE=cloudbr2
> NM_CONTROLLED=no
>
> cat ifcfg-cloudbr2
> DEVICE=cloudbr2
> NM_CONTROLLED=no
> ONBOOT=yes
> TYPE=Bridge
> BOOTPROTO=none
> NAME=cloudbr2
>
> The interfaces match my layout and the physical network
>
> cloudbr0 - Management
> cloudbr1 - guest
> cloudbr2 - public
>
> brctl show
> bridge name bridge id

Re: System vm's with wrong network routing

2014-04-10 Thread Matthew Midgett

Geoff,
 I added a ip to cloudbr0 and now I see a ARP in my management 
router for the private address. I still can't ping them from the 
management lan. Still the same issue as before except I notice that my 
console proxy and ssvm have different routes. Neither of the system vm's 
can reach the internet but can ping the public gateway but nothing 
farther. Note I tried with GRE instead of vlans to see if this made a 
difference. Is there firewall setting on the bridges / physicals that I 
am missing? Really lost now.


cloudbr0 = private 172.16.0.0/16
cloudbr1 = guest
cloudbr2 = public 216.249.111.0/24


ssvm

root@s-2-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth3
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2

Console Proxy

root@v-1-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 216.249.111.1   0.0.0.0 UG0 00 eth2
8.8.4.4 172.16.0.1  255.255.255.255 UGH   0 00 eth1
8.8.8.8 172.16.0.1  255.255.255.255 UGH   0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
172.16.0.0  0.0.0.0 255.255.0.0 U 0 00 eth1
216.249.111.0   0.0.0.0 255.255.255.0   U 0 00 eth2



Yes I will add a ip to the cloudbr0 and see if that fixes the problem. It's a 
good time since I just reset the db to start over. I don't want to vlan so can 
I use advanced networking with GRE instead? GRE takes no switch configuration 
right?


Sent from my Galaxy S®III

 Original message 
From: Geoff Higginbottom 
Date:04/08/2014  4:17 PM  (GMT-05:00)
To: "" 
Subject: Re: System vm's with wrong network routing

Matthew,

Your Bridge configs look OK, but we normally see the management IP on the 
bridge.

Can you move your clustered file system onto a dedicated nic, allowing 
management IP to be placed on the bridge, this may stop the self fencing issues.

It seems too much of a coincidence that the management IP is not on the bridge 
and it's the management traffic which is failing.

Regards

Geoff Higginbottom
CTO / Cloud Architect


D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: 
+447968161581

geoff.higginbot...@shapeblue.com | 
www.shapeblue.com

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 
4HS



On 8 Apr 2014, at 19:56, "Matthew Midgett" 
mailto:supp...@trickhosting.biz>> wrote:

Here are my interfaces and I am sure the labels are correct.  Any other ideas?

This is for my management ip, I couldn't put it on the bridge as my clustered 
file system would keep fencing it self.

cat ifcfg-eth0
DEVICE="eth0"
BOOTPROTO=static
HWADDR="78:E7:D1:8E:2F:AE"
NM_CONTROLLED="none"
ONBOOT=yes
TYPE="Ethernet"
IPADDR=172.16.0.11
NETMASK=255.255.0.0
GATEWAY=172.16.0.1

This is where the physicals for my bridges start

cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
HWADDR=78:E7:D1:8E:2F:B0
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BRIDGE=cloudbr0

cat ifcfg-cloudbr0
DEVICE=cloudbr0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
NAME=cloudbr0

cat ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
HWADDR=78:E7:D1:8E:2F:B2
ONBOOT=yes
USERCTL=no
BRIDGE=cloudbr1
NM_CONTROLLED=no

cat ifcfg-cloudbr1
DEVICE=cloudbr1
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
NAME=cloudbr1

cat ifcfg-eth3
DEVICE=eth3
BOOTPROTO=none
HWADDR=78:E7:D1:8E:2F:B4
ONBOOT=yes
USERCTL=no
BRIDGE=cloudbr2
NM_CONTROLLED=no

cat ifcfg-cloudbr2
DEVICE=cloudbr2
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=none
NAME=cloudbr2

The interfaces match my layout and the physical network

cloudbr0 - Management
cloudbr1 - guest
cloudbr2 - public

brctl show
bridge name bridge id   STP enabled interfaces
cloud0  8000.fe00a9fe01e4   no  vnet0
vnet3
cloudbr08000.78e7d18e2fb0   no  eth1
vnet1
vnet4
vnet6
cloudbr18000.78e7d18e2fb2   no  eth2
cloudbr28000.78e7d18e2fb4   no  eth3
vnet2
vnet5
virbr0  8000.5254007e4d34   yes virbr0-nic











Re: Swift as Secondary Storage

2014-04-10 Thread benoit lair
After solving the problem of the set perms, i could see the replication
request for pushing the datas on swift.

Now another problem and for information for those who whant to install
their own swift : it is a requirement to have a swift public url with swift
v1.0 and not a 2.0 one.

If your swift endpoint is in v2 you won't be able to push your datas on
swift.

Troubleshooting in progress, have modified by gateway from v2 to v1, now
waiting for mgmt cs to repush the data.


Regards, Benoit.


2014-04-10 16:34 GMT+02:00 benoit lair :

> I have more information for my issue  :
>
> 2014-04-10 16:26:23,071 DEBUG [o.a.c.s.r.NfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) Successfully mounted 
> 10.32.0.70:/export/secondary
> at /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8
> 2014-04-10 16:26:23,071 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) Executing: sudo chmod 777
> /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8
> 2014-04-10 16:26:23,345 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) Exit value is 1
> 2014-04-10 16:26:23,358 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) chmod: modification des permissions de
> « /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
> Opération non permise
> 2014-04-10 16:26:23,358 ERROR [o.a.c.s.r.LocalNfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) Unable to set permissions for
> /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due to
> chmod: modification des permissions de
> « /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
> Opération non permise
> 2014-04-10 16:26:23,358 ERROR [o.a.c.s.r.LocalNfsSecondaryStorageResource]
> (pool-10-thread-1:ctx-1a8aedc3) GetRootDir for nfs://
> 10.0.0.200/export/secondary failed due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to set permissions
> for /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due
> to chmod: modification des permissions de
> « /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
> Opération non permise
> com.cloud.utils.exception.CloudRuntimeException: Unable to set permissions
> for /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due
> to chmod: modification des permissions de
> « /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
> Opération non permise
> at
> org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.mount(LocalNfsSecondaryStorageResource.java:111)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.mountUri(NfsSecondaryStorageResource.java:2310)
> at
> org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.getRootDir(LocalNfsSecondaryStorageResource.java:85)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.downloadFromUrlToNfs(NfsSecondaryStorageResource.java:693)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.registerTemplateOnSwift(NfsSecondaryStorageResource.java:724)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:772)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:208)
> at
> org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.executeRequest(LocalNfsSecondaryStorageResource.java:78)
> at
> org.apache.cloudstack.storage.LocalHostEndpoint.sendMessage(LocalHostEndpoint.java:93)
> at
> org.apache.cloudstack.storage.LocalHostEndpoint$CmdRunner.runInContext(LocalHostEndpoint.java:110)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.run

Re: OpenSSL Flaw

2014-04-10 Thread John Kinsella
Sorry folks that I didn’t send it to this list. To be accurate, it’s a blog 
post not a press release. We’ll have a formal solution in a few more days.

https://blogs.apache.org/cloudstack/entry/how_to_mitigate_openssl_heartbleed

On Apr 9, 2014, at 5:19 AM, Antonio Packery 
mailto:antonio.pack...@t-systems.co.za>> wrote:

Here is the CloudStack press release,
How to Mitigate OpenSSL HeartBleed Vulnerability in Apache CloudStack

Wed Apr 09 2014 07:52:17 GMT+0200 (SAST)

Earlier this week, a security vulnerability was disclosed in OpenSSL, one of 
the software libraries that Apache CloudStack uses to encrypt data sent over 
network network connections. As the vulnerability has existed in OpenSSL since 
early 2012, System VMs in Apache CloudStack versions 4.0.0-incubating-4.3 are 
running software using vulnerable versions of OpenSSL. This includes 
CloudStack's Virtual Router VMs, Console Proxy VMs, and Secondary Storage VMs.

We are actively working on creating updated System VM templates for each recent 
version of Apache CloudStack, and for each of the hypervisor platforms which 
Apache CloudStack supports. Due to our testing and QA processes, this will take 
several days. In the meantime, we want to provide our users with a temporary 
workaround for currently running System VMs.

If you are running Apache CloudStack 4.0.0-incubating through the recent 4.3 
release, the the following steps will help ensure the security of your cloud 
infrastructure until an updated version of the System VM template is available:

1.  As an administrator in the CloudStack web UI, navigate to 
Infrastructure->System VMs
2.  For each System VM listed, note the host it is running on, and it's "Link 
Local IP address."
3.  With that data, perform the following steps for each System VM:
   *   ssh into that host as root
   *   From the host, ssh into the SSVM via it's link local IP address: (e.g. 
ssh -i /root/.ssh/id_rsa.cloud -p 3922 169.254.3.33)
   *   On the System VM, first run "apt-get update"
   *   Then run apt-get install openssl. If a dialog appears asking to restart 
programs, accept it's request.
   *   Next, for Secondary Storage VMs, run /etc/init.d/apache2 restart
   *   Log out of the System VM and host server
4.  Back in the CloudStack UI, now navigate to Infrastructure->Virtual Routers. 
For each VR, host it's running on and it's link local IP address, and then 
repeat steps a-f above.

We realize that for larger installations where System VMs are being actively 
created and destroyed based on customer demand, this is a very rough stop-gap. 
The Apache CloudStack security team is actively working on a more permanent fix 
and will be releasing that to the community as soon as possible.

For Apache CloudStack installations that secure the web-based user-interface 
with SSL, these may also be vulnerable to HeartBleed, but that is outside the 
scope of this blog post. We recommend testing your installation with [1] to 
determine if you need to patch/upgrade the SSL library used by any web servers 
(or other SSL-based services) you use.

1: http://filippo.io/Heartbleed/

On 04/09/2014 12:03 PM, Len Bellemore wrote:

Hi Guys,

Does anyone know which version of ACS are affected by the Hearbleed OpenSSL 
flaw?
- http://heartbleed.com/

Thanks
Len


IMPORTANT NOTICE. This electronic message contains information from Control 
Circle Ltd, which may be privileged or confidential. The information is 
intended for use only by the individual(s) or entity named above. If you are 
not the intended recipient, be aware that any disclosure, copying, distribution 
or use of the contents of this information is strictly prohibited. If you have 
received this electronic message in error, please notify me by telephone or 
email (to the number or email address above) immediately. Activity and use of 
the ControlCircle e-mail system is monitored to secure its effective operation 
and for other lawful business purposes. Communications using this system will 
also be monitored and may be recorded to secure effective operation and for 
other lawful business purposes


Disclaimer: This message and/or attachment(s) may contain privileged, 
confidential and/or personal information. If you are not the intended recipient 
you may not disclose or distribute any of the information contained within this 
message. In such case you must destroy this message and inform the sender of 
the error. T-Systems does not accept liability for any errors, omissions, 
information and viruses contained in the transmission of this message. Any 
opinions, conclusions and other information contained within this message not 
related to T-Systems' official business is deemed to be that of the individual 
only and is not endorsed by T-Systems.

This message and/or attachment(s) may contain privileged or confidential
information. If you are not the intended recipient you may not disclose or
distribute any of the information contained 

Re: Swift as Secondary Storage

2014-04-10 Thread benoit lair
I have more information for my issue  :

2014-04-10 16:26:23,071 DEBUG [o.a.c.s.r.NfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) Successfully mounted
10.32.0.70:/export/secondary
at /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8
2014-04-10 16:26:23,071 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) Executing: sudo chmod 777
/var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8
2014-04-10 16:26:23,345 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) Exit value is 1
2014-04-10 16:26:23,358 DEBUG [o.a.c.s.r.LocalNfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) chmod: modification des permissions de
« /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
Opération non permise
2014-04-10 16:26:23,358 ERROR [o.a.c.s.r.LocalNfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) Unable to set permissions for
/var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due to
chmod: modification des permissions de
« /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
Opération non permise
2014-04-10 16:26:23,358 ERROR [o.a.c.s.r.LocalNfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) GetRootDir for nfs://
10.0.0.200/export/secondary failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to set permissions
for /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due
to chmod: modification des permissions de
« /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
Opération non permise
com.cloud.utils.exception.CloudRuntimeException: Unable to set permissions
for /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due
to chmod: modification des permissions de
« /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 »:
Opération non permise
at
org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.mount(LocalNfsSecondaryStorageResource.java:111)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.mountUri(NfsSecondaryStorageResource.java:2310)
at
org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.getRootDir(LocalNfsSecondaryStorageResource.java:85)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.downloadFromUrlToNfs(NfsSecondaryStorageResource.java:693)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.registerTemplateOnSwift(NfsSecondaryStorageResource.java:724)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:772)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:208)
at
org.apache.cloudstack.storage.resource.LocalNfsSecondaryStorageResource.executeRequest(LocalNfsSecondaryStorageResource.java:78)
at
org.apache.cloudstack.storage.LocalHostEndpoint.sendMessage(LocalHostEndpoint.java:93)
at
org.apache.cloudstack.storage.LocalHostEndpoint$CmdRunner.runInContext(LocalHostEndpoint.java:110)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)
2014-04-10 16:26:23,360 DEBUG [o.a.c.s.r.NfsSecondaryStorageResource]
(pool-10-thread-1:ctx-1a8aedc3) Failed to register template into swift
com.cloud.utils.exception.CloudRuntimeException: GetRootDir for nfs://
10.0.0.200/export/secondary failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to set permissions
for /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dda8 due
to chmod: modification des permissions de
« /var/cloudstack/mnt/secStorage/7b0ceb7f-ae60-3922-80e7-8836fec2dd

RE: Cloudstack 4.3 instances can't access outside world

2014-04-10 Thread Suresh Sadhu
Ok  then work around is manually append rule to cloudbr1 . 

Take the backup of iptables rules 
Manfully detach the eth interface from  cloudbr0  and attach to cloudbr1
Apply the all exiting  firewall  rules manually on the interface gain


After that your VMs will access the public network.


Regards
Sadhu



-Original Message-
From: motty cruz [mailto:motty.c...@gmail.com] 
Sent: 10 April 2014 19:40
To: users@cloudstack.apache.org
Subject: Re: Cloudstack 4.3 instances can't access outside world

yes, I'm am using traffic labels, everything was working fine before the 
upgrade to 4.3. did not change anything on the cloudbr0 or cloudbr1.


On Thu, Apr 10, 2014 at 7:05 AM, Suresh Sadhu wrote:

> Did you used traffic name labels?
>
> In 4.3 traffic labels are not considering ,by default its attaching to 
> default  traffic labels(eg:in KVM its cloudbr0 ...due to this unable 
> to access public network i.r before upgrade if ieth2 attached cloudbr1 
> and after upgrade its attached to cloudbr0).maybe you are hitting this issue.
>
> Regards
> sadhu
>
>
> -Original Message-
> From: motty cruz [mailto:motty.c...@gmail.com]
> Sent: 10 April 2014 19:28
> To: users@cloudstack.apache.org
> Subject: Re: Cloudstack 4.3 instances can't access outside world
>
> yes I can ping VR, also after the upgrade VR has four insterfaces, 
> eth0 subnet for Instances, eth1, eth2 for public IP and eth3 for public IP.
>
>
> On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber  wrote:
>
> > Can you ping the VR? Log on to the VR, and get the iptables rules. 
> > How do they look?
> >
> > Erik Weber
> > 10. apr. 2014 00:21 skrev "motty cruz"  følgende:
> >
> > > I did add egress rules, reboot network but no sucess, so I removed 
> > > that rules and nothing.
> > >
> > > I am lost.
> > >
> > >
> > > On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber 
> wrote:
> > >
> > > > Did you remove the egress rule again? If not, try that.
> > > >
> > > > Erik
> > > > 9. apr. 2014 15:49 skrev "motty cruz" 
> følgende:
> > > >
> > > > > yes I try adding the rule, restart network and router but no
> success!
> > > > >
> > > > >
> > > > > On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber 
> > > > > 
> > > wrote:
> > > > >
> > > > > > Try adding an egress rule, and removing it again.
> > > > > >
> > > > > > We experience the same, but has so far believed it was 
> > > > > > because we
> > > > changed
> > > > > > the default rule from deny to allow after accounts were made..
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 8, 2014 at 11:14 PM, motty cruz 
> > > > > > 
> > > > > wrote:
> > > > > >
> > > > > > > I have two isolated network both virtual routers can ping
> > anywhere,
> > > > but
> > > > > > the
> > > > > > > Instances behind the virtual router can't ping or access 
> > > > > > > the
> > > > internet.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 8, 2014 at 10:38 AM, motty cruz <
> > motty.c...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I'm having issues with VMs unable to access outside world.
> > > > > > > > I
> > can
> > > > ping
> > > > > > > > gateway, also when I log in to virtual router, I am able 
> > > > > > > > to
> > ping
> > > > > > > > google.com or anywhere.
> > > > > > > > in the Egress rules I am allowing all. reboot network 
> > > > > > > > and
> > virtual
> > > > > > router
> > > > > > > > does not help.
> > > > > > > >
> > > > > > > > VMs were able to access outside before upgrading from 
> > > > > > > > 4.2 to
> > 4.3.
> > > > > > > >
> > > > > > > > any ideas?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: CloudStack 4.2.1 and XenServer 6.2

2014-04-10 Thread elenhil
Hugues Lepesant  writes:

> 
> Hi all,
> Hug
> 
> 


Hey! thanks for notes.
Also i want to mention that CS4.2.1 works well with XenServer local storages
based on LVM, not ext3.
I didn't configure this from the very beginning - firstly I hosted systemVMs
on iSCSI\NFS share, then i just enabled "system.vm.use.local.storage" in
global configuration and VMs just migrated without anything else

At least it worked for me



Re: Cloudstack 4.3 instances can't access outside world

2014-04-10 Thread motty cruz
yes, I'm am using traffic labels, everything was working fine before the
upgrade to 4.3. did not change anything on the cloudbr0 or cloudbr1.


On Thu, Apr 10, 2014 at 7:05 AM, Suresh Sadhu wrote:

> Did you used traffic name labels?
>
> In 4.3 traffic labels are not considering ,by default its attaching to
> default  traffic labels(eg:in KVM its cloudbr0 ...due to this unable to
> access public network i.r before upgrade if ieth2 attached cloudbr1 and
> after upgrade its attached to cloudbr0).maybe you are hitting this issue.
>
> Regards
> sadhu
>
>
> -Original Message-
> From: motty cruz [mailto:motty.c...@gmail.com]
> Sent: 10 April 2014 19:28
> To: users@cloudstack.apache.org
> Subject: Re: Cloudstack 4.3 instances can't access outside world
>
> yes I can ping VR, also after the upgrade VR has four insterfaces, eth0
> subnet for Instances, eth1, eth2 for public IP and eth3 for public IP.
>
>
> On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber  wrote:
>
> > Can you ping the VR? Log on to the VR, and get the iptables rules. How
> > do they look?
> >
> > Erik Weber
> > 10. apr. 2014 00:21 skrev "motty cruz"  følgende:
> >
> > > I did add egress rules, reboot network but no sucess, so I removed
> > > that rules and nothing.
> > >
> > > I am lost.
> > >
> > >
> > > On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber 
> wrote:
> > >
> > > > Did you remove the egress rule again? If not, try that.
> > > >
> > > > Erik
> > > > 9. apr. 2014 15:49 skrev "motty cruz" 
> følgende:
> > > >
> > > > > yes I try adding the rule, restart network and router but no
> success!
> > > > >
> > > > >
> > > > > On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber
> > > > > 
> > > wrote:
> > > > >
> > > > > > Try adding an egress rule, and removing it again.
> > > > > >
> > > > > > We experience the same, but has so far believed it was because
> > > > > > we
> > > > changed
> > > > > > the default rule from deny to allow after accounts were made..
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 8, 2014 at 11:14 PM, motty cruz
> > > > > > 
> > > > > wrote:
> > > > > >
> > > > > > > I have two isolated network both virtual routers can ping
> > anywhere,
> > > > but
> > > > > > the
> > > > > > > Instances behind the virtual router can't ping or access the
> > > > internet.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 8, 2014 at 10:38 AM, motty cruz <
> > motty.c...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I'm having issues with VMs unable to access outside world.
> > > > > > > > I
> > can
> > > > ping
> > > > > > > > gateway, also when I log in to virtual router, I am able
> > > > > > > > to
> > ping
> > > > > > > > google.com or anywhere.
> > > > > > > > in the Egress rules I am allowing all. reboot network and
> > virtual
> > > > > > router
> > > > > > > > does not help.
> > > > > > > >
> > > > > > > > VMs were able to access outside before upgrading from 4.2
> > > > > > > > to
> > 4.3.
> > > > > > > >
> > > > > > > > any ideas?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


RE: Cloudstack 4.3 instances can't access outside world

2014-04-10 Thread Suresh Sadhu
Did you used traffic name labels?

In 4.3 traffic labels are not considering ,by default its attaching to default  
traffic labels(eg:in KVM its cloudbr0 ...due to this unable to access public 
network i.r before upgrade if ieth2 attached cloudbr1 and after upgrade its 
attached to cloudbr0).maybe you are hitting this issue. 

Regards
sadhu


-Original Message-
From: motty cruz [mailto:motty.c...@gmail.com] 
Sent: 10 April 2014 19:28
To: users@cloudstack.apache.org
Subject: Re: Cloudstack 4.3 instances can't access outside world

yes I can ping VR, also after the upgrade VR has four insterfaces, eth0 subnet 
for Instances, eth1, eth2 for public IP and eth3 for public IP.


On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber  wrote:

> Can you ping the VR? Log on to the VR, and get the iptables rules. How 
> do they look?
>
> Erik Weber
> 10. apr. 2014 00:21 skrev "motty cruz"  følgende:
>
> > I did add egress rules, reboot network but no sucess, so I removed 
> > that rules and nothing.
> >
> > I am lost.
> >
> >
> > On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber  wrote:
> >
> > > Did you remove the egress rule again? If not, try that.
> > >
> > > Erik
> > > 9. apr. 2014 15:49 skrev "motty cruz"  følgende:
> > >
> > > > yes I try adding the rule, restart network and router but no success!
> > > >
> > > >
> > > > On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber 
> > > > 
> > wrote:
> > > >
> > > > > Try adding an egress rule, and removing it again.
> > > > >
> > > > > We experience the same, but has so far believed it was because 
> > > > > we
> > > changed
> > > > > the default rule from deny to allow after accounts were made..
> > > > >
> > > > >
> > > > > On Tue, Apr 8, 2014 at 11:14 PM, motty cruz 
> > > > > 
> > > > wrote:
> > > > >
> > > > > > I have two isolated network both virtual routers can ping
> anywhere,
> > > but
> > > > > the
> > > > > > Instances behind the virtual router can't ping or access the
> > > internet.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 8, 2014 at 10:38 AM, motty cruz <
> motty.c...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > > I'm having issues with VMs unable to access outside world. 
> > > > > > > I
> can
> > > ping
> > > > > > > gateway, also when I log in to virtual router, I am able 
> > > > > > > to
> ping
> > > > > > > google.com or anywhere.
> > > > > > > in the Egress rules I am allowing all. reboot network and
> virtual
> > > > > router
> > > > > > > does not help.
> > > > > > >
> > > > > > > VMs were able to access outside before upgrading from 4.2 
> > > > > > > to
> 4.3.
> > > > > > >
> > > > > > > any ideas?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Cloudstack 4.3 instances can't access outside world

2014-04-10 Thread motty cruz
yes I can ping VR, also after the upgrade VR has four insterfaces, eth0
subnet for Instances, eth1, eth2 for public IP and eth3 for public IP.


On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber  wrote:

> Can you ping the VR? Log on to the VR, and get the iptables rules. How do
> they look?
>
> Erik Weber
> 10. apr. 2014 00:21 skrev "motty cruz"  følgende:
>
> > I did add egress rules, reboot network but no sucess, so I removed that
> > rules and nothing.
> >
> > I am lost.
> >
> >
> > On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber  wrote:
> >
> > > Did you remove the egress rule again? If not, try that.
> > >
> > > Erik
> > > 9. apr. 2014 15:49 skrev "motty cruz"  følgende:
> > >
> > > > yes I try adding the rule, restart network and router but no success!
> > > >
> > > >
> > > > On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber 
> > wrote:
> > > >
> > > > > Try adding an egress rule, and removing it again.
> > > > >
> > > > > We experience the same, but has so far believed it was because we
> > > changed
> > > > > the default rule from deny to allow after accounts were made..
> > > > >
> > > > >
> > > > > On Tue, Apr 8, 2014 at 11:14 PM, motty cruz 
> > > > wrote:
> > > > >
> > > > > > I have two isolated network both virtual routers can ping
> anywhere,
> > > but
> > > > > the
> > > > > > Instances behind the virtual router can't ping or access the
> > > internet.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 8, 2014 at 10:38 AM, motty cruz <
> motty.c...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > > I'm having issues with VMs unable to access outside world. I
> can
> > > ping
> > > > > > > gateway, also when I log in to virtual router, I am able to
> ping
> > > > > > > google.com or anywhere.
> > > > > > > in the Egress rules I am allowing all. reboot network and
> virtual
> > > > > router
> > > > > > > does not help.
> > > > > > >
> > > > > > > VMs were able to access outside before upgrading from 4.2 to
> 4.3.
> > > > > > >
> > > > > > > any ideas?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Cloud Management Server Load CS4.3

2014-04-10 Thread Anoop Mohan
restarting man service helped.I have Python scripts running in another box
to provision machine which runs every minute. I think I have to increase
 the schedule time for the scripts

Is there any Global settings which i need to tweak related to API


On Thu, Apr 10, 2014 at 6:17 AM, Anoop Mohan  wrote:

>  ps aux | grep D
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> cloud21378 66.4 25.2 6522660 2029840 ? Sl   Apr09 908:58
> /usr/lib/jvm/jre/bin/java -Djava.awt.headless=true
> -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
> -XX:MaxPermSize=800m -classpath
> :::/etc/cloudstack/management:/usr/share/cloudstack-management/setup:/usr/share/cloudstack-management/bin/bootstrap.jar:/usr/share/cloudstack-management/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
> -Dcatalina.base=/usr/share/cloudstack-management
> -Dcatalina.home=/usr/share/cloudstack-management -Djava.endorsed.dirs=
> -Djava.io.tmpdir=/usr/share/cloudstack-management/temp
> -Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> org.apache.catalina.startup.Bootstrap start
>
>
>
> On Thu, Apr 10, 2014 at 5:57 AM, Marty Sweet  wrote:
>
>> On 10 April 2014 13:50, Anoop Mohan  wrote:
>> > Man Server load around 100 and java ,mysql  process taking too much
>> load.
>> >
>> > Man Server config : 4VCPU,8GB RAM,Centos 6.4
>> >
>> >
>> > top - 18:08:16 up 13 days,  5:02,  1 user,  load average: 108.75,
>> 101.90,
>> > 98.31
>> > Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
>> > Cpu(s):  1.9%us,  1.3%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.2%si,
>> > 0.0%st
>> > Mem:   8028712k total,  4987304k used,  3041408k free,   145424k buffers
>> > Swap:  8175608k total,0k used,  8175608k free,  2596920k cached
>> >
>> >   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>> > 21378 cloud 20   0 6369m 1.8g  17m S 136.5 23.4 834:31.48 java
>> > 21302 mysql 20   0 2214m 128m 7044 S 131.2  1.6   1136:00 mysqld
>> > 1 root  20   0 19228 1404 1124 S  0.0  0.0   0:00.23 init
>> > 2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd
>> > 3 root  RT   0 000 S  0.0  0.0   0:02.06 migration/0
>> >
>> > I found below blog and tried it .But it doesn't help
>> >
>> >
>> http://blog.remibergsma.com/2012/07/01/high-cpu-load-on-cloudstack-management-servers-after-leap-second-3062012235959-utc/
>> >
>>
>> Hi Anoop,
>>
>> Those processor loads shouldn't be causing such load averages. My
>> closest guess would be processes stuck in D state.
>> Could you provide the output of
>>
>> ps aux | grep D
>>
>>
>> Thanks,
>> Marty Sweet
>>
>
>
>
> --
> Thanks & Regards,
> Anoop Mohan
>



-- 
Thanks & Regards,
Anoop Mohan


Re: Cloud Management Server Load CS4.3

2014-04-10 Thread Anoop Mohan
 ps aux | grep D
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
cloud21378 66.4 25.2 6522660 2029840 ? Sl   Apr09 908:58
/usr/lib/jvm/jre/bin/java -Djava.awt.headless=true
-Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m -classpath
:::/etc/cloudstack/management:/usr/share/cloudstack-management/setup:/usr/share/cloudstack-management/bin/bootstrap.jar:/usr/share/cloudstack-management/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/cloudstack-management
-Dcatalina.home=/usr/share/cloudstack-management -Djava.endorsed.dirs=
-Djava.io.tmpdir=/usr/share/cloudstack-management/temp
-Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start



On Thu, Apr 10, 2014 at 5:57 AM, Marty Sweet  wrote:

> On 10 April 2014 13:50, Anoop Mohan  wrote:
> > Man Server load around 100 and java ,mysql  process taking too much load.
> >
> > Man Server config : 4VCPU,8GB RAM,Centos 6.4
> >
> >
> > top - 18:08:16 up 13 days,  5:02,  1 user,  load average: 108.75, 101.90,
> > 98.31
> > Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
> > Cpu(s):  1.9%us,  1.3%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.2%si,
> > 0.0%st
> > Mem:   8028712k total,  4987304k used,  3041408k free,   145424k buffers
> > Swap:  8175608k total,0k used,  8175608k free,  2596920k cached
> >
> >   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> > 21378 cloud 20   0 6369m 1.8g  17m S 136.5 23.4 834:31.48 java
> > 21302 mysql 20   0 2214m 128m 7044 S 131.2  1.6   1136:00 mysqld
> > 1 root  20   0 19228 1404 1124 S  0.0  0.0   0:00.23 init
> > 2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd
> > 3 root  RT   0 000 S  0.0  0.0   0:02.06 migration/0
> >
> > I found below blog and tried it .But it doesn't help
> >
> >
> http://blog.remibergsma.com/2012/07/01/high-cpu-load-on-cloudstack-management-servers-after-leap-second-3062012235959-utc/
> >
>
> Hi Anoop,
>
> Those processor loads shouldn't be causing such load averages. My
> closest guess would be processes stuck in D state.
> Could you provide the output of
>
> ps aux | grep D
>
>
> Thanks,
> Marty Sweet
>



-- 
Thanks & Regards,
Anoop Mohan


Fwd: KVM Cluster Xen cluster unable to build vms on kvm

2014-04-10 Thread Ivan Rodriguez
-- Forwarded message --
From: "Ivan Rodriguez" 
Date: Apr 10, 2014 10:59 PM
Subject: Fwd: KVM Cluster Xen cluster unable to build vms on kvm
To: 

-- Forwarded message --
From: "Ivan Rodriguez" 
Date: Apr 10, 2014 11:33 AM
Subject: KVM Cluster Xen cluster unable to build vms on kvm
To: 


Dear Cloudstack Users,

We are having a problem with our cloudstack 4.3,
we can't provision vms on kvm hypervisor, our configuration
has 1 Xen cluster which is working fine and 1 KVM cluster
which is not working, cloudstack can see the kvm hosts
and as far as the status goes they are online.

We tried to install the template for kvm 4.3 but there 3 different versions
out there

systemvmtemplate-2014-04-09-master-kvm.qcow2.bz2
systemvm64template-2014-01-14-master-kvm.qcow2.bz2
systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

We are trying with the 2014, also when you have 2 clusters should we have
4 system vms ???


However as soon as we try to provision something cloudstack send the
following error:




2014-04-10 11:12:44,042 WARN  [c.c.s.s.SecondaryStorageManagerImpl]
(secstorage-1:ctx-754a9ede) Exception while trying to sta
rt secondary storage vm
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[SecondaryStorageVm|s-21-VM]Scope=interface
com.cloud.dc.DataCenter; id=1
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:921)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
at
com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
at
com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:88)
at
com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:79)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)


Fwd: KVM Cluster Xen cluster unable to build vms on kvm

2014-04-10 Thread Ivan Rodriguez
-- Forwarded message --
From: "Ivan Rodriguez" 
Date: Apr 10, 2014 11:33 AM
Subject: KVM Cluster Xen cluster unable to build vms on kvm
To: 


Dear Cloudstack Users,

We are having a problem with our cloudstack 4.3,
we can't provision vms on kvm hypervisor, our configuration
has 1 Xen cluster which is working fine and 1 KVM cluster
which is not working, cloudstack can see the kvm hosts
and as far as the status goes they are online.

We tried to install the template for kvm 4.3 but there 3 different versions
out there

systemvmtemplate-2014-04-09-master-kvm.qcow2.bz2
systemvm64template-2014-01-14-master-kvm.qcow2.bz2
systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

We are trying with the 2014, also when you have 2 clusters should we have
4 system vms ???


However as soon as we try to provision something cloudstack send the
following error:




2014-04-10 11:12:44,042 WARN  [c.c.s.s.SecondaryStorageManagerImpl]
(secstorage-1:ctx-754a9ede) Exception while trying to sta
rt secondary storage vm
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[SecondaryStorageVm|s-21-VM]Scope=interface
com.cloud.dc.DataCenter; id=1
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:921)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
at
com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
at
com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
at
com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:88)
at
com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:79)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)


Re: Cloud Management Server Load CS4.3

2014-04-10 Thread Marty Sweet
On 10 April 2014 13:50, Anoop Mohan  wrote:
> Man Server load around 100 and java ,mysql  process taking too much load.
>
> Man Server config : 4VCPU,8GB RAM,Centos 6.4
>
>
> top - 18:08:16 up 13 days,  5:02,  1 user,  load average: 108.75, 101.90,
> 98.31
> Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.9%us,  1.3%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.2%si,
> 0.0%st
> Mem:   8028712k total,  4987304k used,  3041408k free,   145424k buffers
> Swap:  8175608k total,0k used,  8175608k free,  2596920k cached
>
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 21378 cloud 20   0 6369m 1.8g  17m S 136.5 23.4 834:31.48 java
> 21302 mysql 20   0 2214m 128m 7044 S 131.2  1.6   1136:00 mysqld
> 1 root  20   0 19228 1404 1124 S  0.0  0.0   0:00.23 init
> 2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd
> 3 root  RT   0 000 S  0.0  0.0   0:02.06 migration/0
>
> I found below blog and tried it .But it doesn't help
>
> http://blog.remibergsma.com/2012/07/01/high-cpu-load-on-cloudstack-management-servers-after-leap-second-3062012235959-utc/
>

Hi Anoop,

Those processor loads shouldn't be causing such load averages. My
closest guess would be processes stuck in D state.
Could you provide the output of

ps aux | grep D


Thanks,
Marty Sweet


Cloud Management Server Load CS4.3

2014-04-10 Thread Anoop Mohan
Man Server load around 100 and java ,mysql  process taking too much load.

Man Server config : 4VCPU,8GB RAM,Centos 6.4


top - 18:08:16 up 13 days,  5:02,  1 user,  load average: 108.75, 101.90,
98.31
Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.9%us,  1.3%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.2%si,
0.0%st
Mem:   8028712k total,  4987304k used,  3041408k free,   145424k buffers
Swap:  8175608k total,0k used,  8175608k free,  2596920k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
21378 cloud 20   0 6369m 1.8g  17m S 136.5 23.4 834:31.48 java
21302 mysql 20   0 2214m 128m 7044 S 131.2  1.6   1136:00 mysqld
1 root  20   0 19228 1404 1124 S  0.0  0.0   0:00.23 init
2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd
3 root  RT   0 000 S  0.0  0.0   0:02.06 migration/0

I found below blog and tried it .But it doesn't help

http://blog.remibergsma.com/2012/07/01/high-cpu-load-on-cloudstack-management-servers-after-leap-second-3062012235959-utc/


-- 
Thanks & Regards,
Anoop Mohan


Re: Error in terminal:No package cloud-client availble

2014-04-10 Thread anil lakineni
ok , what about your DB..is it installed successfully

and if installed once again start the mysqld service...

and once check the gateway.. by " #route -n "  and check that whether you
are finding your gateway or not (if not add the gateway firstly and try it
.u may get the UI)..

Regards,
Anil Kumar L



Re: AD LDAP authentication failing post CS 4.2.1 to CS 4.3 upgrade

2014-04-10 Thread Antonio Packery
Thats the strange bit, i can add the ldap server which in essence means the 
ldap configuration works but when i try to add a user it fails.

Is there any enhanced debugging i can enable to see what happens when the ldap 
bind/list happens?

On 04/10/2014 08:59 AM, Ian Duffy wrote:

No. Email is only required for imported users as we must create a
cloudstack account for them and that requires an email address.

When you add an ldap server cloudstack attempts to bind to it to validate
your settings. If the bind fails the server will not add.
On Apr 10, 2014 7:32 AM, "Antonio Packery" 

wrote:

> Are there mandatory attributes that need to exist for the
> ldap.bind.principal account .e.g. email addy etc?
>
> On 04/10/2014 08:19 AM, Ian Duffy wrote:
>
> Sorry about the delay on replying. My new $dayJob restricts gmail/gapps
> access.
>
> I am not using LDAPS at the moment. I have tested it in 4.3 and
> confirmed that it worked some time ago though..
>
>
> Disclaimer: This message and/or attachment(s) may contain privileged,
> confidential and/or personal information. If you are not the intended
> recipient you may not disclose or distribute any of the information
> contained within this message. In such case you must destroy this message
> and inform the sender of the error. T-Systems does not accept liability for
> any errors, omissions, information and viruses contained in the
> transmission of this message. Any opinions, conclusions and other
> information contained within this message not related to T-Systems'
> official business is deemed to be that of the individual only and is not
> endorsed by T-Systems.
>
> This message and/or attachment(s) may contain privileged or confidential
> information. If you are not the intended recipient you may not disclose or
> distribute any of the information contained within this message. In such
> case you must destroy this message and inform the sender of the error.
> T-Systems does not accept liability for any errors, omissions, information
> and viruses contained in the transmission of this message. Any opinions,
> conclusions and other information contained within this message not related
> to T-Systems' official business is deemed to be that of the individual only
> and is not endorsed by T-Systems.
>
> T-Systems - Business Flexibility
>


Disclaimer: This message and/or attachment(s) may contain privileged, 
confidential and/or personal information. If you are not the intended recipient 
you may not disclose or distribute any of the information contained within this 
message. In such case you must destroy this message and inform the sender of 
the error. T-Systems does not accept liability for any errors, omissions, 
information and viruses contained in the transmission of this message. Any 
opinions, conclusions and other information contained within this message not 
related to T-Systems' official business is deemed to be that of the individual 
only and is not endorsed by T-Systems.

This message and/or attachment(s) may contain privileged or confidential
 
information. If you are not the intended recipient you may not disclose or  
  
distribute any of the information contained within this message. In such
case you must destroy this message and inform the sender of the error.
T-Systems does not accept liability for any errors, omissions, information
and viruses contained in the transmission of this message. Any opinions, 
conclusions and other information contained within this message not related 
to T-Systems' official business is deemed to be that of the individual only 
and is not endorsed by T-Systems.

  
T-Systems - Business Flexibility


Re: AD LDAP authentication failing post CS 4.2.1 to CS 4.3 upgrade

2014-04-10 Thread Ian Duffy
No. Email is only required for imported users as we must create a
cloudstack account for them and that requires an email address.

When you add an ldap server cloudstack attempts to bind to it to validate
your settings. If the bind fails the server will not add.
On Apr 10, 2014 7:32 AM, "Antonio Packery" 
wrote:

> Are there mandatory attributes that need to exist for the
> ldap.bind.principal account .e.g. email addy etc?
>
> On 04/10/2014 08:19 AM, Ian Duffy wrote:
>
> Sorry about the delay on replying. My new $dayJob restricts gmail/gapps
> access.
>
> I am not using LDAPS at the moment. I have tested it in 4.3 and
> confirmed that it worked some time ago though..
>
>
> Disclaimer: This message and/or attachment(s) may contain privileged,
> confidential and/or personal information. If you are not the intended
> recipient you may not disclose or distribute any of the information
> contained within this message. In such case you must destroy this message
> and inform the sender of the error. T-Systems does not accept liability for
> any errors, omissions, information and viruses contained in the
> transmission of this message. Any opinions, conclusions and other
> information contained within this message not related to T-Systems'
> official business is deemed to be that of the individual only and is not
> endorsed by T-Systems.
>
> This message and/or attachment(s) may contain privileged or confidential
> information. If you are not the intended recipient you may not disclose or
> distribute any of the information contained within this message. In such
> case you must destroy this message and inform the sender of the error.
> T-Systems does not accept liability for any errors, omissions, information
> and viruses contained in the transmission of this message. Any opinions,
> conclusions and other information contained within this message not related
> to T-Systems' official business is deemed to be that of the individual only
> and is not endorsed by T-Systems.
>
> T-Systems - Business Flexibility
>