[jira] [Assigned] (CLOUDSTACK-4549) ceph:deployvm from template created from snapshot is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4549: -- Assignee: Wido den Hollander ceph:deployvm from template created from snapshot is failing Key: CLOUDSTACK-4549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4549 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: sadhu suresh Assignee: Wido den Hollander Priority: Critical Attachments: management-server.rar VM deployment form template which is created form snapshot is failing where as VM deployment with uploaded template successful. created template form snapshot is storing in raw format(https://10-147-49-100.realhostip.com/userdata/0c826645-ec82-40f1-a1b0-38fc9ba1c76f.raw).. not sure are we converting again to QCwo2 when we try to deploy a VM steps: 1.create a ceph instance(configure compute offering with RBD and deploy a vm) 2.Once it successful,select the root partition and perform snapshot 3.once snapshot successful,create a template from snapshot 4 try to create vm uning above VM actual result: deploy vm failing with exception -29 15:21:43,756 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Service SecurityGroup is not supported in the network id=204 2013-08-29 15:21:43,762 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Applying userdata and password entry in network Ntwk[204|Guest|8] 2013-08-29 15:21:43,800 DEBUG [agent.transport.Request] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Seq 1-2089159931: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100111, [{com.cloud.agent.api.routing.SavePasswordCommand:{password:fnirq_cnffjbeq,vmIpAddress:10.1.1.140,vmName:6e798618-8e4d-4305-94a1-642e5f3aad08,executeInSequence:true,accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.248,router.name:r-15-VM},wait:0}},{com.cloud.agent.api.routing.VmDataCommand:{vmIpAddress:10.1.1.140,vmName:6e798618-8e4d-4305-94a1-642e5f3aad08,executeInSequence:true,accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.248,router.name:r-15-VM},wait:0}}] } 2013-08-29 15:21:44,168 DEBUG [agent.transport.Request] (AgentManager-Handler-14:null) Seq 1-2089159931: Processing: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 110, [{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}}] } 2013-08-29 15:21:44,169 DEBUG [agent.manager.AgentAttache] (AgentManager-Handler-14:null) Seq 1-2089159931: No more commands found 2013-08-29 15:21:44,169 DEBUG [agent.transport.Request] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Seq 1-2089159931: Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 110, { Answer, Answer } } 2013-08-29 15:21:44,179 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Service SecurityGroup is not supported in the network id=204 2013-08-29 15:21:44,182 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Checking if we need to prepare 1 volumes for VM[User|6e798618-8e4d-4305-94a1-642e5f3aad08] 2013-08-29 15:21:44,207 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) template 202 is already in store:1, type:Image 2013-08-29 15:21:44,219 DEBUG [storage.datastore.PrimaryDataStoreImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Not found (templateId:202poolId:5) in template_spool_ref, persisting it 2013-08-29 15:21:44,234 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) template 202 is already in store:5, type:Primary 2013-08-29 15:21:44,237 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Found template 246c1e4ac-9fc0-3122-bcfb-77deff789f61 in storage pool 5 with VMTemplateStoragePool id: 5 2013-08-29 15:21:44,433 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) Acquire lock on VMTemplateStoragePool 5 with timeout 3600 seconds 2013-08-29 15:21:44,438 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-14:job-42 = [ 3dcbbb22-d258-4859-bf3f-c8a620768e25 ]) lock is acquired for
[jira] [Assigned] (CLOUDSTACK-4667) ceph:UI:Not showing proper error message while providing invalid values in addPrimaryStorage wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4667: -- Assignee: Wido den Hollander ceph:UI:Not showing proper error message while providing invalid values in addPrimaryStorage wizard --- Key: CLOUDSTACK-4667 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4667 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Reporter: sadhu suresh Assignee: Wido den Hollander Priority: Minor Try to add the RBD based primary storage by proving invalid details like invalid user name,authorization key,server and check the displayed error messgae actual results: its not shown proper error message and it shows Failed to delete storage pool on host and its misleading to end user. http://localhost:8080/client/api?command=createStoragePoolscope=clusterzoneid=72de9a30-4e59-4bf5-a82c-59f824e097b2podid=0dadd3d1-6798-423b-b7fe-1ad5c42d6f5dclusterid=b8aabe18-98b2-45e4-82b2-c38b04261eb7name=testurl=rbd%3A%2F%2Fadmin%3AQVFCVjdBRlNzTG1aRUJBQW1HaXZBay9CVjFpTXZjYVJIUWZpWGc9PQ%3D%3D%40localhost%2Fbaburesponse=jsonsessionkey=GDka3Ul7UmsVtPnMthqKVxqn4cY%3D_=1379089750610 { createstoragepoolresponse : {uuidList:[],errorcode:530,cserrorcode:,errortext:Failed to delete storage pool on host} } -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4667) ceph:UI:Not showing proper error message while providing invalid values in addPrimaryStorage wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983476#comment-13983476 ] Wido den Hollander commented on CLOUDSTACK-4667: So yes, this is a problem. The fact is that we pass down a XML to libvirt and it tries to start the storage pool. That fails, but we don't get exact feedback. Might be an idea to test the credentials first using RADOS Java, that way we can give the user some more feedback. If that succeeds, then we add the pool to libvirt. ceph:UI:Not showing proper error message while providing invalid values in addPrimaryStorage wizard --- Key: CLOUDSTACK-4667 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4667 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Reporter: sadhu suresh Assignee: Wido den Hollander Priority: Minor Try to add the RBD based primary storage by proving invalid details like invalid user name,authorization key,server and check the displayed error messgae actual results: its not shown proper error message and it shows Failed to delete storage pool on host and its misleading to end user. http://localhost:8080/client/api?command=createStoragePoolscope=clusterzoneid=72de9a30-4e59-4bf5-a82c-59f824e097b2podid=0dadd3d1-6798-423b-b7fe-1ad5c42d6f5dclusterid=b8aabe18-98b2-45e4-82b2-c38b04261eb7name=testurl=rbd%3A%2F%2Fadmin%3AQVFCVjdBRlNzTG1aRUJBQW1HaXZBay9CVjFpTXZjYVJIUWZpWGc9PQ%3D%3D%40localhost%2Fbaburesponse=jsonsessionkey=GDka3Ul7UmsVtPnMthqKVxqn4cY%3D_=1379089750610 { createstoragepoolresponse : {uuidList:[],errorcode:530,cserrorcode:,errortext:Failed to delete storage pool on host} } -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6530) Populate first class entities in the context parameter
Nitin Mehta created CLOUDSTACK-6530: --- Summary: Populate first class entities in the context parameter Key: CLOUDSTACK-6530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6530 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta Populate the first class entities in the context to be available for publishing more information for the event bus, checking the displayable property etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6530) Populate first class entities in the context parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983847#comment-13983847 ] ASF subversion and git services commented on CLOUDSTACK-6530: - Commit 3e7ea4e8d99a92872007f11a09ab87c8ba61e1da in cloudstack's branch refs/heads/4.4-forward from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3e7ea4e ] CLOUDSTACK-6530: Populate the first class entities in the context to be available for publishing more information for the event bus, checking the displayable property etc. Populate first class entities in the context parameter -- Key: CLOUDSTACK-6530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6530 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta Populate the first class entities in the context to be available for publishing more information for the event bus, checking the displayable property etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6530) Populate first class entities in the context parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983848#comment-13983848 ] ASF subversion and git services commented on CLOUDSTACK-6530: - Commit dd55095fd5a1e3b9ea4e6f10f00e47495d7fb167 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dd55095 ] CLOUDSTACK-6530: Populate the first class entities in the context to be available for publishing more information for the event bus, checking the displayable property etc. (cherry picked from commit 3e7ea4e8d99a92872007f11a09ab87c8ba61e1da) Populate first class entities in the context parameter -- Key: CLOUDSTACK-6530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6530 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta Populate the first class entities in the context to be available for publishing more information for the event bus, checking the displayable property etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4371) [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984012#comment-13984012 ] ASF subversion and git services commented on CLOUDSTACK-4371: - Commit de114f554895c24c0d25106a775f1405eac79c6d in cloudstack's branch refs/heads/4.4-forward from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=de114f5 ] CLOUDSTACK-4371: [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time Fixed simulator code to handle local storage during host reconnect [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time Key: CLOUDSTACK-4371 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4371 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: Basic zone, with over 20K simulator hosts Reporter: Sowmya Krishnan Assignee: Koushik Das Labels: performance Fix For: 4.3.0 Attachments: agenttaskpool_334.log, ms1_restartfail.log.gz, ms2_restartfail.log.gz, ms3_restartfail.log.gz Basic zone performance test bed: 20K simulator hosts, 3 Management servers 1 host/cluster Local storage Java heap size: 12GB db.cloud.maxActive=2000 direct.agent.load.size=1000 agent.lb.enabled=true Deploy around 20K simulator hosts with 3 Management servers clustered (Not deployed any VMs yet) After all hosts are deployed, stop all 3 Management servers and then start all 3 one after another Result = Hosts don't get to connected state at all even after 10 minutes. While around 2K of them go into alert state while rest are in disconnected state. mysql select count(*), status, resource_state, type, mgmt_server_id from host group by mgmt_server_id, status, type, resource_state; +--+--++++ | count(*) | status | resource_state | type | mgmt_server_id | +--+--++++ | 1946 | Alert| Enabled| Routing| NULL | |18054 | Disconnected | Enabled| Routing| NULL | |1 | Disconnected | Enabled| SecondaryStorageVM | NULL | +--+--++++ 3 rows in set (0.11 sec) MS Logs show lot of storage pool exceptions while hosts try to get connected: 2013-08-16 05:49:25,592 DEBUG [agent.transport.Request] (AgentTaskPool-12:null) Seq 13-32440322: Sending { Cmd , MgmtId: 206915885094132, via: 13, Ver: v1, Flags: 100011, [{com.cloud.agen t.api.CleanupNetworkRulesCmd:{interval:2028,wait:0}}] } 2013-08-16 05:49:25,592 DEBUG [agent.transport.Request] (AgentTaskPool-12:null) Seq 13-32440322: Executing: { Cmd , MgmtId: 206915885094132, via: 13, Ver: v1, Flags: 100011, [{com.cloud.a gent.api.CleanupNetworkRulesCmd:{interval:2028,wait:0}}] } 2013-08-16 05:49:25,592 DEBUG [xen.discoverer.XcpServerDiscoverer] (AgentTaskPool-14:null) Not XenServer so moving on. 2013-08-16 05:49:25,592 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-14:null) Sending Connect to listener: DeploymentPlanningManagerImpl_EnhancerByCloudStack_76f3d8e4 2013-08-16 05:49:25,591 DEBUG [cloud.resource.AgentResourceBase] (ClusteredAgentManager Timer:null) Deserializing simulated agent on reconnect 2013-08-16 05:49:25,594 INFO [network.security.SecurityGroupListener] (AgentTaskPool-12:null) Scheduled network rules cleanup, interval=2028 2013-08-16 05:49:25,594 INFO [network.security.SecurityGroupListener] (AgentTaskPool-12:null) Received a host startup notification 2013-08-16 05:49:25,595 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: StoragePoolMonitor ... ... 2013-08-16 05:49:25,761 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: ClusteredVirtualMachineManagerImpl_EnhancerByCloudStack_b5459b7b 2013-08-16 05:49:25,764 DEBUG [cloud.vm.VirtualMachineManagerImpl] (AgentTaskPool-12:null) Found 0 VMs for host 13 2013-08-16 05:49:25,765 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: LocalStoragePoolListener 2013-08-16 05:49:25,768 DEBUG [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl] (AgentTaskPool-12:null) createPool
[jira] [Commented] (CLOUDSTACK-4371) [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984040#comment-13984040 ] ASF subversion and git services commented on CLOUDSTACK-4371: - Commit 8d92d00c87b34eea77119dda64f9870b1e078a6c in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8d92d00 ] CLOUDSTACK-4371: [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time Fixed simulator code to handle local storage during host reconnect [Performance Testing] Basic zone with 20K Hosts, management server restart leaves the hosts in disconnected state for very long time Key: CLOUDSTACK-4371 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4371 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: Basic zone, with over 20K simulator hosts Reporter: Sowmya Krishnan Assignee: Koushik Das Labels: performance Fix For: 4.3.0 Attachments: agenttaskpool_334.log, ms1_restartfail.log.gz, ms2_restartfail.log.gz, ms3_restartfail.log.gz Basic zone performance test bed: 20K simulator hosts, 3 Management servers 1 host/cluster Local storage Java heap size: 12GB db.cloud.maxActive=2000 direct.agent.load.size=1000 agent.lb.enabled=true Deploy around 20K simulator hosts with 3 Management servers clustered (Not deployed any VMs yet) After all hosts are deployed, stop all 3 Management servers and then start all 3 one after another Result = Hosts don't get to connected state at all even after 10 minutes. While around 2K of them go into alert state while rest are in disconnected state. mysql select count(*), status, resource_state, type, mgmt_server_id from host group by mgmt_server_id, status, type, resource_state; +--+--++++ | count(*) | status | resource_state | type | mgmt_server_id | +--+--++++ | 1946 | Alert| Enabled| Routing| NULL | |18054 | Disconnected | Enabled| Routing| NULL | |1 | Disconnected | Enabled| SecondaryStorageVM | NULL | +--+--++++ 3 rows in set (0.11 sec) MS Logs show lot of storage pool exceptions while hosts try to get connected: 2013-08-16 05:49:25,592 DEBUG [agent.transport.Request] (AgentTaskPool-12:null) Seq 13-32440322: Sending { Cmd , MgmtId: 206915885094132, via: 13, Ver: v1, Flags: 100011, [{com.cloud.agen t.api.CleanupNetworkRulesCmd:{interval:2028,wait:0}}] } 2013-08-16 05:49:25,592 DEBUG [agent.transport.Request] (AgentTaskPool-12:null) Seq 13-32440322: Executing: { Cmd , MgmtId: 206915885094132, via: 13, Ver: v1, Flags: 100011, [{com.cloud.a gent.api.CleanupNetworkRulesCmd:{interval:2028,wait:0}}] } 2013-08-16 05:49:25,592 DEBUG [xen.discoverer.XcpServerDiscoverer] (AgentTaskPool-14:null) Not XenServer so moving on. 2013-08-16 05:49:25,592 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-14:null) Sending Connect to listener: DeploymentPlanningManagerImpl_EnhancerByCloudStack_76f3d8e4 2013-08-16 05:49:25,591 DEBUG [cloud.resource.AgentResourceBase] (ClusteredAgentManager Timer:null) Deserializing simulated agent on reconnect 2013-08-16 05:49:25,594 INFO [network.security.SecurityGroupListener] (AgentTaskPool-12:null) Scheduled network rules cleanup, interval=2028 2013-08-16 05:49:25,594 INFO [network.security.SecurityGroupListener] (AgentTaskPool-12:null) Received a host startup notification 2013-08-16 05:49:25,595 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: StoragePoolMonitor ... ... 2013-08-16 05:49:25,761 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: ClusteredVirtualMachineManagerImpl_EnhancerByCloudStack_b5459b7b 2013-08-16 05:49:25,764 DEBUG [cloud.vm.VirtualMachineManagerImpl] (AgentTaskPool-12:null) Found 0 VMs for host 13 2013-08-16 05:49:25,765 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-12:null) Sending Connect to listener: LocalStoragePoolListener 2013-08-16 05:49:25,768 DEBUG [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl] (AgentTaskPool-12:null) createPool Params @
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984048#comment-13984048 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 934056097a638c1563f067b4236ad4c37211e9db in cloudstack's branch refs/heads/4.4-forward from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9340560 ] CLOUDSTACK-6170 Needed to add logic for XS 6.2 + XS62ESP1 + XS62ESP1004 Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer and ESX (KVM is targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6304) MySQLSyntaxErrorExceptions and SQLExceptions are seen on catalina.out log during Management Server Deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-6304. - Resolution: Fixed Please re open if we need to check before removing those indexes and keys instead of throwing warning MySQLSyntaxErrorExceptions and SQLExceptions are seen on catalina.out log during Management Server Deployment - Key: CLOUDSTACK-6304 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6304 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Chandan Purushothama Assignee: Damodar Reddy T Priority: Critical Fix For: 4.4.0 Attachments: catalina.zip Attached the catalina.out log to the bug report. The log has the details pertaining to the MySQLSyntaxErrorExceptions and SQLExceptions seen during Management Server Installation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6386) DB Exceptions while starting the Management server first time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-6386. - Resolution: Fixed Please re open if we need to check before removing those indexes and keys instead of throwing warning DB Exceptions while starting the Management server first time -- Key: CLOUDSTACK-6386 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6386 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Damodar Reddy T Fix For: 4.4.0 Attachments: management-server.log Steps: 1. Using Latest 4.4 and started Management server using cloudstack-setup-management script Observation: Notice below DB exceptions. This is not causing for any failure to start the server. 2014-04-11 16:21:24,430 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Verify and set the KVM snapshot flag if snapshot was used. 2014-04-11 16:21:24,431 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Done set KVM snapshot flag. 2014-04-11 16:21:24,431 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Dropping index i_alert__last_sent if it exists 2014-04-11 16:21:24,450 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key last_sent on table alert com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'last_sent'; check that column/key exists at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37) at com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28) at com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543) at com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482) at
[jira] [Resolved] (CLOUDSTACK-6435) Add new Command line options to setup/bindir/cloud-setup-databases.in and remove OS specific commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-6435. - Resolution: Fixed Add new Command line options to setup/bindir/cloud-setup-databases.in and remove OS specific commands - Key: CLOUDSTACK-6435 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6435 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future Currently the python script setup/bindir/cloud-setup-databases.in for setup databases uses template based parameters which will get replaced during rpm build. Along with this also enable new command line options to over ride those template based parameters if the same get passed as command line options. Accept the following options: 1. db-conf-path 2. db-files-path 3. encryption-jar-path 4. encryption-key-file Also replace code that calls OS specific commands with python specific libraries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6528) SetupGuestNetwork command is not deleting the guest network configured on the eth device
Rajesh Battala created CLOUDSTACK-6528: -- Summary: SetupGuestNetwork command is not deleting the guest network configured on the eth device Key: CLOUDSTACK-6528 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6528 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6498) [Automation] unable to start management server after restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982852#comment-13982852 ] Damodar Reddy T commented on CLOUDSTACK-6498: - Also with the commit 1d0b14673da2b877112a4030c17496e26cf3f531 on master the key file has to be on the classpath. This commit removed the hard coded key path /etc/cloudstack/management/key and loading it from the classpath. [Automation] unable to start management server after restart Key: CLOUDSTACK-6498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6498 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: advanced zone xenserer 6.2 Reporter: Srikanteswararao Talluri Assignee: Harikrishna Patnala Priority: Blocker Fix For: 4.5.0 Attachments: cloud.sql, log.tar.gz on the daily automation environment, After the zone is deployed , system VMs came up fine. After setting few global settings, I tried to restart management server, it never came up again. I could see some db exceptions related to duplicate keys. I will attach management server logs to this bug for your reference. Caught SQLException when inserting system account com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1' for key 'PRIMARY' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) 14761,2-9 96% -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5012) Bad data inserted into physical network labels for Zone Create Wizard using VMWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-5012: --- Assignee: Sateesh Chodapuneedi (was: Damodar Reddy T) Bad data inserted into physical network labels for Zone Create Wizard using VMWare -- Key: CLOUDSTACK-5012 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5012 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: Jim Leary Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.4.0 When using the Zone create wizard and choosing VMWare, the physical network labels contain additional data, rendering any attempt to create a VMWare cluster unsuccessful. The Zone wizard must be cancelled and the physical network labels corrected, then manually create the cluster, primary and secondary storage for the Zone to function correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5262) Few of the snapshot creation from ROOT volume fails when there are concurrent snapshots in progress.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-5262: --- Assignee: Anthony Xu (was: Harikrishna Patnala) Few of the snapshot creation from ROOT volume fails when there are concurrent snapshots in progress. - Key: CLOUDSTACK-5262 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5262 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 Reporter: Sangeetha Hariharan Assignee: Anthony Xu Priority: Critical Fix For: 4.4.0 Attachments: management-server.rar, xen1-2.rar, xen1.rar, xen2.rar Steps to reproduce the problem: Set up - Advanced zone with 2 Xenserver 6.2 hosts Deploy 10 Vms in each of the hosts , so we start with 20 Vms. We are constantly writing to the ROOT volume ( print timestamp every 1 minute). Start concurrent snapshots for ROOT volumes for all the Vms. Few of the snapshot jobs ( 4 of them) are failing due to the following exception: 2013-11-25 08:16:14,239 DEBUG [c.c.a.t.Request] (Job-Executor-165:ctx-bae63a1a ctx-4f637cc6) Seq 2-756819795: Sending { Cmd , MgmtId: 112516401760401, via: 2(Rack3Host23.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:ee56cec0-632d-469f-9326-d683e9fc1425,volume:{uuid:aee2805e-6394-47a6-9360-65829ce61929,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:babe1c7d-3154-3b46-addc-837ca2b7f07d,id:1,poolType:NetworkFilesystem,host:10.223.110.231,path:/export/home/sangeetha/felton/xen/primary,port:2049,url:NetworkFilesystem://10.223.110.231//export/home/sangeetha/felton/xen/primary/?ROLE=PrimarySTOREUUID=babe1c7d-3154-3b46-addc-837ca2b7f07d}},name:ROOT-73,size:21474836480,path:d1988b67-9f8f-4685-9bfd-a171238e8abd,volumeId:73,vmName:i-9-73-MyTestVM,accountId:9,format:VHD,id:73,deviceId:0,hypervisorType:XenServer},parentSnapshotPath:d3975b00-d9c3-418a-9a39-f09139754a32,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:babe1c7d-3154-3b46-addc-837ca2b7f07d,id:1,poolType:NetworkFilesystem,host:10.223.110.231,path:/export/home/sangeetha/felton/xen/primary,port:2049,url:NetworkFilesystem://10.223.110.231//export/home/sangeetha/felton/xen/primary/?ROLE=PrimarySTOREUUID=babe1c7d-3154-3b46-addc-837ca2b7f07d}},vmName:i-9-73-MyTestVM,name:TestVM-tiny-host-0ps-0-3_ROOT-73_20131125131535,hypervisorType:XenServer,id:296,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/9/73,volume:{uuid:aee2805e-6394-47a6-9360-65829ce61929,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:babe1c7d-3154-3b46-addc-837ca2b7f07d,id:1,poolType:NetworkFilesystem,host:10.223.110.231,path:/export/home/sangeetha/felton/xen/primary,port:2049,url:NetworkFilesystem://10.223.110.231//export/home/sangeetha/felton/xen/primary/?ROLE=PrimarySTOREUUID=babe1c7d-3154-3b46-addc-837ca2b7f07d}},name:ROOT-73,size:21474836480,path:d1988b67-9f8f-4685-9bfd-a171238e8abd,volumeId:73,vmName:i-9-73-MyTestVM,accountId:9,format:VHD,id:73,deviceId:0,hypervisorType:XenServer},parentSnapshotPath:snapshots/9/73/20ebe402-5c2f-4a61-a0c4-525d97ebfa71,dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.233:/export/home/sangeetha/felton/xen/secondary,_role:Image}},vmName:i-9-73-MyTestVM,name:TestVM-tiny-host-0ps-0-3_ROOT-73_20131125131535,hypervisorType:XenServer,id:296,quiescevm:false}},executeInSequence:false,wait:21600}}] } 2013-11-25 08:16:14,239 DEBUG [c.c.a.t.Request] (Job-Executor-165:ctx-bae63a1a ctx-4f637cc6) Seq 2-756819795: Executing: { Cmd , MgmtId: 112516401760401, via: 2(Rack3Host23.lab.vmops.com), Ver: v1, Flags: 100011,
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-6036: --- Assignee: (was: Koushik Das) CloudStack stops the machine for no reason --- Key: CLOUDSTACK-6036 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: ACS 4.2.1 after upgrade from 3.0.2 ACS 4.2.1 clean install XCP 1.1 Reporter: Tomasz Zieba Priority: Critical Fix For: 4.4.0 Attachments: management-server.log.2014-02-19.gz, management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error associated with self-stopping machine after changing the offering. Steps to reproduce: 1. Running instance of the machine 2. Stop with the operating system 3. Change offering of machine 4. Start the machine 5. Waiting for 10 minutes 6. CloudStack stops the machine for no reason 7. Restart the machine In the logs you can find information: 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request] (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId: 160544475005497, via: 50, Ver: v1, Flags: 10, [{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:2,_newStates:{i-41-824-VM:{t:f32a4fee-b64e-4868-9c52-2a27e32d4c0e,u:Running,v:viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4}},_isExecuted:false,result:true,wait:0}}] } 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = Running 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl] (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState = Running 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId: 160544475005497, via: 51, Ver: v1, Flags: 100111, [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}] } 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId: 160544475005497, via: 51, Ver: v1, Flags: 100111, [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:i-41-824-VM,wait:0}}] } 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state You will notice that the stop of the machine corresponds to the component HA-Worker. Such operation after the upgrade is complicating work of users. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6507) ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-6507. -- Resolution: Fixed ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand --- Key: CLOUDSTACK-6507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6507 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand. On the scripts that process these commands, should check the last sequence number stored in the bridge, only if the update is latest (i.e. sequence number in the command the last sequence number stored in hte bridge config). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6505) bridge gets reset for cluster level OVS network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-6505. -- Resolution: Fixed bridge gets reset for cluster level OVS network. Key: CLOUDSTACK-6505 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6505 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 This is regression introduced by below commit. commit faf52530cc9ff5827825eefe1c09b2887d0a0883 Author: Murali Reddy muralimmre...@gmail.com Date: Tue Apr 8 19:04:06 2014 +0530 CLOUDSTACK-6356: OVS: tunnel networks does not work across the XenServer clusers To make internal network work across the cluster, above fix introduced logic to plug/un-plug VIF in dom0 connected to OVS internal nework. this logic would ensure there is a bridge created on each host. But this logic should execute only once to created bridge. Currently its executing multiple times resulting in bridge to be recreated and hence loosing all the open flow rules. configured. Fix for this bug should ensure we only create bridge once on each for the OVS tunnel network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6431) [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-6431. -- Resolution: Fixed [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host - Key: CLOUDSTACK-6431 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6431 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 80d82106dcc701e9569dde16161b24ff3abfa67f Hypervisor: XenServer6.2 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.log.2014-04-15.gz [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host Steps to Reproduce: = 1.Bring up CS in advanced zone with GRE isolation using two hosts in the xenserver cluster 2.Create an isolated network using stretched-l2 service 3.Deploy few guest vms in the network and make sure that vms are spanned across the two hosts in the cluster 4.Make sure that GRE tunnels are created between these two hosts 5.Add another host to the cluster 6.Migrate one of the vms to the new host added to the cluster Expected Result: = GRE tunnel port should be created on the new host and should have tunnels between this new host and the exiting two hosts. Actual Result: tunnel ports were not created on the new host after vm migration. When we deployed another vm on the new host then only tunnel ports and interfaces with proper gre keys and remote_ips created for mesh topology creation from the new host to the remaining hosts in the cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6529) deployDatacCenter.py script fails when there is more than one host in a cluster.
Bharat kumar created CLOUDSTACK-6529: Summary: deployDatacCenter.py script fails when there is more than one host in a cluster. Key: CLOUDSTACK-6529 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6529 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Bharat kumar Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6271) Integrate Deploy DB Into windows msi installer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982924#comment-13982924 ] ASF subversion and git services commented on CLOUDSTACK-6271: - Commit 881792991ecbce5538939e2917cbf6582257ad43 in cloudstack's branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8817929 ] CLOUDSTACK-6271:[Windows] Integrating setup databases with msi installer for windows Signed-off-by: Abhinandan Prateek aprat...@apache.org Integrate Deploy DB Into windows msi installer -- Key: CLOUDSTACK-6271 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6271 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: 4.4.0 Currently MSI Installer assumes that the back end DB is already created. But going further deploy db should be part of installation instead of assumption. of existence -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5981) [Automation] Test case test_01_volume_from_snapshot failing while checking content
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982942#comment-13982942 ] Girish Shilamkar commented on CLOUDSTACK-5981: -- We need to change the template used to default Centos template. Not a testcase issue. [Automation] Test case test_01_volume_from_snapshot failing while checking content --- Key: CLOUDSTACK-5981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5981 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Fix For: 4.4.0 Below test case always failing in vmware integration.component.test_snapshots.TestSnapshots.test_01_volume_from_snapshot observed below error in log paramiko.transport: DEBUG: [chan 5] Max packet out: 32768 bytes paramiko.transport: INFO: Secsh channel 5 opened. paramiko.transport: DEBUG: [chan 5] Sesch channel 5 request ok paramiko.transport: DEBUG: [chan 5] EOF received (5) paramiko.transport: DEBUG: [chan 5] EOF sent (5) sshClient: DEBUG: {Cmd: cat /mnt/tmp/test/test2/random.data via Host: 10.223.243.36} {returns: ['cat: /mnt/tmp/test/test2/random.data: No such file or directory']} test_01_volume_from_snapshot (integration.component.test_snapshots.TestSnapshots): DEBUG: returned_data_0: cat: /mnt/tmp/test/test1/random.data: No such file or directory test_01_volume_from_snapshot (integration.component.test_snapshots.TestSnapshots): DEBUG: returned_data_1: cat: /mnt/tmp/test/test2/random.data: No such file or directory test_01_volume_from_snapshot (integration.component.test_snapshots.TestSnapshots): CRITICAL: FAILED: test_01_volume_from_snapshot: Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py, line 520, in test_01_volume_from_snapshot Verify newly attached volume contents with existing one File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) AssertionError: Verify newly attached volume contents with existing one - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py, line 520, in test_01_volume_from_snapshot Verify newly attached volume contents with existing one File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Verify newly attached volume contents with existing one begin captured logging test_05_snapshot_events (integration.component.test_snapshots.TestSnapshotEvents): DEBUG: sending GET request: deleteServiceOffering {'id': u'fb02efa2-7284-463a-9393-27564de948e4'} test_05_snapshot_events (integration.component.test_snapshots.TestSnapshotEvents): DEBUG: Computed Signature by Marvin: VIAVY2npT1ST2Jtu7ADQERxVxGQ= requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.223.49.197 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982960#comment-13982960 ] Daan Hoogland commented on CLOUDSTACK-6485: --- Solution method: on creation of a gateway network the vpc will be set to null, so it won't be used to recreate the nics on the vpc router. [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland reassigned CLOUDSTACK-6485: - Assignee: Daan Hoogland [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982964#comment-13982964 ] ASF subversion and git services commented on CLOUDSTACK-6485: - Commit 3bd594c584f34dff2ea69a942202f79b87d44698 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3bd594c ] CLOUDSTACK-6485: private gateway network should not be associated with vpc Signed-off-by: Daan Hoogland d...@onecht.net [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-4684) ceph:migration of volume from one storage to another is not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4684: -- Assignee: Wido den Hollander ceph:migration of volume from one storage to another is not working --- Key: CLOUDSTACK-4684 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4684 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.2.0 Reporter: sadhu suresh Assignee: Wido den Hollander Attachments: management-server.rar 1.create a disk offering based on RBD 2.create data disk and perform storage migration from one storage to another storage (RBD based) 3.add one more kvm cluster with RBD base dprimary storage 4.perform storage migratation from one storage pool to another storage pool exists in another cluser actual results: in both cases volume migration is failing , 2013-09-17 04:42:17,606 WARN [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Unsupported data object (VOLUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@2a3d0fc1), no need to delete from object in store ref table 2013-09-17 04:42:17,726 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100011, [{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:ea77aa58-9368-411f-8df6-8d940cd9de54,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:59b50b13-75b2-3385-87c7-a452d56e2ee0,id:3,poolType:RBD,host:10.147.41.3,path:sadhu22,port:6789}},name:ggg,size:5368709120,path:c4cafbe0-8e09-486c-8d35-f94c189d0fa7,volumeId:30,accountId:2,format:QCOW2,id:30,hypervisorType:KVM}},wait:0}}] } 2013-09-17 04:42:17,880 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Processing Seq 2-49564: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n \connections\: []\n},wait:0}}] } 2013-09-17 04:42:17,890 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Sending Seq 2-49564: { Ans: , MgmtId: 7175246184473, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-09-17 04:42:17,904 DEBUG [agent.transport.Request] (AgentManager-Handler-11:null) Seq 1-308895640: Processing: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, [{com.cloud.agent.api.Answer:{result:true,wait:0}}] } 2013-09-17 04:42:17,905 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, { Answer } } 2013-09-17 04:42:17,917 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Volume 30 is not referred anywhere, remove it from volumes table 2013-09-17 04:42:17,925 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) migrate volume failed:com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 2013-09-17 04:42:17,925 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Failed to migrate volume: com.cloud.exception.StorageUnavailableException: Resource [StoragePool:3] is unreachable: migrate volume failed: com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2238) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd.execute(MigrateVolumeCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at
[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982976#comment-13982976 ] ASF subversion and git services commented on CLOUDSTACK-6485: - Commit 69add34ad0f07674f5ed560ef708b706e038a3dd in cloudstack's branch refs/heads/4.4-forward from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=69add34 ] CLOUDSTACK-6485: private gateway network should not be associated with vpc Signed-off-by: Daan Hoogland d...@onecht.net [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-4684) ceph:migration of volume from one storage to another is not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-4684. Resolution: Cannot Reproduce Leaving it to Cannot Reproduce for now since it worked fine on my 4.3 setup. ceph:migration of volume from one storage to another is not working --- Key: CLOUDSTACK-4684 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4684 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.2.0 Reporter: sadhu suresh Assignee: Wido den Hollander Attachments: management-server.rar 1.create a disk offering based on RBD 2.create data disk and perform storage migration from one storage to another storage (RBD based) 3.add one more kvm cluster with RBD base dprimary storage 4.perform storage migratation from one storage pool to another storage pool exists in another cluser actual results: in both cases volume migration is failing , 2013-09-17 04:42:17,606 WARN [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Unsupported data object (VOLUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@2a3d0fc1), no need to delete from object in store ref table 2013-09-17 04:42:17,726 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100011, [{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:ea77aa58-9368-411f-8df6-8d940cd9de54,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:59b50b13-75b2-3385-87c7-a452d56e2ee0,id:3,poolType:RBD,host:10.147.41.3,path:sadhu22,port:6789}},name:ggg,size:5368709120,path:c4cafbe0-8e09-486c-8d35-f94c189d0fa7,volumeId:30,accountId:2,format:QCOW2,id:30,hypervisorType:KVM}},wait:0}}] } 2013-09-17 04:42:17,880 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Processing Seq 2-49564: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n \connections\: []\n},wait:0}}] } 2013-09-17 04:42:17,890 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Sending Seq 2-49564: { Ans: , MgmtId: 7175246184473, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-09-17 04:42:17,904 DEBUG [agent.transport.Request] (AgentManager-Handler-11:null) Seq 1-308895640: Processing: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, [{com.cloud.agent.api.Answer:{result:true,wait:0}}] } 2013-09-17 04:42:17,905 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, { Answer } } 2013-09-17 04:42:17,917 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Volume 30 is not referred anywhere, remove it from volumes table 2013-09-17 04:42:17,925 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) migrate volume failed:com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 2013-09-17 04:42:17,925 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Failed to migrate volume: com.cloud.exception.StorageUnavailableException: Resource [StoragePool:3] is unreachable: migrate volume failed: com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2238) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd.execute(MigrateVolumeCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at
[jira] [Commented] (CLOUDSTACK-4684) ceph:migration of volume from one storage to another is not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982980#comment-13982980 ] Wido den Hollander commented on CLOUDSTACK-4684: I tested this with CloudStack 4.3 and migration is working for me: 1. Created data disk on NFS 2. Migrated to RBD from NFS 3. Migrated from RBD to RBD All 3 steps worked just fine. The disk moved from all Primary Storages. I think this was resolved by some other fixes I made and backported into the 4.3 and 4.4 branch. For now I'm resolving this one. If it comes up again, please re-open. ceph:migration of volume from one storage to another is not working --- Key: CLOUDSTACK-4684 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4684 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.2.0 Reporter: sadhu suresh Assignee: Wido den Hollander Attachments: management-server.rar 1.create a disk offering based on RBD 2.create data disk and perform storage migration from one storage to another storage (RBD based) 3.add one more kvm cluster with RBD base dprimary storage 4.perform storage migratation from one storage pool to another storage pool exists in another cluser actual results: in both cases volume migration is failing , 2013-09-17 04:42:17,606 WARN [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Unsupported data object (VOLUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@2a3d0fc1), no need to delete from object in store ref table 2013-09-17 04:42:17,726 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100011, [{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:ea77aa58-9368-411f-8df6-8d940cd9de54,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:59b50b13-75b2-3385-87c7-a452d56e2ee0,id:3,poolType:RBD,host:10.147.41.3,path:sadhu22,port:6789}},name:ggg,size:5368709120,path:c4cafbe0-8e09-486c-8d35-f94c189d0fa7,volumeId:30,accountId:2,format:QCOW2,id:30,hypervisorType:KVM}},wait:0}}] } 2013-09-17 04:42:17,880 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Processing Seq 2-49564: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n \connections\: []\n},wait:0}}] } 2013-09-17 04:42:17,890 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 2-49564: Sending Seq 2-49564: { Ans: , MgmtId: 7175246184473, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-09-17 04:42:17,904 DEBUG [agent.transport.Request] (AgentManager-Handler-11:null) Seq 1-308895640: Processing: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, [{com.cloud.agent.api.Answer:{result:true,wait:0}}] } 2013-09-17 04:42:17,905 DEBUG [agent.transport.Request] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Seq 1-308895640: Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10, { Answer } } 2013-09-17 04:42:17,917 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Volume 30 is not referred anywhere, remove it from volumes table 2013-09-17 04:42:17,925 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) migrate volume failed:com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 2013-09-17 04:42:17,925 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-78:job-86 = [ 3a080033-dafe-43a8-a93d-d3e53036b43c ]) Failed to migrate volume: com.cloud.exception.StorageUnavailableException: Resource [StoragePool:3] is unreachable: migrate volume failed: com.cloud.utils.exception.CloudRuntimeException: Failed to copy sadhu1/c4cafbe0-8e09-486c-8d35-f94c189d0fa7 to 70e45ca3-fc28-4978-adb2-188dad981da3.qcow2 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2238) at
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982977#comment-13982977 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 4f1f182cba5579da2fc7ce1f02019a0afa00efeb in cloudstack's branch refs/heads/4.4-automation from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4f1f182 ] CLOUDSTACK-5674:Fixed pep8 errors in python files in marvin folder Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation]: Enhancements to accommodate multiple regression runs on a single CS server Key: CLOUDSTACK-5674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, we will not be able to run multiple regression runs on a given CS server either sequentially\parallelly reason being few hard codings done at various places. 2. So, the idea is to run complete regression\automation test suites at one stretch on a given setup post deployDC. We deploy multiple zones with different hypervisor type in each zone. 3. Tests should cut down time and run across multiple zones with different hypervisor type in each zone, post deployment 3. The fixes and new changes should incorporate to take care to run suites parallelly if we wanted or sequentially for various test suites like vmware,xen,kvm etc on single CS machine without disturbing\redeploying and installing the new CS instance. Phase1: We will make framework\marvin changes. Phase2: Incorporate test module changes for these. Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6480) Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982984#comment-13982984 ] ASF subversion and git services commented on CLOUDSTACK-6480: - Commit b9c136d9aa938145ff2dafd2edd115a13fb98dc0 in cloudstack's branch refs/heads/4.4 from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b9c136d ] CLOUDSTACK-6480: Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly. Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly Key: CLOUDSTACK-6480 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6480 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Sanjay Tripathi Fix For: 4.4.0 While creating SO with Implicit Dedication planner in Strict/Preferred Mode fails with log message Please specify the pciDevice and vgpuType correctly. Ideally SO should be created without specifying pciDevice abd vgpuType. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982985#comment-13982985 ] ASF subversion and git services commented on CLOUDSTACK-6485: - Commit 90600f1bdff34fcdac1adefe076d72766dc1c556 in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=90600f1 ] CLOUDSTACK-6485: private gateway network should not be associated with vpc Signed-off-by: Daan Hoogland d...@onecht.net [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-6485. --- Resolution: Fixed [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983004#comment-13983004 ] ASF subversion and git services commented on CLOUDSTACK-6485: - Commit c37df38c834a7cfc075228c697fc6d358a70f574 in cloudstack's branch refs/heads/4.3 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c37df38 ] CLOUDSTACK-6485: private gateway network should not be associated with vpc Signed-off-by: Daan Hoogland d...@onecht.net [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6255) UI for supporting region level VPC, distributed routing enabled VPC and stretched L2 neworks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983188#comment-13983188 ] ASF subversion and git services commented on CLOUDSTACK-6255: - Commit b6fabfecf28b33feafcc1beaac44bc550386e737 in cloudstack's branch refs/heads/4.4 from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b6fabfe ] CLOUDSTACK-6255 UI for supporting region level VPC, distributed routing enabled VPC and stretched L2 neworks UI for supporting region level VPC, distributed routing enabled VPC and stretched L2 neworks Key: CLOUDSTACK-6255 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6255 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Gabor Apati-Nagy Fix For: 4.4.0 UI for supporting region level VPC, distributed routing enabled VPC and stretched L2 neworks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6453) [GPU] Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983234#comment-13983234 ] Ram Ganesh commented on CLOUDSTACK-6453: a specific scenario is not working so not sure if we should still flag it as blocker. Sailaja : Can you confirm? [GPU] Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers -- Key: CLOUDSTACK-6453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6453 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Sanjay Tripathi Priority: Blocker Fix For: 4.4.0 Attachments: SMlog, gpulogs.zip Steps: 1. Install and Configure Adv zone using Xen 6.2.5 which has GRID K2 2. Create Service Offering using K2 - K200 profile of vGPU 3. Deploy windows 2012 instance with ISO using K200 vGPU profile offering 4. Install Windows 2012 instance and install PV drivers 5. During PV driver installation Windows 2012 server went for reboot. Observation: 1. After reboot, Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers 2. It remained in stopped state. 3. Tried to start instance manually , Cloudstack says Instance started and instance moved to running state. But XenServer failed to start the instance. 4. Later Cloudstack also marked the instance in stopped state. Attached detailed logs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6295) Management server cannot start because Java 7 missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983238#comment-13983238 ] Ram Ganesh commented on CLOUDSTACK-6295: Paul is your observation same as CLOUDSTACK-6351? Management server cannot start because Java 7 missing - Key: CLOUDSTACK-6295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: centos 6.5 Reporter: Paul Angus Priority: Blocker Management server cannot start because java 7 is not installed. Java 7 package dependency needs to be added into installation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5382) Random failure when trying to deploy an instance from a template which is available across zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-5382. - Resolution: Fixed Random failure when trying to deploy an instance from a template which is available across zones Key: CLOUDSTACK-5382 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5382 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Reporter: Kirk Kosinski Assignee: Daan Hoogland When trying to deploy an instance from a template which is available across zones, CloudStack randomly selects the wrong secondary storage. Selection happens by a random method from the available secondary storages which belong to multiple zones. 2013-11-13 10:29:05,402 TRACE [db.Transaction.Statement] (Job-Executor-102:job-2102 = [ 29ea7d9b-ddc6-49eb-af54-689d5c002a8d ]) Closing: com.mysql.jdbc.JDBC4PreparedStatement@5080267f: SELECT template_store_ref.id, template_store_ref.store_id, template_store_ref.template_id, template_store_ref.store_role, template_store_ref.created, template_store_ref.last_updated, template_store_ref.download_pct, template_store_ref.size, template_store_ref.physical_size, template_store_ref.download_state, template_store_ref.local_path, template_store_ref.error_str, template_store_ref.job_id, template_store_ref.install_path, template_store_ref.url, template_store_ref.download_url, template_store_ref.download_url_created, template_store_ref.is_copy, template_store_ref.destroyed, template_store_ref.update_count, template_store_ref.updated, template_store_ref.state, template_store_ref.ref_cnt FROM template_store_ref WHERE template_store_ref.template_id = 211 AND template_store_ref.store_role = 'Image' AND template_store_ref.destroyed = 0 ORDER BY RAND() LIMIT 1 For example, for template 211, attempts were made to access it from the wrong secondary storage share three times before the correct secondary storage was used. The issue is a DB query with WHERE template_store_ref.template_id = 211 AND template_store_ref.store_role = 'Image' AND template_store_ref.destroyed = 0 ORDER BY RAND() LIMIT 1 This results in a random image_store.id but not necessarily one in the correct zone. 20:22:45,183 INFO VmwareStorageProcessor:217 - Template 68dd65a2-ab83-3c49-8b9d-b54cd972c88e is not setup yet, setup template from secondary storage with uuid name: 46f1e17908053d9a8615e5c64ecc3811 20:22:45,214 INFO VmwareStorageProcessor:130 - Executing copyTemplateFromSecondaryToPrimary. secondaryStorage: nfs://nfshost/path/to/share, templatePathAtSecondaryStorage: template/tmpl/9/211/, templateName: 68dd65a2-ab83-3c49-8b9d-b54cd972c88e 20:22:45,535 WARN NfsSecondaryStorageResource:2225 - Unable to mount 10.x.x.x:/path/to/share due to mount.nfs: access denied by server while mounting 10.x.x.x:/path/to/share 20:22:45,535 INFO VmwareStorageProcessor:135 - Secondary storage mount point: /mnt/SecStorage/6cd05351-e52d-3c98-8cd8-ace877ed7518 20:22:45,535 INFO VmwareStorageProcessor:147 - Executing command: tar --no-same-owner -xf /mnt/SecStorage/6cd05351-e52d-3c98-8cd8-ace877ed7518/template/tmpl/9/211//68dd65a2-ab83-3c49-8b9d-b54cd972c88e.ova 20:22:45,541 WARN VmwareStorageProcessor:267 - Exception: tar --no-same-owner -xf /mnt/SecStorage/6cd05351-e52d-3c98-8cd8-ace877ed7518/template/tmpl/9/211//68dd65a2-ab83-3c49-8b9d-b54cd972c88e.ova java.io.IOException: Cannot run program tar (in directory /mnt/SecStorage/6cd05351-e52d-3c98-8cd8-ace877ed7518/template/tmpl/9/211): java.io.IOException: error=2, No such file or directory -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6024) template copy to primary storage uses a random source secstorage from any zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6024. - template copy to primary storage uses a random source secstorage from any zone -- Key: CLOUDSTACK-6024 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6024 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1, 4.1.2, 4.4.0 Environment: Multiple zones where the secstorage of a zone is not accessible to hosts from the other zone. Reporter: Joris van Lieshout Assignee: Daan Hoogland Priority: Blocker Fix For: 4.3.0, 4.4.0 2014-02-04 15:19:07,674 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Checking if we need to prepare 1 volumes for VM[User|xx-app01] 2014-02-04 15:19:07,693 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) template 467 is already in store:117, type:Image // store 117 is not accessible from the zone where this hypervisor lives 2014-02-04 15:19:07,705 DEBUG [storage.datastore.PrimaryDataStoreImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Not found (templateId:467poolId:208) in template_spool_ref, persisting it 2014-02-04 15:19:07,718 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) template 467 is already in store:208, type:Primary 2014-02-04 15:19:07,722 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Found template 467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938 in storage pool 208 with VMTemplateStoragePool id: 36433 2014-02-04 15:19:07,732 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Acquire lock on VMTemplateStoragePool 36433 with timeout 3600 seconds 2014-02-04 15:19:07,737 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) lock is acquired for VMTemplateStoragePool 36433 2014-02-04 15:19:07,748 DEBUG [storage.motion.AncientDataMotionStrategy] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE 2014-02-04 15:19:07,775 DEBUG [agent.manager.ClusteredAgentAttache] (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Seq 93-1862347354: Forwarding Seq 93-1862347354: { Cmd , MgmtId: 345052370018, via: 93, Ver: v1, Flags: 100111, [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/467/c263eb76-3d72-3732-8cc6-42b0dad55c4d.vhd,origUrl:http://x.x.com/image/centos64x64-daily-v1b104.vhd,uuid:ca5e3f26-e9b6-41c8-a85b-df900be5673c,id:467,format:VHD,accountId:2,checksum:604a8327bd83850ed621ace2ea84402a,hvm:true,displayText:centos template created by hans.pl from machine name centos-daily-b104,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://.storage..xx.xxx/volumes/pool0/--1-1,_role:Image}},name:467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938,hypervisorType:XenServer}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://xx.xx.com/image/centos64x64-daily-v1b104.vhd,uuid:ca5e3f26-e9b6-41c8-a85b-df900be5673c,id:467,format:VHD,accountId:2,checksum:604a8327bd83850ed621ace2ea84402a,hvm:true,displayText:centos template created by hans.pl from machine name centos-daily-b104,imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:b290385b-466d-3243-a939-3d242164e034,id:208,poolType:NetworkFilesystem,host:..x.net,path:/volumes/pool0/xx-XEN-1,port:2049}},name:467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938,hypervisorType:XenServer}},executeInSequence:true,wait:10800}}] } to 345052370017 ===FILE: server/src/com/cloud/storage/VolumeManagerImpl.java public void prepare(VirtualMachineProfile? extends VirtualMachine vm, DeployDestination dest) throws StorageUnavailableException, InsufficientStorageCapacityException, ConcurrentOperationException { if (dest == null) { if (s_logger.isDebugEnabled()) { s_logger.debug(DeployDestination cannot be null, cannot prepare Volumes for the vm: + vm); } throw new CloudRuntimeException( Unable to prepare Volume for vm because DeployDestination is null, vm:
[jira] [Resolved] (CLOUDSTACK-6480) Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-6480. - Resolution: Fixed Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly Key: CLOUDSTACK-6480 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6480 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Sanjay Tripathi Fix For: 4.4.0 While creating SO with Implicit Dedication planner in Strict/Preferred Mode fails with log message Please specify the pciDevice and vgpuType correctly. Ideally SO should be created without specifying pciDevice abd vgpuType. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6501) IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983357#comment-13983357 ] ASF subversion and git services commented on CLOUDSTACK-6501: - Commit 6af1a2919bfd91cdc722a400d926b7c25fc76200 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6af1a29 ] CLOUDSTACK-6501:IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed. IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed. -- Key: CLOUDSTACK-6501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account is not listed. Steps to reproduce the problem: Set up: Pre Reqs: Admin - Creates object Domain Admin for d1 - D1 - Creates object - d1 Domain Admin for d1 - D1/D11 User account for d1 - D1/D111 - Creates object - d111a Domain Admin for d1 - D1/D12 Domain Admin for d2 - D2 - Creates object -d2 User Account in domain D1 - userD1-1 - Creates object -d1a User Account in domain D1 - userD1-2 - Creates object - d1b Domain Account in domain D1/D11 - D11 - Creates object - d11 User Account in domain D1/D11 - userD1-a - Creates object - d11a User Account in domain D1/D11 - userD1-a - Creates object - d11b User Account in domain D1/D12- userD1-b - Creates object - d12a User Account in domain D1/D12 - userD-a - Creates object - d12b As domain admin account D1 , try to list all the Vms for d11 (domain admin user) using account and domainId parameters. Expected Result: Vm owned by the account that is passed in account/domainId parameter. Actual Result: Empty set is returned. GET http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=0e8d9d60-c39a-4304-b048-1e63500d0d30account=testD11listAll=trueisrecursive=trueapiKey=bW1FEJkIERji0cWRNQqvmWOgOINjMeBggyoPsMjN9_Qnvq-QtC6L4ORqmbdfQ-XtUYQdSoJIniZrHK3_oi9pcQsignature=5qLgaWzslWKSz%2FXbVSK0zdj%2B49I%3D \n\n current Time: Thu Apr 24 14:43:18 PDT 2014 ?xml version=1.0 encoding=UTF-8?listvirtualmachinesresponse cloud-stack-version=4.4.0-SNAPSHOT/listvirtualmachinesresponseConnection to 10.223.49.6 8080 port [tcp/webcache] succeeded! Response Time(in secs) : 0 current Time: Thu Apr 24 14:43:18 PDT 2014 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6349) IAM - No error message presented to the user , when invalid password is provided.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983356#comment-13983356 ] ASF subversion and git services commented on CLOUDSTACK-6349: - Commit 9514c9e0455d69988b1cd2f79d0b276fc1ebcc04 in cloudstack's branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9514c9e ] CLOUDSTACK-6349: IAM - No error message presented to the user , when invalid password is provided. - AccountManager now works using accountId instead of accountType in following methods too: - isResourceDomainAdmin() - isAdmin() IAM - No error message presented to the user , when invalid password is provided. - Key: CLOUDSTACK-6349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6349 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Assignee: Prachi Damle Priority: Critical Fix For: 4.4.0 Try to log in as regular user , by providing invalid username/password. User is not presented with any error message: apilog.log: 2014-04-07 10:51:15,849 INFO [a.c.c.a.ApiServer] (catalina-exec-6:ctx-5511ac44) 10.215.3.0 -- POST command=login domain=/ unknown exception writing api response Management server log: 2014-04-07 10:47:28,001 DEBUG [c.c.a.ApiServlet] (catalina-exec-3:ctx-845578ba) ===START=== 10.215.3.0 -- POST 2014-04-07 10:47:28,003 DEBUG [c.c.u.AccountManagerImpl] (catalina-exec-3:ctx-845578ba) Attempting to log in user: test in domain 1 2014-04-07 10:47:28,003 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,005 DEBUG [c.c.s.a.MD5UserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,009 DEBUG [c.c.s.a.MD5UserAuthenticator] (catalina-exec-3:ctx-845578ba) Password does not match 2014-04-07 10:47:28,012 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,016 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (catalina-exec-3:ctx-845578ba) Password does not match 2014-04-07 10:47:28,016 DEBUG [c.c.u.AccountManagerImpl] (catalina-exec-3:ctx-845578ba) Unable to authenticate user with username test in domain 1 2014-04-07 10:47:28,019 ERROR [c.c.a.ApiServlet] (catalina-exec-3:ctx-845578ba) unknown exception writing api response com.cloud.exception.InvalidParameterValueException: Caller cannot be passed as NULL to IAM! at org.apache.cloudstack.iam.RoleBasedEntityAccessChecker.checkAccess(RoleBasedEntityAccessChecker.java:67) at com.cloud.user.AccountManagerImpl.isRootAdmin(AccountManagerImpl.java:371) at com.cloud.user.AccountManagerImpl.isInternalAccount(AccountManagerImpl.java:420) at com.cloud.user.AccountManagerImpl.getUserAccount(AccountManagerImpl.java:2045) at com.cloud.user.AccountManagerImpl.authenticateUser(AccountManagerImpl.java:1871) 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.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 $Proxy99.authenticateUser(Unknown Source) at com.cloud.api.ApiServer.loginUser(ApiServer.java:850) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:231) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at
[jira] [Commented] (CLOUDSTACK-6502) IAMGroup.list and IAMPolicy.list in marvin base.py are not working.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983358#comment-13983358 ] ASF subversion and git services commented on CLOUDSTACK-6502: - Commit 96af7396b6ea5da560975807b1c50d78ef875b79 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96af739 ] CLOUDSTACK-6502:IAMGroup.list and IAMPolicy.list in marvin base.py are not working. IAMGroup.list and IAMPolicy.list in marvin base.py are not working. --- Key: CLOUDSTACK-6502 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6502 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAMGroup.list and IAMPolicy.list in marvin base.py library have typo bugs, which blocks folks from writing IAM group and policy list related automation test. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6513) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983360#comment-13983360 ] ASF subversion and git services commented on CLOUDSTACK-6513: - Commit 44ff7fea5f10dc6e979d482cc4a6d22fdfd1a5f0 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=44ff7fe ] CLOUDSTACK-6513: IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. This commit reverts listTemplates behavior to 4.3 old logic without using consistent interpretation of list parameters adopted in new IAM model. IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. --- Key: CLOUDSTACK-6513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6513 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. Steps to reproduce the problem: As user1 , Create a private template and a public template. Grant access to the private template for user2 using updateTemplatePermissions. As user2 , list templates with templatefilter=shared. This returns both public and the the shared template. GET http://10.223.49.6/client/api?command=listTemplatespagesize=100page=1listAll=truetemplatefilter=sharedapiKey=SrgUY-U-nUl4qsOyn409kCjA2jC7dR5ReIV9SjdnmzLOn3c0Fm-vZbDSpkldUjuqLAXt5ShodtXYOgRB5NCnJQsignature=WBO8ll9nyjiB29aVq%2FpUsEQrthM%3D \n\n ?xml version=1.0 encoding=UTF-8?listtemplatesresponse cloud-stack-version=4.4.0-SNAPSHOTcount6/counttemplateida2065bcc-7139-46b0-ac15-db7d3ff7dd75/idnamePublic_featured_d1a-TP7TPK/namedisplaytextpublic and feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateidce1635dc-1fcb-4f60-8d2f-d1129a3771ce/idnamePublic_not_featured_d2a-NPYFSN/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD2/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD2/domaindomainid18222e53-7221-4d6f-9a76-8f59869f24b2/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateid223e0c09-e18e-4188-9d8e-7ff2e2305547/idnamePrivate_featured_d1-E9PQHO/namedisplaytextprivate and featured Template/displaytextispublicfalse/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateida7b69a5e-4cb3-45fa-b3e7-dab3a6b73e45/idnamePublic_not_featured_d1a-XOCR05/namedisplaytextpublic and not feature
[jira] [Commented] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983359#comment-13983359 ] ASF subversion and git services commented on CLOUDSTACK-6512: - Commit 3e4151e13e1e2e8ae9b9593260cd136403230358 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3e4151e ] CLOUDSTACK-6512:IAM - Not able to list shared networks in the Vm deployment flow. This commit is to revert ec5ee761d98c67c7da2ea70b623d4a9f3da966b5 to still use old logic for listNetworks to keep old behavior instead of new IAM model. IAM - Not able to list shared networks in the Vm deployment flow. - Key: CLOUDSTACK-6512 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Not able to list shared networks in the Vm deployment flow. Steps to reproduce the problem: Create a shared network that is domain specific / account specific. Log in as the account which should have access to this shared network. Using UI , try to deploy a VM using this shared network. shared network is not displayed in the list of networks. This is the call made by UI: http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911 When Networks are listed using the network tab , then we see the shared network being listed. Following API call without the domainid and account paramater is able to return the shared network. http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6439) [Automation] Two Test Cases failed on test_disk_offerings.py - provision type is not returned by listDiskOfferings response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6439. -- Resolution: Invalid [Automation] Two Test Cases failed on test_disk_offerings.py - provision type is not returned by listDiskOfferings response - Key: CLOUDSTACK-6439 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6439 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, IAM Affects Versions: 4.4.0 Environment: Basic Zone XenServer Reporter: Chandan Purushothama Assignee: Min Chen Priority: Blocker Fix For: 4.4.0 Two Cases failed: 1. test_02_create_sparse_type_disk_offering 2. test_04_create_fat_type_disk_offering = Assertion Errors: = *Assertion Error 1* Check provisionig type in createServiceOffering begin captured logging test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: STARTED : TC: test_02_create_sparse_type_disk_offering ::: test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: sending GET request: createDiskOffering {'name': 'Sparse Type Disk offering', 'disksize': 1, 'displaytext': 'Sparse Type Disk offering'} test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Computed Signature by Marvin: m0/TZdrSBwiGRHLEVS5pdjF/y0U= requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.223.240.161 requests.packages.urllib3.connectionpool: DEBUG: GET /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json HTTP/1.1 200 297 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Request: http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json Response: { creatediskofferingresponse : { diskoffering : {id:ffece54d-6736-4d72-8426-6eeade833db8,name:Sparse Type Disk offering,displaytext:Sparse Type Disk offering,disksize:1,created:2014-04-16T15:52:37-0700,iscustomized:false,storagetype:shared,displayoffering:true} } } test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Created Disk offering with ID: ffece54d-6736-4d72-8426-6eeade833db8 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: sending GET request: listDiskOfferings {'id': u'ffece54d-6736-4d72-8426-6eeade833db8'} test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Computed Signature by Marvin: XtzgOFFqAn/1FdLA2F+/yDvHKbQ= requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.223.240.161 requests.packages.urllib3.connectionpool: DEBUG: GET /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json HTTP/1.1 200 310 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Request: http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json Response: { listdiskofferingsresponse : { count:1 ,diskoffering : [ {id:ffece54d-6736-4d72-8426-6eeade833db8,name:Sparse Type Disk offering,displaytext:Sparse Type Disk offering,disksize:1,created:2014-04-16T15:52:37-0700,iscustomized:false,storagetype:shared,displayoffering:true} ] } } test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): CRITICAL: FAILED: test_02_create_sparse_type_disk_offering: Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 327, in run
[jira] [Commented] (CLOUDSTACK-6439) [Automation] Two Test Cases failed on test_disk_offerings.py - provision type is not returned by listDiskOfferings response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983377#comment-13983377 ] Min Chen commented on CLOUDSTACK-6439: -- Our automation setup has issue. If you look at the test_disk_offerings.py file in 4.4 branch, you will see that there is no such a testcase test_02_create_sparse_type_disk_offering at all. This testcase is only added in master branch, also provisioning type is also added by Marcus to master branch with commit 11f5bdd78de4121331b07995800f6e9e7c22f2c0. So we are basically running 4.4 branch source code against 4.5 testcases, this will for sure fail. This is not related to IAM change at all. [Automation] Two Test Cases failed on test_disk_offerings.py - provision type is not returned by listDiskOfferings response - Key: CLOUDSTACK-6439 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6439 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, IAM Affects Versions: 4.4.0 Environment: Basic Zone XenServer Reporter: Chandan Purushothama Assignee: Min Chen Priority: Blocker Fix For: 4.4.0 Two Cases failed: 1. test_02_create_sparse_type_disk_offering 2. test_04_create_fat_type_disk_offering = Assertion Errors: = *Assertion Error 1* Check provisionig type in createServiceOffering begin captured logging test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: STARTED : TC: test_02_create_sparse_type_disk_offering ::: test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: sending GET request: createDiskOffering {'name': 'Sparse Type Disk offering', 'disksize': 1, 'displaytext': 'Sparse Type Disk offering'} test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Computed Signature by Marvin: m0/TZdrSBwiGRHLEVS5pdjF/y0U= requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.223.240.161 requests.packages.urllib3.connectionpool: DEBUG: GET /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json HTTP/1.1 200 297 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Request: http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json Response: { creatediskofferingresponse : { diskoffering : {id:ffece54d-6736-4d72-8426-6eeade833db8,name:Sparse Type Disk offering,displaytext:Sparse Type Disk offering,disksize:1,created:2014-04-16T15:52:37-0700,iscustomized:false,storagetype:shared,displayoffering:true} } } test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Created Disk offering with ID: ffece54d-6736-4d72-8426-6eeade833db8 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: sending GET request: listDiskOfferings {'id': u'ffece54d-6736-4d72-8426-6eeade833db8'} test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Computed Signature by Marvin: XtzgOFFqAn/1FdLA2F+/yDvHKbQ= requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.223.240.161 requests.packages.urllib3.connectionpool: DEBUG: GET /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json HTTP/1.1 200 310 test_02_create_sparse_type_disk_offering (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: Request: http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json Response: { listdiskofferingsresponse : { count:1
[jira] [Closed] (CLOUDSTACK-4652) ceph:UI:Noticed 2 records for same volume after migrating instance from one primary to another primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-4652. -- Resolution: Fixed Fix Version/s: 4.3.1 4.4.0 This was related to the old RBD volume not being deleted. This has been fixed in the 4.3 branch and will be in 4.3.1 and will also be in 4.4 ceph:UI:Noticed 2 records for same volume after migrating instance from one primary to another primary -- Key: CLOUDSTACK-4652 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4652 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: sadhu suresh Assignee: Wido den Hollander Fix For: 4.4.0, 4.3.1 1.deploy advanced zone with kvm cluster(single cluster with ubuntu host+nfs as primary storage) 2.add RBD based primary storage 3.create compute offering and create a instance using this offering 4.stop the running VM which was created in step 3 5.perform migrate instance from one primary to another primary Actual result: migrate instance successful but UI shows 2 records for same Volume(newly created one and expunged one).it looks like volume was successfuly copied from primary1 to secondary and secondary to primary2 .once its copied to primry2 successfully and it tries to delete the volume exits in primary1 and its fail to delete the object.due to this reason it shows 2 records for same volume. [root@cen62307 ~]# grep -i job-21 /var/log/cloudstack/management/management-server.log 2013-09-12 19:54:55,954 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-21:null) submit async job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ], details: AsyncJobVO {id:21, userId: 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null, cmdInfo: {response:json,sessionkey:W/+BolWn+DoUEK1P92X71fVmknc\u003d,virtualmachineid:42c31b97-d376-4e04-b6c3-08cecda7c13f,cmdEventType:VM.MIGRATE,ctxUserId:2,storageid:59b50b13-75b2-3385-87c7-a452d56e2ee0,httpmethod:GET,_:1378976549445,ctxAccountId:2,ctxStartEventId:133}, cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processStatus: 0, resultCode: 0, result: null, initMsid: 7175246184473, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2013-09-12 19:54:56,290 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ] 2013-09-12 19:54:56,332 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) VM state transitted from :Stopped to Migrating with event: StorageMigrationRequestedvm's original host id: 1 new host id: null host id before state transition: null 2013-09-12 19:54:56,860 DEBUG [storage.motion.AncientDataMotionStrategy] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) copyAsync inspecting src type VOLUME copyAsync inspecting dest type VOLUME 2013-09-12 19:54:56,957 DEBUG [cache.allocator.StorageCacheRandomAllocator] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Can't find staging storage in zone: 1 2013-09-12 19:54:57,691 DEBUG [agent.transport.Request] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Seq 1-1872036399: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100111, [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1b5f2f3e-6b11-43aa-9d18-aa02d7e00aa1,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:2c19704e-55d4-31aa-b0e7-a52f1fffab9e,id:2,poolType:RBD,host:10.147.41.3,path:sadhu1,port:6789}},name:ROOT-7,size:8589934592,path:48d50558-02f0-48d3-839f-bc73d119d190,volumeId:8,vmName:i-2-7-VM,accountId:2,format:RAW,id:8,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1b5f2f3e-6b11-43aa-9d18-aa02d7e00aa1,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/sadhu/asf/kvmsec,_role:Image}},name:ROOT-7,size:8589934592,path:volumes/2/8,volumeId:8,vmName:i-2-7-VM,accountId:2,format:RAW,id:8,hypervisorType:KVM}},executeInSequence:true,wait:10800}}] } 2013-09-12 20:02:03,636 DEBUG [agent.transport.Request] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Seq 1-1872036399: Received: { Ans: , MgmtId:
[jira] [Assigned] (CLOUDSTACK-4657) ceph:fail to attach a volume to instance which is migrated from one primary to another primary.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4657: -- Assignee: Wido den Hollander ceph:fail to attach a volume to instance which is migrated from one primary to another primary. Key: CLOUDSTACK-4657 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4657 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Reporter: sadhu suresh Assignee: Wido den Hollander fail to attach a data volume to instance after migrating instance from one primary to another primary. due to problem specified in the issue #CLOUDSTACK-4652. 2.add RBD based primary storage 3.create compute offering and create a instance using this offering 4.stop the running VM which was created in step 3 5.perform migrate instance from one primary to another primary 6.create a data volume and try to attach data volume to above instance actual result: attach volume is failing in this specific case. content of management log: GET command=attachVolumeid=3d67606b-eeaf-474e-a7f4-95e24a4da7fdvirtualMachineId=42c31b97-d376-4e04-b6c3-08cecda7c13fresponse=jsonsessionkey=W%2F%2BBolWn%2BDoUEK1P92X71fVmknc%3D_=1378979512588 2013-09-12 20:44:19,627 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ] 2013-09-12 20:44:19,956 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: The VM VM33 has more than one ROOT volume and is in an invalid state. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1815) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-09-12 20:44:19,980 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Complete async job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: The VM VM33 has more than one ROOT volume and is in an invalid state. 2013-09-12 20:44:22,270 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) SeqA 2-1802: Processing Seq 2-1802: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo: {\n \connections\: []\n} ,wait:0}}] } 2013-09-12 20:44:22,279 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) SeqA 2-1802: Sending Seq 2-1802: { Ans: , MgmtId: 7175246184473, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-09-12 20:44:22,497 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) ===START=== 10.252.192.100 – GET command=queryAsyncJobResultjobId=3158826e-9c85-4210-bc1a-d97ce9865a3dresponse=jsonsessionkey=W%2F%2BBolWn%2BDoUEK1P92X71fVmknc%3D_=1378979516168 2013-09-12 20:44:22,508 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-14:null) Async job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ] completed 2013-09-12 20:44:22,514 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) ===END=== 10.252.192.100 – GET command=queryAsyncJobResultjobId=3158826e-9c85-4210-bc1a-d97ce9865a3dresponse=jsonsessionkey=W%2F%2BBolWn%2BDoUEK1P92X71fVmknc%3D_=1378979516168 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-4657) ceph:fail to attach a volume to instance which is migrated from one primary to another primary.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-4657. -- Resolution: Fixed I think this one is resolved as well. I tried this on a 4.3 cluster (build from 4.3 branch) and it's working fine. It was all related to a problem in the RADOS Java bindings and that all lead to 4665. Should be resolved. Please re-open if it comes up again. ceph:fail to attach a volume to instance which is migrated from one primary to another primary. Key: CLOUDSTACK-4657 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4657 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Reporter: sadhu suresh Assignee: Wido den Hollander fail to attach a data volume to instance after migrating instance from one primary to another primary. due to problem specified in the issue #CLOUDSTACK-4652. 2.add RBD based primary storage 3.create compute offering and create a instance using this offering 4.stop the running VM which was created in step 3 5.perform migrate instance from one primary to another primary 6.create a data volume and try to attach data volume to above instance actual result: attach volume is failing in this specific case. content of management log: GET command=attachVolumeid=3d67606b-eeaf-474e-a7f4-95e24a4da7fdvirtualMachineId=42c31b97-d376-4e04-b6c3-08cecda7c13fresponse=jsonsessionkey=W%2F%2BBolWn%2BDoUEK1P92X71fVmknc%3D_=1378979512588 2013-09-12 20:44:19,627 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ] 2013-09-12 20:44:19,956 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: The VM VM33 has more than one ROOT volume and is in an invalid state. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1815) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-09-12 20:44:19,980 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ]) Complete async job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: The VM VM33 has more than one ROOT volume and is in an invalid state. 2013-09-12 20:44:22,270 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) SeqA 2-1802: Processing Seq 2-1802: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo: {\n \connections\: []\n} ,wait:0}}] } 2013-09-12 20:44:22,279 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) SeqA 2-1802: Sending Seq 2-1802: { Ans: , MgmtId: 7175246184473, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-09-12 20:44:22,497 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) ===START=== 10.252.192.100 – GET command=queryAsyncJobResultjobId=3158826e-9c85-4210-bc1a-d97ce9865a3dresponse=jsonsessionkey=W%2F%2BBolWn%2BDoUEK1P92X71fVmknc%3D_=1378979516168 2013-09-12 20:44:22,508 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-14:null) Async job-23 = [ 3158826e-9c85-4210-bc1a-d97ce9865a3d ] completed 2013-09-12 20:44:22,514 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) ===END=== 10.252.192.100 – GET
[jira] [Resolved] (CLOUDSTACK-4557) ceph:Performance:first time operstions taking more time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-4557. Resolution: Fixed Fix Version/s: 4.3.1 4.4.0 This was resolved in both the 4.3 and 4.4 branch. /tmp is no longer used, we use qemu-img to do the copy for us. ceph:Performance:first time operstions taking more time --- Key: CLOUDSTACK-4557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4557 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: sadhu suresh Assignee: Wido den Hollander Fix For: 4.4.0, 4.3.1 Its taking more time to deploy a first vm on rbd based primary storage when compared to VM deployment on NFS based storage. In our environment its taking more than 7 mins.[our observation is first time operations are taking more time ],like first t time vm deployment/snapshot/attach operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-4557) ceph:Performance:first time operstions taking more time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4557: -- Assignee: Wido den Hollander ceph:Performance:first time operstions taking more time --- Key: CLOUDSTACK-4557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4557 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: sadhu suresh Assignee: Wido den Hollander Fix For: 4.4.0, 4.3.1 Its taking more time to deploy a first vm on rbd based primary storage when compared to VM deployment on NFS based storage. In our environment its taking more than 7 mins.[our observation is first time operations are taking more time ],like first t time vm deployment/snapshot/attach operations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-4652) ceph:UI:Noticed 2 records for same volume after migrating instance from one primary to another primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander reassigned CLOUDSTACK-4652: -- Assignee: Wido den Hollander ceph:UI:Noticed 2 records for same volume after migrating instance from one primary to another primary -- Key: CLOUDSTACK-4652 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4652 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: sadhu suresh Assignee: Wido den Hollander 1.deploy advanced zone with kvm cluster(single cluster with ubuntu host+nfs as primary storage) 2.add RBD based primary storage 3.create compute offering and create a instance using this offering 4.stop the running VM which was created in step 3 5.perform migrate instance from one primary to another primary Actual result: migrate instance successful but UI shows 2 records for same Volume(newly created one and expunged one).it looks like volume was successfuly copied from primary1 to secondary and secondary to primary2 .once its copied to primry2 successfully and it tries to delete the volume exits in primary1 and its fail to delete the object.due to this reason it shows 2 records for same volume. [root@cen62307 ~]# grep -i job-21 /var/log/cloudstack/management/management-server.log 2013-09-12 19:54:55,954 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-21:null) submit async job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ], details: AsyncJobVO {id:21, userId: 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd: org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null, cmdInfo: {response:json,sessionkey:W/+BolWn+DoUEK1P92X71fVmknc\u003d,virtualmachineid:42c31b97-d376-4e04-b6c3-08cecda7c13f,cmdEventType:VM.MIGRATE,ctxUserId:2,storageid:59b50b13-75b2-3385-87c7-a452d56e2ee0,httpmethod:GET,_:1378976549445,ctxAccountId:2,ctxStartEventId:133}, cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processStatus: 0, resultCode: 0, result: null, initMsid: 7175246184473, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2013-09-12 19:54:56,290 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Executing org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ] 2013-09-12 19:54:56,332 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) VM state transitted from :Stopped to Migrating with event: StorageMigrationRequestedvm's original host id: 1 new host id: null host id before state transition: null 2013-09-12 19:54:56,860 DEBUG [storage.motion.AncientDataMotionStrategy] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) copyAsync inspecting src type VOLUME copyAsync inspecting dest type VOLUME 2013-09-12 19:54:56,957 DEBUG [cache.allocator.StorageCacheRandomAllocator] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Can't find staging storage in zone: 1 2013-09-12 19:54:57,691 DEBUG [agent.transport.Request] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Seq 1-1872036399: Sending { Cmd , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 100111, [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1b5f2f3e-6b11-43aa-9d18-aa02d7e00aa1,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:2c19704e-55d4-31aa-b0e7-a52f1fffab9e,id:2,poolType:RBD,host:10.147.41.3,path:sadhu1,port:6789}},name:ROOT-7,size:8589934592,path:48d50558-02f0-48d3-839f-bc73d119d190,volumeId:8,vmName:i-2-7-VM,accountId:2,format:RAW,id:8,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1b5f2f3e-6b11-43aa-9d18-aa02d7e00aa1,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/sadhu/asf/kvmsec,_role:Image}},name:ROOT-7,size:8589934592,path:volumes/2/8,volumeId:8,vmName:i-2-7-VM,accountId:2,format:RAW,id:8,hypervisorType:KVM}},executeInSequence:true,wait:10800}}] } 2013-09-12 20:02:03,636 DEBUG [agent.transport.Request] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Seq 1-1872036399: Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 110, { CopyCmdAnswer } } 2013-09-12 20:02:03,759 DEBUG [agent.transport.Request] (Job-Executor-7:job-21 = [ ca7b08f2-a7a7-4797-8ed7-9c11c15e34aa ]) Seq 1-1872036425: Sending { Cmd