[jira] [Closed] (CLOUDSTACK-6748) Creating an instance with user-data when network doesn't support user-data should error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-6748. --- Creating an instance with user-data when network doesn't support user-data should error --- Key: CLOUDSTACK-6748 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.4.3, 4.5.1 While deploying a VM we provide user-data in order to configure appliance instances. Right now we do not throw error if user data is sent while deploying the vm and network does not support userdata. We should not allow sending userdata when network does not support UserData service since this may create eventual problems. We should fail fast or error the creation of the instance if user-data is supplied when the guest network doesn't support this capability The same applies for ssh key and password enabled templates. Say if a vm is deployed using password enabled template we cannot send password to router if network does not support userdata service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6748) Creating an instance with user-data when network doesn't support user-data should error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-6748. - Resolution: Fixed Creating an instance with user-data when network doesn't support user-data should error --- Key: CLOUDSTACK-6748 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.4.3, 4.5.1 While deploying a VM we provide user-data in order to configure appliance instances. Right now we do not throw error if user data is sent while deploying the vm and network does not support userdata. We should not allow sending userdata when network does not support UserData service since this may create eventual problems. We should fail fast or error the creation of the instance if user-data is supplied when the guest network doesn't support this capability The same applies for ssh key and password enabled templates. Say if a vm is deployed using password enabled template we cannot send password to router if network does not support userdata service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-317) get xcp 1.5 into an advanced network zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-317. -- Resolution: Won't Fix very old issue get xcp 1.5 into an advanced network zone - Key: CLOUDSTACK-317 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-317 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Environment: Cloudstack 4.0.0/ubuntu 12.04 LTS for management server/xcp 1.5 appliance centos from xen.org Reporter: benoit lair Fix For: 4.4.3 I'm trying to get my xcp 1.5 onto cloudstack. After the well known-tricks on NFS python scripts and packages xs:main, i can get my xcp on a basic network zone. But when i try to get my xcp 1.5 onto an advanced network zone, i got errors. Here is the log entries when i try to get it working. 2012-10-11 15:32:30,347 DEBUG [xen.resource.XenServerConnectionPool] (catalina-exec-4:null) Logging on as the master to 172.20.0.7 2012-10-11 15:32:30,438 INFO [xen.discoverer.XcpServerDiscoverer] (catalina-exec-4:null) Found host xenserver-xcp-vps-07 ip=172.20.0.7 product version=1.4.90 2012-10-11 15:32:30,610 DEBUG [xen.resource.CitrixResourceBase] (catalina-exec-4:null) Management network is on pif=2994f899-f449-178f-7da4-bf1ecdbd8259 2012-10-11 15:32:30,621 WARN [xen.resource.CitrixResourceBase] (catalina-exec-4:null) Unable to get host information for 172.20.0.7 java.lang.NullPointerException at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getHostInfo(CitrixResourceBase.java:4331) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.initialize(CitrixResourceBase.java:4460) at com.cloud.resource.ResourceManagerImpl.createHostAndAgent(ResourceManagerImpl.java:1598) at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:720) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:544) at com.cloud.api.commands.AddHostCmd.execute(AddHostCmd.java:140) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:543) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:422) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:63) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2012-10-11 15:32:30,622 WARN [xen.resource.CitrixResourceBase] (catalina-exec-4:null) Unable to get host information for 172.20.0.7 2012-10-11 15:32:30,622 INFO [cloud.resource.ResourceManagerImpl] (catalina-exec-4:null) Unable to fully initialize the agent because no StartupCommands are returned 2012-10-11 15:32:30,622 INFO [cloud.resource.ResourceManagerImpl] (catalina-exec-4:null) server resources successfully discovered by XCP Agent 2012-10-11 15:32:30,622 WARN [cloud.api.ApiDispatcher] (catalina-exec-4:null) class com.cloud.api.ServerApiException : Failed to add host 2012-10-11 15:32:52,774 DEBUG [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) Primary storage is not ready, wait until it is ready to launch secondary
[jira] [Closed] (CLOUDSTACK-3225) Multiple NPEs when cloudstack-management service is restarted with incomplete tasks/notifications.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-3225. --- Resolution: Won't Fix old issue, not seen anymore Multiple NPEs when cloudstack-management service is restarted with incomplete tasks/notifications. -- Key: CLOUDSTACK-3225 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3225 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: master-6-17-stable build Reporter: manasaveloori Assignee: Prachi Damle Priority: Minor Fix For: 4.4.3 Attachments: management-server.zip Steps: 1.Have a CS setup with any zone. 2.Create any task like rebooting the instance/ router VM/VPC restart etc.. 3.While the task is incomplete try to restart the management service. Observation: Observed multiple NPEs in the MS log. 2013-06-27 17:26:26,267 ERROR [cloud.api.ApiServlet] (catalina-exec-4:null) unknown exception writing api response java.lang.NullPointerException at com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:309) at com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:150) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:238) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-06-27 17:26:26,283 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) ===END=== 10.252.192.69 -- GET command=queryAsyncJobResultjobId=459114c9-5e2a-4cf0-8267-df2a179499c2response=jsonsessionkey=nJAZqwBB2k8KRNoM%2FpKQPK4DZkg%3D_=1372314733853 2013-06-27 17:26:29,277 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===START=== 10.252.192.69 -- GET command=queryAsyncJobResultjobId=459114c9-5e2a-4cf0-8267-df2a179499c2response=jsonsessionkey=nJAZqwBB2k8KRNoM%2FpKQPK4DZkg%3D_=1372314736852 2013-06-27 17:26:29,278 ERROR [cloud.api.ApiServlet] (catalina-exec-5:null) unknown exception writing api response java.lang.NullPointerException at com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:309) at com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:150) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:238) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) Attaching the MS log. -- This message was sent by Atlassian JIRA
[jira] [Closed] (CLOUDSTACK-124) NetworkGarbageCollector not cleaning up networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-124. -- Resolution: Won't Fix very old issue and we don't support pre-4.0 CloudStack issues NetworkGarbageCollector not cleaning up networks Key: CLOUDSTACK-124 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-124 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: pre-4.0.0 Environment: KVM Reporter: Adam Tistler Priority: Minor Fix For: 4.4.3 Seeing an issue in version 2.2.14 with the NetworkGarbageCollector. Basically we have a virtual network (all of whose virtual machines have been terminated), however the network never gets cleaned up, and the virtual router never stops. Config: - category: Advanced name: network.gc.interval value: 600 description: Seconds to wait before checking for networks to shutdown - category: Advanced name: network.gc.wait value: 600 description: Time (in seconds) to wait before shutting down a network that's not in used Management logs (grepped): 2012-08-13 13:58:01,598 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 399 to be free for the first time. Adding it to the list: 1313360040 2012-08-13 14:08:01,758 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 239 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 241 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 247 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 265 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 277 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 280 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 281 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 296 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 325 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 352 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) We found network 353 to be free for the first time. Adding it to the list: 1313360626 2012-08-13 14:08:01,759 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 399 is still free but it's not time to shutdown yet: 1313360040 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 239 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 241 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 247 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 265 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 277 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 280 is still free but it's not time to shutdown yet: 1313360626 2012-08-13 14:18:01,761 DEBUG [cloud.network.NetworkManagerImpl] (Network-Scavenger-1:null) Network 281 is still free but it's not time to shutdown yet: 1313360626 2012-08-13
[jira] [Assigned] (CLOUDSTACK-5550) UI - Api key and secret key not fully visible in user detail view.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-5550: --- Assignee: Rohit Yadav (was: Gabor Apati-Nagy) UI - Api key and secret key not fully visible in user detail view. -- Key: CLOUDSTACK-5550 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5550 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Rohit Yadav Priority: Minor Fix For: 4.4.3 Attachments: api-key.png, secret-key.png UI - Api key and secret key not fully visible in user detail view. Steps to reproduce the problem: Go to Accounts-select any account and use View users. Select any user and generate keys. Notice that api key and secret key get truncated in the user detail view. Attaching screenshots: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav reassigned CLOUDSTACK-7539:
---
Assignee: Rohit Yadav (was: Min Chen)
[S3] Parallel deployment makes reference count of a cache in nfs secondary
staging store negative(-1)
-
Key: CLOUDSTACK-7539
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, Template
Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0, Hypervisor:
KVM, Primary Storage: Local Storage, Secondary Storage: S3(RADOS), Zone:
Advanced
Reporter: Hiroki Ohashi
Assignee: Rohit Yadav
Priority: Critical
Fix For: 4.5.1
When we create some instances in parallel in an environment shown above, an
exception like ([#2]) happens. After that, reference count of a cache in NFS
Secondary Staging Store(SSS) becomes negative([#3]).
In this situcation, we can't use a template used for creating the instances
because negative reference count will cause another
exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0
branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed
about volume reference count setter problem by myself. But the reference
count problem still happens.
Conditions to trigger
- A cache of a template isn't on NFS SSS.
- Choose compute offering that occupies all resources in a host.(ex. Use
all cores and almost all memory)
- Create multiple instances ([#1]).
Other behaviors
- Management server inserts multiple entries for template cache(ImageCache)
to cloud.template_store_ref.
- SSVM probably downloads same template from S3 and creates multiple caches
to NFS SSS concurrently. Sometimes, SSVM retries download and cache creation.
(1)
{anchor:1}
{noformat}
#! /bin/bash
COMPUTE_OFFERING=b6fc0598-6903-48cc-b894-ead3bb0e39f5
TEMPLATE=ef1d5a8e-5951-4036-a236-fe2d47224fe4
ZONE=23156857-4722-4fc4-86d4-a12ca1028197
NETWORK=4ba56179-f7b9-4560-a00e-80c946856ff8
KEYPAIR=mykey
NAME1=test-template-error-0003
NAME2=test-template-error-0004
cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
sleep 1
cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
{noformat}
(2)
{anchor:2}
{noformat}
2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
Seq 171-1789133096: Processing: { Ans: , MgmtId: 98532524288, via: 171, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,id:0,accountId:0,hvm:false,name:22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,size:14340259840,physicalSize:14340259840}},result:true,wait:0}}]
}
2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request]
(Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received: {
Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject]
(Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new
state from Allocated via OperationSuccessed
at
com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
at
org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
at
org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
at
org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
at
org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:165)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:428)
at
[jira] [Assigned] (CLOUDSTACK-1309) Large guest subnets downgrade performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-1309: --- Assignee: Rohit Yadav (was: Prasanna Santhanam) Large guest subnets downgrade performance - Key: CLOUDSTACK-1309 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1309 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: pre-4.0.0 Environment: CloudStack version: 3.0.5.20120904142539 MySQL server version: 5.1.61-4.el6 Reporter: Vladimir Ostrovsky Assignee: Rohit Yadav Fix For: 4.4.3 Attachments: Large guest subnets in CloudStack.jpg When guest network / VLAN is defined in CloudStack, a separate record is created in the cloud.user_ip_address table for each address in the range, even if it isn't really allocated. As a result, if a very wide subnet is defined (say, Class B), then the table contains at least 65534 records. On a system with 5 such Class B VLANs defined, the size of the table grew to more than 327670 records. This caused mysqld to spend about 95-99% of its time in Waiting state and efficiently stuck the CloudStack. top - 11:58:43 up 2:25, 3 users, load average: 2.91, 2.71, 2.21 Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie Cpu0 : 1.8%us, 0.4%sy, 0.0%ni, 1.8%id, 95.7%wa, 0.0%hi, 0.4%si, 0.0%st When I tried to delete such network, the operation lasted about an hour. It obviously doesn't seem to be limitation of MySQL itself; I suspect that CloudStack's algorythms working with this table are pretty inefficient and aren't built to the case of huge number of addresses. Am I right? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-2919) Snapshot cannot be saved to full Secondary Storage, but doesn't utilize other Secondary Storage locations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-2919: --- Assignee: Rohit Yadav (was: Nitin Mehta) Snapshot cannot be saved to full Secondary Storage, but doesn't utilize other Secondary Storage locations - Key: CLOUDSTACK-2919 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2919 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Rohit Yadav Fix For: 4.5.1 This issue was noticed when a customer attempted to take a snapshot but failed. Logs revealed that the Secondary Storage to which CS was trying to save the Snapshot had no more free space. CS did retry multiple times to save to the same Secondary Storage location after the initial failure but with no success. However, CS failed to notice two other Secondary Storage locations in the same zone with enough free space for a successful snapshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-2853) Cloudstack copies xenserver scripts while adding host even the server is KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-2853: --- Assignee: Rohit Yadav Cloudstack copies xenserver scripts while adding host even the server is KVM host - Key: CLOUDSTACK-2853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2853 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: master build Reporter: Sanjeev N Assignee: Rohit Yadav Fix For: 4.4.3 Cloudstack copies xenserver scripts while adding host even the server is KVM host 1.Create a zone with cluster kvm and add at least one kvm host. 2.After the host addition is successful login to the hypervisor and check the scripts at following location: /usr/share/cloudstack-common/scripts/vm/hypervisor/ I could see all the xenserver related scripts at /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-310) Failed to add host - Plugin error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-310. -- Resolution: Won't Fix very old issue Failed to add host - Plugin error - Key: CLOUDSTACK-310 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-310 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Xen Affects Versions: 4.1.0, 4.2.0 Environment: Management server is running centos 6.2 Host is running Xen 4.1 on ubuntu 12.04 LTS installed with xcp-xapi package Followed the tutorial - http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution_-_proposed Reporter: Taavi Türnpuu Priority: Minor Fix For: 4.4.3 Original Estimate: 168h Remaining Estimate: 168h management-server.log 2012-10-10 12:47:44,767 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage UPintenance mode 2012-10-10 12:47:45,826 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 routers. 2012-10-10 12:48:14,767 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage UPintenance mode 2012-10-10 12:48:15,820 DEBUG [storage.snapshot.SnapshotSchedulerImpl] (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2012-10-10 09:48:15 GMT 2012-10-10 12:48:15,822 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) Found 0 running routers. 2012-10-10 12:48:15,822 DEBUG [storage.snapshot.SnapshotSchedulerImpl] (SnapshotPollTask:null) Got 0 snapshots to be executed at 2012-10-10 09:48:15 GMT 2012-10-10 12:48:15,826 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 routers. 2012-10-10 12:48:16,045 DEBUG [cloud.network.ExternalLoadBalancerUsageManagerImpl] (ExternalNetworkMonitor-1:null) External load balancer devices stats collector is running... 2012-10-10 12:48:32,413 DEBUG [cloud.server.StatsCollector] (StatsCollector-2:null) VmStatsCollector is running... 2012-10-10 12:48:32,413 DEBUG [cloud.server.StatsCollector] (StatsCollector-3:null) HostStatsCollector is running... 2012-10-10 12:48:32,855 DEBUG [cloud.server.StatsCollector] (StatsCollector-2:null) StorageCollector is running... 2012-10-10 12:48:44,767 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage UPintenance mode 2012-10-10 12:48:45,788 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Running Capacity Checker ... 2012-10-10 12:48:45,788 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) recalculating system capacity 2012-10-10 12:48:45,788 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Executing cpu/ram capacity update 2012-10-10 12:48:45,790 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done executing cpu/ram capacity update 2012-10-10 12:48:45,790 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Executing storage capacity update 2012-10-10 12:48:45,791 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done executing storage capacity update 2012-10-10 12:48:45,791 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Executing capacity updates for public ip and Vlans 2012-10-10 12:48:45,799 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done capacity updates for public ip and Vlans 2012-10-10 12:48:45,799 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Executing capacity updates for private ip 2012-10-10 12:48:45,806 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done executing capacity updates for private ip 2012-10-10 12:48:45,806 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done recalculating system capacity 2012-10-10 12:48:45,827 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 routers. 2012-10-10 12:48:45,831 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done running Capacity Checker ... 2012-10-10 12:49:14,767 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage UPintenance mode 2012-10-10 12:49:15,826 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 routers. 2012-10-10 12:49:32,416 DEBUG [cloud.server.StatsCollector] (StatsCollector-2:null) VmStatsCollector is running... 2012-10-10 12:49:32,417 DEBUG [cloud.server.StatsCollector] (StatsCollector-1:null)
[jira] [Assigned] (CLOUDSTACK-8043) Have all CloudStack tables's primary keys auto-increment to avoid multi-master DB setup issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-8043: --- Assignee: Rohit Yadav Have all CloudStack tables's primary keys auto-increment to avoid multi-master DB setup issues -- Key: CLOUDSTACK-8043 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8043 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: Future, 4.6.0, 4.5.1 In multi-master DB setup, tables where primary keys don't auto-increment can conflict in case of concurrent insert operations. This was partially fixed in https://issues.apache.org/jira/browse/CLOUDSTACK-6212 The following tables have a primary key without the auto_increment flag, should we alter those columns to have auto_increment? cluster_vsm_map op_host op_host_tranfer op_host_upgrade op_it_work op_lock op_networks op_router_monitoring_services op_user_stats_log user_vm_clone_setting vm_work_job -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-338) Unique Names of Disk and Service Offerings in the database are prefixed with Cloud.com String
[ https://issues.apache.org/jira/browse/CLOUDSTACK-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-338. -- Resolution: Not A Problem in setup/db/postprocess-20to21.sql, it removes such offerings that have a Cloud.com- prefix Unique Names of Disk and Service Offerings in the database are prefixed with Cloud.com String --- Key: CLOUDSTACK-338 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-338 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0, 4.2.0 Reporter: Chandan Purushothama Priority: Minor Fix For: 4.4.3 Unique names of disk and service offerings in the database are prefixed with Cloud.com string. mysql select id,name,unique_name from disk_offering; ++--++ | id | name | unique_name| ++--++ | 1 | Small Instance | Cloud.Com-Small Instance | | 2 | Medium Instance | Cloud.Com-Medium Instance | | 3 | Small| Cloud.Com-Small| | 4 | Medium | Cloud.Com-Medium | | 5 | Large| Cloud.Com-Large| | 6 | Custom | Cloud.Com-Custom | | 7 | System Offering For Secondary Storage VM | Cloud.com-SecondaryStorage | | 8 | System Offering For Console Proxy| Cloud.com-ConsoleProxy | | 9 | System Offering For Software Router | Cloud.Com-SoftwareRouter | | 10 | System Offering For Elastic LB VM| Cloud.Com-ElasticLBVm | ++--++ 10 rows in set (0.00 sec) === JARs version Information: === This is the version information for the manifests in the JAR files. Implementation_Version: 2.2.20121012230921 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-6307) java.lang.Exception: Uanble to find management port group null
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav reassigned CLOUDSTACK-6307:
---
Assignee: Rohit Yadav
java.lang.Exception: Uanble to find management port group null
--
Key: CLOUDSTACK-6307
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6307
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.3.0
Environment: Apache CloudStack 4.3.0 with VMware vSphere 5.5 -
advanced network with vlan tagging, primary and secondary storage are hosted
on NFS
Reporter: ilya musayev
Assignee: Rohit Yadav
Labels: SSVM, TEMPLATE, VSPHERE
Fix For: 4.5.1
When converting a volume to template, following error is observed on ssvm
cloud.log
2014-03-29 19:08:45,903 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null)
Received response: Seq 10-6933: { Ans: , MgmtId: 345049223690, via: 10, Ver:
v1, Flags: 100010, [{com.cloud.agent.api.PingAnswer:{_
command:{hostType:Storage,hostId:10,wait:0},result:true,wait:0}}]
}
2014-03-29 19:08:46,908 INFO [vmware.util.VmwareContext]
(agentRequest-Handler-5:null) Connected, conn:
sun.net.www.protocol.https.DelegateHttpsURLConnection:https://243.221.84.11/folder/CloudStack-Shell/Clou
dStack-Shell.vmsd?dcPath=Diamond-CICdsName=b0d3033166f3361abea8b85e0efe4055,
retry: 0
2014-03-29 19:08:47,201 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: .encoding = UTF-8
2014-03-29 19:08:47,202 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: snapshot.lastUID =
1
2014-03-29 19:08:47,203 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: snapshot.current =
1
2014-03-29 19:08:47,203 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: snapshot0.uid = 1
2014-03-29 19:08:47,203 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: snapshot0.filename
= CloudStack-Shell-Snapshot1.vmsn
2014-03-29 19:08:47,204 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.displayName = 2fe485b8b-e9cd-354c-bd4d-d49a05f73252
2014-03-29 19:08:47,204 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.description = Temporary snapshot for template creation
2014-03-29 19:08:47,204 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.createTimeHigh = 325059
2014-03-29 19:08:47,205 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.createTimeLow = -1945658117
2014-03-29 19:08:47,205 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content: snapshot0.numDisks
= 1
2014-03-29 19:08:47,205 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.disk0.fileName = ROOT-37.vmdk
2014-03-29 19:08:47,206 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot0.disk0.node = scsi0:0
2014-03-29 19:08:47,206 INFO [vmware.mo.SnapshotDescriptor]
(agentRequest-Handler-5:null) Parse snapshot file content:
snapshot.numSnapshots = 1
2014-03-29 19:08:47,207 INFO [vmware.mo.VirtualMachineMO]
(agentRequest-Handler-5:null) Convert snapshot disk file name to datastore
path. ROOT-37.vmdk-[b0d3033166f3361abea8b85e0efe4055]
CloudStack-Shell/ROOT-37.vmdk
2014-03-29 19:08:50,736 INFO [vmware.mo.VirtualMachineMO]
(agentRequest-Handler-5:null) volss: copy vmdk and ovf file starts
1396120130736
2014-03-29 19:08:50,737 INFO [vmware.mo.HypervisorHostHelper]
(agentRequest-Handler-5:null) Resolving host name in url through vCenter,
url:
https://west-diamond-vhv07.corp.company-x.com/nfc/52cb24d3-d48b-9edf-cae1-a35a122e5dfb/disk-0.vmdk
2014-03-29 19:08:50,864 WARN [vmware.mo.HypervisorHostHelper]
(agentRequest-Handler-5:null) Unexpected exception
java.lang.Exception: Uanble to find management port group null
at
com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostNetworkSummary(HostMO.java:981)
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.resolveHostNameInUrl(HypervisorHostHelper.java:1286)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.exportVm(VirtualMachineMO.java:1413)
at
com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:636)
[jira] [Commented] (CLOUDSTACK-8161) [Automation]: mark the data volume related operations on LXC as skipped if RBD storage pool is not available
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513860#comment-14513860 ] Rohit Yadav commented on CLOUDSTACK-8161: - [~talluri] - ping, any update on this? Since it's marked as blocker, can you fix it (since looks like you've already done few commits on master), or mark as resolved if already fixed? [Automation]: mark the data volume related operations on LXC as skipped if RBD storage pool is not available Key: CLOUDSTACK-8161 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8161 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Environment: LXC Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Priority: Blocker Fix For: 4.5.1 mark the data volume related operations as skipped if RBD storage pool is not available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-963) [cloud.utils.AnnotationHelper] class java.lang.Stringdoes not have a Table annotation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-963: -- Assignee: Rohit Yadav [cloud.utils.AnnotationHelper] class java.lang.Stringdoes not have a Table annotation -- Key: CLOUDSTACK-963 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-963 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Environment: Running on cloudstack - master branch Reporter: Prasanna Santhanam Assignee: Rohit Yadav Priority: Minor Fix For: 4.4.3 whenever a host is added to cloudstack i see the INFO message in the logs about missing Table annotation: Related to the recent cloud-utils refactor? The message also doesn't seem to indicate any INFO, proobably a WARN/ERROR? 2013-01-11 23:42:39,985 INFO [xen.discoverer.XcpServerDiscoverer] (1589138432@qtp-1513148157-5:null) Found host acs-qa-h20 ip=10.223.78.20 product version=6.0.2 2013-01-11 23:42:39,993 INFO [cloud.utils.AnnotationHelper] (1589138432@qtp-1513148157-5:null) class java.lang.Stringdoes not have a Table annotation 2013-01-11 23:42:39,993 DEBUG [cloud.network.NetworkManagerImpl] (1589138432@qtp-1513148157-5:null) Failed to retrive the default label for storage traffic:zone: 1 hypervisor: XenServer due to:Unable to find the default physical network with traffic=Storage in the specified zone id -- 2013-01-11 23:43:05,008 DEBUG [cloud.api.ApiServlet] (1513306926@qtp-1513148157-0:null) ===START=== 0:0:0:0:0:0:0:1 -- GET allocationstate=EnabledapiKey=W7IfidZg8KCiCjO8X-jB46-BdndysOb1SvbDht3XdDBT99gWfPm6Z36Rk52j0IWrtMJZL6ItPV1AEhCoQMSVRAcommand=updateZoneid=7b21e7ea-969d-49d9-8293-5ebea8be4cearesponse=jsonsignature=d7hpLc16eXvooaq%2BQMbaVy4E9qE%3D 2013-01-11 23:43:05,049 INFO [cloud.utils.AnnotationHelper] (1513306926@qtp-1513148157-0:null) class java.lang.Stringdoes not have a Table annotation 2013-01-11 23:43:05,070 INFO [cloud.configuration.ConfigurationManagerImpl] (1513306926@qtp-1513148157-0:null) No storage traffic type was specified by admin, create default storage traffic on physical network 200 with same configure of management traffic type -- 2013-01-11 23:43:46,675 INFO [xen.discoverer.XcpServerDiscoverer] (1513306926@qtp-1513148157-0:null) Found host acs-qa-h21 ip=10.223.78.140 product version=6.0.2 2013-01-11 23:43:46,681 INFO [cloud.utils.AnnotationHelper] (1513306926@qtp-1513148157-0:null) class java.lang.Stringdoes not have a Table annotation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7881) Allow VPN IP range to be specified when creating a VPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-7881: --- Assignee: Rohit Yadav Allow VPN IP range to be specified when creating a VPN -- Key: CLOUDSTACK-7881 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7881 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Assignee: Rohit Yadav Priority: Minor Fix For: 4.6.0, 4.5.1 Attachments: f74b1a26db4514b9795ed760504351db8b03ef03.patch Currently when creating a VPN on an Isolated Network via the UI the default VPN IP range (specified in Global Settings) is used. The API permits overriding this range during VPN creation. I would suggest adding a text box to the VPN creation form in the UI to specify an IP range that overrides the defaults. While not critical, it can be useful to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6807) [HyperV] [Doc] Hyper-v requires all virtual switch names should be same across the entire cluster for live migration of VM to succeed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-6807: Priority: Major (was: Critical) [HyperV] [Doc] Hyper-v requires all virtual switch names should be same across the entire cluster for live migration of VM to succeed - Key: CLOUDSTACK-6807 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6807 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Reporter: Anshul Gangwar Assignee: Radhika Nair Labels: docs, hyper-V,, hyper-v Fix For: 4.5.1 In setup process we have to mention one more step that Hyper-v requires all virtual switch names should be same across the entire cluster for live migration of VM to succeed as mentioned @http://technet.microsoft.com/en-us/library/ff715313%28v=ws.10%29.aspx#BKMK_switchname. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7695) cache disk policy not recording into the database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-7695: --- Assignee: Rohit Yadav (was: Wido den Hollander) cache disk policy not recording into the database - Key: CLOUDSTACK-7695 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7695 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1 Environment: Centos 6.5 x86_64 hypervisor: kvm Storage type: NFS Reporter: Thierry Bernard Assignee: Rohit Yadav Fix For: 4.5.1 By generating a new instance with a new disk offerings (e.g. with writethrough cache feature) the vm's xml config file returns that the cache is none. I changed the entry in the database and it works well. I think it is a bug in the UI by creating a new disk offerings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-4890) [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-4890: --- Assignee: Rohit Yadav [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed Key: CLOUDSTACK-4890 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4890 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: MSCloudPlatform-4.2.1-732-rhel6.3.tar.gz Hosts XS 6.2 Reporter: angeline shen Assignee: Rohit Yadav Priority: Minor Fix For: 4.5.1 1. Create multiple VM snapshots for the same VM - say 3 snapshots - S1,S2,S3. 2. Destroy the Vm. 3. Restore VM. All VM snapshots are removed. It would be nice to be able to recover VM snapshots when VM is restored . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5033) ipaddress in management-server.log and api.log are wrong if management servers is behind a reverse proxy or load balancer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-5033. --- Resolution: Fixed Already fixed in 6715c6ccfa68b53a3891f49ec98b568511c9cfb9 ipaddress in management-server.log and api.log are wrong if management servers is behind a reverse proxy or load balancer - Key: CLOUDSTACK-5033 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5033 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Wei Zhou Assignee: Wei Zhou Priority: Minor Fix For: 4.4.3 If management servers is behind a reverse proxy or load balancer, the ipaddress of API calls in management-server.log and api.log are wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-3553) [UI]UI remains in the processing state forever when it failed to delete primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-3553: --- Assignee: Rohit Yadav [UI]UI remains in the processing state forever when it failed to delete primary storage --- Key: CLOUDSTACK-3553 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3553 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Rohit Yadav Priority: Minor Fix For: 4.4.3 Attachments: storageUI.png Steps: 1. Configure Adv zone with VMWARE 2. Have Primary storage added at the cluster level. 3. Deploy VM's using a new user account 4. Pu the host into maintenance . There are no other storage pools to migrate its volumes 5. Tried to delete primary storage when it has volumes 6. It failed to remove saying 'Cannot delete pool PS1 as there are associated non-destroyed vols for this pool' Observation : But UI remains in the processing state forever when it failed to delete primary storage (Attached the snap) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8405) [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513927#comment-14513927 ] ASF subversion and git services commented on CLOUDSTACK-8405: - Commit f45e6b94edf3af1feaf4613daf292e5bb8ba7758 in cloudstack's branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f45e6b9 ] CLOUDSTACK-8405: Restore VM results in deletion of data disk. Dont evict template when a delete command has been sent to VMware resource for deletion of volume. [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk. --- Key: CLOUDSTACK-8405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8405 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy a CS setup with VMware 5.5 (two clusters with a host each). 2. Deploy a VM in cluster1 ( without any data disk). 3. Migrate the VM along with storage to cluster2. 4. Create a data disk and attach it to the VM. 5. Now Restore the VM. +Result+ VM gets deleted from vCenter which results in the deletion of the data disk (data loss). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-7300. --- Resolution: Not A Problem Cannot create Snapshot on KVM - Key: CLOUDSTACK-7300 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.4.0 Environment: KVM on CentOS Reporter: Prieur Leary Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.1, 4.5.0 Cannot create volume Snapshots on KVM. 1. Creating a Snapshot says successful. 2. When viewing the actual Snapshot, it shows Error status. 3. Management Server Logs the error below. 4. It seems the Snapshot is attempting to be copied to a path that is not mounted (Sec Storage Snapshots). 5. Have restarted Agent, SSVM, and management server. Has not corrected. -- 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed to create snapshot com.cloud.utils.exception.CloudRuntimeException: Failed to backup c498663d-5986-4ee1-a864-bf99a7fab48d for disk /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 to /m$ at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.Del at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7300: Fix Version/s: (was: 4.4.3) 4.5.0 4.5.1 Cannot create Snapshot on KVM - Key: CLOUDSTACK-7300 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.4.0 Environment: KVM on CentOS Reporter: Prieur Leary Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.0, 4.5.1 Cannot create volume Snapshots on KVM. 1. Creating a Snapshot says successful. 2. When viewing the actual Snapshot, it shows Error status. 3. Management Server Logs the error below. 4. It seems the Snapshot is attempting to be copied to a path that is not mounted (Sec Storage Snapshots). 5. Have restarted Agent, SSVM, and management server. Has not corrected. -- 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed to create snapshot com.cloud.utils.exception.CloudRuntimeException: Failed to backup c498663d-5986-4ee1-a864-bf99a7fab48d for disk /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 to /m$ at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.Del at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[jira] [Closed] (CLOUDSTACK-237) StopVMCommand reported success in spite of failing to stop a VM which got stuck during installation from an ISO
[
https://issues.apache.org/jira/browse/CLOUDSTACK-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav closed CLOUDSTACK-237.
--
Resolution: Fixed
very old issue.
StopVMCommand reported success in spite of failing to stop a VM which got
stuck during installation from an ISO
---
Key: CLOUDSTACK-237
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-237
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
Fix For: 4.4.3
Tried to deploy a VM using openSUSE-12.2-DVD-x86_64 ISO. The installation got
stuck midway after 21% of Installation. I tried to stop the VM in order to
start the installation from the beginning. The StopVMCmd reported success but
the VM is still in running state.I expected an error to be thrown on event of
StopVMCmd Failure.
=
StopVMCmd Job:
=
2012-09-28 15:28:27,893 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-24:null) submit async job-119, details: AsyncJobVO {id:119,
userId: 3, accountId: 3, sessionKey: null, instanceType: VirtualMachine,
instanceId: 16, cmd: com.cloud.api.commands.StopVMCmd, cmdOriginator: null,
cmdInfo:
{id:c5a25701-d6a9-46b8-adb7-9ac8d843d507,response:json,sessionkey:QrlDUGRAUpoIcM3AnFXDnRggcK4\u003d,ctxUserId:3,_:1348871599463,ctxAccountId:3,ctxStartEventId:438,forced:false},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 7471666038533,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2012-09-28 15:28:27,896 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-14:job-119) Executing com.cloud.api.commands.StopVMCmd for
job-119
2012-09-28 15:28:27,908 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-14:job-119) Access to VM[User|OpenSUSE-VM-1] granted to
Acct[3-atoms] by DomainChecker
2012-09-28 15:28:27,914 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-14:job-119) VM state transitted from :Running to Stopping with
event: StopRequestedvm's original host id: 1 new host id: 1 host id before
state transition: 1
2012-09-28 15:28:27,916 WARN [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-14:job-119) Unable to stop vm VM[User|OpenSUSE-VM-1]
2012-09-28 15:28:27,921 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-14:job-119) VM state transitted from :Stopping to Running with
event: OperationFailedvm's original host id: 1 new host id: 1 host id before
state transition: 1
2012-09-28 15:28:27,933 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-14:job-119) Complete async job-119, jobStatus: 1, resultCode:
0, result: com.cloud.api.response.UserVmResponse@7e8c4906
2012-09-28 15:28:27,941 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-14:job-119) Done executing com.cloud.api.commands.StopVMCmd for
job-119
2012-09-28 15:28:33,211 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-25:null) Async job-119 completed
==
Git Info:
==
Git Revision: 30b19887fd05c7694f8fdf45be9fe9b02d90b1d1
Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-77) console proxy display issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-77. - Resolution: Won't Fix very old issue console proxy display issues Key: CLOUDSTACK-77 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-77 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: pre-4.0.0 Environment: KMV, FC14, CS 2.2.14 Reporter: Jasper Wonnink Fix For: 4.4.3 As an addition to ticket: http://bugs.cloudstack.org/browse/CS-5273 I encountered the same problem as mentioned above. White squares, screen not updating. The fix for me was to turn off GSO and TSO via ethtool on the console proxy. After turning it off it did not have the issue anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-1885) Broken testcases in 4.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-1885. --- Resolution: Won't Fix very old issue Broken testcases in 4.1 --- Key: CLOUDSTACK-1885 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1885 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.1.0, 4.2.0 Reporter: Hugo Trippaers Assignee: Srikanteswararao Talluri Fix For: 4.4.3 The following testcases are marked as excluded in server/pom.xml for 4.1 exclude%regex[.*[0-9]*To[0-9]*.*Test.*]/exclude excludecom/cloud/upgrade/AdvanceZone223To224UpgradeTest/exclude excludecom/cloud/upgrade/AdvanceZone217To224UpgradeTest/exclude excludecom/cloud/async/*/exclude excludecom/cloud/cluster/*/exclude excludecom/cloud/snapshot/*/exclude excludecom/cloud/storage/dao/*/exclude excludecom/cloud/vm/dao/*/exclude excludecom/cloud/vpc/*/exclude excludecom/cloud/api/ListPerfTest.java/exclude excludecom/cloud/network/vpn/RemoteAccessVpnTest.java/exclude excludecom/cloud/network/security/SecurityGroupManagerImpl2Test.java/exclude These tests should be reviewed and either deleted or fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-1527) Non-fatal POSTIN scriptlet failure in rpm package cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-1527. --- Resolution: Won't Fix very old issue Non-fatal POSTIN scriptlet failure in rpm package cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64 - Key: CLOUDSTACK-1527 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1527 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 Reporter: venkata swamybabu budumuru Fix For: 4.4.3 Steps to reproduce : (1) copy the latest MASTER build and try to install wget http:///releases/ASF/rhel/6.3/master/CloudStack-non-OSS-MASTER-101-rhel6.3.tar.gz Observations: Here is the snippet of the installation messages ./install.sh (option M) Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : cloudstack-common-4.2.0-SNAPSHOT.el6.x86_64 1/2 Installing : cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64 2/2 Non-fatal POSTIN scriptlet failure in rpm package cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64 Please download vhd-util from http://download.cloud.com.s3.amazonaws.com/tools/vhd-util and put it in /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/ warning: %post(cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64) scriptlet failed, exit status 1 Verifying : cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64 1/2 Verifying : cloudstack-common-4.2.0-SNAPSHOT.el6.x86_64 2/2 Installed: cloudstack-management.x86_64 0:4.2.0-SNAPSHOT.el6 Dependency Installed: cloudstack-common.x86_64 0:4.2.0-SNAPSHOT.el6 Complete! Done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-3186) Duplicate entries in /etc/hosts file on VR after reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-3186. --- Resolution: Not A Problem Duplicate entries in /etc/hosts file on VR after reboot --- Key: CLOUDSTACK-3186 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3186 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: Latest build from master6-17-statble branch Reporter: Sanjeev N Assignee: Sheng Yang Fix For: 4.4.3 /etc/hosts file on VR contains the IP address to Host Name mappings. In 4.2 we have introduced a new entry called data-server and mapped to Router VMs eth0 interface ip address. This is for the guest vms to access user-data and ssh-keys from the Router VM. Please refer to bug https://issues.apache.org/jira/browse/CLOUDSTACK-2644 for more info. Making this entry in the hosts file is part of cloud-early-config file and every time a router is rebooted new entry would be made to the hosts file. If the router reboots multiple times for some reason, we see lot of duplicate entries in the hosts file. Following is the contents from /etc/hosts file from VR which was rebooted for multiple times: 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 10.147.43.6 data-server 10.147.43.6 r-4-VM 10.147.43.6 data-server 10.147.43.6 r-4-VM 10.147.43.6 data-server 10.147.43.6 r-4-VM 10.147.43.5 s1 10.147.43.7 s1-passwd 10.147.43.10 addaf9b0-bdbc-4c4a-80ed-67664ad781e0 10.147.43.8 3b2804dd-225d-4cf3-bcdc-fed468c61192 10.147.43.130 s2 10.147.43.132 0e0df8e6-2c0f-455b-8571-b5f6a0dbd44e 10.147.43.133 s2-passwd 10.147.43.134 bf2e0e55-a2c9-4d26-a489-b8d8aa596350 It would be good to check for the entries present in the file before appending to it and avoid duplicate entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8262) Missing usage event on FollowAgentPowerOffReport (Instance shutdown from OS)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-8262. --- Resolution: Fixed Fixed on 4.4/4.5/master Missing usage event on FollowAgentPowerOffReport (Instance shutdown from OS) Key: CLOUDSTACK-8262 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8262 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Usage Affects Versions: 4.4.2 Environment: KVM Reporter: Loic Lambiel Fix For: 4.4.3 When shutting down an instance from the OS, no VM.STOP usage record is being inserted. From usage perspective, instance is still considered as running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8405) [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk.
Likitha Shetty created CLOUDSTACK-8405: -- Summary: [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk. Key: CLOUDSTACK-8405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8405 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy a CS setup with VMware 5.5 (two clusters with a host each). 2. Deploy a VM in cluster1 ( without any data disk). 3. Migrate the VM along with storage to cluster2. 4. Create a data disk and attach it to the VM. 5. Now Restore the VM. +Result+ VM gets deleted from vCenter which results in the deletion of the data disk (data loss). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7734) CLONE - addHost fails for XenServer with vSwitch networking
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav updated CLOUDSTACK-7734:
Priority: Major (was: Critical)
CLONE - addHost fails for XenServer with vSwitch networking
---
Key: CLOUDSTACK-7734
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7734
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Doc
Affects Versions: Future, 4.4.0
Environment: MS: ACS Master
(http://jenkins.buildacloud.org/job/package-rhel63-master/2647)
XenServer 6.2
Reporter: Anthony Xu
Assignee: Radhika Nair
Fix For: 4.5.1
Attempt to add a XenServer host (with the default vSwitch networking) to a
Basic Networking Zone fails. Adding a XenServer host configured to use
bridge works ok.
From MS log (attached):
{noformat}
2014-04-24 13:41:07,361 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-1:ctx-3e360a0c) Failed to configure brige firewall
2014-04-24 13:41:07,361 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-1:ctx-3e360a0c) Check host 10.81.40.102 for CSP is installed or
not and check network mode for bridge
2014-04-24 13:41:07,361 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-1:ctx-3e360a0c) Seq 1-7133701809754865665: Response Received:
2014-04-24 13:41:07,363 DEBUG [c.c.a.t.Request] (DirectAgent-1:ctx-3e360a0c)
Seq 1-7133701809754865665: Processing: { Ans: , MgmtId: 275410316893143,
via: 1, Ver: v1, Flags: 110, [{com.cloud.agent.api.Set
upAnswer:{_reconnect:true,result:false,details:Failed to configure
brige firewall,wait:0}}] }
2014-04-24 13:41:07,363 DEBUG [c.c.a.t.Request] (catalina-exec-2:ctx-407da4e1
ctx-e02434c0 ctx-a13beb18) Seq 1-7133701809754865665: Received: { Ans: ,
MgmtId: 275410316893143, via: 1, Ver: v1, Flags: 110,
{ SetupAnswer } }
2014-04-24 13:41:07,363 WARN [c.c.h.x.d.XcpServerDiscoverer]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Unable to setup
agent 1 due to Failed to configure brige firewall
2014-04-24 13:41:07,364 INFO [c.c.u.e.CSExceptionErrorCode]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Could not find
exception: com.cloud.exception.ConnectionException in error code list for
exceptions
2014-04-24 13:41:07,364 WARN [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Monitor
XcpServerDiscoverer says there is an error in the connect process for 1 due
to Reini
tialize agent after setup.
2014-04-24 13:41:07,364 INFO [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Host 1 is
disconnecting with event AgentDisconnected
2014-04-24 13:41:07,364 DEBUG [c.c.a.m.AgentAttache]
(DirectAgent-1:ctx-3e360a0c) Seq 1-7133701809754865665: No more commands found
2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) The next status of
agent 1is Alert, current status is Connecting
2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Deregistering link
for 1 with state Alert
2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Remove Agent : 1
{noformat}
...snip...
{noformat}
2014-04-24 13:41:07,460 DEBUG [c.c.a.m.AgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Sending Disconnect
to listener: com.cloud.network.router.VirtualNetworkApplianceManagerImpl
2014-04-24 13:41:07,460 DEBUG [c.c.h.Status] (catalina-exec-2:ctx-407da4e1
ctx-e02434c0 ctx-a13beb18) Transition:[Resource state = Enabled, Agent event
= AgentDisconnected, Host id = 1, name = xrtuk-09-03]
2014-04-24 13:41:07,766 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Notifying other
nodes of to disconnect
2014-04-24 13:41:07,770 WARN [c.c.r.ResourceManagerImpl]
(catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Unable to connect
due to
com.cloud.exception.ConnectionException: Reinitialize agent after setup.
at
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer.processConnect(XcpServerDiscoverer.java:657)
at
com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:514)
at
com.cloud.agent.manager.AgentManagerImpl.handleDirectConnectAgent(AgentManagerImpl.java:1428)
at
com.cloud.resource.ResourceManagerImpl.createHostAndAgent(ResourceManagerImpl.java:1767)
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:773)
at
[jira] [Closed] (CLOUDSTACK-5243) SSVM responds with timestamp
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-5243. --- Resolution: Fixed Assignee: Rohit Yadav Fixed in 4.5/master SSVM responds with timestamp Key: CLOUDSTACK-5243 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5243 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: John Kinsella Assignee: Rohit Yadav Labels: security Fix For: 4.4.3 Scanners report SSVM responded with a TCP timestamp and that “the TCP timestamp response can be used to approximate the remote host's uptime, potentially aiding in further attacks. Additionally, some operating systems can be fingerprinted based on the behavior of their TCP timestamps.” The fix is straightforward: Set the value of net.ipv4.tcp_timestamps to 0 by running the following command: sysctl -w net.ipv4.tcp_timestamps=0 Additionally, put the following value in the default sysctl configuration file, generally sysctl.conf: net.ipv4.tcp_timestamps=0 Identified by: Demetrius Tsitrelis from Citrix -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-1007) Not able to delete Shared network because of not being able to stop the router.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav closed CLOUDSTACK-1007.
---
Resolution: Not A Problem
Not able to delete Shared network because of not being able to stop the
router.
---
Key: CLOUDSTACK-1007
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1007
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: Build from network-refactor
Reporter: Sangeetha Hariharan
Assignee: Sangeetha Hariharan
Fix For: 4.4.3
Attachments: agent.log, agent.log.2013-01-17.gz, management-server.zip
Steps to reproduce the problem:
Set up - Advanced zone with KVM host.
Create a Zone wide Shared network.
Deploy Vm using this network.
Destroy this Vm.
Wait for the Vm to get Expunged.
Delete the network.
Network deletion fails because we are not able to destroy the router.
Management server logs:
2013-01-17 18:05:31,818 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-6:job-34) Sending destroy to
com.cloud.network.element.VirtualRouterElement$$EnhancerByCGLIB$$d659f5e7@447d4275
2013-01-17 18:05:31,820 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-6:job-34)
Attempting to destroy router 10
2013-01-17 18:05:31,840 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-6:job-34) VM state transitted from :Running to Stopping with
event: StopRequestedvm's original host id: 1 new host id: 1 host id before
state transition: 1
2013-01-17 18:05:31,850 DEBUG [agent.transport.Request]
(Job-Executor-6:job-34) Seq 1-772669469: Sending { Cmd , MgmtId:
206915885081428, via: 1, Ver: v1, Flags: 100111,
[{StopCommand:{isProxy:false,vmName:r-10-VM,wait:0}}] }
2013-01-17 18:05:33,284 DEBUG [cloud.server.StatsCollector]
(StatsCollector-2:null) HostStatsCollector is running...
2013-01-17 18:05:33,883 DEBUG [agent.transport.Request]
(StatsCollector-2:null) Seq 1-772669470: Received: { Ans: , MgmtId:
206915885081428, via: 1, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
2013-01-17 18:05:36,715 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
===START=== 10.217.252.59 -- GET
command=queryAsyncJobResultjobId=82e583fa-7829-4396-a2f7-4358e2abba80response=jsonsessionkey=hd3IkmVY5KODN5MiyOXg%2FapVTb4%3D_=1358464170203
2013-01-17 18:05:36,746 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
===END=== 10.217.252.59 -- GET
command=queryAsyncJobResultjobId=82e583fa-7829-4396-a2f7-4358e2abba80response=jsonsessionkey=hd3IkmVY5KODN5MiyOXg%2FapVTb4%3D_=1358464170203
2013-01-17 18:05:38,232 DEBUG [agent.transport.Request]
(AgentManager-Handler-15:null) Seq 1-772669469: Processing: { Ans: , MgmtId:
206915885081428, via: 1, Ver: v1, Flags: 110,
[{Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.getStorageAdaptor(KVMStoragePoolManager.java:41)\n\tat
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.getStoragePool(KVMStoragePoolManager.java:66)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.cleanupDisk(LibvirtComputingResource.java:3153)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2687)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:968)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
java.lang.Thread.run(Thread.java:679)\n,wait:0}}] }
2013-01-17 18:05:38,232 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-15:null) Seq 1-772669469: No more commands found
2013-01-17 18:05:38,232 DEBUG [agent.transport.Request]
(Job-Executor-6:job-34) Seq 1-772669469: Received: { Ans: , MgmtId:
206915885081428, via: 1, Ver: v1, Flags: 110, { Answer } }
2013-01-17 18:05:38,232 WARN [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-6:job-34) Unable to stop vm VM[DomainRouter|r-10-VM]
2013-01-17 18:05:38,299 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-6:job-34) VM state transitted from :Stopping to Running with
event: OperationFailedvm's original host id: 1 new host id: 1 host id before
state transition: 1
2013-01-17 18:05:38,300 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-6:job-34) Unable to stop the
[jira] [Closed] (CLOUDSTACK-2790) AWSAPI: packaging includes all .class files bloating size of the RPM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-2790. --- Resolution: Not A Problem AWSAPI: packaging includes all .class files bloating size of the RPM Key: CLOUDSTACK-2790 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2790 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Packaging Affects Versions: 4.2.0 Reporter: Prachi Damle Assignee: Rayees Namathponnan Fix For: 4.4.3 The AWSAPI package cloudstack-awsapi seems to be including all the .class files as part of the RPM instead of putting them into a jar/aar archive. This bloats the size of the package to ~60M. It can be much smaller if archived -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-2714) Setting tab should not be visible for user accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-2714: --- Assignee: Rohit Yadav Setting tab should not be visible for user accounts Key: CLOUDSTACK-2714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: prashant kumar mishra Assignee: Rohit Yadav Priority: Minor Fix For: 4.4.0 Attachments: screenshot-1.jpg please check screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7881) Allow VPN IP range to be specified when creating a VPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513913#comment-14513913 ] Rohit Yadav commented on CLOUDSTACK-7881: - [~tqlogan] - can you send the patch as a Github PR for review? Allow VPN IP range to be specified when creating a VPN -- Key: CLOUDSTACK-7881 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7881 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Assignee: Rohit Yadav Priority: Minor Fix For: 4.6.0, 4.5.1 Attachments: f74b1a26db4514b9795ed760504351db8b03ef03.patch Currently when creating a VPN on an Isolated Network via the UI the default VPN IP range (specified in Global Settings) is used. The API permits overriding this range during VPN creation. I would suggest adding a text box to the VPN creation form in the UI to specify an IP range that overrides the defaults. While not critical, it can be useful to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-1633) Why do ACS security groups only support TCP, UDP, ICMP?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513915#comment-14513915 ] Rohit Yadav commented on CLOUDSTACK-1633: - [~jlkinsel] ping? Why do ACS security groups only support TCP, UDP, ICMP? --- Key: CLOUDSTACK-1633 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1633 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: John Kinsella Assignee: John Kinsella Fix For: 4.4.3 If I attempt to make an API call to authorizeSecurityGroupIngress specifying a protocol of 41, I get an error of Invalid protocol 41. Real-world use for this - Windows AD servers attempt to establish an ISATAP[1] connection between servers. Without opening the firewall, packets will be dropped as shown in the log below: Mar 11 19:07:27 c10 kernel: DROP:i-2-1711-VM-eg:IN=cloudbr0 OUT=cloudbr0 PHYSIN=vnet2 PHYSOUT=bond1 MAC=00:04:e9:ff:f3:90:06:c5:36:00:00:1a:0f:00 SRC=192.168.1.10 DST=192.168.1.20 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=2898 PROTO=41 1:http://en.wikipedia.org/wiki/ISATAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8209) VM migration fails across KVM hosts if hosts have same hostname even if different libvirt uuid or IPs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav reassigned CLOUDSTACK-8209:
---
Assignee: Rohit Yadav
VM migration fails across KVM hosts if hosts have same hostname even if
different libvirt uuid or IPs
-
Key: CLOUDSTACK-8209
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8209
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Minor
Fix For: 4.6.0, 4.5.1
In case KVM hosts have same hostname but different libvirtd host uuid or IPs,
VM migration fails with:
2015-02-04 15:22:18,042 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-13:ctx-ae4c1ba1 job-37/job-38) Unable to complete
AsyncJobVO {id:38, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwACcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 5071960016, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Feb 04 15:22:15 IST 2015}, job origin:37
com.cloud.utils.exception.CloudRuntimeException:
org.libvirt.LibvirtException: internal error: Attempt to migrate guest to the
same host kvm-test
---at
com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1956)
---at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1854)
---at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4501)
---at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
---at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
---at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
---at java.lang.reflect.Method.invoke(Method.java:606)
---at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
---at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4633)
---at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
---at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
---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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493)
---at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
---at java.util.concurrent.FutureTask.run(FutureTask.java:262)
---at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
---at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
---at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513921#comment-14513921 ] Rohit Yadav commented on CLOUDSTACK-7472: - [~kishan] ping? Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true --- Key: CLOUDSTACK-7472 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.1 We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7049) APIs return sensitive information which CloudStack does not manage and which caller did not request
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-7049: --- Assignee: Rohit Yadav APIs return sensitive information which CloudStack does not manage and which caller did not request --- Key: CLOUDSTACK-7049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7049 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Demetrius Tsitrelis Assignee: Rohit Yadav Priority: Critical Labels: security Fix For: 4.5.1 CloudStack stores sensitive information such as passwords and keys. Some of this information it creates such as the users’ secret keys. Admins configure CloudStack with the other types of sensitive information such as host passwords, S3 secret keys, etc. There are two problems with the way the API returns sensitive information: 1) Many of the APIs return the entire state of the modified object on which they operate. For example, if the API to remove a NIC from a VM is called then the response returns the VM password even though the caller did not ask for it. 2) Some of the APIs return sensitive information which is not created nor managed by CloudStack. For instance, the listS3s API returns the S3 secret key. There doesn’t seem to be any legitimate use case for returning this category of information; this type of sensitive data could go into CloudStack for its internal use but should not come out via the API (i.e., CloudStack is not a password manager app!). Substantial changes cannot be made to the API without bumping the API version. A near-term mitigation for these problems then is simply to return empty strings in the response for the sensitive information which is not requested or which is not managed by CloudStack. So for the removeNicFromVirtualMachine API, for instance, return an empty string for the password value. A caller could still use getVMPassword to obtain the password if he needed it since it is CloudStack which generated the VM password. For the S3 case, ALWAYS return an empty value for the S3 secret key since that key is managed by Amazon and not CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8158) After the host reboots, the system will run out vm management IP, no matter how much.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-8158: --- Assignee: Rohit Yadav After the host reboots, the system will run out vm management IP, no matter how much. - Key: CLOUDSTACK-8158 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8158 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.4.0, 4.4.1, 4.4.2 Environment: All nodes in the system OS: Centos 6.5 x64 are Cloudstack Version: 4.4.1 / 4.4.2 / 4.4.0 All nodes are installed on a single host, use the basic network, installation documentation is installed in accordance with the documentation provided by the official. Reporter: liliang Assignee: Rohit Yadav Labels: patch Fix For: 4.5.1 Original Estimate: 12h Remaining Estimate: 12h cloudstack all nodes installed on a host, all nodes in the system OS are centos6.5 x64. After using basic network build regional success, reboot the host, the system will manage IP vm exhausted. Every restart a host system vm will occupy the new management IP address, the old IP address can not be released. According to the analysis system BUG logs, restart once every host system vm will automatically rebuild destroyed repeatedly, until the system vm system up or manage IP exhausted, the system can start vm, the premise is under the management of IP abundant, management IP consumption when you do not start the system vm, database tables need to manually release the management IP. And under normal circumstances, reboot the system into the production environment is not su, senior network has not been detected this problem, cloudstack 所有节点安装在一台资源充沛的宿主机，所有节点系统OS均为 centos6.5 x64。安装成功后，使用基本网络搭建区域成功后，重启宿主机后，系统vm会把管理IP耗尽。每重启一次宿主机，系统vm都会占用新的管理IP地址，旧的IP地址无法释放。根据系统BUG日志的分析，每重启一次宿主机，系统vm会自动反复重建销毁，直到系统vm系统起来或管理IP耗尽，系统vm可以正常启动，前提是管理IP充裕的情况下，管理IP耗尽时则无法启动系统vm ，需要到数据库表中手动释放管理IP。都未运行任何实例。而在正常的情况下，重启系统宿主机，系统vm不会自动销毁重建，或占用大量IP。而在4.3.1或4.3.0以下，包括（4.3.0/4.3.1）不会出现上述问题，安装方式是按照官方提供的文档进行的安装，安装文档是：http://cloudstack-installation.readthedocs.org/en/latest/qig.html 未投入生产环境中，高级网络中尚未检测到这种问题。 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5282) KVM - Advanced zone Isolated networks - Egress rules are not functional because of router having mutiple nics for the public ip address.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14515015#comment-14515015 ] Aleksandr commented on CLOUDSTACK-5282: --- Hi Issue still here... Cloudstack ver 4.4.2, VR ver 4.4.1, clean install, advanced zone/GRE ( OVS ), nic configuration from manul - 3 fake bridges + 1 main ( mgmt0, cloudbr0, cloudbr1) - all on 1 nic. New instance with default network offering : default isolated with source nat. Just after VR goes up a host logs in and adds another public interface with the same ip and same mac as 1st public interface ( eth2 ) : root@r-28-VM:~# cat /etc/network/interfaces auto lo eth0 eth1 eth2 iface lo inet loopback iface eth0 inet static address 172.17.150.1 netmask 255.255.255.0 iface eth1 inet static address 169.254.1.48 netmask 255.255.0.0 iface eth2 inet static public iface address 185.22.**.** netmask 255.255.255.0 root@r-28-VM:~# cat /var/log/auth.log | grep eth3 Apr 25 20:00:50 r-28-VM sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/sbin/ip link show eth3 Apr 25 20:00:50 r-28-VM sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/sbin/ip addr add dev eth3 185.22.**.**/24 brd + This leads to non-working routing/NAT for instances KVM - Advanced zone Isolated networks - Egress rules are not functional because of router having mutiple nics for the public ip address. - Key: CLOUDSTACK-5282 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5282 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: Build from 4.3 using 64 bit system templates. Reporter: Sangeetha Hariharan Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Attachments: management-server.rar KVM - Advanced zone Isolated networks - Egress rules are not functional. Steps to reproduce the problem: Advanced zone with 2 KVM hosts (rhel6.3), Isolated network with 20 vms. Create a egress rule to allow all traffic to all cidrs. From Vm , try to ping google.com We are not able to ping/ssh outside from the VM. Egress rules are programmed in the router. But I see that the router has as many NICs as the number of Vms that it services asssigned to the same public Ip address but with 2 different MAC address. root@r-10-MyTestVM:~# ip route default via 10.223.138.129 dev eth2 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.1 10.223.138.128/26 dev eth2 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth3 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth4 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth5 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth6 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth7 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth8 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth9 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth10 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth11 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth12 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth13 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth14 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth15 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth16 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth17 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth18 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth19 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth20 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth21 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth22 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth23 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth24 proto kernel scope link src 10.223.138.137 169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.3.13 root@r-10-MyTestVM:~# ifconfig eth0 Link encap:Ethernet HWaddr 02:00:51:27:00:02 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::51ff:fe27:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:757 errors:0 dropped:0 overruns:0 frame:0 TX packets:324
[jira] [Updated] (CLOUDSTACK-8407) Presharedkey is not created during the creation of remote access vpn
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Grangier updated CLOUDSTACK-8407: - Summary: Presharedkey is not created during the creation of remote access vpn (was: Presharedkey is not create during the creation of remote access vpn) Presharedkey is not created during the creation of remote access vpn Key: CLOUDSTACK-8407 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8407 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Management Server Affects Versions: 4.5.1 Reporter: Nicolas Grangier Priority: Minor The presharedkey not appear/create during remote access vpn creation Confirmed with cloudmonkey that the value is not present, === Steps to Reproduce: === 1.Go the network tab 2.Configure the VPC 3.Go in the router section, public IP adresses 4.Click on the IP who is SourceNat, 5.Activate the remote access VPN, 6.It say : Your Remote Access VPN is currently enabled and can be accessed via the IP x.x.x.x. Your IPSec pre-shared key is undefined Actual result : Remote Access VPN is created in the database, but it didn't create the presharedkey, i also use cloudmonkey to list remoteaccessvpns, the field presharedkey = is even not created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8407) Presharedkey is not create during the creation of remote access vpn
Nicolas Grangier created CLOUDSTACK-8407: Summary: Presharedkey is not create during the creation of remote access vpn Key: CLOUDSTACK-8407 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8407 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Management Server Affects Versions: 4.5.1 Reporter: Nicolas Grangier Priority: Minor The presharedkey not appear/create during remote access vpn creation Confirmed with cloudmonkey that the value is not present, === Steps to Reproduce: === 1. Go the network tab 2. Configure the VPC 3. Go in the router section, public IP adresses 4. Click on the IP who is SourceNat, 5. Activate the remote access VPN, 6. It say : Your Remote Access VPN is currently enabled and can be accessed via the IP x.x.x.x. Your IPSec pre-shared key is undefined Actual result : Remote Access VPN is created in the database, but it didn't create the presharedkey, i also use cloudmonkey to list remoteaccessvpns, the field presharedkey = is even not created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8407) Presharedkey is not create during the creation of remote access vpn
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Grangier updated CLOUDSTACK-8407: - Summary: Presharedkey is not create during the creation of remote access vpn (was: Presharedkey is not created during the creation of remote access vpn) Presharedkey is not create during the creation of remote access vpn --- Key: CLOUDSTACK-8407 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8407 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Management Server Affects Versions: 4.5.1 Reporter: Nicolas Grangier Priority: Minor The presharedkey not appear/create during remote access vpn creation Confirmed with cloudmonkey that the value is not present, === Steps to Reproduce: === 1.Go the network tab 2.Configure the VPC 3.Go in the router section, public IP adresses 4.Click on the IP who is SourceNat, 5.Activate the remote access VPN, 6.It say : Your Remote Access VPN is currently enabled and can be accessed via the IP x.x.x.x. Your IPSec pre-shared key is undefined Actual result : Remote Access VPN is created in the database, but it didn't create the presharedkey, i also use cloudmonkey to list remoteaccessvpns, the field presharedkey = is even not created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8404) cloudstack-management not able to start the App
Keerthiraja created CLOUDSTACK-8404: --- Summary: cloudstack-management not able to start the App Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8403) Modify tags accordingly for test cases which can't be run on simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-8403. Resolution: Fixed Modify tags accordingly for test cases which can't be run on simulator -- Key: CLOUDSTACK-8403 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8403 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: Future Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: Future Set required_hardware=true for tests which should not be run on the simulator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8404) cloudstack-management not able to start the App
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14513752#comment-14513752 ] Keerthiraja commented on CLOUDSTACK-8404: - Issue been resolved its because of the Java issue on CentOS 6.6 the OS package pulled the latest java-1.8.0-openjdk-headless-1.8.0.40-25.b25.fc21.x86_64 so I removed the java-1.8 and installed the java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el6_6.x86_64. During the yum install cloudstack-manamgement it pulls the dependencies packages as latest java. cloudstack-management not able to start the App --- Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8404) cloudstack-management not able to start the App
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keerthiraja resolved CLOUDSTACK-8404. - Resolution: Fixed Issue been resolved its because of the Java issue on CentOS 6.6 the OS package pulled the latest java-1.8.0-openjdk-headless-1.8.0.40-25.b25.fc21.x86_64 so I removed the java-1.8 and installed the java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el6_6.x86_64. During the yum install cloudstack-manamgement it pulls the dependencies packages as latest java. cloudstack-management not able to start the App --- Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-8404) cloudstack-management not able to start the App
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keerthiraja updated CLOUDSTACK-8404: Comment: was deleted (was: Issue been resolved its because of the Java issue on CentOS 6.6 the OS package pulled the latest java-1.8.0-openjdk-headless-1.8.0.40-25.b25.fc21.x86_64 so I removed the java-1.8 and installed the java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el6_6.x86_64. During the yum install cloudstack-manamgement it pulls the dependencies packages as latest java. ) cloudstack-management not able to start the App --- Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8405) [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty updated CLOUDSTACK-8405: --- Fix Version/s: (was: Future) 4.6.0 [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk. --- Key: CLOUDSTACK-8405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8405 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: 4.6.0 +Steps to reproduce+ 1. Deploy a CS setup with VMware 5.5 (two clusters with a host each). 2. Deploy a VM in cluster1 ( without any data disk). 3. Migrate the VM along with storage to cluster2. 4. Create a data disk and attach it to the VM. 5. Now Restore the VM. +Result+ VM gets deleted from vCenter which results in the deletion of the data disk (data loss). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8405) [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-8405. Resolution: Fixed +Issue+ In case of vSphere 5.5, if VM restore is performed on a VM that has previously been migrated, all data volumes associated with the VM will be deleted. +Root Cause Analysis+ During VM restore, CS does the following sequentially- 1. Stop VM (if running). 2. Delete VM's Root volume. 3. Create new Root volume from base template. 4. Configure VM to use the new Root volume. 5. Start VM. During step 2 of VM restore, CS does a cleanup of the existing ROOT volume and this cleanup triggers a detach of the Root volume from the VM. And once the Root volume is detached, CS changes ROOT volume's type from 'ROOT' to 'DATADISK'. This change in volume type was introduced as part of CS's new capability to allow users to attach and detach Root disks of a VM. In case of VMware, while deleting a volume if the volume is not of type 'ROOT' and if there is a VM by the name of the volume's path, then CS assumes that the VM is a template and that a request is being made to destroy that template. And when that VM which CS assumes to be a template is destroyed, every volume attached to that VM is destroyed. Why is this issue seen only in vSphere 5.5? - Starting 5.5, all volumes associated with a VM are named after the VM. For e.g. 'i-2-4-VM_1.vmdk'. And since CS destroys a VM only if it finds a VM by the volume's name, it only happens in case of 5.5. Previously, volume names used to be UUIDs. Why is the issue seen only in VMs that have been migrated at least once? - When a VM is first created via CS, CS names the volumes associated with the VM. But once a VM is migrated, vSphere renames every volume associated with the VM as per its conventions. And as mentioned above, in case of 5.5, the volumes are renamed to start with the VM's name. +Workaround+ Detach all data disks before performing a VM restore. [vCenter 5.5] Restore VM on a migrated VM results in the deletion of the data disk. --- Key: CLOUDSTACK-8405 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8405 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy a CS setup with VMware 5.5 (two clusters with a host each). 2. Deploy a VM in cluster1 ( without any data disk). 3. Migrate the VM along with storage to cluster2. 4. Create a data disk and attach it to the VM. 5. Now Restore the VM. +Result+ VM gets deleted from vCenter which results in the deletion of the data disk (data loss). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8406) Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-8406: -- Affects Version/s: 4.5.1 Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service -- Key: CLOUDSTACK-8406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8406 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.1 Reporter: Sanjeev N Don't allow creating network offering with userdata service and VR as the provider without DHCP service. If we create shared network offering without DHCP service and with VR as the userdata service provider then user vm will not be able to access the userdata from VR since it gets the IP address from the external dhcp server. VM and VR might be in a different network so VM would not be able to access VR to fetch the userdata from VR. So it would be better not to allow this combination while creating network offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8406) Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service
Sanjeev N created CLOUDSTACK-8406: - Summary: Don't allow creating shared network offering with userdata service and VR as the provider without DHCP service Key: CLOUDSTACK-8406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8406 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Sanjeev N Don't allow creating network offering with userdata service and VR as the provider without DHCP service. If we create shared network offering without DHCP service and with VR as the userdata service provider then user vm will not be able to access the userdata from VR since it gets the IP address from the external dhcp server. VM and VR might be in a different network so VM would not be able to access VR to fetch the userdata from VR. So it would be better not to allow this combination while creating network offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-8404) cloudstack-management not able to start the App
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reopened CLOUDSTACK-8404: - Assignee: Rohit Yadav Reopening to discuss and see if we can detect JDK/JRE 1.8 and try a fix or only installed jre/jdk 1.7.x cloudstack-management not able to start the App --- Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja Assignee: Rohit Yadav I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-1145) It would be great if the Computing power Allocation Algorithm used in version 4.0 of CloudStack is explained in a document.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-1145. --- Resolution: Not A Problem It would be great if the Computing power Allocation Algorithm used in version 4.0 of CloudStack is explained in a document. --- Key: CLOUDSTACK-1145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1145 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.0.0 Reporter: Kausal Malladi Labels: doc Fix For: 4.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8404) cloudstack-management not able to start the App
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514077#comment-14514077 ] Keerthiraja commented on CLOUDSTACK-8404: - thank you for considering this issue cloudstack-management not able to start the App --- Key: CLOUDSTACK-8404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.5.1 Reporter: Keerthiraja Assignee: Rohit Yadav I installed the ACS in my VirtualBox. After I install the CS with 4GB base memory I could not able to start the server. I scale the memory upto 12GB still I could not able to start the ACS. In /var/log/cloudstack/management/catalina.out I could see error as Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Can't start up: not enough memory Is I missing anything. In the default file of below I could see the java value as default. tomcat6.conf - /etc/cloudstack/management/tomcat6-nonssl.conf JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers I even tried by increasing the -Xmx2g into 4g still I don't see any improvement. After the long investigation I found the issue. If i start the app using /etc/init.d/cloudstack-management start I could see error as catalina.out as Can't start up: not enough memory if I do the same using /etc/init.d/tomcat.sh start I able to start the app. But @ the same time when I check the browser I don't see the cloudstack UI. If I cross check the /usr/share/tomcat6/webapps location I don't see any files inside. Tested the App from the repo http://packages.bhaisaab.org/cloudstack/testing/centos/4.5/ cloudstack-awsapi-4.5.1-shapeblue3.el6.x86_64 cloudstack-management-4.5.1-shapeblue3.el6.x86_64 cloudstack-common-4.5.1-shapeblue3.el6.x86_64 Thanks, Keerthi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6165) Cannot upload data
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-6165. --- Resolution: Incomplete Cannot upload data -- Key: CLOUDSTACK-6165 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6165 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.0.2 Environment: Centos6 Reporter: Ranjith Fix For: 4.0.2 cannot find an image store for zone 1 while uploading document to the specified storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5031) Wrong install steps for installing the Usage server in the documentation of ACS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-5031. --- Resolution: Not A Problem Wrong install steps for installing the Usage server in the documentation of ACS. Key: CLOUDSTACK-5031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5031 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Kiran Koneti Priority: Critical Fix For: 4.2.0 In the steps for installation of the usage server in the documentation under thes etion 9.1 we dosent see the correct steps for installing the usage server. The steps mentioned in the doc are as below: 9.1.2. Steps to Install the Usage Server Run ./install.sh. # ./install.sh You should see a few messages as the installer prepares, followed by a list of choices. Choose S to install the Usage Server. S Once installed, start the Usage Server with the following command. # service cloudstack-usage start The Administration Guide discusses further configuration of the Usage Server. But the ACS version doesn't have the install.sh script it can be done using the yum install cloudstack-usage . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8409) simplify the dictionary*,jsp
Laszlo Hornyak created CLOUDSTACK-8409: -- Summary: simplify the dictionary*,jsp Key: CLOUDSTACK-8409 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8409 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Laszlo Hornyak Assignee: Laszlo Hornyak Priority: Minor Probably there is a way to get rid of the long list of messages from dictionary.jsp and distionary2.jsp and simply dump all the messages available from the MessageBundle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8408) unused i18n keys
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laszlo Hornyak reassigned CLOUDSTACK-8408:
--
Assignee: Laszlo Hornyak
unused i18n keys
Key: CLOUDSTACK-8408
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8408
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.6.0
Reporter: Laszlo Hornyak
Assignee: Laszlo Hornyak
Priority: Minor
Labels: easyfix
Some i18n key defined in the messages.properties and dictionary*.jsp are not
actually used anywhere by the application.
List of suspicious keys: (to be verified)
{noformat}
confirm.enable.s3
confirm.enable.swift
error.login
error.menu.select
error.mgmt.server.inaccessible
error.please.specify.physical.network.tags
error.session.expired
error.unresolved.internet.name
force.delete.domain.warning
force.remove.host.warning
force.stop.instance.warning
label.account.id
label.account.lower
label.account.specific
label.action.attach.disk.processing
label.action.attach.iso.processing
label.action.cancel.maintenance.mode.processing
label.action.change.service.processing
label.action.copy.ISO.processing
label.action.copy.template.processing
label.action.create.template.from.vm
label.action.create.template.from.volume
label.action.create.template.processing
label.action.create.vm.processing
label.action.create.volume.processing
label.action.delete.account.processing
label.action.delete.cluster.processing
label.action.delete.disk.offering.processing
label.action.delete.domain.processing
label.action.delete.firewall.processing
label.action.delete.ingress.rule.processing
label.action.delete.IP.range.processing
label.action.delete.ISO.processing
label.action.delete.load.balancer.processing
label.action.delete.network.processing
label.action.delete.pod.processing
label.action.delete.primary.storage.processing
label.action.delete.secondary.storage.processing
label.action.delete.security.group.processing
label.action.delete.service.offering.processing
label.action.delete.snapshot.processing
label.action.delete.template.processing
label.action.delete.user.processing
label.action.delete.volume.processing
label.action.delete.zone.processing
label.action.destroy.instance.processing
label.action.destroy.systemvm.processing
label.action.detach.disk.processing
label.action.detach.iso.processing
label.action.disable.account.processing
label.action.disable.cluster.processing
label.action.disable.physical.network
label.action.disable.pod.processing
label.action.disable.static.NAT.processing
label.action.disable.user.processing
label.action.disable.zone.processing
label.action.download.volume.processing
label.action.edit.account
label.action.edit.disk.offering
label.action.edit.global.setting
label.action.edit.host
label.action.edit.instance
label.action.edit.ISO
label.action.edit.network.offering
label.action.edit.network.processing
label.action.edit.pod
label.action.edit.primary.storage
label.action.edit.resource.limits
label.action.edit.service.offering
label.action.edit.template
label.action.edit.user
label.action.edit.zone
label.action.enable.account.processing
label.action.enable.cluster.processing
label.action.enable.maintenance.mode.processing
label.action.enable.physical.network
label.action.enable.pod.processing
label.action.enable.static.NAT.processing
label.action.enable.user.processing
label.action.enable.zone.processing
label.action.expunge.instance.processing
label.action.force.reconnect.processing
label.action.generate.keys.processing
label.action.lock.account.processing
label.action.manage.cluster.processing
label.action.migrate.instance.processing
label.action.migrate.router.processing
label.action.migrate.systemvm.processing
label.action.reboot.instance.processing
label.action.reboot.router.processing
label.action.reboot.systemvm.processing
label.action.release.ip.processing
label.action.remove.host.processing
label.action.reset.password.processing
label.action.resource.limits
label.action.restore.instance.processing
label.action.revert.snapshot.processing
label.action.start.instance.processing
label.action.start.router.processing
label.action.start.systemvm.processing
label.action.stop.instance.processing
label.action.stop.router.processing
label.action.stop.systemvm.processing
label.action.take.snapshot.processing
label.action.unmanage.cluster.processing
label.action.update.OS.preference.processing
label.action.update.resource.count.processing
label.add.by.cidr
label.add.by.group
label.add.direct.iprange
label.added.network.offering
label.adding.cluster
[jira] [Created] (CLOUDSTACK-8408) unused i18n keys
Laszlo Hornyak created CLOUDSTACK-8408:
--
Summary: unused i18n keys
Key: CLOUDSTACK-8408
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8408
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.6.0
Reporter: Laszlo Hornyak
Priority: Minor
Some i18n key defined in the messages.properties and dictionary*.jsp are not
actually used anywhere by the application.
List of suspicious keys: (to be verified)
{noformat}
confirm.enable.s3
confirm.enable.swift
error.login
error.menu.select
error.mgmt.server.inaccessible
error.please.specify.physical.network.tags
error.session.expired
error.unresolved.internet.name
force.delete.domain.warning
force.remove.host.warning
force.stop.instance.warning
label.account.id
label.account.lower
label.account.specific
label.action.attach.disk.processing
label.action.attach.iso.processing
label.action.cancel.maintenance.mode.processing
label.action.change.service.processing
label.action.copy.ISO.processing
label.action.copy.template.processing
label.action.create.template.from.vm
label.action.create.template.from.volume
label.action.create.template.processing
label.action.create.vm.processing
label.action.create.volume.processing
label.action.delete.account.processing
label.action.delete.cluster.processing
label.action.delete.disk.offering.processing
label.action.delete.domain.processing
label.action.delete.firewall.processing
label.action.delete.ingress.rule.processing
label.action.delete.IP.range.processing
label.action.delete.ISO.processing
label.action.delete.load.balancer.processing
label.action.delete.network.processing
label.action.delete.pod.processing
label.action.delete.primary.storage.processing
label.action.delete.secondary.storage.processing
label.action.delete.security.group.processing
label.action.delete.service.offering.processing
label.action.delete.snapshot.processing
label.action.delete.template.processing
label.action.delete.user.processing
label.action.delete.volume.processing
label.action.delete.zone.processing
label.action.destroy.instance.processing
label.action.destroy.systemvm.processing
label.action.detach.disk.processing
label.action.detach.iso.processing
label.action.disable.account.processing
label.action.disable.cluster.processing
label.action.disable.physical.network
label.action.disable.pod.processing
label.action.disable.static.NAT.processing
label.action.disable.user.processing
label.action.disable.zone.processing
label.action.download.volume.processing
label.action.edit.account
label.action.edit.disk.offering
label.action.edit.global.setting
label.action.edit.host
label.action.edit.instance
label.action.edit.ISO
label.action.edit.network.offering
label.action.edit.network.processing
label.action.edit.pod
label.action.edit.primary.storage
label.action.edit.resource.limits
label.action.edit.service.offering
label.action.edit.template
label.action.edit.user
label.action.edit.zone
label.action.enable.account.processing
label.action.enable.cluster.processing
label.action.enable.maintenance.mode.processing
label.action.enable.physical.network
label.action.enable.pod.processing
label.action.enable.static.NAT.processing
label.action.enable.user.processing
label.action.enable.zone.processing
label.action.expunge.instance.processing
label.action.force.reconnect.processing
label.action.generate.keys.processing
label.action.lock.account.processing
label.action.manage.cluster.processing
label.action.migrate.instance.processing
label.action.migrate.router.processing
label.action.migrate.systemvm.processing
label.action.reboot.instance.processing
label.action.reboot.router.processing
label.action.reboot.systemvm.processing
label.action.release.ip.processing
label.action.remove.host.processing
label.action.reset.password.processing
label.action.resource.limits
label.action.restore.instance.processing
label.action.revert.snapshot.processing
label.action.start.instance.processing
label.action.start.router.processing
label.action.start.systemvm.processing
label.action.stop.instance.processing
label.action.stop.router.processing
label.action.stop.systemvm.processing
label.action.take.snapshot.processing
label.action.unmanage.cluster.processing
label.action.update.OS.preference.processing
label.action.update.resource.count.processing
label.add.by.cidr
label.add.by.group
label.add.direct.iprange
label.added.network.offering
label.adding.cluster
label.adding.failed
label.adding.pod
label.adding.processing
label.adding.succeeded
label.adding.user
label.adding.zone
label.additional.networks
label.add.more
label.add.network.device
label.add.new.F5
label.add.new.NetScaler
label.add.new.PA
label.add.new.SRX
label.add.physical.network
label.add.resources
label.add.service.offering
label.add.template
[jira] [Commented] (CLOUDSTACK-8410) VMware ESXi host disconnects frequently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516296#comment-14516296
]
ASF subversion and git services commented on CLOUDSTACK-8410:
-
Commit de7173a0ed6434d1809d0471fe8f28bd339f208e in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=de7173a ]
CLOUDSTACK-8410. ESXi host stuck disconnects frequently.
During ping task, while scanning and updating status of all VMs on the host
that are stuck in a transitional state
and are missing from the power report, do so only for VMs that are not removed.
VMware ESXi host disconnects frequently
---
Key: CLOUDSTACK-8410
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8410
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
Even though CS is able to successfully ping a host, the host is found to be
behind on ping.
Below failure is seen in the logs during every ping-
{noformat}
2015-04-23 00:02:07,457 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-283:ctx-c17caf7a) Unable to complete the ping task
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.handlePowerOffReportWithNoPendingJobsOnVM(VirtualMachineManagerImpl.java:4230)
at
com.cloud.vm.VirtualMachineManagerImpl.scanStalledVMInTransitionStateOnUpHost(VirtualMachineManagerImpl.java:4306)
at
com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:3121)
at
com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:292)
at
com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:157)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8411) Volume is stuck in Copying state after a failed attach
Likitha Shetty created CLOUDSTACK-8411:
--
Summary: Volume is stuck in Copying state after a failed attach
Key: CLOUDSTACK-8411
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8411
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Deploy a VMware setup.
2. Upload an OVA volume to CS that is incompatible with the ESXi host.
3. Attempt to attach the uploaded volume to a VM.
4. Attach will fail because of the incompatibility and the volume will remain
in Copying state.
5. Trying to delete the volume will result in the below error -
{noformat}
2015-04-23 13:58:33,131 DEBUG [o.a.c.s.v.VolumeObject]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to transit
volume: 22, due to: com.cloud.utils.fsm.NoTransitionException: Unable to
transition to a new state from Copying via DestroyRequested
2015-04-23 13:58:33,131 WARN [c.c.s.VolumeApiServiceImpl]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to expunge
volume:
com.cloud.utils.exception.CloudRuntimeException: Failed to transit volume: 22,
due to: com.cloud.utils.fsm.NoTransitionException: Unable to transition to a
new state from Copying via DestroyRequested
at
org.apache.cloudstack.storage.volume.VolumeObject.stateTransit(VolumeObject.java:190)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.destroyVolume(VolumeServiceImpl.java:761)
at
com.cloud.storage.VolumeApiServiceImpl.deleteVolume(VolumeApiServiceImpl.java:1203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy186.deleteVolume(Unknown Source)
at
org.apache.cloudstack.api.command.user.volume.DeleteVolumeCmd.execute(DeleteVolumeCmd.java:85)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:723)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:548)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:282)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jira] [Resolved] (CLOUDSTACK-8411) Volume is stuck in Copying state after a failed attach
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8411.
Resolution: Fixed
Volume is stuck in Copying state after a failed attach
--
Key: CLOUDSTACK-8411
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8411
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Deploy a VMware setup.
2. Upload an OVA volume to CS that is incompatible with the ESXi host.
3. Attempt to attach the uploaded volume to a VM.
4. Attach will fail because of the incompatibility and the volume will remain
in Copying state.
5. Trying to delete the volume will result in the below error -
{noformat}
2015-04-23 13:58:33,131 DEBUG [o.a.c.s.v.VolumeObject]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to
transit volume: 22, due to: com.cloud.utils.fsm.NoTransitionException: Unable
to transition to a new state from Copying via DestroyRequested
2015-04-23 13:58:33,131 WARN [c.c.s.VolumeApiServiceImpl]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to
expunge volume:
com.cloud.utils.exception.CloudRuntimeException: Failed to transit volume:
22, due to: com.cloud.utils.fsm.NoTransitionException: Unable to transition
to a new state from Copying via DestroyRequested
at
org.apache.cloudstack.storage.volume.VolumeObject.stateTransit(VolumeObject.java:190)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.destroyVolume(VolumeServiceImpl.java:761)
at
com.cloud.storage.VolumeApiServiceImpl.deleteVolume(VolumeApiServiceImpl.java:1203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy186.deleteVolume(Unknown Source)
at
org.apache.cloudstack.api.command.user.volume.DeleteVolumeCmd.execute(DeleteVolumeCmd.java:85)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:723)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:548)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:282)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
[jira] [Resolved] (CLOUDSTACK-8412) VM migration with storage fails in a clustered management server setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8412.
Resolution: Fixed
+Root Cause Analysis+
When a request is made to migrate a VM along with its storage, CS spawns an
internal VM work job (VmWorkMigrateWithStorage). If this job is being processed
by a MS that is not the owner of the host that the VM belongs to, then the
request will be forwarded to the MS that owns the VM's host. In case of any
forwarded request, CCP attempts to de-serialize the JSON request. But in case
of 'MigrateWithStorageCommand' this de-serialization fails
This issue will be intermittently observed in a clustered Management Server
(MS) because the issue will only occur if the VM Migrate job is not being
processed by the MS that owns the host that the VM being migrated belongs to.
+Steps to reproduce+
1. Setup a clustered management server environment.
2. Have at least 2 hosts and 2 primary storages in one cluster.
3. Deploy at least a couple of VMs.
4. Call 'migrateVirtualMachineWithVolume' API to migrate the VMs between hosts
and storage pools.
5. Retry till the error is seen in the management server that owns the source
host.
VM migration with storage fails in a clustered management server setup
--
Key: CLOUDSTACK-8412
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8412
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.6.0
When a VM migration with storage request is forwarded by CS from one MS to
another, de-serialization of the JSON request will fail in second management
server with the below error -
{noformat}
2015-04-18 10:43:33,232 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:88d08ca3) Add job-120140
into job monitoring
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:58b8c3e1) Executing
AsyncJobVO {id:120140, userId: 42, accountId: 2, instanceType: None,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-17:ctx-53d5ddc1 ctx-7d9c3e95 ctx-ba112db2) (logid:69812f7a)
submit async job-120140, details: AsyncJobVO {id:120140, userId: 42,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,301 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140 ctx-36e40c6e) (logid:58b8c3e1)
Sync job-120141 execution on object VmWorkJobQueue.2082
2015-04-18 10:43:33,985 ERROR [c.c.a.t.Request] (AgentManager-Handler-1:null)
(logid:) Caught problem with
[{com.cloud.agent.api.MigrateWithStorageCommand:{vm:{id:2082,name:i-3-2082-VM,bootloader:HVM,type:User,cpus:2,minSpeed:1860,maxSpeed:1860,minRam:4294967296,maxRam:4294967296,hostName:PKNSRV-DC01,arch:x86_64,os:Windows
Server
[jira] [Created] (CLOUDSTACK-8413) Resource Tags on a disk are lost when migrate to another storage
Anshul Gangwar created CLOUDSTACK-8413: -- Summary: Resource Tags on a disk are lost when migrate to another storage Key: CLOUDSTACK-8413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8413 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Resource Tags on a disk are lost when migrate to another storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8410) VMware ESXi host disconnects frequently
Likitha Shetty created CLOUDSTACK-8410:
--
Summary: VMware ESXi host disconnects frequently
Key: CLOUDSTACK-8410
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8410
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
Even though CS is able to successfully ping a host, the host is found to be
behind on ping.
Below failure is seen in the logs during every ping-
{noformat}
2015-04-23 00:02:07,457 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-283:ctx-c17caf7a) Unable to complete the ping task
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.handlePowerOffReportWithNoPendingJobsOnVM(VirtualMachineManagerImpl.java:4230)
at
com.cloud.vm.VirtualMachineManagerImpl.scanStalledVMInTransitionStateOnUpHost(VirtualMachineManagerImpl.java:4306)
at
com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:3121)
at
com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:292)
at
com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:157)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8410) VMware ESXi host disconnects frequently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8410.
Resolution: Fixed
VMware ESXi host disconnects frequently
---
Key: CLOUDSTACK-8410
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8410
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
Even though CS is able to successfully ping a host, the host is found to be
behind on ping.
Below failure is seen in the logs during every ping-
{noformat}
2015-04-23 00:02:07,457 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-283:ctx-c17caf7a) Unable to complete the ping task
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.handlePowerOffReportWithNoPendingJobsOnVM(VirtualMachineManagerImpl.java:4230)
at
com.cloud.vm.VirtualMachineManagerImpl.scanStalledVMInTransitionStateOnUpHost(VirtualMachineManagerImpl.java:4306)
at
com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:3121)
at
com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:292)
at
com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:157)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8411) Volume is stuck in Copying state after a failed attach
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516323#comment-14516323
]
ASF subversion and git services commented on CLOUDSTACK-8411:
-
Commit 10a106f5d86a7f6786b94a7298a5c63c32eab66b in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=10a106f ]
CLOUDSTACK-8411. Unable to delete an uploaded volume after CCP fails to attach
the volume to a VM.
Correctly update the status of an uploaded volume upon failure to attach it to
a VM.
Volume is stuck in Copying state after a failed attach
--
Key: CLOUDSTACK-8411
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8411
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Deploy a VMware setup.
2. Upload an OVA volume to CS that is incompatible with the ESXi host.
3. Attempt to attach the uploaded volume to a VM.
4. Attach will fail because of the incompatibility and the volume will remain
in Copying state.
5. Trying to delete the volume will result in the below error -
{noformat}
2015-04-23 13:58:33,131 DEBUG [o.a.c.s.v.VolumeObject]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to
transit volume: 22, due to: com.cloud.utils.fsm.NoTransitionException: Unable
to transition to a new state from Copying via DestroyRequested
2015-04-23 13:58:33,131 WARN [c.c.s.VolumeApiServiceImpl]
(catalina-exec-6:ctx-dc092088 ctx-4e53aa0e) (logid:71d41bd9) Failed to
expunge volume:
com.cloud.utils.exception.CloudRuntimeException: Failed to transit volume:
22, due to: com.cloud.utils.fsm.NoTransitionException: Unable to transition
to a new state from Copying via DestroyRequested
at
org.apache.cloudstack.storage.volume.VolumeObject.stateTransit(VolumeObject.java:190)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.destroyVolume(VolumeServiceImpl.java:761)
at
com.cloud.storage.VolumeApiServiceImpl.deleteVolume(VolumeApiServiceImpl.java:1203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy186.deleteVolume(Unknown Source)
at
org.apache.cloudstack.api.command.user.volume.DeleteVolumeCmd.execute(DeleteVolumeCmd.java:85)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:723)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:548)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:282)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at
[jira] [Commented] (CLOUDSTACK-8412) VM migration with storage fails in a clustered management server setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516364#comment-14516364
]
ASF subversion and git services commented on CLOUDSTACK-8412:
-
Commit 04365601dac6d4dfa396e5c86ab7e698906dfb44 in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0436560 ]
CLOUDSTACK-8412. VM migration with storage fails.
Update MigrateWithStorageCommand to avoid JSON deserialization error.
VM migration with storage fails in a clustered management server setup
--
Key: CLOUDSTACK-8412
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8412
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.6.0
When a VM migration with storage request is forwarded by CS from one MS to
another, de-serialization of the JSON request will fail in second management
server with the below error -
{noformat}
2015-04-18 10:43:33,232 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:88d08ca3) Add job-120140
into job monitoring
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:58b8c3e1) Executing
AsyncJobVO {id:120140, userId: 42, accountId: 2, instanceType: None,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-17:ctx-53d5ddc1 ctx-7d9c3e95 ctx-ba112db2) (logid:69812f7a)
submit async job-120140, details: AsyncJobVO {id:120140, userId: 42,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,301 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140 ctx-36e40c6e) (logid:58b8c3e1)
Sync job-120141 execution on object VmWorkJobQueue.2082
2015-04-18 10:43:33,985 ERROR [c.c.a.t.Request] (AgentManager-Handler-1:null)
(logid:) Caught problem with
[{com.cloud.agent.api.MigrateWithStorageCommand:{vm:{id:2082,name:i-3-2082-VM,bootloader:HVM,type:User,cpus:2,minSpeed:1860,maxSpeed:1860,minRam:4294967296,maxRam:4294967296,hostName:PKNSRV-DC01,arch:x86_64,os:Windows
Server 2012 R2
[jira] [Commented] (CLOUDSTACK-8413) Resource Tags on a disk are lost when migrate to another storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516386#comment-14516386 ] ASF GitHub Bot commented on CLOUDSTACK-8413: GitHub user anshul1886 opened a pull request: https://github.com/apache/cloudstack/pull/194 CLOUDSTACK-8413: Fixed resource tags on disk are lost when migrate to another storage During cold volume migration we are duplicating volume entry in volumes table. When migration is complete, we update the uuid of new entry and expunge the older entry. This results in removal of resource tags on volume as its resource id still pointing to older volume. As part of fix while updating uuid for volume, we are updating resource_id for tags also. You can merge this pull request into a Git repository by running: $ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8413 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/194.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #194 commit ded824bffc7900268427242a0ad357303ac5ca3b Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2015-02-19T10:52:20Z CLOUDSTACK-8413: Fixed resource tags on disk are lost when migrate to another storage During cold volume migration we are duplicating volume entry in volumes table. When migration is complete, we update the uuid of new entry and expunge the older entry. This results in removal of resource tags on volume as its resource id still pointing to older volume. As part of fix while updating uuid for volume, we are updating resource_id for tags also. Resource Tags on a disk are lost when migrate to another storage Key: CLOUDSTACK-8413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Resource Tags on a disk are lost when migrate to another storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5282) KVM - Advanced zone Isolated networks - Egress rules are not functional because of router having mutiple nics for the public ip address.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516336#comment-14516336 ] Jayapal Reddy commented on CLOUDSTACK-5282: --- It seems additional nic eth3 got added outside the cloudstack due to this egress rules got affected. When another interface got added with same mac, ip address vm traffic send to eth2/eth3 depending the arp resolution. Cloudstack knows only eth2 and it added egress rules for eth2 only. From cloudstack if additional nic get added then the egress rules adds corresponding rules for the additional nic. If we fix adding eth3 interface then egress rules work properly. Can you down the eth3 interface manually and see the vm public traffic. Can you attach 'ip addr show' and 'iptables -L -nv' output from the VR. KVM - Advanced zone Isolated networks - Egress rules are not functional because of router having mutiple nics for the public ip address. - Key: CLOUDSTACK-5282 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5282 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: Build from 4.3 using 64 bit system templates. Reporter: Sangeetha Hariharan Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Attachments: management-server.rar KVM - Advanced zone Isolated networks - Egress rules are not functional. Steps to reproduce the problem: Advanced zone with 2 KVM hosts (rhel6.3), Isolated network with 20 vms. Create a egress rule to allow all traffic to all cidrs. From Vm , try to ping google.com We are not able to ping/ssh outside from the VM. Egress rules are programmed in the router. But I see that the router has as many NICs as the number of Vms that it services asssigned to the same public Ip address but with 2 different MAC address. root@r-10-MyTestVM:~# ip route default via 10.223.138.129 dev eth2 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.1 10.223.138.128/26 dev eth2 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth3 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth4 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth5 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth6 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth7 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth8 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth9 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth10 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth11 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth12 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth13 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth14 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth15 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth16 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth17 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth18 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth19 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth20 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth21 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth22 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth23 proto kernel scope link src 10.223.138.137 10.223.138.128/26 dev eth24 proto kernel scope link src 10.223.138.137 169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.3.13 root@r-10-MyTestVM:~# ifconfig eth0 Link encap:Ethernet HWaddr 02:00:51:27:00:02 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::51ff:fe27:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:757 errors:0 dropped:0 overruns:0 frame:0 TX packets:324 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:116494 (113.7 KiB) TX bytes:44376 (43.3 KiB) eth1 Link encap:Ethernet HWaddr 0e:00:a9:fe:03:0d inet addr:169.254.3.13 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c00:a9ff:fefe:30d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14587 errors:0
[jira] [Resolved] (CLOUDSTACK-7422) [Automation] Attach volume test case failing with error Invalid configuration for device '0'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-7422.
-
Resolution: Fixed
from the comments, looks like its fixed
[Automation] Attach volume test case failing with error Invalid
configuration for device '0'
--
Key: CLOUDSTACK-7422
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7422
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Environment: Vmware 5.0
build 4.5
Reporter: Rayees Namathponnan
Priority: Critical
Fix For: 4.5.1
Steps to reproduce the defect
Run the test
integration.component.test_volumes.TestAttachVolumeISO.test_01_volume_iso_attach
This test case performing below steps
678 # Validate the following
679 # 1. Create and attach 5 data volumes to VM
680 # 2. Create an ISO. Attach it to VM instance
681 # 3. Verify that attach ISO is successful
Here attach volume fails with below error
{noformat}
a5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAZh0ABRWb2x1
bWVBcGlTZXJ2aWNlSW1wbHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAACnNxAH4ABgHJ
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 90928106758026, completeMsid: null, lastUpdated:
null, lastPolled: null, created: Sat Aug 23 14:45:42 PDT 2014}, job
origin:3043
com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume
TestDiskServ to VM TestVM-24cfe95b-8976-48af-ba42-459b37cfb89c; AttachV
olumeCommand failed due to Exception: java.lang.RuntimeException
Message: Invalid configuration for device '0'.
at
com.cloud.storage.VolumeApiServiceImpl.sendAttachVolumeCommand(VolumeApiServiceImpl.java:2248)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1216)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2615)
at sun.reflect.GeneratedMethodAccessor855.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
at sun.reflect.GeneratedMethodAccessor568.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy184.handleVmWorkJob(Unknown Source)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[jira] [Created] (CLOUDSTACK-8412) VM migration with storage fails in a clustered management server setup
Likitha Shetty created CLOUDSTACK-8412:
--
Summary: VM migration with storage fails in a clustered management
server setup
Key: CLOUDSTACK-8412
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8412
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.6.0
When a VM migration with storage request is forwarded by CS from one MS to
another, de-serialization of the JSON request will fail in second management
server with the below error -
{noformat}
2015-04-18 10:43:33,232 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:88d08ca3) Add job-120140
into job monitoring
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140) (logid:58b8c3e1) Executing
AsyncJobVO {id:120140, userId: 42, accountId: 2, instanceType: None,
instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,245 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-17:ctx-53d5ddc1 ctx-7d9c3e95 ctx-ba112db2) (logid:69812f7a)
submit async job-120140, details: AsyncJobVO {id:120140, userId: 42, accountId:
2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{virtualmachineid:cf879643-3143-4822-a727-0223783d0553,cmdEventType:VM.MIGRATE,ctxUserId:42,httpmethod:GET,migrateto[0].pool:f04a44e1-d75e-3829-813d-8bb6f356f3c2,migrateto[0].volume:933adc86-44aa-4afd-b704-d5572f513a13,apiKey:LrQgAYP2C8u47ZnFahkISur_4eKlWLTZK7fnkOJw5AuMtgz3s0KFKP1d6ow_mx5ecbI3zS8w18fG-ljIZ2m5dA,response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cf879643-3143-4822-a727-0223783d0553\,\com.cloud.host.Host\:\9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4\},hostid:9a74034e-2dbd-4b4f-84e3-9a7d828fdcb4,ctxAccountId:2,ctxStartEventId:64200,signature:gmEZXBo5X0Lwcc4fQ9MAgvsAoW8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 345049612948, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-04-18 10:43:33,301 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-52:ctx-d5bbb06c job-120140 ctx-36e40c6e) (logid:58b8c3e1)
Sync job-120141 execution on object VmWorkJobQueue.2082
2015-04-18 10:43:33,985 ERROR [c.c.a.t.Request] (AgentManager-Handler-1:null)
(logid:) Caught problem with
[{com.cloud.agent.api.MigrateWithStorageCommand:{vm:{id:2082,name:i-3-2082-VM,bootloader:HVM,type:User,cpus:2,minSpeed:1860,maxSpeed:1860,minRam:4294967296,maxRam:4294967296,hostName:PKNSRV-DC01,arch:x86_64,os:Windows
Server 2012 R2
(64-bit),platformEmulator:windows8Server64Guest,bootArgs:,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:true,vncPassword:f1ce1313c3a2ce1c,params:{memoryOvercommitRatio:1,Message.ReservedCapacityFreed.Flag:true,dataDiskController:osdefault,cpuOvercommitRatio:4.0,nicAdapter:Vmxnet3,vmware.reserve.cpu:false,nestedVirtualizationFlag:false,rootDiskController:osdefault,vmware.reserve.mem:false},uuid:cf879643-3143-4822-a727-0223783d0553,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:933adc86-44aa-4afd-b704-d5572f513a13,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f14aba0e-cd98-3397-81da-a8e00f23f1eb,id:216,poolType:VMFS,host:VMFS
datastore:
/REALCLOUD/RCBLNSAN03-VMCLP-Vol02,path:/REALCLOUD/RCBLNSAN03-VMCLP-Vol02,port:0,url:VMFS://VMFS
datastore:
/REALCLOUD/RCBLNSAN03-VMCLP-Vol02/REALCLOUD/RCBLNSAN03-VMCLP-Vol02/?ROLE\u003dPrimary\u0026STOREUUID\u003df14aba0e-cd98-3397-81da-a8e00f23f1eb}},name:ROOT-2082,size:42949672960,path:ROOT-2082-01,volumeId:2790,vmName:i-3-2082-VM,accountId:3,chainInfo:{\diskDeviceBusName\:\scsi0:0\,\diskChain\:[\[RCBLNSAN03-VMCLP-Vol02]
[jira] [Commented] (CLOUDSTACK-8304) maven repositories are checked for snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514464#comment-14514464 ] ASF GitHub Bot commented on CLOUDSTACK-8304: Github user K0zka commented on the pull request: https://github.com/apache/cloudstack/pull/193#issuecomment-96743926 Just a sidenote: CLOUDSTACK-8304 (maven repositories are checked for snapshots) is not the relevant issue. more likely CLOUDSTACK-8394 maven repositories are checked for snapshots Key: CLOUDSTACK-8304 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8304 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: any version of maven Reporter: Laszlo Hornyak Assignee: Laszlo Hornyak Priority: Minor Labels: build Fix For: 4.5.0, 4.6.0 Original Estimate: 5m Remaining Estimate: 5m libvirt.org and ceph.org maven repositories are checked for snapshots while they do not host snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8417) [Hyper-V] Add support for smb share path in Hyper-V settings virtual disk path
Anshul Gangwar created CLOUDSTACK-8417: -- Summary: [Hyper-V] Add support for smb share path in Hyper-V settings virtual disk path Key: CLOUDSTACK-8417 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8417 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V] Add support for smb share path in Hyper-V settings virtual disk path -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8414) [Hyper-V] template_spool_ref table is not getting updated with correct template_size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516394#comment-14516394 ] ASF GitHub Bot commented on CLOUDSTACK-8414: GitHub user anshul1886 opened a pull request: https://github.com/apache/cloudstack/pull/195 CLOUDSTACK-8414: [Hyper-V] Fixed template_spool_ref table is not getting updated with correct template size Fixed template_spool_ref table is not getting updated with correct template size Now returning file size instead of null. You can merge this pull request into a Git repository by running: $ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8414 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/195.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #195 commit 28401f043677f23001eb868fce94eeeb90e6e60e Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2015-03-23T09:43:53Z CLOUDSTACK-8414: Fixed template_spool_ref table is not getting updated with correct template_size Now returning file size instead of null. [Hyper-V] template_spool_ref table is not getting updated with correct template_size Key: CLOUDSTACK-8414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8414 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar template_spool_ref table is not getting updated with correct template_size -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8414) [Hyper-V] template_spool_ref table is not getting updated with correct template_size and local path
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-8414: --- Description: template_spool_ref table is not getting updated with correct template_size and local path (was: template_spool_ref table is not getting updated with correct template_size) [Hyper-V] template_spool_ref table is not getting updated with correct template_size and local path --- Key: CLOUDSTACK-8414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8414 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar template_spool_ref table is not getting updated with correct template_size and local path -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8415) [VMware] SSVM shutdown during snapshot operation results in disks to be left behind
Likitha Shetty created CLOUDSTACK-8415: -- Summary: [VMware] SSVM shutdown during snapshot operation results in disks to be left behind Key: CLOUDSTACK-8415 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8415 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 Partial disks are residue of a failed snapshot operation caused by SSVM reboot/shutdown. The disks do not get cleaned up on secondary storage and need to be cleaned up manually to release storage. +Steps to reproduce+ 1. Initiate a volume snapshot operation. 2. Destroy SSVM while the operation is in progress. 3. Check the snapshot folder in secondary storage - Files including disks are present in the folder and are never cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8414) [Hyper-V] template_spool_ref table is not getting updated with correct template_size
Anshul Gangwar created CLOUDSTACK-8414: -- Summary: [Hyper-V] template_spool_ref table is not getting updated with correct template_size Key: CLOUDSTACK-8414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8414 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar template_spool_ref table is not getting updated with correct template_size -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8414) [Hyper-V] template_spool_ref table is not getting updated with correct template_size and local path
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-8414: --- Summary: [Hyper-V] template_spool_ref table is not getting updated with correct template_size and local path (was: [Hyper-V] template_spool_ref table is not getting updated with correct template_size) [Hyper-V] template_spool_ref table is not getting updated with correct template_size and local path --- Key: CLOUDSTACK-8414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8414 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar template_spool_ref table is not getting updated with correct template_size -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8416) Add support for FIPS compliant checksum for upload volume and template
Anshul Gangwar created CLOUDSTACK-8416: -- Summary: Add support for FIPS compliant checksum for upload volume and template Key: CLOUDSTACK-8416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8416 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Add support for FIPS compliant checksum for upload volume and template -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8416) Add support for FIPS compliant checksum for upload volume and template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516426#comment-14516426 ] ASF GitHub Bot commented on CLOUDSTACK-8416: GitHub user anshul1886 opened a pull request: https://github.com/apache/cloudstack/pull/196 CLOUDSTACK-8416: added support for FIPS compliant checksum. It will now support md5, sha1, sha224, sha256, sha384 and sha512 checksums. In same checksum parameter user can pass any of the above algorithms hash You can merge this pull request into a Git repository by running: $ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8416 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/196.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #196 commit f5c3b248fc165cbf43129b4bfaafafba3fcbe7ed Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2015-03-31T07:38:17Z CLOUDSTACK-8416: added support for FIPS compliant checksum. It will now support md5, sha1, sha224, sha256, sha384 and sha512 checksums. In same checksum parameter user can pass any of the above algorithms hash Add support for FIPS compliant checksum for upload volume and template -- Key: CLOUDSTACK-8416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Add support for FIPS compliant checksum for upload volume and template -- This message was sent by Atlassian JIRA (v6.3.4#6332)
