[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
