[jira] [Updated] (CLOUDSTACK-4247) [VMWARE]Network read/write statistics is zero always
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-4247: -- Priority: Major (was: Critical) [VMWARE]Network read/write statistics is zero always Key: CLOUDSTACK-4247 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4247 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Likitha Shetty Fix For: 4.4.0 Attachments: apilog.log, management-server.log, networkdb.sql, networkstatistics.png Steps: 1. Configure Adv Networking zone with ESXi server 2. Create a new account and deploy VM 3. Configure Rules ( LB and Firewall rules with 22 port) 4. SSH to VM and verify that it is reachable 5. Tried to view the network statistics of this instance Observation : 1. Network read/write statistics is zero always -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040462#comment-14040462 ] ASF subversion and git services commented on CLOUDSTACK-6965: - Commit ef45f06f88c955dcf47f1fb69a3a0e87eb817e1d in cloudstack's branch refs/heads/4.4-forward from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ef45f06 ] CLOUDSTACK-6965: fixed the NullPointerException introduced by fix for cloudstack 6935 in AbstractStoragePoolAllocator#filter method for Zone Wide storage Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix for CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6976) Support for SecStorageFirewallCfgCommand for simulator.
Santhosh Kumar Edukulla created CLOUDSTACK-6976: --- Summary: Support for SecStorageFirewallCfgCommand for simulator. Key: CLOUDSTACK-6976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6976 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.4.0 Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla Fix For: 4.4.0, 4.5.0 Simulator currently, does not support SecStorageFirewallCfgCommand and throws up below error. Added support for this command now. [c.c.a.m.AgentManagerImpl] (Simulator-Agent-Mgr-1:ctx-6381ef3d) Unsupported Command: Unsupported command issued:com.cloud.agent.api.SecStorageFirewallCfgCommand. Are you sure you got the right type of server? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6968) Allow Cluster scope volumes to attach to any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040484#comment-14040484 ] ASF subversion and git services commented on CLOUDSTACK-6968: - Commit 6416de5770ad5579f78dc06ebc58bb0e4262c2c2 in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6416de5 ] CLOUDSTACK-6968: allowing cluster scope volumes to attach to any VM. If migration is needed then first they will be migrated to appropriate cluster before attaching. Allow Cluster scope volumes to attach to any VM --- Key: CLOUDSTACK-6968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently cluster scope volumes are failed to attach to VM if the vm is not in same cluster as volumes. This will relax that restriction. This makes more sense as we allow zone wide primary store to attach to any VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040485#comment-14040485 ] ASF subversion and git services commented on CLOUDSTACK-6965: - Commit bbcffbbab09905872a1b9c405a67734e457182fd in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbcffbb ] CLOUDSTACK-6965: fixed the NullPointerException introduced by fix for cloudstack 6935 in AbstractStoragePoolAllocator#filter method for Zone Wide storage Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix for CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6968) Allow Cluster scope volumes to attach to any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040494#comment-14040494 ] ASF subversion and git services commented on CLOUDSTACK-6968: - Commit 1b1a417bb43f507cf920b99b3c0d5ebca97c1724 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1b1a417 ] CLOUDSTACK-6968: Allowing cluster scope volumes to attach to any VM. If migration is needed then first they will be migrated to appropriate cluster before attaching. (cherry picked from commit e7ba46b5f7da21c4fc13dc3284aa802d177045f2) Allow Cluster scope volumes to attach to any VM --- Key: CLOUDSTACK-6968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently cluster scope volumes are failed to attach to VM if the vm is not in same cluster as volumes. This will relax that restriction. This makes more sense as we allow zone wide primary store to attach to any VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040492#comment-14040492 ] ASF subversion and git services commented on CLOUDSTACK-6965: - Commit 423c23af4052b29e908110d35978a4a720501448 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=423c23a ] CLOUDSTACK-6965: fixed the NullPointerException introduced by fix for cloudstack 6935 in AbstractStoragePoolAllocator#filter method for Zone Wide storage (cherry picked from commit ef45f06f88c955dcf47f1fb69a3a0e87eb817e1d) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix for CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6830) [Hyper-V] If a VM is is created with it's volumes on zone wide primary storage, the migration of that VM always asks for storage migration as well and fails.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040499#comment-14040499 ] ASF subversion and git services commented on CLOUDSTACK-6830: - Commit af37ade9e3ff4c686883b2218e309c30b2d192ac in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af37ade ] CLOUDSTACK-6830: Fixed [hyper-v] during VM migration, volumes on zone wide primary store requires storage migration resulting in failure of VM migration. This also improves the hostsformigration api. Firstly we were trying to list all hosts and then finding suitable storage pools for all volumes and then we were checking whether vm migration requires storage migration to that host. Now the process is updated. We are checking for only those volumes which are not in zone wide primary store. We are verifying by comparing volumes-poolid-clusterid to host clusterid. If it uses local or clusterids are different then verifying whether host has suitable storage pools for the volume of the vm to be migrated too. (cherry picked from commit 64153a43711420224655bfbe248b4b87474a1f23) Conflicts: engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java [Hyper-V] If a VM is is created with it's volumes on zone wide primary storage, the migration of that VM always asks for storage migration as well and fails. - Key: CLOUDSTACK-6830 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6830 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Affects Versions: 4.4.0 Environment: Advanced zone Hypervisor : Hyper-V Primary storage : cluster wide, zone wide and local Reporter: Abhinav Roy Assignee: Anshul Gangwar Priority: Critical Labels: hyper-V,, hyper-v, hyperv Fix For: 4.4.0 Steps : == 1. Deploy an advanced zone HyperV setup with 2 clusters. c1 having 2 hosts , h1 h2 2 primary storages ps1 ps2 c2 having 1 host, h3 2 primary storages ps3 p4 2 zone wide primary storages zwps1 zwps2 2. Create a VM such that its volume lies on zwps1 3. Migrate the VM Expected behavior : = 1. When we try to migrate the VM, the API or UI should list the hosts suitable for migration. And the migration should not require storage motion since the pool used is a zone wide primary storage 2. Migration should be successful. Observed behavior : 1. When we try to migrate the VM, the API lists the hosts suitable for migration but it also says that the process involved storage motion ( which is wrong) monkey# find hostsformigration virtualmachineid=25 count = 2 host: id = 6452c7b7-2623-48ec-930f-dc4f98d10e21 name = 10.102.244.20 capabilities = hvm clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e clustername = cluster1 clustertype = CloudManaged cpuallocated = 0% cpunumber = 4 cpuspeed = 3093 cpuused = 1% cpuwithoverprovisioning = 12372.0 created = 2014-06-02T11:56:28+0530 disconnected = 2014-06-02T12:28:48+0530 events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout hahost = False hosttags = tag1 hypervisor = Hyperv hypervisorversion = 6.2 ipaddress = 10.102.244.20 islocalstorageactive = False jobstatus = 0 lastpinged = 1970-01-17T01:43:59+0530 managementserverid = 213737702773493 memoryallocated = 3447717888 memorytotal = 8558297088 memoryused = 4933872 networkkbsread = 53356091604 networkkbswrite = 326400170803 podid = 69ba6799-d3f4-482e-93f1-9bdc637c0e51 podname = hyperv requiresStorageMotion = True resourcestate = Enabled state = Up suitableformigration = True type = Routing version = 4.4.0-SNAPSHOT zoneid = 1259f9d6-87a6-45c1-ad45-0be382c68b4b zonename = hyperv id = ee8ca90c-08da-4bae-b04b-83ff8e78ded2 name = 10.102.244.21 capabilities = hvm clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e clustername = cluster1 clustertype = CloudManaged cpuallocated = 0% cpunumber = 4 cpuspeed = 3093 cpuused = 1% cpuwithoverprovisioning = 12372.0 created = 2014-06-02T11:57:11+0530 disconnected = 2014-06-02T12:28:48+0530 events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout hahost = False
[jira] [Resolved] (CLOUDSTACK-6830) [Hyper-V] If a VM is is created with it's volumes on zone wide primary storage, the migration of that VM always asks for storage migration as well and fails.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6830. Resolution: Fixed [Hyper-V] If a VM is is created with it's volumes on zone wide primary storage, the migration of that VM always asks for storage migration as well and fails. - Key: CLOUDSTACK-6830 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6830 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Affects Versions: 4.4.0 Environment: Advanced zone Hypervisor : Hyper-V Primary storage : cluster wide, zone wide and local Reporter: Abhinav Roy Assignee: Anshul Gangwar Priority: Critical Labels: hyper-V,, hyper-v, hyperv Fix For: 4.4.0 Steps : == 1. Deploy an advanced zone HyperV setup with 2 clusters. c1 having 2 hosts , h1 h2 2 primary storages ps1 ps2 c2 having 1 host, h3 2 primary storages ps3 p4 2 zone wide primary storages zwps1 zwps2 2. Create a VM such that its volume lies on zwps1 3. Migrate the VM Expected behavior : = 1. When we try to migrate the VM, the API or UI should list the hosts suitable for migration. And the migration should not require storage motion since the pool used is a zone wide primary storage 2. Migration should be successful. Observed behavior : 1. When we try to migrate the VM, the API lists the hosts suitable for migration but it also says that the process involved storage motion ( which is wrong) monkey# find hostsformigration virtualmachineid=25 count = 2 host: id = 6452c7b7-2623-48ec-930f-dc4f98d10e21 name = 10.102.244.20 capabilities = hvm clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e clustername = cluster1 clustertype = CloudManaged cpuallocated = 0% cpunumber = 4 cpuspeed = 3093 cpuused = 1% cpuwithoverprovisioning = 12372.0 created = 2014-06-02T11:56:28+0530 disconnected = 2014-06-02T12:28:48+0530 events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout hahost = False hosttags = tag1 hypervisor = Hyperv hypervisorversion = 6.2 ipaddress = 10.102.244.20 islocalstorageactive = False jobstatus = 0 lastpinged = 1970-01-17T01:43:59+0530 managementserverid = 213737702773493 memoryallocated = 3447717888 memorytotal = 8558297088 memoryused = 4933872 networkkbsread = 53356091604 networkkbswrite = 326400170803 podid = 69ba6799-d3f4-482e-93f1-9bdc637c0e51 podname = hyperv requiresStorageMotion = True resourcestate = Enabled state = Up suitableformigration = True type = Routing version = 4.4.0-SNAPSHOT zoneid = 1259f9d6-87a6-45c1-ad45-0be382c68b4b zonename = hyperv id = ee8ca90c-08da-4bae-b04b-83ff8e78ded2 name = 10.102.244.21 capabilities = hvm clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e clustername = cluster1 clustertype = CloudManaged cpuallocated = 0% cpunumber = 4 cpuspeed = 3093 cpuused = 1% cpuwithoverprovisioning = 12372.0 created = 2014-06-02T11:57:11+0530 disconnected = 2014-06-02T12:28:48+0530 events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout hahost = False hypervisor = Hyperv hypervisorversion = 6.2 ipaddress = 10.102.244.21 islocalstorageactive = False jobstatus = 0 lastpinged = 1970-01-17T01:43:59+0530 managementserverid = 213737702773493 memoryallocated = 1166016512 memorytotal = 8558297088 memoryused = 2956140 networkkbsread = 189444293536 networkkbswrite = 63265905010 podid = 69ba6799-d3f4-482e-93f1-9bdc637c0e51 podname = hyperv requiresStorageMotion = True resourcestate = Enabled state = Up suitableformigration = True type = Routing version = 4.4.0-SNAPSHOT zoneid = 1259f9d6-87a6-45c1-ad45-0be382c68b4b zonename = hyperv == 2. The migration fails : 2014-06-03 13:45:58,082 DEBUG [c.c.a.ApiServlet] (catalina-exec-20:ctx-8c9a3f4f) ===START=== 10.144.7.13 -- GET command=migrateVirtualMachineWithVolumehostid=ee8ca90c-08da-4bae-b04b-83ff8e78ded2virtualmachineid=e9523ccd-28cb-4089-b4cd-c5cbb8658120response=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401782981308 2014-06-03 13:45:58,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (catalina-exec-20:ctx-8c9a3f4f ctx-81f3bd5c) submit async
[jira] [Resolved] (CLOUDSTACK-6968) Allow Cluster scope volumes to attach to any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6968. Resolution: Fixed Allow Cluster scope volumes to attach to any VM --- Key: CLOUDSTACK-6968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently cluster scope volumes are failed to attach to VM if the vm is not in same cluster as volumes. This will relax that restriction. This makes more sense as we allow zone wide primary store to attach to any VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6965. Resolution: Fixed Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix for CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6968) Allow Cluster scope volumes to attach to any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-6968: --- Status: Reviewable (was: In Progress) Allow Cluster scope volumes to attach to any VM --- Key: CLOUDSTACK-6968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently cluster scope volumes are failed to attach to VM if the vm is not in same cluster as volumes. This will relax that restriction. This makes more sense as we allow zone wide primary store to attach to any VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-6965: --- Status: Reviewable (was: In Progress) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix for CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3317) DVS does not support management\storage network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-3317: -- Fix Version/s: (was: 4.4.0) Future DVS does not support management\storage network --- Key: CLOUDSTACK-3317 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3317 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Reporter: Ram Ganesh Assignee: Sateesh Chodapuneedi Fix For: Future The need for this was discussed long time back but looks like no one filed a bug to track this much needed change. Here is the link to the email discussion - http://markmail.org/message/sz7xudwqod44awlf#query:+page:1+mid:7t2quwaxzycatfey+state:results -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-797) Remove or fix unknown classes in cloud-api
[ https://issues.apache.org/jira/browse/CLOUDSTACK-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-797: - Fix Version/s: (was: 4.4.0) Future Remove or fix unknown classes in cloud-api -- Key: CLOUDSTACK-797 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-797 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Rohit Yadav Assignee: Kishan Kavala Fix For: Future The following cmd classes exists under cloud-api, there are not being used nor there are mentioned in apidocs. The issue is to verify them and if they are not needed remove them. api/src/com/cloud/api/commands//CreatePrivateNetworkCmd.java api/src/com/cloud/api/commands//DestroyConsoleProxyCmd.java api/src/com/cloud/api/commands//ListRecurringSnapshotScheduleCmd.java -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5281) resource limit shouldnt be counted for resources with display flag = 0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-5281: -- Fix Version/s: (was: 4.4.0) Future resource limit shouldnt be counted for resources with display flag = 0 -- Key: CLOUDSTACK-5281 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5281 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: Future Resource limit shouldnt be counted for resources with display flag = 0 These are resources created by admin and hidden from the end user so shouldnt count in the resource count or limit while creating/deleting them. But once the flag is turned on it should start getting counted in the resource count. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5251) No Error message is displayed when nonexistent NFS secondary storage is added to CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland updated CLOUDSTACK-5251:
--
Fix Version/s: (was: 4.4.0)
Future
No Error message is displayed when nonexistent NFS secondary storage is
added to CS.
-
Key: CLOUDSTACK-5251
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5251
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: manasaveloori
Assignee: edison su
Fix For: Future
Attachments: management-server.log
Steps:
1.Deploy a CS .
2.After the UI comes up,try to add the another NFS secondary storage
which is not existing in the path added.
Observation:
Secondary storage got added in the UI .
Observing the below Debug messages and not ERROR messages in log:
2013-11-25 07:47:28,352 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-a89b587d) ===START=== 10.252.192.19 -- GET
command=addImageStoreresponse=jsonsessionkey=pDnp1RLy0kkw5icS9lA1JS34SR8%3Dname=test5provider=NFSzoneid=79124a51-3510-4bf7-b17c-4b8e4818b515url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Fmanasa%2Fdummy_=1385364241867
2013-11-25 07:47:28,367 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl]
(catalina-exec-18:ctx-a89b587d ctx-8dbd09ee) Trying to add a new data store
at nfs://10.147.28.7/export/home/manasa/dummy to data center 1
2013-11-25 07:47:28,480 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-a89b587d ctx-8dbd09ee) ===END=== 10.252.192.19 -- GET
command=addImageStoreresponse=jsonsessionkey=pDnp1RLy0kkw5icS9lA1JS34SR8%3Dname=test5provider=NFSzoneid=79124a51-3510-4bf7-b17c-4b8e4818b515url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Fmanasa%2Fdummy_=1385364241867
2013-11-25 07:47:33,608 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-325: Processing Seq 5-325: { Cmd ,
MgmtId: -1, via: 5, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:7,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-11-25 07:47:33,618 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-325: Sending Seq 5-325: { Ans: ,
MgmtId: 6758231703598, via: 5, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-11-25 07:47:38,911 DEBUG [c.c.s.StatsCollector]
(StatsCollector-3:ctx-ca134799) StorageCollector is running...
2013-11-25 07:47:38,988 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-ca134799) Seq 4-628555880: Received: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
2013-11-25 07:48:39,942 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-0b21c1ed) Seq 4-628555883: Received: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
2013-11-25 07:48:40,038 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-15:null) Seq 4-628555884: Processing: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for nfs://10.147.28.7/export/home/manasa/sectest failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to mount
10.147.28.7:/export/home/manasa/sectest at
/mnt/SecStorage/5885435a-769d-360d-87fa-63f1a925e11b due to mount.nfs:
mounting 10.147.28.7:/export/home/manasa/sectest failed, reason given by
server: No such file or directory\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1939)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:1692)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:216)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:679)\n,wait:0}}] }
2013-11-25 07:48:40,039 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-0b21c1ed) Seq 4-628555884: Received: { Ans: , MgmtId:
[jira] [Updated] (CLOUDSTACK-4492) [object_store_ref] Attaching volume to a vm is failing after upgrade if the volume was uploaded before upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland updated CLOUDSTACK-4492:
--
Fix Version/s: (was: 4.4.0)
Future
[object_store_ref] Attaching volume to a vm is failing after upgrade if the
volume was uploaded before upgrade
---
Key: CLOUDSTACK-4492
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4492
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, Volumes
Affects Versions: 4.2.1
Environment: Build is from commit
:a6bf80216466ada185de7e04d3e64be4e25c11a7
Upgrade from 3.0.6 to 4.2
Reporter: Sanjeev N
Assignee: edison su
Priority: Critical
Labels: ReleaseNote
Fix For: Future
Attachments: cloud.dmp, cloud.dmp, management-server.rar,
management-server.rar
Failing to attach a volume to a vm after upgrade if it was uploaded before
upgrade.
Steps to Reproduce:
1.Bring up CS with VMWare cluster using 3.0.6 GA build
2.upload volume using API:
http://10.147.59.126:8096/client/api?command=uploadVolumeformat=OVAname=cent53-upload-BUurl=http://10.147.28.7/templates/vmware/CentOS5.3-x86_64.ovazoneid=9076c21d-d0c4-4cee-9820-2a551b65616eaccount=admindomainid=1
3.Upgrade to 4.2
4.Deploy one vm with root disk
5.Try to attach the volume uploaded at step2 to vm created above
Result:
=
Attaching volume failed with InvalidParameterValueException
Observations:
===
Uploaded volume has state set to UploadOp in volumes table. However
AttachVolumeCmd is checking for volume state to be either in Allocated, Ready
or in Uploaded state. So attaching is failing.
Following is the log snippet:
2013-08-26 01:36:30,254 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
===START=== 10.146.0.131 -- GET
command=attachVolumeid=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7evirtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982aresponse=jsonsessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D_=1377495389690
2013-08-26 01:36:30,405 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-4:null) submit async job-189 = [
0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ], details: AsyncJobVO {id:189, userId:
2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 20, cmd:
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdOriginator:
null, cmdInfo:
{response:json,id:55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e,sessionkey:u8uFWRNIgqqVZ+/BLCQbaSfZMCw\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:ce3c8eb5-05f9-445b-ab74-68751e8a982a,httpmethod:GET,_:1377495389690,ctxAccountId:2,ctxStartEventId:2015},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-26 01:36:30,408 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
===END=== 10.146.0.131 -- GET
command=attachVolumeid=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7evirtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982aresponse=jsonsessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D_=1377495389690
2013-08-26 01:36:30,410 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ]
2013-08-26 01:36:30,468 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.exception.InvalidParameterValueException: Volume state must be in
Allocated, Ready or in Uploaded state
at
com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1807)
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
[jira] [Commented] (CLOUDSTACK-5843) registering templates/isos should be either async or changed to non-blocking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040539#comment-14040539 ] Daan Hoogland commented on CLOUDSTACK-5843: --- Marcus, can you update this issue or close it? registering templates/isos should be either async or changed to non-blocking Key: CLOUDSTACK-5843 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5843 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, 4.3.0, 4.4.0 Reporter: Marcus Sorensen Fix For: Future The call to register templates and isos does more than most sync calls do, it seems to talk to the ssvm and have it run commands that can potentially time out. I ran into this in a test system when we tried to register a template with a non-routable URL. The cloudstack API call just hung. I realize that there was a problem (ssvm could not reach the template host), but no sync call should do anything like this that would block. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5843) registering templates/isos should be either async or changed to non-blocking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-5843: -- Fix Version/s: (was: 4.4.0) Future registering templates/isos should be either async or changed to non-blocking Key: CLOUDSTACK-5843 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5843 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, 4.3.0, 4.4.0 Reporter: Marcus Sorensen Fix For: Future The call to register templates and isos does more than most sync calls do, it seems to talk to the ssvm and have it run commands that can potentially time out. I ran into this in a test system when we tried to register a template with a non-routable URL. The cloudstack API call just hung. I realize that there was a problem (ssvm could not reach the template host), but no sync call should do anything like this that would block. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5885) When process receives error, loading overlay on listView element does not disappear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040540#comment-14040540 ] Daan Hoogland commented on CLOUDSTACK-5885: --- Ricky, did you find a way to get this implemented? it seems that it would be moved to future releases. When process receives error, loading overlay on listView element does not disappear --- Key: CLOUDSTACK-5885 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5885 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: Google Chrome on Mac Reporter: Ricky Hopper Priority: Minor Fix For: 4.4.0 We noticed while developing a ui plugin for Cloudstack that when an operation initiated from the quickview dropdown fails with an error dialog, the loading overlay on that list element does not disappear, though the js code to remove the overlay is executed. This appears to be happening across all of Cloudstack, though we first noticed it during plugin development work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040541#comment-14040541 ] Daan Hoogland commented on CLOUDSTACK-5923: --- Anthony, can this be closed? XS/CS integration improvement, CS doesn't do master switch for XS - Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5952) [UI] VM ip address information is not shown after configuring static NAT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-5952: -- Fix Version/s: (was: 4.4.0) Future [UI] VM ip address information is not shown after configuring static NAT Key: CLOUDSTACK-5952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Jayapal Reddy Assignee: Brian Federle Fix For: Future 1. Create a VM and acquire secondary ip address for the nic. 2. Go to network - IP address: Enable the static nat for the for the VM secondary ip address. 3. After static nat enable success, go to ip addresses page. 4. On public the static nat is configured, on vm name column there is no vm ip address info. Expected: The ip address should also displayed. 5. In API listPublicIpAddresses response has the vm ip addr info with name 'vmipaddress' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5952) [UI] VM ip address information is not shown after configuring static NAT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040544#comment-14040544 ] Daan Hoogland commented on CLOUDSTACK-5952: --- no activity, moving out to 'future' [UI] VM ip address information is not shown after configuring static NAT Key: CLOUDSTACK-5952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Jayapal Reddy Assignee: Brian Federle Fix For: Future 1. Create a VM and acquire secondary ip address for the nic. 2. Go to network - IP address: Enable the static nat for the for the VM secondary ip address. 3. After static nat enable success, go to ip addresses page. 4. On public the static nat is configured, on vm name column there is no vm ip address info. Expected: The ip address should also displayed. 5. In API listPublicIpAddresses response has the vm ip addr info with name 'vmipaddress' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6977) [OVS] distributed routing: send updated to host parallely
Murali Reddy created CLOUDSTACK-6977: Summary: [OVS] distributed routing: send updated to host parallely Key: CLOUDSTACK-6977 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6977 Project: CloudStack Issue Type: Improvement 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.5.0 When distributed routing is enabled for VPC, through Ovs, currently updates are send to each host on which VPC spans. Updates are sent on topology changes and ACL updates. Currently updates are sent sequentially to each host. This improvements is to change the behaviour to send updates parallel to the hosts that needs update -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6967) OVM3 support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040605#comment-14040605 ] ASF subversion and git services commented on CLOUDSTACK-6967: - Commit 189972bc7c9e73abff392429eda298f9f837992e in cloudstack's branch refs/heads/master from [~funsie] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=189972b ] CLOUDSTACK-6967: Now with module! Signed-off-by: Sebastien Goasguen run...@gmail.com (cherry picked from commit 1516b041bc762535b8f2e74bcb1e6594e5657f86) OVM3 support Key: CLOUDSTACK-6967 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6967 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Funs Kessen We need ovm3 support in cloudstack! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6967) OVM3 support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040604#comment-14040604 ] ASF subversion and git services commented on CLOUDSTACK-6967: - Commit 8a485b9b59e4108e862022baf7477f768380b325 in cloudstack's branch refs/heads/master from [~funsie] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8a485b9 ] CLOUDSTACK-6967: Initial OVM3 drop Signed-off-by: Sebastien Goasguen run...@gmail.com (cherry picked from commit ed47763e2525a21fa4578d199492462d0fb1c7ef) Conflicts: api/src/com/cloud/network/NetworkService.java api/src/org/apache/cloudstack/api/ApiConstants.java api/src/org/apache/cloudstack/api/command/admin/usage/AddTrafficTypeCmd.java engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/SnapshotObject.java plugins/pom.xml server/src/com/cloud/network/NetworkServiceImpl.java server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java server/test/com/cloud/vpc/MockNetworkManagerImpl.java ui/scripts/docs.js OVM3 support Key: CLOUDSTACK-6967 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6967 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Funs Kessen We need ovm3 support in cloudstack! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6978) CLONE - [Windows] Can not create Template from ROOT snapshot For S3 Storage Server
Damodar Reddy T created CLOUDSTACK-6978: --- Summary: CLONE - [Windows] Can not create Template from ROOT snapshot For S3 Storage Server Key: CLOUDSTACK-6978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6978 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.5.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Steps to reproduce the issue 1. Create a snapshot from ROOT disk 2. Goto the above created snapshot 3. Try to create template out of it. It is failing with the following trace. 014-05-12 04:02:01,813 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-428:ctx-2ece4baa) null due to Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd java.net.URISyntaxException: Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.init(Unknown Source) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createVolumeFromSnapshot(XenServerStorageProcessor.java:1617) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:96) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6636) [Windows] Can not create Template from ROOT snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-6636. - Resolution: Fixed Fix Version/s: 4.5.0 [Windows] Can not create Template from ROOT snapshot Key: CLOUDSTACK-6636 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6636 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.5.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: 4.5.0 Steps to reproduce the issue 1. Create a snapshot from ROOT disk 2. Goto the above created snapshot 3. Try to create template out of it. It is failing with the following trace. 014-05-12 04:02:01,813 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-428:ctx-2ece4baa) null due to Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd java.net.URISyntaxException: Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.init(Unknown Source) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createVolumeFromSnapshot(XenServerStorageProcessor.java:1617) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:96) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6966) Attach volume causes unexpected exception intermittently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040648#comment-14040648
]
Santhosh Kumar Edukulla commented on CLOUDSTACK-6966:
-
Girish,
1. Is this bug, specific to few hypervisors or is reproducible with any
hypervisor?
2. Iam just trying to fix the bug. Will the bug mentioned requires hardware, or
can be verified against simulator?
Santhosh
Attach volume causes unexpected exception intermittently
Key: CLOUDSTACK-6966
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6966
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Girish Shilamkar
Assignee: Santhosh Kumar Edukulla
test_09_delete_detached_volume test fails sometimes while attaching the
volume. Upon investigating it was found that unexpected exception is thrown
by management server.
Log:
2014-06-19 07:43:09,198 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Unexpected exception while
executing org.apache.cloudstack.api.
command.admin.volume.AttachVolumeCmdByAdmin
java.lang.RuntimeException: Unexpected exception
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1045)
at sun.reflect.GeneratedMethodAccessor669.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy182.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:38)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: Job failed due to exception Failed to
attach volume Test Volume to VM VM-43cf6765-bf73-4c3f-a1b3-24214d7dee93;
org.libvirt.Libvi
rtException: internal error unable to execute QEMU command
'__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
... 25 more
2014-06-19 07:43:09,199 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Complete async job-7728,
jobStatus: FAILED, resultCode: 530
, result: org.apache.cloudstack.api.response.ExceptionResponse/null/
{uuidList:[],errorcode:530,errortext:Unexpected exception}
2014-06-19 07:43:09,199 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-80:ctx-830fcb84 job-7728/job-7729) Remove job-7729 from
job monitoring
2014-06-19 07:43:09,203 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Done executing
org.apache.cloudstack.api.command.admin.volu
me.AttachVolumeCmdByAdmin for job-7728
2014-06-19 07:43:09,207 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Remove job-7728 from job
monitoring
2014-06-19 07:43:09,655 DEBUG
[jira] [Created] (CLOUDSTACK-6979) Not abe to delete virtual router hence network
Tejas created CLOUDSTACK-6979: - Summary: Not abe to delete virtual router hence network Key: CLOUDSTACK-6979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6979 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, XenServer Affects Versions: 4.3.0 Environment: CentOS 6.3, Xenserver 6.2 SP1, Cloudstack 4.3, Reporter: Tejas Priority: Critical I have created DefaultSharedNetworkOffering with redundant router for guest network. While trying to recreate the delete the routers one router got deleted other was showing in expunging state. So I was not able to delete network also. While trying to delete the network it was showing below logs, 2014-06-23 13:02:21,589 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Unable to apply ip association, virtual router is not in the right state Expunging 2014-06-23 13:02:21,594 DEBUG [c.c.n.IpAddressManagerImpl] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Resource is not available: VirtualRouter com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Unable to apply ip association, virtual router is not in the right state at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3928) 2014-06-23 13:02:21,595 WARN [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Unable to apply ip address associations for Ntwk[207|Guest|17] as a part of shutdownNetworkRules 2014-06-23 13:02:21,595 WARN [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Failed to cleanup network id=207 resources as a part of shutdownNetwork 2014-06-23 13:02:21,599 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Sending network shutdown to VirtualRouter 2014-06-23 13:02:21,601 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Stopping router VM[DomainRouter|r-27-VM] 2014-06-23 13:02:21,604 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Stopped called on VM[DomainRouter|r-27-VM] but the state is Expunging 2014-06-23 13:02:21,606 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Network id=207 is shutdown successfully, cleaning up corresponding resources now. 2014-06-23 13:02:21,654 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Lock is released for network Ntwk[207|Guest|17] as a part of network shutdown 2014-06-23 13:02:22,045 WARN [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-16:ctx-011048ba ctx-55af37fa) Unable to complete destroy of the network due to element: VirtualRouter OR while restarting the network with cleanup checked it says, ecSt5VOMl2wgsZtnAYbNEfbh8%2Bk%3D_=1403505273057 2014-06-23 12:04:33,538 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-11:ctx-587064a4) Unexpected exception while executing org.apache.cloudstack.api.command.user.network.RestartNetworkCmd com.cloud.exception.InvalidParameterValueException: Network is not in the right state to be restarted. Correct states are: Implemented, Setup at com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1832) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) I did work around for this. I changed broadcast uri in 'networks' table in cloud db to unused integer. removed ip range from UI under exiting network. I was able to add network with same vlan,gw netmask. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6966) Attach volume causes unexpected exception intermittently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040690#comment-14040690
]
Santhosh Kumar Edukulla commented on CLOUDSTACK-6966:
-
I just ran the below case twice and both the times it was successful.
Delete a Volume unattached to an VM ... === TestName:
test_09_delete_detached_volume | Status : SUCCESS ===
ok
--
Ran 1 test in 73.340s
OK
~
Attach volume causes unexpected exception intermittently
Key: CLOUDSTACK-6966
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6966
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Girish Shilamkar
Assignee: Santhosh Kumar Edukulla
test_09_delete_detached_volume test fails sometimes while attaching the
volume. Upon investigating it was found that unexpected exception is thrown
by management server.
Log:
2014-06-19 07:43:09,198 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Unexpected exception while
executing org.apache.cloudstack.api.
command.admin.volume.AttachVolumeCmdByAdmin
java.lang.RuntimeException: Unexpected exception
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1045)
at sun.reflect.GeneratedMethodAccessor669.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy182.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:38)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: Job failed due to exception Failed to
attach volume Test Volume to VM VM-43cf6765-bf73-4c3f-a1b3-24214d7dee93;
org.libvirt.Libvi
rtException: internal error unable to execute QEMU command
'__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
... 25 more
2014-06-19 07:43:09,199 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Complete async job-7728,
jobStatus: FAILED, resultCode: 530
, result: org.apache.cloudstack.api.response.ExceptionResponse/null/
{uuidList:[],errorcode:530,errortext:Unexpected exception}
2014-06-19 07:43:09,199 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-80:ctx-830fcb84 job-7728/job-7729) Remove job-7729 from
job monitoring
2014-06-19 07:43:09,203 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Done executing
org.apache.cloudstack.api.command.admin.volu
me.AttachVolumeCmdByAdmin for job-7728
2014-06-19 07:43:09,207 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-40:ctx-c775dc91 job-7728) Remove job-7728 from
[jira] [Commented] (CLOUDSTACK-6976) Support for SecStorageFirewallCfgCommand for simulator.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040741#comment-14040741 ] ASF subversion and git services commented on CLOUDSTACK-6976: - Commit 76f72d3624e8fcbf2ba9d7c200f0f83c197ca967 in cloudstack's branch refs/heads/4.4-forward from Santhosh Edukulla [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=76f72d3 ] CLOUDSTACK-6976: Added the support for SecStorageFirewallCfgCommand Signed-off-by: Daan Hoogland d...@onecht.net Support for SecStorageFirewallCfgCommand for simulator. - Key: CLOUDSTACK-6976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6976 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.4.0 Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla Fix For: 4.4.0, 4.5.0 Simulator currently, does not support SecStorageFirewallCfgCommand and throws up below error. Added support for this command now. [c.c.a.m.AgentManagerImpl] (Simulator-Agent-Mgr-1:ctx-6381ef3d) Unsupported Command: Unsupported command issued:com.cloud.agent.api.SecStorageFirewallCfgCommand. Are you sure you got the right type of server? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6971) createAutoScaleVmProfile failed with NPE due to lack of bean injection.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6971. -- Resolution: Fixed createAutoScaleVmProfile failed with NPE due to lack of bean injection. --- Key: CLOUDSTACK-6971 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6971 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 When creating autoscale policy, its failing to create with below NPE exception. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:ctx-f439aaf2 job-146) Remove job-146 from job monitoring ERROR [c.c.a.ApiServer] (21050798@qtp-4315003-10:ctx-1bb507da ctx-db84c324) unhandled exception executing api command: [Ljava.lang.String;@17b6fd java.lang.NullPointerException at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:410) at com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:222) at com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:216) at com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:88) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy250.createAutoScaleVmProfile(Unknown Source) at org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263) at com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) 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 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at
[jira] [Reopened] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reopened CLOUDSTACK-6923: --- Reopening the bug as it introduced the regression. List by lbId got broken. Jayapal, when make your fixes, make sure you test the command with: * id * lbId * both id and lbId deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id --- Key: CLOUDSTACK-6923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.2 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.4.0 deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-5923. Resolution: Fixed XS/CS integration improvement, CS doesn't do master switch for XS - Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6854) MS:IPv6: IP6 network address with notation differences are treated as same IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041038#comment-14041038 ] ASF subversion and git services commented on CLOUDSTACK-6854: - Commit dfe20f34f2e72335586b0e014ba1f91aa4ed473e in cloudstack's branch refs/heads/4.4-forward from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dfe20f3 ] CLOUDSTACK-6854: Fix inconsistent IPv6 address formats fc00:0003:1373::0002 should be treated the same as fc00:3:1373::2. MS:IPv6: IP6 network address with notation differences are treated as same IP - Key: CLOUDSTACK-6854 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6854 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: Parth Jagirdar Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Attachments: Screen Shot 2014-06-05 at 11.42.09 AM.png, management-server.log.zip Observed in a dual stack deployment, A router and a virtual machines were assigned same IP from IPv6 range. The only difference was the notation, so it may be the case that notation differences are not being interpret by management server correctly. fc00:0003:1373::0002 was assigned to router and fc00:3:1373::2 was assigned to the guest VM. Please refer to the attached screen and logs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6854) MS:IPv6: IP6 network address with notation differences are treated as same IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041041#comment-14041041 ] ASF subversion and git services commented on CLOUDSTACK-6854: - Commit a93a30595d39641fafb2ca366e6cfd790786c556 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a93a305 ] CLOUDSTACK-6854: Fix inconsistent IPv6 address formats fc00:0003:1373::0002 should be treated the same as fc00:3:1373::2. MS:IPv6: IP6 network address with notation differences are treated as same IP - Key: CLOUDSTACK-6854 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6854 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: Parth Jagirdar Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Attachments: Screen Shot 2014-06-05 at 11.42.09 AM.png, management-server.log.zip Observed in a dual stack deployment, A router and a virtual machines were assigned same IP from IPv6 range. The only difference was the notation, so it may be the case that notation differences are not being interpret by management server correctly. fc00:0003:1373::0002 was assigned to router and fc00:3:1373::2 was assigned to the guest VM. Please refer to the attached screen and logs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6938) Cannot create template from snapshot when using S3 storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Logan B resolved CLOUDSTACK-6938. - Resolution: Fixed Fixed with 736bf540e8ef759a101d221622c64f3b3c3ed425 Cannot create template from snapshot when using S3 storage -- Key: CLOUDSTACK-6938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6938 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.4.0 Environment: KVM + S3 Secondary Storage Reporter: Logan B Priority: Critical Fix For: 4.4.0 When trying to create a template from a snapshot with S3 secondary storage, the command immediately fails with a NullPointerException. This appears to only happen when there is a pre-existing snapshot folder in the NFS staging store. This indicates that there is something wrong with the copy command (e.g., it's using 'mkdir' instead of 'mkdir -p'). The issue can be worked around by deleting the existing snapshot folder on the staging store every time you want to create a new template. This is obviously not viable for end users. This issue should be fixed before 4.4 ships because it should be a stupid simple thing to correct, but completely breaks restoring snapshots for end users. Waiting for 4.5 would be far too long for an issue like this. 2014-06-18 21:13:54,789 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Processing command: org.apache.cloudstack.storage.command.CopyCommand 2014-06-18 21:13:54,789 INFO [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-2:null) Determined host 172.16.48.99 corresponds to IP 172.16.48.99 2014-06-18 21:13:54,797 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-2:null) Unable to create directory /mnt/SecStorage/6b9bdec9-fdc9-3fdd-a5f8-0481df177ae8/snapshots/2/25 to copy from S3 to cache. I'm guessing it's an issue with the mkdirs() function in the code, but I've been unable to find it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6971) createAutoScaleVmProfile failed with NPE due to lack of bean injection.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041074#comment-14041074 ] ASF subversion and git services commented on CLOUDSTACK-6971: - Commit 0d23ad903d8dabf8f7b752c5e42e3256a2e6a506 in cloudstack's branch refs/heads/4.4 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0d23ad9 ] CLOUDSTACK-6971: createAutoScaleVmProfile failed with NPE due to lack of bean injection. (cherry picked from commit 31e250a9d2adbf9ee59da66073497e38c02ded86) createAutoScaleVmProfile failed with NPE due to lack of bean injection. --- Key: CLOUDSTACK-6971 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6971 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 When creating autoscale policy, its failing to create with below NPE exception. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:ctx-f439aaf2 job-146) Remove job-146 from job monitoring ERROR [c.c.a.ApiServer] (21050798@qtp-4315003-10:ctx-1bb507da ctx-db84c324) unhandled exception executing api command: [Ljava.lang.String;@17b6fd java.lang.NullPointerException at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:410) at com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:222) at com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:216) at com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:88) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy250.createAutoScaleVmProfile(Unknown Source) at org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263) at com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) 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 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: cloudstack-6460_44.patch
Patch for 4.4
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6854) MS:IPv6: IP6 network address with notation differences are treated as same IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041088#comment-14041088 ] ASF subversion and git services commented on CLOUDSTACK-6854: - Commit f7dd1720cb6217d4425e9a92268f6b716e88a18c in cloudstack's branch refs/heads/4.4 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f7dd172 ] CLOUDSTACK-6854: Fix inconsistent IPv6 address formats fc00:0003:1373::0002 should be treated the same as fc00:3:1373::2. (cherry picked from commit dfe20f34f2e72335586b0e014ba1f91aa4ed473e) MS:IPv6: IP6 network address with notation differences are treated as same IP - Key: CLOUDSTACK-6854 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6854 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: Parth Jagirdar Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Attachments: Screen Shot 2014-06-05 at 11.42.09 AM.png, management-server.log.zip Observed in a dual stack deployment, A router and a virtual machines were assigned same IP from IPv6 range. The only difference was the notation, so it may be the case that notation differences are not being interpret by management server correctly. fc00:0003:1373::0002 was assigned to router and fc00:3:1373::2 was assigned to the guest VM. Please refer to the attached screen and logs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6854) MS:IPv6: IP6 network address with notation differences are treated as same IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-6854. Resolution: Fixed MS:IPv6: IP6 network address with notation differences are treated as same IP - Key: CLOUDSTACK-6854 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6854 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: Parth Jagirdar Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Attachments: Screen Shot 2014-06-05 at 11.42.09 AM.png, management-server.log.zip Observed in a dual stack deployment, A router and a virtual machines were assigned same IP from IPv6 range. The only difference was the notation, so it may be the case that notation differences are not being interpret by management server correctly. fc00:0003:1373::0002 was assigned to router and fc00:3:1373::2 was assigned to the guest VM. Please refer to the attached screen and logs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041674#comment-14041674
]
ASF subversion and git services commented on CLOUDSTACK-6444:
-
Commit 24401e0b2b575d1aa151dbf5d4e0e0e1de4e9361 in cloudstack's branch
refs/heads/4.4-forward from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24401e0 ]
CLOUDSTACK-6444: Fixing the issue with iSCSI path Format /targetIQN/LUN.
Signed-off-by: Koushik Das kous...@apache.org
[Automation] test_01_primary_storage_iscsi failed on
test_primary_storage.py - Wrong iscsi path format - it should be
/targetIQN/LUN
Key: CLOUDSTACK-6444
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6444
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Damodar Reddy T
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.log.2014-04-16.gz
Error Message:
Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
begin captured logging
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
STARTED : TC: test_01_primary_storage_iscsi :::
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listZones {}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
HTTP/1.1 200 735
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
Response: { listzonesresponse : { count:2 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
{id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listClusters {'zoneid':
[jira] [Commented] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041676#comment-14041676
]
Sudha Ponnaganti commented on CLOUDSTACK-6444:
--
I am OOO from 6/23 through 6/27.
[Automation] test_01_primary_storage_iscsi failed on
test_primary_storage.py - Wrong iscsi path format - it should be
/targetIQN/LUN
Key: CLOUDSTACK-6444
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6444
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Damodar Reddy T
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.log.2014-04-16.gz
Error Message:
Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
begin captured logging
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
STARTED : TC: test_01_primary_storage_iscsi :::
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listZones {}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
HTTP/1.1 200 735
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
Response: { listzonesresponse : { count:2 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
{id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listClusters {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: CGgAerZxK5EJBr34YnPiWBJHqWg=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
[jira] [Commented] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041683#comment-14041683
]
ASF subversion and git services commented on CLOUDSTACK-6444:
-
Commit d3ffb7a5659bf988d00f607ee14cc07741b76c4a in cloudstack's branch
refs/heads/master from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d3ffb7a ]
CLOUDSTACK-6444: Fixing the issue with iSCSI path Format /targetIQN/LUN.
Signed-off-by: Koushik Das kous...@apache.org
[Automation] test_01_primary_storage_iscsi failed on
test_primary_storage.py - Wrong iscsi path format - it should be
/targetIQN/LUN
Key: CLOUDSTACK-6444
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6444
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Damodar Reddy T
Priority: Critical
Fix For: 4.4.0
Attachments: management-server.log.2014-04-16.gz
Error Message:
Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
begin captured logging
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
STARTED : TC: test_01_primary_storage_iscsi :::
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listZones {}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
HTTP/1.1 200 735
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
Response: { listzonesresponse : { count:2 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
{id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listClusters {'zoneid':
[jira] [Created] (CLOUDSTACK-6980) UI for RegisterTemplate API does not expose requireshvm parameter
Kishan Kavala created CLOUDSTACK-6980: - Summary: UI for RegisterTemplate API does not expose requireshvm parameter Key: CLOUDSTACK-6980 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6980 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Kishan Kavala requireshvm parameter should be false for LXC templates. UI does not provide option to set this parameter to false for RegisterTemplate API -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041711#comment-14041711 ] ASF subversion and git services commented on CLOUDSTACK-6923: - Commit a195e50ae7da4b4392844e2984823c1331ca1396 in cloudstack's branch refs/heads/4.4-forward from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a195e50 ] CLOUDSTACK-6923: Fixed issue in lbsticlbsticlbrule with lbrule id deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id --- Key: CLOUDSTACK-6923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.2 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.4.0 deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041715#comment-14041715 ] ASF subversion and git services commented on CLOUDSTACK-6923: - Commit 5da2e9828d2c83a67ffdbc4e3853be73fc681a6b in cloudstack's branch refs/heads/master from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5da2e98 ] CLOUDSTACK-6923: Fixed issue in lbsticlbsticlbrule with lbrule id deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id --- Key: CLOUDSTACK-6923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.2 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.4.0 deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6981) vm console page doesn't work in IE8
net_insect created CLOUDSTACK-6981:
--
Summary: vm console page doesn't work in IE8
Key: CLOUDSTACK-6981
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6981
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.2.1, 4.3.0
Environment: windows with IE8
Reporter: net_insect
there are redundant comma in ajaxkeys.js, such as “{type: KEY_UP, code:
X11_KEY_ADD, modifiers: 0, shift: true },” it does not work in IE8.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
