[jira] [Resolved] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JF Vincent resolved CLOUDSTACK-7741. Resolution: Not a Problem Our LDAP server required different field that the one used in the doc. UI login - 401 unable to verify user credentials Key: CLOUDSTACK-7741 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Cloudstack CentOS installation - 2 management servers Reporter: JF Vincent Priority: Critical After a period of time (after the night, second occurence) , on one of our two servers, we're no more able to login. Google Chrome or Mozilla will hang after pressing the login button. After restarting the management server, problem disappear for many hours. Here is the only error log in the apiserver.log : 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463564799 401 unable to verify user credentials 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463578569 401 unable to verify user credentials 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463751221 401 unable to verify user credentials 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463870965 401 unable to verify user credentials 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463876790 401 unable to verify user credentials while this server has the problem, on the other servr with is the backup we don't have the problem. The problem occurs for LDAP and local accounts. Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176804#comment-14176804 ] JF Vincent commented on CLOUDSTACK-7703: The problem occurs once we add a NFS storage on a local root VOLUME. The NFS pool is almost full. Problem is the same with VM creation with local root / NFS volume. Problem occurs when the volume is implented. Regards Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Centos 6.5 Reporter: JF Vincent Priority: Critical When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free CPU: 57268 , Requested CPU: 500 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free RAM: 93916725248 , Requested RAM: 524288000 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has enough CPU and RAM available 2014-10-14 11:39:20,721 DEBUG
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176819#comment-14176819 ] JF Vincent commented on CLOUDSTACK-7703: two storage pools. One local and one NFS ROOT disks are always local. Add-on disks are from the NFS pool. Yes we create them with two disks. Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Centos 6.5 Reporter: JF Vincent Priority: Critical When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free CPU: 57268 , Requested CPU: 500 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free RAM: 93916725248 , Requested RAM: 524288000 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has enough CPU and RAM available 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS:
[jira] [Commented] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14174886#comment-14174886 ] JF Vincent commented on CLOUDSTACK-7741: not just that in the catalina.out : Catalina.out : 2014-10-17 09:42:22,888 DEBUG [c.c.a.ApiServlet] (http-6443-exec-467:ctx-86fe168f) ===START=== 10.26.238.65 -- POST 2014-10-17 09:42:22,891 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-467:ctx-86fe168f) Attempting to log in user: jf in domain 1 2014-10-17 09:42:22,892 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-467:ctx-86fe168f) Retrieving user: jf 2014-10-17 09:42:22,900 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-467:ctx-86fe168f) User: jf in domain 1 has successfully logged in UI login - 401 unable to verify user credentials Key: CLOUDSTACK-7741 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Cloudstack CentOS installation - 2 management servers Reporter: JF Vincent Priority: Critical After a period of time (after the night, second occurence) , on one of our two servers, we're no more able to login. Google Chrome or Mozilla will hang after pressing the login button. After restarting the management server, problem disappear for many hours. Here is the only error log in the apiserver.log : 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463564799 401 unable to verify user credentials 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463578569 401 unable to verify user credentials 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463751221 401 unable to verify user credentials 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463870965 401 unable to verify user credentials 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463876790 401 unable to verify user credentials while this server has the problem, on the other servr with is the backup we don't have the problem. The problem occurs for LDAP and local accounts. Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
JF Vincent created CLOUDSTACK-7741: -- Summary: UI login - 401 unable to verify user credentials Key: CLOUDSTACK-7741 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Cloudstack CentOS installation - 2 management servers Reporter: JF Vincent Priority: Critical After a period of time (after the night, second occurence) , on one of our two servers, we're no more able to login. Google Chrome or Mozilla will hang after pressing the login button. After restarting the management server, problem disappear for many hours. Here is the only error log in the apiserver.log : 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463564799 401 unable to verify user credentials 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463578569 401 unable to verify user credentials 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463751221 401 unable to verify user credentials 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463870965 401 unable to verify user credentials 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463876790 401 unable to verify user credentials while this server has the problem, on the other servr with is the backup we don't have the problem. The problem occurs for LDAP and local accounts. Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JF Vincent updated CLOUDSTACK-7741: --- Affects Version/s: (was: 4.2.0) 4.3.0 UI login - 401 unable to verify user credentials Key: CLOUDSTACK-7741 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Cloudstack CentOS installation - 2 management servers Reporter: JF Vincent Priority: Critical After a period of time (after the night, second occurence) , on one of our two servers, we're no more able to login. Google Chrome or Mozilla will hang after pressing the login button. After restarting the management server, problem disappear for many hours. Here is the only error log in the apiserver.log : 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463564799 401 unable to verify user credentials 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463578569 401 unable to verify user credentials 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463751221 401 unable to verify user credentials 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463870965 401 unable to verify user credentials 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET command=listCapabilitiesresponse=jsonsessionkey=null_=1413463876790 401 unable to verify user credentials while this server has the problem, on the other servr with is the backup we don't have the problem. The problem occurs for LDAP and local accounts. Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
JF Vincent created CLOUDSTACK-7703: -- Summary: Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Centos 6.5 Reporter: JF Vincent Priority: Critical When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free CPU: 57268 , Requested CPU: 500 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free RAM: 93916725248 , Requested RAM: 524288000 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has enough CPU and RAM available 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS: Can alloc CPU from host: 79, used: 19000, reserved: 500, actual total: 19192, total with overprovisioning: 76768; requested cpu:500,alloc_from_last_host?:false ,considerReservedCapacity?: true 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS: Can alloc MEM from host: 79, used: 17192452096, reserved: 524288000, total: 111633465344; requested mem:
[jira] [Created] (CLOUDSTACK-7672) Virtual routers HA do not serve correctly the root password service for starting VMs
JF Vincent created CLOUDSTACK-7672: -- Summary: Virtual routers HA do not serve correctly the root password service for starting VMs Key: CLOUDSTACK-7672 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7672 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.3.0 Environment: VMware Reporter: JF Vincent When the HA virtual router is selected, Both DHCP servers are active and thus when the VM is trying to get the root password server, the request will fail each time the first DHCP server to respond is the passive one. Very annoying. Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7549) Apache cloudstack failed to authenticate using a novell NIM openldap server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135093#comment-14135093 ] JF Vincent commented on CLOUDSTACK-7549: HAD a look on the packets sent and received by the NIM server. Cloudstack correctly bound to the server (this one correclty reported one entry for the user) but do not ask the server to check the password. Just 3 packets were exchanged. Apache cloudstack failed to authenticate using a novell NIM openldap server --- Key: CLOUDSTACK-7549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7549 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Novell NIM openldap server Reporter: JF Vincent Priority: Critical Succeeded to connect to a A.D. server. When trying to connect to a Novel NIM authentication server, authentication failed while correctly configured : DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===START=== 10.26.238.65 -- POST DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Attempting to log in user: b11 in domain 1 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match INFO [o.a.c.l.LdapManagerImpl] (http-6443-exec-6:ctx-f6badad3) Failed to authenticate user: b11. incorrect password. DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Unable to authenticate user with username b11 in domain 1 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) User: a543197 in domain 1 has failed to log in DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===END=== 10.26.238.65 -- POST -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7549) Apache cloudstack failed to authenticate using a novell NIM openldap server
JF Vincent created CLOUDSTACK-7549: -- Summary: Apache cloudstack failed to authenticate using a novell NIM openldap server Key: CLOUDSTACK-7549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7549 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Novell NIM openldap server Reporter: JF Vincent Priority: Critical Succeeded to connect to a A.D. server. When trying to connect to a Novel NIM authentication server, authentication failed while correctly configured : DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===START=== 10.26.238.65 -- POST DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Attempting to log in user: a543197 in domain 1 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match INFO [o.a.c.l.LdapManagerImpl] (http-6443-exec-6:ctx-f6badad3) Failed to authenticate user: a543197. incorrect password. DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Unable to authenticate user with username a543197 in domain 1 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) User: a543197 in domain 1 has failed to log in DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===END=== 10.26.238.65 -- POST -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7549) Apache cloudstack failed to authenticate using a novell NIM openldap server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JF Vincent updated CLOUDSTACK-7549: --- Description: Succeeded to connect to a A.D. server. When trying to connect to a Novel NIM authentication server, authentication failed while correctly configured : DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===START=== 10.26.238.65 -- POST DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Attempting to log in user: b11 in domain 1 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match INFO [o.a.c.l.LdapManagerImpl] (http-6443-exec-6:ctx-f6badad3) Failed to authenticate user: b11. incorrect password. DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Unable to authenticate user with username b11 in domain 1 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) User: a543197 in domain 1 has failed to log in DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===END=== 10.26.238.65 -- POST was: Succeeded to connect to a A.D. server. When trying to connect to a Novel NIM authentication server, authentication failed while correctly configured : DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===START=== 10.26.238.65 -- POST DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Attempting to log in user: a543197 in domain 1 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match INFO [o.a.c.l.LdapManagerImpl] (http-6443-exec-6:ctx-f6badad3) Failed to authenticate user: a543197. incorrect password. DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: a543197 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Unable to authenticate user with username a543197 in domain 1 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) User: a543197 in domain 1 has failed to log in DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===END=== 10.26.238.65 -- POST Apache cloudstack failed to authenticate using a novell NIM openldap server --- Key: CLOUDSTACK-7549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7549 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Novell NIM openldap server Reporter: JF Vincent Priority: Critical Succeeded to connect to a A.D. server. When trying to connect to a Novel NIM authentication server, authentication failed while correctly configured : DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===START=== 10.26.238.65 -- POST DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Attempting to log in user: b11 in domain 1 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.MD5UserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match INFO [o.a.c.l.LdapManagerImpl] (http-6443-exec-6:ctx-f6badad3) Failed to authenticate user: b11. incorrect password. DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Retrieving user: b11 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (http-6443-exec-6:ctx-f6badad3) Password does not match DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) Unable to authenticate user with username b11 in domain 1 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-6:ctx-f6badad3) User: a543197 in domain 1 has failed to log in DEBUG [c.c.a.ApiServlet] (http-6443-exec-6:ctx-f6badad3) ===END=== 10.26.238.65 -- POST -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-6885) system-vm rsyslog logs rotation does not work properly
JF Vincent created CLOUDSTACK-6885:
--
Summary: system-vm rsyslog logs rotation does not work properly
Key: CLOUDSTACK-6885
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6885
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.3.0
Reporter: JF Vincent
Priority: Critical
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in
potential FULL on /var/ and critical failures on the VR.
See below please :
root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.
reload argument in the invoke-rc.d line shoud be replaced by rotate
argument.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6885) system-vm rsyslog logs rotation does not work properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JF Vincent updated CLOUDSTACK-6885:
---
Description:
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in
potential FULL on /var/ and critical failures on the VR.
See below please :
root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload /dev/null
endscript
}
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload /dev/null
endscript
}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.
reload argument in the invoke-rc.d line shoud be replaced by rotate
argument.
was:
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in
potential FULL on /var/ and critical failures on the VR.
See below please :
root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.
reload argument in the invoke-rc.d line shoud be replaced by rotate
argument.
system-vm rsyslog logs rotation does not work properly
--
Key: CLOUDSTACK-6885
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6885
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.3.0
Reporter: JF Vincent
Priority: Critical
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in
potential FULL on /var/ and critical failures on the VR.
See below please :
root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload /dev/null
endscript
}
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload /dev/null
endscript
}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.
reload argument in the invoke-rc.d line shoud be replaced by rotate
argument.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6168) vm.instancename.flag inefficient
JF Vincent created CLOUDSTACK-6168: -- Summary: vm.instancename.flag inefficient Key: CLOUDSTACK-6168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Cloudstack 4.2.1 on Reporter: JF Vincent Fix For: Future -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JF Vincent updated CLOUDSTACK-6168: --- Description: have set vm.instancename.flag to YES, restarted the management server - started a new instance in my KVM zone with or without any display name = no change on instance name on hypervisor. - started a new instance in my vCenter zone with a display name madrid. Instance name on ESXi is just madrid and not i-xx--madrid. Regards JF vm.instancename.flag inefficient Key: CLOUDSTACK-6168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Cloudstack 4.2.1 on Reporter: JF Vincent Fix For: Future have set vm.instancename.flag to YES, restarted the management server - started a new instance in my KVM zone with or without any display name = no change on instance name on hypervisor. - started a new instance in my vCenter zone with a display name madrid. Instance name on ESXi is just madrid and not i-xx--madrid. Regards JF -- This message was sent by Atlassian JIRA (v6.1.5#6160)
