[jira] [Created] (CLOUDSTACK-5344) [Hyperv-V] Console access does not work for any VM
Sanjeev N created CLOUDSTACK-5344: - Summary: [Hyperv-V] Console access does not work for any VM Key: CLOUDSTACK-5344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5344 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Priority: Blocker Fix For: 4.3.0 [Hyperv-V] Console access does not work for any VM Steps to Reproduce: 1.Bring up CS with latest build from 4.3 using hyperv 2.Wait for the CPVM to come up. 3.Deploy guest vm and try to access the vm's console Result: === Server Internal Error -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5097) Volumes created with snapshot (which in turn were created from the volumes having some random data) carry garbage data
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837497#comment-13837497 ] Girish Shilamkar commented on CLOUDSTACK-5097: -- Abhinandan, We still this issue consistently on KVM. The commit messages were wrongly included in this ticket. Thanks, Girish Volumes created with snapshot (which in turn were created from the volumes having some random data) carry garbage data --- Key: CLOUDSTACK-5097 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5097 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Environment: Found on KVM Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Priority: Critical Fix For: 4.3.0 1. Create a virtual machine and data volume 2. Attach data volume to VM 3. Login to machine; create temp/test directories on data volume and write sample data into it 4. Snapshot the Volume 5. Create another Volume from snapshot 6. Mount/Attach volume to another VM 7. Now compare the data on the volume, data should match The directories and files created earlier exist on the volume, but the data in the files is garbage data instead of the data we have written into the volume earlier. Data is not matching. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5344) [Hyper-V] Console access does not work for any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-5344: -- Summary: [Hyper-V] Console access does not work for any VM (was: [Hyperv-V] Console access does not work for any VM) [Hyper-V] Console access does not work for any VM - Key: CLOUDSTACK-5344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5344 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Priority: Blocker Fix For: 4.3.0 [Hyperv-V] Console access does not work for any VM Steps to Reproduce: 1.Bring up CS with latest build from 4.3 using hyperv 2.Wait for the CPVM to come up. 3.Deploy guest vm and try to access the vm's console Result: === Server Internal Error -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5345) dont show upgrade router to new template if the router is already upgraded
shweta agarwal created CLOUDSTACK-5345: -- Summary: dont show upgrade router to new template if the router is already upgraded Key: CLOUDSTACK-5345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5345 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: shweta agarwal Fix For: 4.3.0 Repro steps : if routers are already upgraded to new system VM template don't show upgrade router to new template action item. Applicable for group by zone/pod cluster also. i.e if all the VRs in a pod/cluster/zone are upgraded and requires upgrade comes is no t hen don't show upgrade router to new template action button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5326) Create private gateway command doesnt fails on non upgraded vpc router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-5326:
---
Assignee: Kishan Kavala
Create private gateway command doesnt fails on non upgraded vpc router
---
Key: CLOUDSTACK-5326
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5326
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Upgrade, Virtual Router
Affects Versions: 4.3.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
Fix For: 4.3.0
epro steps:
1. On 3.0.7 setup create a VPC network
2. upgrade to 4.3
3.CreatePrivateGateway on vpc network when router is not upgraded
Bug:
CreatePrivateGatewayCmd command will succeed
Exception :
CreatePrivateGatewayCmd command should fail sating router needs upgrade:
MS log shows :
: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:35,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-12-02 14:24:38,447 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-13:null) SeqA 7-43654: Sending Seq 7-43654: { Ans: ,
MgmtId: 233845177509765, via: 7, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-12-02 14:24:42,434 DEBUG [c.c.a.ApiServlet]
(catalina-exec-17:ctx-51f64ba2) ===START=== 10.146.0.132 -- GET
command=createPrivateGatewaysourcenatsupported=trueresponse=jsonsessionkey=ddX%2Ft0njp20uMoPQpDyeHCV%2F4ns%3Dphysicalnetworkid=8b22e636-7774-44cb-b670-63f75c2fd157vpcid=a53580fe-719d-4113-b7f8-2b5819e60efdipaddress=10.147.51.99gateway=10.147.51.1netmask=255.255.255.0vlan=51aclid=05f7d01e-5809-11e3-b771-1db63afd4974_=1385974543623
2013-12-02 14:24:42,463 DEBUG [c.c.n.v.VpcManagerImpl]
(catalina-exec-17:ctx-51f64ba2 ctx-f2edd8ff) Creating Private gateway for VPC
[VPC [4-vpc4]
2013-12-02 14:24:42,463 INFO [c.c.n.v.VpcManagerImpl]
(catalina-exec-17:ctx-51f64ba2 ctx-f2edd8ff) creating new network for vpc
[VPC [4-vpc4] using broadcast uri: 51
2013-12-02 14:24:42,474 DEBUG [c.c.u.d.T.Transaction]
(catalina-exec-17:ctx-51f64ba2 ctx-f2edd8ff) Rolling back the transaction:
Time = 10 Name = catalina-exec-17; called by
-TransactionLegacy.rollback:896-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-Transaction.execute:41-NetworkServiceImpl.createPrivateNetwork:3924-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:57-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:622-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150
2013-12-02 14:24:42,565 INFO [c.c.a.ApiServer]
(catalina-exec-17:ctx-51f64ba2 ctx-f2edd8ff) Network with vlan vlan://51
already exists in zone 1
2013-12-02 14:24:42,566 DEBUG [c.c.a.ApiServlet]
(catalina-exec-17:ctx-51f64ba2 ctx-f2edd8ff) ===END=== 10.146.0.132 -- GET
command=createPrivateGatewaysourcenatsupported=trueresponse=jsonsessionkey=ddX%2Ft0njp20uMoPQpDyeHCV%2F4ns%3Dphysicalnetworkid=8b22e636-7774-44cb-b670-63f75c2fd157vpcid=a53580fe-719d-4113-b7f8-2b5819e60efdipaddress=10.147.51.99gateway=10.147.51.1netmask=255.255.25
DB shows vpc id router not upgraded
id element_id public_mac_address public_ip_address public_netmask
guest_netmask guest_ip_address is_redundant_router priority
is_priority_bumpup redundant_state stop_pending role
template_version scripts_version vpc_id
11 2 06:98:6e:00:00:2c 10.147.51.13 255.255.255.0 0 0 0
UNKNOWN 0 VIRTUAL_ROUTER Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST
2012 973c0565a2fe991f0903902588d4d52e 1
12 2 06:8f:e4:00:00:39 10.147.51.26 255.255.255.0 0 0 0
UNKNOWN 0 VIRTUAL_ROUTER Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST
2012 973c0565a2fe991f0903902588d4d52e 2
13 2 06:b0:ee:00:00:78 10.147.51.89 255.255.255.0 0 0 0
UNKNOWN 0 VIRTUAL_ROUTER Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST
2012 973c0565a2fe991f0903902588d4d52e 3
14 2 06:85:fc:00:00:2b 10.147.51.12 255.255.255.0 0 0 0
UNKNOWN 0 VIRTUAL_ROUTER Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST
2012 973c0565a2fe991f0903902588d4d52e 4
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5345) dont show upgrade router to new template if the router is already upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-5345: --- Attachment: upgrade router.jpg dont show upgrade router to new template if the router is already upgraded -- Key: CLOUDSTACK-5345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5345 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: shweta agarwal Fix For: 4.3.0 Attachments: upgrade router.jpg Repro steps : if routers are already upgraded to new system VM template don't show upgrade router to new template action item. Applicable for group by zone/pod cluster also. i.e if all the VRs in a pod/cluster/zone are upgraded and requires upgrade comes is no t hen don't show upgrade router to new template action button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5344) [Hyper-V] Console access does not work for any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-5344: -- Labels: hyper-V, (was: ) [Hyper-V] Console access does not work for any VM - Key: CLOUDSTACK-5344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5344 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Priority: Blocker Labels: hyper-V, Fix For: 4.3.0 [Hyperv-V] Console access does not work for any VM Steps to Reproduce: 1.Bring up CS with latest build from 4.3 using hyperv 2.Wait for the CPVM to come up. 3.Deploy guest vm and try to access the vm's console Result: === Server Internal Error -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5340) [Hyper-V] Control IPs are not getting released when VRs are in stopped state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-5340: -- Labels: hyper-V, (was: ) [Hyper-V] Control IPs are not getting released when VRs are in stopped state Key: CLOUDSTACK-5340 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5340 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, Network Controller Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Priority: Critical Labels: hyper-V, Fix For: 4.3.0 Attachments: management-server.log.2013-12-02.gz [Hyper-V] Control IPs are not getting released when VRs are in stopped state Steps to Reproduce: = 1.Bring up Advanced zone with Hyperv using latest 4.3 build 2.Implement network and make sure Vr is in running state 3.Stop,start VR multiple times. Expected Result: == Each time VR is stopped, control IP should be released to the pool and when the VR is started again it should get one ip address from the pool. Actual Result: === When the VR is stopped, control IP is not getting released to the pool. It remains in the reserved state. Currently in the setup there are only 5 system vms (SSVM,CPVM,3VRs) are there. So in total there should be only 6 controls IPs in reserved state.However op_dc_ip_address_alloc tables shows only one IP in free state out of 10 Pod Ip addresses. mysql select * from op_dc_ip_address_alloc; ++---++++--+-+-+ | id | ip_address| data_center_id | pod_id | nic_id | reservation_id | taken | mac_address | ++---++++--+-+-+ | 1 | 10.147.40.231 | 1 | 1 | 7 | 2709a8d9-71af-4c9b-9139-75e47aad6c76 | 2013-12-02 10:38:36 | 1 | | 2 | 10.147.40.232 | 1 | 1 | NULL | NULL | NULL| 2 | | 3 | 10.147.40.233 | 1 | 1 | 15 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:37 | 3 | | 4 | 10.147.40.234 | 1 | 1 | 23 | 1a1d5501-5e94-46b0-a770-af6277715f74 | 2013-12-02 17:15:05 | 4 | | 5 | 10.147.40.235 | 1 | 1 | 18 | 02e7a340-d1f3-46ab-adb9-dd91c3549d30 | 2013-12-02 15:44:13 | 5 | | 6 | 10.147.40.236 | 1 | 1 | 28 | 762014f4-fcd8-41d9-906c-1b05dbf07df7 | 2013-12-02 17:54:00 | 6 | | 7 | 10.147.40.237 | 1 | 1 | 18 | ced340b8-a34e-43fe-829e-7b790e380387 | 2013-12-02 15:25:37 | 7 | | 8 | 10.147.40.238 | 1 | 1 | 14 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:36 | 8 | | 9 | 10.147.40.239 | 1 | 1 | 23 | c2e2d7b1-4b4f-48da-b9ba-a8e64255711b | 2013-12-02 17:36:45 | 9 | | 10 | 10.147.40.240 | 1 | 1 | 18 | cb036c69-1721-4d13-b61d-42b6f2e7a76c | 2013-12-02 17:50:20 | 10 | ++---++++--+-+-+ 10 rows in set (0.00 sec) mysql select id,name,state from vm_instance where removed is null and vm_type!='User'; ++-+--+ | id | name| state| ++-+--+ | 2 | v-2-VM | Running | | 4 | s-4-VM | Running | | 6 | r-6-VM | Stopped | | 9 | r-9-VM | Stopped | | 11 | r-11-VM | Starting | ++-+--+ 5 rows in set (0.00 sec) Attaching management server log file with this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5339) VHDX file type not recognised by CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837538#comment-13837538 ] ASF subversion and git services commented on CLOUDSTACK-5339: - Commit d2bf5c9d5e5977120b3218707ee479d2c8f760ab in branch refs/heads/master from [~dlaffe...@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d2bf5c9 ] bug CLOUDSTACK-5339 VHDX file type not recognised by CloudStack --- Key: CLOUDSTACK-5339 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5339 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template, Volumes Affects Versions: 4.3.0, 4.4.0 Reporter: Donal Lafferty Assignee: Devdeep Singh Priority: Blocker Labels: hyper-V, Original Estimate: 24h Remaining Estimate: 24h Code that looks at the file extension of a template URL or volume does not recognise vhd. E.g. grep -R -A 2 -B 10 'Please specify a valid ' * --include=*.java When checking the fix, add a test for vhdx.gz decompression in the Hyper-V hypervisor. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5337) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837548#comment-13837548 ] ASF subversion and git services commented on CLOUDSTACK-5337: - Commit cb70ed1550c4cf659da92312a00d09496a32e1d6 in branch refs/heads/4.3 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cb70ed1 ] CLOUDSTACK-5337: Trimming account name (username) to 99 characters [Automation] Test cases creating account with more 100 character; account creation failing due to this -- Key: CLOUDSTACK-5337 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5337 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar test_add_remove_network.py:test_27_remove_nic_insufficient_permission test case failing from regression suite, this test case creating account with more than 100 character we should trim Similar issue reported in https://issues.apache.org/jira/browse/CLOUDSTACK-4747, instead of fixing in test case,please fix in Marvin; trim account name to 99 before creating account -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5337) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5337. -- Resolution: Fixed Fix Version/s: 4.4.0 4.3.0 4.2.1 [Automation] Test cases creating account with more 100 character; account creation failing due to this -- Key: CLOUDSTACK-5337 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5337 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Fix For: 4.2.1, 4.3.0, 4.4.0 test_add_remove_network.py:test_27_remove_nic_insufficient_permission test case failing from regression suite, this test case creating account with more than 100 character we should trim Similar issue reported in https://issues.apache.org/jira/browse/CLOUDSTACK-4747, instead of fixing in test case,please fix in Marvin; trim account name to 99 before creating account -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5337) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837550#comment-13837550 ] ASF subversion and git services commented on CLOUDSTACK-5337: - Commit cf1eaad846bc1fca2a2f966c6a4529d34b40cf56 in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cf1eaad ] CLOUDSTACK-5337: Trimming account name (username) to 99 characters [Automation] Test cases creating account with more 100 character; account creation failing due to this -- Key: CLOUDSTACK-5337 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5337 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar test_add_remove_network.py:test_27_remove_nic_insufficient_permission test case failing from regression suite, this test case creating account with more than 100 character we should trim Similar issue reported in https://issues.apache.org/jira/browse/CLOUDSTACK-4747, instead of fixing in test case,please fix in Marvin; trim account name to 99 before creating account -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5337) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837546#comment-13837546 ] ASF subversion and git services commented on CLOUDSTACK-5337: - Commit c39bc04be6f310cc684dec9923fdcefe95ac53d0 in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c39bc04 ] CLOUDSTACK-5337: Trimming account name (username) to 99 characters [Automation] Test cases creating account with more 100 character; account creation failing due to this -- Key: CLOUDSTACK-5337 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5337 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar test_add_remove_network.py:test_27_remove_nic_insufficient_permission test case failing from regression suite, this test case creating account with more than 100 character we should trim Similar issue reported in https://issues.apache.org/jira/browse/CLOUDSTACK-4747, instead of fixing in test case,please fix in Marvin; trim account name to 99 before creating account -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5186) egress rules - Increase time out to wait for router to start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5186: - Issue Type: Bug (was: Test) egress rules - Increase time out to wait for router to start Key: CLOUDSTACK-5186 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5186 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 Some test cases are failing because the router did not come up in the specified time. Increase the time out in this case to pass the test case. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5191) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5191: - Issue Type: Bug (was: Test) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed -- Key: CLOUDSTACK-5191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5191 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.3.0 Test case integration.component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failed in KVM basic zone setup Test cases failed while ping outside from VM, observed below error in log Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py, line 1067, in test_revoke_egress_rule Ping to outside world from VM should be successful File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Ping to outside world from VM should be successful begin captured logging test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Created security group with ID: 020865e7-d87b-4da9-b157-c315dc42e33d test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing ingress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing egress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Deploying VM in account: test-TestStartStopVMWithEgressRule-test_multiple_account_egress_rule_negative-Q4UAPL test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: SSH into VM: 10.223.250.230 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 paramiko.transport: DEBUG: starting thread (client mode): 0xd9d0ad0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.250.230: 0f8b3ff9dc4dce10340227dab3cac032 paramiko.transport: DEBUG: Trying discovered key a0114fddd71936946702c57069b4175b in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (password) successful! test_revoke_egress_rule
[jira] [Updated] (CLOUDSTACK-5191) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5191: - Labels: automation, product (was: ) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed -- Key: CLOUDSTACK-5191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5191 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Labels: automation,, product Fix For: 4.3.0 Test case integration.component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failed in KVM basic zone setup Test cases failed while ping outside from VM, observed below error in log Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py, line 1067, in test_revoke_egress_rule Ping to outside world from VM should be successful File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Ping to outside world from VM should be successful begin captured logging test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Created security group with ID: 020865e7-d87b-4da9-b157-c315dc42e33d test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing ingress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing egress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Deploying VM in account: test-TestStartStopVMWithEgressRule-test_multiple_account_egress_rule_negative-Q4UAPL test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: SSH into VM: 10.223.250.230 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 paramiko.transport: DEBUG: starting thread (client mode): 0xd9d0ad0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.250.230: 0f8b3ff9dc4dce10340227dab3cac032 paramiko.transport: DEBUG: Trying discovered key a0114fddd71936946702c57069b4175b in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (password)
[jira] [Updated] (CLOUDSTACK-5304) Hyper-V] Creation of a VM on shared primary storage is failing with network path not found
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sowmya Krishnan updated CLOUDSTACK-5304:
Labels: hyper-V, hyperv (was: hyperv)
Hyper-V] Creation of a VM on shared primary storage is failing with network
path not found
Key: CLOUDSTACK-5304
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5304
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, shared storage
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,, hyperv
Fix For: 4.3.0
The deployment of a VM on shared primary storage is failing with the
following error :
2013-11-28 15:53:57,713 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
exceptionHyper-V Job failed, Error Code:32768, Description: 'i-2-22-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
'i-2-22-VM': Cannot get information for attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. (Virtual machine
ID 1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
2013-11-28 15:53:57,716 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Cleaning up resources for the vm
VM[User|v1-shared] in Starting state
2013-11-28 15:53:57,718 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Sending { Cmd , MgmtId: 280320865129348, via:
1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Executing: { Cmd , MgmtId: 280320865129348,
via: 1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-41:ctx-a018c42b) Seq 1-73793602: Executing request
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5210) Need Support for the Hyper-V for the Report sockets CS-4908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan updated CLOUDSTACK-5210: Labels: hyper-V, (was: ) Need Support for the Hyper-V for the Report sockets CS-4908 --- Key: CLOUDSTACK-5210 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5210 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kiran Koneti Priority: Blocker Labels: hyper-V, For the report sockets feature we need to provide support for the Hyper-V hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3385) Wrong Image for Hyper-V System VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan updated CLOUDSTACK-3385: Labels: hyper-V, (was: ) Wrong Image for Hyper-V System VM - Key: CLOUDSTACK-3385 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3385 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: Future Reporter: Donal Lafferty Labels: hyper-V, Fix For: 4.3.0 Original Estimate: 24h Remaining Estimate: 24h The System VM registered on downloads.cloud.com for Hyper-V is not a Hyper-V image. It should be updated with a more recent version from http://jenkins.cloudstack.org/job/build-systemvm-master/? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5004) Hyper-V VMs in wrong state after Mgmt Server Restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan updated CLOUDSTACK-5004: Labels: hyper-V, (was: ) Hyper-V VMs in wrong state after Mgmt Server Restart Key: CLOUDSTACK-5004 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5004 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Donal Lafferty Labels: hyper-V, Original Estimate: 2h Remaining Estimate: 2h When mgmt server is restarted, the CloudStack kernel will synchronise VM states in its database with the values on the hypervisor. With Hyper-V hypervisors, this process fails. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3281) StartCommand carries VolumeObjectTO with format field of NULL
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sowmya Krishnan updated CLOUDSTACK-3281:
Labels: hyper-V, (was: )
StartCommand carries VolumeObjectTO with format field of NULL
-
Key: CLOUDSTACK-3281
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3281
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: Future
Environment: Hyper-V cluster
Reporter: Donal Lafferty
Labels: hyper-V,
Fix For: 4.3.0
Disk image format is missing from VolumeObjectTO in StartCommand. Not clear
whether Hypervisor needs to set this in the CopyCmdAnswer returned when the
volume is created, if the hypervisor is never to use the format when looking
up an image or if there is a bug in the system.
Sample command:
{
vm: {
id: 2,
name: v-2-VM,
type: ConsoleProxy,
cpus: 1,
minSpeed: 500,
maxSpeed: 500,
minRam: 1073741824,
maxRam: 1073741824,
arch: i686,
os: Debian GNU/Linux 5.0 (32-bit),
bootArgs: template=domP type=consoleproxy host=10.80.3.83 port=8250
name=v-2-VM premium=true zone=1 pod=1 guid=Proxy.2 proxy_vm=2
disable_rp_filter=true eth2ip=10.70.176.125 eth2mask=255.255.240.0
gateway=10.70.176.1 eth0ip=169.254.1.121 eth0mask=255.255.0.0
eth1ip=10.70.176.96 eth1mask=255.255.240.0 mgmtcidr=10.80.2.0/23
localgw=10.70.176.1 internaldns1=10.70.176.118 internaldns2=10.70.160.66
dns1=4.4.4.4,
rebootOnCrash: false,
enableHA: false,
limitCpuUse: false,
enableDynamicallyScaleVm: false,
vncPassword: ce12c56d3290de94,
params: {},
uuid: 89384857-b45d-47c0-8c7e-b011b0fcb118,
disks: [
{
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 35a079e4-7767-47d1-8629-72d32c866a08,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: 700b99d8-36e7-3f0c-b362-44f1c773241b-HypervResource,
id: 1,
poolType: Filesystem,
host: 10.70.176.29,
path: E:\\Disks\\,
port: 0
}
},
name: ROOT-2,
size: 140616708,
volumeId: 2,
vmName: v-2-VM,
accountId: 1,
id: 2
}
},
diskSeq: 0,
type: ROOT
}
],
nics: [
{
deviceId: 2,
networkRateMbps: -1,
defaultNic: true,
uuid: 022f8487-aba2-441b-85dd-3a68c3614fec,
ip: 10.70.176.125,
netmask: 255.255.240.0,
gateway: 10.70.176.1,
mac: 06:9d:26:00:00:0c,
dns1: 4.4.4.4,
broadcastType: Vlan,
type: Public,
broadcastUri: vlan://untagged,
isolationUri: vlan://untagged,
isSecurityGroupEnabled: false
},
{
deviceId: 0,
networkRateMbps: -1,
defaultNic: false,
uuid: 4fbb6713-de1e-4930-a944-6b5685c4ac62,
ip: 169.254.1.121,
netmask: 255.255.0.0,
gateway: 169.254.0.1,
mac: 0e:00:a9:fe:01:79,
broadcastType: LinkLocal,
type: Control,
isSecurityGroupEnabled: false
},
{
deviceId: 1,
networkRateMbps: -1,
defaultNic: false,
uuid: 2eeefa17-429e-47a5-bf41-bfa4742b712c,
ip: 10.70.176.96,
netmask: 255.255.240.0,
gateway: 10.70.176.1,
mac: 06:26:ae:00:00:07,
broadcastType: Native,
type: Management,
isSecurityGroupEnabled: false
}
]
},
hostIp: 10.70.176.29,
executeInSequence: false,
contextMap: {},
wait: 0
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3853) System VM Template for Hyper-V has wrong guest OS type Information on the Database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan updated CLOUDSTACK-3853: Labels: hyper-V, (was: ) System VM Template for Hyper-V has wrong guest OS type Information on the Database -- Key: CLOUDSTACK-3853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3853 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: Default template database, e.g. mysql select URL from template_view where hypervisor_type='Hyperv'; +---+ | url | +---+ | http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 | +---+ 1 row in set (0.00 sec) Reporter: Donal Lafferty Labels: hyper-V, Image recorded as Hyper-V system VM is not a valid Hyper-V image. It will not boot :( Fortunately, the more recent builds of the Hyper-V system VM do boot. This image has been examined, and it has the correct drivers for Hyper-V. See http://dlafferty.blogspot.co.uk/2013/07/installing-hyper-v-pv-drivers-for-linux.html for details of the required drivers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5191) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5191: - Labels: automation, product x (was: automation, product) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed -- Key: CLOUDSTACK-5191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5191 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Labels: automation,, product, x Fix For: 4.3.0 Test case integration.component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failed in KVM basic zone setup Test cases failed while ping outside from VM, observed below error in log Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py, line 1067, in test_revoke_egress_rule Ping to outside world from VM should be successful File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Ping to outside world from VM should be successful begin captured logging test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Created security group with ID: 020865e7-d87b-4da9-b157-c315dc42e33d test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing ingress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing egress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Deploying VM in account: test-TestStartStopVMWithEgressRule-test_multiple_account_egress_rule_negative-Q4UAPL test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: SSH into VM: 10.223.250.230 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 paramiko.transport: DEBUG: starting thread (client mode): 0xd9d0ad0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.250.230: 0f8b3ff9dc4dce10340227dab3cac032 paramiko.transport: DEBUG: Trying discovered key a0114fddd71936946702c57069b4175b in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO:
[jira] [Commented] (CLOUDSTACK-5161) add dynamic compute support to scale vm and upgrade vm apis.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837590#comment-13837590 ] ASF subversion and git services commented on CLOUDSTACK-5161: - Commit 089c7bc9f8f0861bb2eedc340ae623f5abeccfc3 in branch refs/heads/4.3 from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=089c7bc ] CLOUDSTACK-5161 use a map to specify the custom parameters instead of having one parameter each add dynamic compute support to scale vm and upgrade vm apis. Key: CLOUDSTACK-5161 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5161 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Priority: Critical Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5287) [doc] nTier Apps 2.0 : Remote access VPN to VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837607#comment-13837607 ] Radhika Nair commented on CLOUDSTACK-5287: -- commit 351cf1a8c5e5a115ebb0094ce6df1000d6848286 Author: radhikap radhika.puthiyet...@citrix.com Date: Tue Dec 3 17:13:03 2013 +0530 CLOUDSTACK-5287 remote access VPN in VPC [doc] nTier Apps 2.0 : Remote access VPN to VPC --- Key: CLOUDSTACK-5287 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5287 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Radhika Nair Assignee: Radhika Nair Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5022) [Automation] Failed to create volume from snapshot in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837608#comment-13837608
]
ASF subversion and git services commented on CLOUDSTACK-5022:
-
Commit 03ba659ae7263ca4fdb7c1c0eaccbecdf45594e8 in branch refs/heads/4.2 from
[~dgrizzanti]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03ba659 ]
CLOUDSTACK-5022: NullPointerException when invalid zone is passed into
UsageEventUtils
[Automation] Failed to create volume from snapshot in KVM
-
Key: CLOUDSTACK-5022
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5022
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.2.1
Environment: KVM (RHEL 6.3)
Build : 4.2
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Blocker
Fix For: 4.2.1
Attachments: CLOUDSTACK-5022.rar
Steps to reproduce
Step 1 : Create snapshot of ROOT volume
Step 2 : Create volume from snapshot
Failed to create volume with below null pointer exception
2013-11-01 08:19:18,229 DEBUG [agent.transport.Request]
(Job-Executor-147:job-6486 = [ 14b465b9-0c03-4783-866f-1296b20c358b ]) Seq
1-894971116: Sending { Cmd , MgmtId: 29066118877352, via: 1, Ver: v1, Flags:
11,
[{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:911,publicIp:10.223.122.92,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:39:a6:00:00:55,networkRate:200,trafficType:Public},{accountId:911,publicIp:10.223.122.113,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:52:bb:00:00:55,networkRate:200,trafficType:Public},{accountId:911,publicIp:10.223.122.79,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:52:bb:00:00:55,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.0.81,router.name:r-1662-QA},wait:0}}]
}
2013-11-01 08:19:18,345 DEBUG [agent.transport.Request]
(AgentManager-Handler-6:null) Seq 2-877402380: Processing: { Ans: , MgmtId:
29066118877352, via: 2, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.createVolumeFromSnapshot(KVMStorageProcessor.java:1178)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:86)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1286)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
java.lang.Thread.run(Thread.java:679)\n,wait:0}}] }
2013-11-01 08:19:18,345 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-6:null) Seq 2-877402380: No more commands found
2013-11-01 08:19:18,345 DEBUG [agent.transport.Request]
(Job-Executor-120:job-6487 = [ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Seq
2-877402380: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
Flags: 110, { Answer } }
2013-11-01 08:19:18,350 WARN
[storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-120:job-6487 =
[ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Unsupported data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@3918ddd), no
need to delete from object in store ref table
2013-11-01 08:19:18,372 WARN
[storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-120:job-6487 =
[ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Snapshot 38 is not found on image
store 1, so no need to delete
2013-11-01 08:19:18,372 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-120:job-6487 = [ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Failed
to create volume from snapshot:java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.createVolumeFromSnapshot(KVMStorageProcessor.java:1178)
at
[jira] [Resolved] (CLOUDSTACK-5160) add a map to specify the custom parameters in the deployvm api.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5160. -- Resolution: Fixed 089c7bc9f8f0861bb2eedc340ae623f5abeccfc3 4.3 add a map to specify the custom parameters in the deployvm api. Key: CLOUDSTACK-5160 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5160 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.3.0 As of now we are passing the custom parametes to the deployvm command using one parameter for each of the values. need to changes this and use a map instead. this will be easier to add other parameters later and a neater way to group all the custom parameters together. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4904) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837627#comment-13837627 ] Harikrishna Patnala commented on CLOUDSTACK-4904: - Can you please review my patch submitted here @https://reviews.apache.org/r/15902/ Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4904 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4904 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 Functionality required/broken - For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4697) Not able to delete Primary storage when there are no hosts in the cluster.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-4697. - Resolution: Duplicate CLOUDSTACK-4402 Not able to delete Primary storage when there are no hosts in the cluster. -- Key: CLOUDSTACK-4697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: Build from 4.2-forward Reporter: Sangeetha Hariharan Assignee: Koushik Das Priority: Critical Fix For: 4.3.0 Not able to delete Primary storage when there are no hosts in the cluster. Steps to reproduce the problem: I had 1 cluster with 1 cluster-wide primary storage and 1 host. Put the host is maintenance mode and deleted the host successfully. Put the primary storage in maintenance mode. Try to delete the primary storage. Primary storage deletion fails with Failed to delete storage pool on host. Tried with forced option set to true. Same issue is seen. Following is the exception seen in management server logs: http://10.223.240.160:8080/client/api?command=deleteStoragePoolid=6aa75bda-523e-3a70-876a-551889baf1fbforced=trueresponse=jsonsessionkey=w5yXStAmUJHVfEBV5vAYnmtnKeI%3D_=1379455061206 2013-09-17 14:47:14,109 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) ===START=== 10.215.3.9 -- GET command=deleteStoragePoolid=6aa75bda-523e-3a70-8 76a-551889baf1fbforced=trueresponse=jsonsessionkey=w5yXStAmUJHVfEBV5vAYnmtnKeI%3D_=1379455061206 2013-09-17 14:47:14,121 ERROR [cloud.api.ApiServer] (catalina-exec-2:null) unhandled exception executing api command: deleteStoragePool com.cloud.utils.exception.CloudRuntimeException: Failed to delete storage pool on host at org.apache.cloudstack.storage.datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl.deleteDataStore(CloudStackPrimaryDataStoreLifeCycleImpl. java:478) at com.cloud.storage.StorageManagerImpl.deletePool(StorageManagerImpl.java:937) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.admin.storage.DeletePoolCmd.execute(DeletePoolCmd.java:78) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-17 14:47:14,124 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) ===END=== 10.215.3.9 -- GET command=deleteStoragePoolid=6aa75bda-523e-3a70-876 a-551889baf1fbforced=trueresponse=jsonsessionkey=w5yXStAmUJHVfEBV5vAYnmtnKeI%3D_=1379455061206 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5167) Basic Zone - Egress - Ping to outside world from VM still possible even after revoking the egress rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-5167. --- Resolution: Invalid After revoking egress rule the default behaviour is allow is applied. So it is issue (CLOUDSTACK-5168) with the script and it got fixed Basic Zone - Egress - Ping to outside world from VM still possible even after revoking the egress rule -- Key: CLOUDSTACK-5167 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5167 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Environment: Basic Zone Reporter: Ashutosk Kelkar Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Create an account. Create a security group for this account. Authorize egress and ingress rule for this security group. Deploy a VM in this account with above security group. SSH to VM and try pinging google, ping is successful. Now revoke the egress rule and try pinging google Ping is still successful, it should fail after revoking the egress rule. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5168) component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5168: - Issue Type: Bug (was: Test) component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error - Key: CLOUDSTACK-5168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5168 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic Zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 Test case fails with assertion error Ping to outside world should be successful -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5168) component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5168: - Labels: automation (was: ) component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error - Key: CLOUDSTACK-5168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5168 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic Zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 Test case fails with assertion error Ping to outside world should be successful -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5168) component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5168. -- Resolution: Fixed component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failing with assertion error - Key: CLOUDSTACK-5168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5168 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic Zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 Test case fails with assertion error Ping to outside world should be successful -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5346) component.test_project_resources.TestNetwork.test_03_network_create failed due to Exception during cleanup: Failed to delete network
Gaurav Aradhye created CLOUDSTACK-5346: -- Summary: component.test_project_resources.TestNetwork.test_03_network_create failed due to Exception during cleanup: Failed to delete network Key: CLOUDSTACK-5346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5346 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 The test case failed in cleanup operation while deleting the shared network created. Reason: It still has VMs in it. Solution: First delete the VMs in the network, wait for expunge interval and then proceed for cleanup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5346) component.test_project_resources.TestNetwork.test_03_network_create failed due to Exception during cleanup: Failed to delete network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye updated CLOUDSTACK-5346:
---
Description:
The test case failed in cleanup operation while deleting the shared network
created.
Log:
2013-12-04 00:04:21,276 WARN [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-97:ctx-1c01dfdf ctx-e1c82b96) Can't delete the network, not all
user vms are expunge
d. Vm VM[User|QA-ad2ee28a-cdbd-42ba-b3e1-33a2e1f1317c] is in Stopped state
2013-12-04 00:04:21,285 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-97:ctx-1c01dfdf) Complete async job-2761, jobStatus: FAILED,
resultCode: 530, resu
lt:
org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
to delete network}
Reason: It still has VMs in it.
Solution: First delete the VMs in the network, wait for expunge interval and
then proceed for cleanup.
was:
The test case failed in cleanup operation while deleting the shared network
created.
Reason: It still has VMs in it.
Solution: First delete the VMs in the network, wait for expunge interval and
then proceed for cleanup.
component.test_project_resources.TestNetwork.test_03_network_create failed
due to Exception during cleanup: Failed to delete network
--
Key: CLOUDSTACK-5346
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5346
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
Labels: automation
Fix For: 4.3.0
The test case failed in cleanup operation while deleting the shared network
created.
Log:
2013-12-04 00:04:21,276 WARN [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-97:ctx-1c01dfdf ctx-e1c82b96) Can't delete the network, not all
user vms are expunge
d. Vm VM[User|QA-ad2ee28a-cdbd-42ba-b3e1-33a2e1f1317c] is in Stopped state
2013-12-04 00:04:21,285 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-97:ctx-1c01dfdf) Complete async job-2761, jobStatus: FAILED,
resultCode: 530, resu
lt:
org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
to delete network}
Reason: It still has VMs in it.
Solution: First delete the VMs in the network, wait for expunge interval and
then proceed for cleanup.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5347) component.test_project_resources.TestSnapshots.test_06_create_snapshots_in_project failed due to Check Snapshot state is Running or not
Gaurav Aradhye created CLOUDSTACK-5347: -- Summary: component.test_project_resources.TestSnapshots.test_06_create_snapshots_in_project failed due to Check Snapshot state is Running or not Key: CLOUDSTACK-5347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5347 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 The test case failed while checking the snapshot state. It checks the snapshot state in (BackedUp, CreatedOnPrimary) only whereas snapshot could also be Allocated because the snapshot gets Allocated first on primary storage before getting created in primary storage and getting backed up on secondary storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5304) Hyper-V] Creation of a VM on shared primary storage is failing with network path not found
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837729#comment-13837729
]
Devdeep Singh commented on CLOUDSTACK-5304:
---
Fixed in commit 80a5dd75cdaaabd12c3ee80ffa03a1f5959ca66e.
Hyper-V] Creation of a VM on shared primary storage is failing with network
path not found
Key: CLOUDSTACK-5304
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5304
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, shared storage
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,, hyperv
Fix For: 4.3.0
The deployment of a VM on shared primary storage is failing with the
following error :
2013-11-28 15:53:57,713 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
exceptionHyper-V Job failed, Error Code:32768, Description: 'i-2-22-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
'i-2-22-VM': Cannot get information for attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. (Virtual machine
ID 1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
2013-11-28 15:53:57,716 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Cleaning up resources for the vm
VM[User|v1-shared] in Starting state
2013-11-28 15:53:57,718 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Sending { Cmd , MgmtId: 280320865129348, via:
1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Executing: { Cmd , MgmtId: 280320865129348,
via: 1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-41:ctx-a018c42b) Seq 1-73793602: Executing request
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5304) Hyper-V] Creation of a VM on shared primary storage is failing with network path not found
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-5304.
---
Resolution: Fixed
Hyper-V] Creation of a VM on shared primary storage is failing with network
path not found
Key: CLOUDSTACK-5304
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5304
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, shared storage
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,, hyperv
Fix For: 4.3.0
The deployment of a VM on shared primary storage is failing with the
following error :
2013-11-28 15:53:57,713 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
exceptionHyper-V Job failed, Error Code:32768, Description: 'i-2-22-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
'i-2-22-VM': Cannot get information for attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. (Virtual machine
ID 1A869BE5-170C-4319-9D5B-C19454BAFEBE)
Failed to open attachment
'\\10.102.192.19/HYPERV-SMB/abhinav-primary2\ROOT-22.vhd'. Error: 'The
network path was not found.'.
2013-11-28 15:53:57,716 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-3:ctx-486eb19d ctx-1ff2cbf2) Cleaning up resources for the vm
VM[User|v1-shared] in Starting state
2013-11-28 15:53:57,718 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Sending { Cmd , MgmtId: 280320865129348, via:
1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.t.Request] (Job-Executor-3:ctx-486eb19d
ctx-1ff2cbf2) Seq 1-73793602: Executing: { Cmd , MgmtId: 280320865129348,
via: 1(10.102.192.9), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-22-VM,wait:0}}]
}
2013-11-28 15:53:57,719 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-41:ctx-a018c42b) Seq 1-73793602: Executing request
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5339) VHDX file type not recognised by CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-5339: -- Assignee: Rajesh Battala (was: Devdeep Singh) VHDX file type not recognised by CloudStack --- Key: CLOUDSTACK-5339 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5339 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template, Volumes Affects Versions: 4.3.0, 4.4.0 Reporter: Donal Lafferty Assignee: Rajesh Battala Priority: Blocker Labels: hyper-V, Original Estimate: 24h Remaining Estimate: 24h Code that looks at the file extension of a template URL or volume does not recognise vhd. E.g. grep -R -A 2 -B 10 'Please specify a valid ' * --include=*.java When checking the fix, add a test for vhdx.gz decompression in the Hyper-V hypervisor. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5330) [Hyper-V] VR creation fails in shared network while assigning IP to VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala resolved CLOUDSTACK-5330.
Resolution: Fixed
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=99e65d051dcd0b87fab86b6c65bb3c51c29f037f
[Hyper-V] VR creation fails in shared network while assigning IP to VR
--
Key: CLOUDSTACK-5330
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5330
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: 4.3, Advanced zone Shared n/w, Hyper-V
Reporter: Sowmya Krishnan
Assignee: Rajesh Battala
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: shared_nw_error.log
Shared network in advanced zone:
Launching VR fails in shared network while allocating an IP to VR.
Steps:
Create shared n/w offering with DHCP, DNS, LB, SourceNAT, PF
Create a shared n/w with the above offering, with scope = account
Specify required parameters for gateway, start, end IPs
Launch VM
VR launch fails due to following error:
.StartCommand fail on exceptionAn invalid IP address was specified.
Following is the exception seen:
2013-12-02 16:42:56,881 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-478:ctx-e3c75946) POST response
is[{com.cloud.agent.api.StartAnswer:{result:false,details:com.cloud
.agent.api.StartCommand fail on exceptionAn invalid IP address was
specified.,vm:{id:38,name:r-38-VM,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728
,maxRam:134217728,arch:i686,os:Debian GNU/Linux 5.0
(32-bit),bootArgs: template=domP name=r-38-VM eth0ip=10.102.198.3
eth0mask=255.255.255.240 gateway=10.102.198.1 domain=cs3cl
oud.internal dhcprange=10.102.198.1 eth1ip=10.102.195.52
eth1mask=255.255.252.0 type=dhcpsrvr disable_rp_filter=true dns1=10.140.50.5
dns2= ip6dns1= ip6dns2=,rebootOnCrash:false,enableH
A:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:f4f8f227e1dc93f2,params:{},uuid:21b5e4ef-f9b4-4721-b69e-830e30838a6f,disks:[{data:{org.apache.cloudst
ack.storage.to.VolumeObjectTO:{uuid:085d9286-e572-4e9c-aab9-6718550fd9c6,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4e16f596-365a-3
153-b962-02ae3a12ec4d-HypervResource,id:4,poolType:Filesystem,host:10.102.192.9,path:C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,port:0,url:Filesystem://10
.102.192.9/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks/?ROLE=PrimarySTOREUUID=4e16f596-365a-3153-b962-02ae3a12ec4d-HypervResource}},name:ROOT-38,size:2101252608,volum
eId:40,vmName:r-38-VM,accountId:1,id:40,deviceId:0,hypervisorType:Hyperv}},diskSeq:0,type:ROOT,_details:{managed:false,storagePort:0,storageHost:10.102.192
.9,volumeSize:2101252608}}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,uuid:1a04b57a-825e-432d-879f-ce4643bb222b,ip:10.102.198.3,netmask:255.255.255.240,
gateway:10.102.198.1,mac:06:d7:2e:00:00:26,dns1:10.140.50.5,dns2:,broadcastType:Vlan,type:Guest,broadcastUri:vlan://110,isolationUri:vlan://110,isSecurityGr
oupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:81a44c44-a71e-46bd-ad6b-273e73c1bb87,ip:10.102.195.52,netmask:255.255.252.0,gateway:10.102.192.1
,mac:02:00:05:d0:00:06,broadcastType:Native,type:Control,isSecurityGroupEnabled:false}]},contextMap:{}}}]
2013-12-02 16:42:56,882 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-478:ctx-e3c75946) executeRequest received response
[{com.cloud.agent.api.StartAnswer:{vm:{id:38,nam
e:r-38-VM,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003
ddomP name\u003dr-38-VM eth0ip\u003d10.102.198.3
eth0mask\u003d255.255.255.240 gateway\u003d10.102.198.1
domain\u003dcs3cloud.internal dhcprange\u003d10.102.198.1
eth1ip\u003d10.102.195.52
eth1mask\u003d255.255.252.0 type\u003ddhcpsrvr disable_rp_filter\u003dtrue
dns1\u003d10.140.50.5 dns2\u003d ip6dns1\u003d
ip6dns2\u003d,rebootOnCrash:false,enableHA:true,limitCpuUse:
false,enableDynamicallyScaleVm:false,vncPassword:f4f8f227e1dc93f2,params:{},uuid:21b5e4ef-f9b4-4721-b69e-830e30838a6f,disks:[{data:{org.apache.cloudstack.storage.to.VolumeO
bjectTO:{uuid:085d9286-e572-4e9c-aab9-6718550fd9c6,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4e16f596-365a-3153-b962-02ae3a12ec4d-
HypervResource,id:4,poolType:Filesystem,host:10.102.192.9,path:C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,port:0,url:Filesystem://10.102.192.9/C:\\Users\\
[jira] [Assigned] (CLOUDSTACK-5004) Hyper-V VMs in wrong state after Mgmt Server Restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-5004: -- Assignee: Rajesh Battala (was: Donal Lafferty) Hyper-V VMs in wrong state after Mgmt Server Restart Key: CLOUDSTACK-5004 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5004 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Original Estimate: 2h Remaining Estimate: 2h When mgmt server is restarted, the CloudStack kernel will synchronise VM states in its database with the values on the hypervisor. With Hyper-V hypervisors, this process fails. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-3853) System VM Template for Hyper-V has wrong guest OS type Information on the Database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-3853: -- Assignee: Rajesh Battala System VM Template for Hyper-V has wrong guest OS type Information on the Database -- Key: CLOUDSTACK-3853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3853 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: Default template database, e.g. mysql select URL from template_view where hypervisor_type='Hyperv'; +---+ | url | +---+ | http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 | +---+ 1 row in set (0.00 sec) Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Image recorded as Hyper-V system VM is not a valid Hyper-V image. It will not boot :( Fortunately, the more recent builds of the Hyper-V system VM do boot. This image has been examined, and it has the correct drivers for Hyper-V. See http://dlafferty.blogspot.co.uk/2013/07/installing-hyper-v-pv-drivers-for-linux.html for details of the required drivers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3853) System VM Template for Hyper-V has wrong guest OS type Information on the Database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-3853. Resolution: Fixed System VM Template for Hyper-V has wrong guest OS type Information on the Database -- Key: CLOUDSTACK-3853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3853 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: Default template database, e.g. mysql select URL from template_view where hypervisor_type='Hyperv'; +---+ | url | +---+ | http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 | +---+ 1 row in set (0.00 sec) Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Image recorded as Hyper-V system VM is not a valid Hyper-V image. It will not boot :( Fortunately, the more recent builds of the Hyper-V system VM do boot. This image has been examined, and it has the correct drivers for Hyper-V. See http://dlafferty.blogspot.co.uk/2013/07/installing-hyper-v-pv-drivers-for-linux.html for details of the required drivers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3853) System VM Template for Hyper-V has wrong guest OS type Information on the Database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837743#comment-13837743 ] Rajesh Battala commented on CLOUDSTACK-3853: verified system template guest os id is mapping to debian based guest os id. System VM Template for Hyper-V has wrong guest OS type Information on the Database -- Key: CLOUDSTACK-3853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3853 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: Default template database, e.g. mysql select URL from template_view where hypervisor_type='Hyperv'; +---+ | url | +---+ | http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 | +---+ 1 row in set (0.00 sec) Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Image recorded as Hyper-V system VM is not a valid Hyper-V image. It will not boot :( Fortunately, the more recent builds of the Hyper-V system VM do boot. This image has been examined, and it has the correct drivers for Hyper-V. See http://dlafferty.blogspot.co.uk/2013/07/installing-hyper-v-pv-drivers-for-linux.html for details of the required drivers. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5004) Hyper-V VMs in wrong state after Mgmt Server Restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837748#comment-13837748 ] Rajesh Battala commented on CLOUDSTACK-5004: This commit should fix the issue Rajesh Battala rajesh.batt...@citrix.com Fri, 8 Nov 2013 07:41:32 + (12:41 +0530) committer Rajesh Battala rajesh.batt...@citrix.com Fri, 8 Nov 2013 07:44:52 + (12:44 +0530) commit 63b23bb341e86daf3b6407a1710c1b2a113b9088 treed1bc35becbd2461d760ab6c863caa8e71505926ftree | snapshot parent 3c350ab0b8ce1687a8f7e27e9e2f8e8d0fa68c47commit | diff Fixed VmSync issues in HyperV. Hyper-V VMs in wrong state after Mgmt Server Restart Key: CLOUDSTACK-5004 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5004 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Original Estimate: 2h Remaining Estimate: 2h When mgmt server is restarted, the CloudStack kernel will synchronise VM states in its database with the values on the hypervisor. With Hyper-V hypervisors, this process fails. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5004) Hyper-V VMs in wrong state after Mgmt Server Restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-5004. Resolution: Fixed Hyper-V VMs in wrong state after Mgmt Server Restart Key: CLOUDSTACK-5004 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5004 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Original Estimate: 2h Remaining Estimate: 2h When mgmt server is restarted, the CloudStack kernel will synchronise VM states in its database with the values on the hypervisor. With Hyper-V hypervisors, this process fails. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3385) Wrong Image for Hyper-V System VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837752#comment-13837752 ] Rajesh Battala commented on CLOUDSTACK-3385: I had generated a new systemvm image, will test and close it Wrong Image for Hyper-V System VM - Key: CLOUDSTACK-3385 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3385 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: Future Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Fix For: 4.3.0 Original Estimate: 24h Remaining Estimate: 24h The System VM registered on downloads.cloud.com for Hyper-V is not a Hyper-V image. It should be updated with a more recent version from http://jenkins.cloudstack.org/job/build-systemvm-master/? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-3385) Wrong Image for Hyper-V System VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-3385: -- Assignee: Rajesh Battala Wrong Image for Hyper-V System VM - Key: CLOUDSTACK-3385 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3385 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: Future Reporter: Donal Lafferty Assignee: Rajesh Battala Labels: hyper-V, Fix For: 4.3.0 Original Estimate: 24h Remaining Estimate: 24h The System VM registered on downloads.cloud.com for Hyper-V is not a Hyper-V image. It should be updated with a more recent version from http://jenkins.cloudstack.org/job/build-systemvm-master/? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5267: Component/s: (was: Management Server) Automation [Automation] instance.name name should not append with VM's Name Key: CLOUDSTACK-5267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Branch : 4.3.0 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.3.0 Steps to reproduce Step 1 : set instance.name=TestVM in global parameter Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the VM Actual Result UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be deployed with name 56276ab1-3353-473c-8b35-f27f81f68bd8 vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here instance.name also included We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan reopened CLOUDSTACK-5267: - Assignee: (was: Rajani Karuturi) This changes is made intentionally; we need to fix in test case integration.component.test_custom_hostname.TestInstanceNameFlagFalse.test_01_custom_hostname_instancename_false integration.component.test_custom_hostname.TestInstanceNameFlagFalse.test_02_custom_hostname_instancename_false Changing component is automation [Automation] instance.name name should not append with VM's Name Key: CLOUDSTACK-5267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Branch : 4.3.0 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.3.0 Steps to reproduce Step 1 : set instance.name=TestVM in global parameter Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the VM Actual Result UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be deployed with name 56276ab1-3353-473c-8b35-f27f81f68bd8 vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here instance.name also included We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5267: Labels: automation (was: ) [Automation] instance.name name should not append with VM's Name Key: CLOUDSTACK-5267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Branch : 4.3.0 Reporter: Rayees Namathponnan Priority: Blocker Labels: automation Fix For: 4.3.0 Steps to reproduce Step 1 : set instance.name=TestVM in global parameter Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the VM Actual Result UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be deployed with name 56276ab1-3353-473c-8b35-f27f81f68bd8 vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here instance.name also included We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5348) [Automation] Disabled test cases from test_egress_fw_rules.py need to be enabled
Rayees Namathponnan created CLOUDSTACK-5348: --- Summary: [Automation] Disabled test cases from test_egress_fw_rules.py need to be enabled Key: CLOUDSTACK-5348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5348 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Environment: Automation Reporter: Rayees Namathponnan There are 4 test cases disabled in test_egress_fw_rules.py, this defect created to track this; def test_05_egress_fr5(self): def test_05_1_egress_fr5(self): def test_08_egress_fr8(self): def test_08_1_egress_fr8(self): -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5349: Priority: Blocker (was: Major) [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: ALL branch 4.3 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
Rayees Namathponnan created CLOUDSTACK-5349: --- Summary: [Automation] VOLUME.CREATE missing in events table Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: ALL branch 4.3 Reporter: Rayees Namathponnan Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
Rayees Namathponnan created CLOUDSTACK-5350: --- Summary: [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) 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 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) 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(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at
[jira] [Created] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
Rayees Namathponnan created CLOUDSTACK-5351: --- Summary: [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.3.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen updated CLOUDSTACK-5145: Description: ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. was:ListNetworkACL API should filer ACLs by user and list ACLs which can be accessed by the user only ListNetworkACL API should list ACLs owned by the user only -- Key: CLOUDSTACK-5145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.1, 4.3.0 ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta reassigned CLOUDSTACK-5352: --- Assignee: Nitin Mehta CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
Nitin Mehta created CLOUDSTACK-5352: --- Summary: CPU cap calculated incorrectly for VMs on XenServer hosts Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-5352: Description: The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 was: The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe
[jira] [Resolved] (CLOUDSTACK-4504) VM creation Is failing using the Ubuntu ISO with Xen 6.1 and 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta resolved CLOUDSTACK-4504.
-
Resolution: Won't Fix
Cant fix this as this is a XS issue
VM creation Is failing using the Ubuntu ISO with Xen 6.1 and 6.2
Key: CLOUDSTACK-4504
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4504
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: 4.2.1
Reporter: Kiran Koneti
Assignee: Nitin Mehta
Priority: Critical
Fix For: 4.3.0
Attachments: Screen Shot 2013-08-28 at 2.57.40 PM.png,
management-server.zip
1)Registered a Ubuntu 10.04 32 bit in the CS.
2)Tried to create a VM using the ISO then observed the below error message
2013-08-26 21:28:58,345 DEBUG [agent.transport.Request]
(AgentManager-Handler-14:null) Seq 3-347996257: Processing: { Ans: , MgmtId:
6703101771911, via: 3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.storage.DownloadAnswer:{jobId:565318cc-d0b4-4365-aea2-044dedb938ea,downloadPct:100,errorString:Download
success, starting install
,downloadStatus:DOWNLOAD_IN_PROGRESS,downloadPath:/mnt/SecStorage/ec67adf1-b86c-3674-ad7f-46ddd34d104f/template/tmpl/2/202/dnld2917500853441314915tmp_,installPath:template/tmpl/2/202/202-2-c006beb1-8a48-3ac2-b4d5-af1b6c940b5e.iso,templateSize:0,templatePhySicalSize:0,checkSum:27aa354b8088527ffcd32007b51b25bf,result:true,details:Download
success, starting install ,wait:0}}] }
2013-08-26 21:29:00,477 DEBUG [cloud.server.StatsCollector]
(StatsCollector-1:null) StorageCollector is running...
^C
[root@Kiran-RHEl631 setup]# vi
/var/log/cloudstack/management/management-server.log
status: failure
residentOn: com.xensource.xenapi.Host@e79e523d
progress: 1.0
type: none/
result:
errorInfo: [INTERNAL_ERROR, xenopsd internal error:
XenguestHelper.Xenctrl_dom_linux_build_failure(2, elf_xen_note_check:
ERROR: Will only load images built \\\)]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
com.cloud.utils.exception.CloudRuntimeException: Unable to start VM(i-2-3-VM)
on host(fe1fce23-4155-4831-b669-a99988cd3259) due to Task failed! Task
record: uuid: d7d77fe7-2d04-35a2-df1f-200ca1a80bbc
nameLabel: Async.VM.start_on
nameDescription:
allowedOperations: []
currentOperations: {}
created: Mon Aug 26 12:06:14 IST 2013
finished: Mon Aug 26 12:06:17 IST 2013
status: failure
residentOn: com.xensource.xenapi.Host@e79e523d
progress: 1.0
type: none/
result:
errorInfo: [INTERNAL_ERROR, xenopsd internal error:
XenguestHelper.Xenctrl_dom_linux_build_failure(2, elf_xen_note_check:
ERROR: Will only load images built \\\)]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.startVM(CitrixResourceBase.java:3717)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1636)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:553)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:104)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
Atatching the MS logs for additional debugging.
The DB table entries for the Ubuntu templates for the Xen are as below:
mysql select * from guest_os_hypervisor where guest_os_id in (select id from
guest_os where display_name like '%ubu%');
+-+-+-+-+
| id | hypervisor_type | guest_os_name | guest_os_id |
+-+-+-+-+
| 79 | XenServer | Other install media | 59 |
| 80 | XenServer | Other install media | 100 |
| 83 | XenServer | Other install media | 121 |
| 84 | XenServer | Other install media | 126 |
| 85 | XenServer | Other install media | 122 |
| 86 | XenServer | Other install media | 127 |
| 87 | XenServer |
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838053#comment-13838053 ] Will Stevens commented on CLOUDSTACK-5278: -- 1. Regarding the default policy with a 'deny' default. - Because all of the devices you have mentioned already have a 'deny' by default policy, this bug does not show up in those implementations. Any device that tries to support the 'deny' by default policy provided by ACS which have allow egress traffic by default at the device level will have problems. This is because the deny rule is not actually created when the network is created, so the device default will be used (which in this case would be 'allow'), so the expected functionality is broken. 2. Not cleaning up system rules. - I still don't like that the cleanup of the system egress rules are not handled by ACS. ACS handles the clean up of all the other types of rules like this. I don't see why each provider should have to implement their own logic to handle the cleanup of these rules. Network restarts and such are bound to complicate things on a per provider basis. 3. The default system egress rules are not in the db. - I think that most of the problems stem from the fact that these rules are not in the DB. - The reason all of the system default rules get the same ID (of 0) is probably because the DB is not being referenced for the next available ID. - The rules would probably get cleaned up correctly if they were in the DB. (point 2) So it is my understanding it that because workarounds for these issues have been implemented for the providers that are currently available, these issues are not considered bugs? Fixing these issues will becoming increasingly difficult as more providers are added and have to build custom logic to handle these issues on a provider by provider basis. If it is expected that the providers should be handling these issues, then there should really be some documentation to describe the additional logic required by the providers to work around these issues. Egress Firewall rules clarifications Key: CLOUDSTACK-5278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5278 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 These issues may also exist in the 4.2 branch, but I am currently testing/working on the 4.3 branch. I believe these bugs were introduced with the change to the Network Service Offering to add the 'Default egress policy' dropdown. https://issues.apache.org/jira/browse/CLOUDSTACK-1578 I am trying to resolve the bugs this change introduced in the Palo Alto plugin. There are two types of Egress rules (from what I can tell). - FirewallRule.FirewallRuleType.System : this appears to be set up by the system on network creation to correspond to the global network default allow/deny egress rule. - FirewallRule.FirewallRuleType.User : any rule that a user creates through the UI will get this type. There are bugs associated with both of the options in the dropdown (allow and deny). Case: 'deny' - When the network is setup, it does not try to create the global deny rule for the network, but it appears to register that it exists. Instead, when the first egress rule is created by a user, the system sees both the 'system' and 'user' rules, so it will create both rules then. Case: both 'allow' and 'deny' - The clean up of the network global 'system' egress rules are never done. So when a network is deleted, it will leave an orphaned egress rule associated with the previous network's cidr. This is bound to cause many issues. - Even worse, it appears that the ID for the network global 'system' egress rule is hardcoded to '0'. Every time I try to spin up a new network it will attempt to create a rule with a '0' ID, but since one already exists with that ID, there is a config collision. In my case (Palo Alto), the second rule with the same ID gets ignored because it checks to see if the rule exists and it gets a 'yes' back because the previous network has an egress rule with that ID already. Let me know if you have additional questions... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5353) [Automation] listVpnUsers API returns null
Rayees Namathponnan created CLOUDSTACK-5353:
---
Summary: [Automation] listVpnUsers API returns null
Key: CLOUDSTACK-5353
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5353
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API, Management Server
Affects Versions: 4.3.0
Environment: Branch ; 4.3
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.3.0
Steps:
***
1.deploy the advance zone with hypervisor as KVM
2.deployvm on new network
3. Acquire new IP
4.enable vpn on Ip
5.create Vpn users
Expected result
Newly created user should be displayed same page
Actual Result
New added user not displayed
also below API call does not return anything
http://10.223.49.195:8096/?command=listVpnUserslistall=true
Firebug
1)
http://10.223.49.195:8080/client/api?command=addVpnUserresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Daccount=admindomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8password=dsdsusername=sddsds
{ addvpnuserresponse :
{id:8cedbb84-e4fa-4508-9465-6ad993377e72,jobid:d3377654-ad52-4b61-b746-525e788224de}
}
2)
http://10.223.49.195:8080/client/api?command=queryAsyncJobResultjobId=d3377654-ad52-4b61-b746-525e788224deresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3D_=1386100530785
{ queryasyncjobresultresponse :
{accountid:d644a994-5bbb-11e3-a447-1a6f7bb0d0a8,userid:d644e0b2-5bbb-11e3-a447-1a6f7bb0d0a8,cmd:org.apache.cloudstack.api.command.user.vpn.AddVpnUserCmd,jobstatus:1,jobprocstatus:0,jobresultcode:0,jobresulttype:object,jobresult:{vpnuser:{id:8cedbb84-e4fa-4508-9465-6ad993377e72,username:sddsds,account:admin,domainid:8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8,domain:ROOT}},created:2013-12-03T11:55:27-0800,jobid:d3377654-ad52-4b61-b746-525e788224de}
3)
http://10.223.49.195:8080/client/api?command=listVpnUsersresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Ddomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8account=admin_=1386100530852
_ 1386100530852
account admin
command listVpnUsers
domainid8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8
responsejson
sessionkey RfqSp9FX7ZZhKDOc6CWZLEekFO4=
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5114) Select VM for static NAT screen shouldn't have checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838143#comment-13838143 ] ASF subversion and git services commented on CLOUDSTACK-5114: - Commit af3add9353c46a77c933d1c704412cf25a8127b5 in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af3add9 ] CLOUDSTACK-5114: Remove checkbox column from dialog list view Select VM for static NAT screen shouldn't have checkbox. Key: CLOUDSTACK-5114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: jessica_screenshot_1.jpg The checkboxes shouldn’t be in “Select VM for static NAT” screen. Only one VM is allowed to select, so it should be selected by only radio button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5114) Select VM for static NAT screen shouldn't have checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838144#comment-13838144 ] ASF subversion and git services commented on CLOUDSTACK-5114: - Commit b5527e1f157c7f5701e10f117c1d1e18bdbfee93 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b5527e1 ] CLOUDSTACK-5114: Remove checkbox column from dialog list view Select VM for static NAT screen shouldn't have checkbox. Key: CLOUDSTACK-5114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: jessica_screenshot_1.jpg The checkboxes shouldn’t be in “Select VM for static NAT” screen. Only one VM is allowed to select, so it should be selected by only radio button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5114) Select VM for static NAT screen shouldn't have checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-5114. --- Resolution: Fixed Select VM for static NAT screen shouldn't have checkbox. Key: CLOUDSTACK-5114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: jessica_screenshot_1.jpg The checkboxes shouldn’t be in “Select VM for static NAT” screen. Only one VM is allowed to select, so it should be selected by only radio button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-5301) Router page is not listing VPC types router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle reopened CLOUDSTACK-5301: --- Assignee: Brian Federle (was: Alena Prokharchyk) Router page is not listing VPC types router --- Key: CLOUDSTACK-5301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5301 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: 4.3 build : CloudPlatform-4.3-860-rhel6.3 Reporter: shweta agarwal Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: router.jpg Repro steps : create few VR and VPC VR From infrastructure page select Router view all Bug : Router page is not showing VPC router (router belonging to type VPC)\ this brings a discrepancy in Count shown on infrastructure page and the list shown on router page As in my case infrastructure page shows 16 router but when i select router view all it shows only 12 entries as 4 router belongs to VPC API call http://10.147.40.27:8080/client/api?command=listRouterslistAll=truepage=1pagesize=20response=jsonsessionkey=lYYot5QzbQ89KDvUiFH66cT19hs%3Dforvpc=false_=1385 633369178 Need to make one more call with VPC=true as well This is affecting group by feature on router page introduced recently for upgrading router . Grouping feature is also giving wrong count. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5301) Router page is not listing VPC types router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838182#comment-13838182 ] Alena Prokharchyk commented on CLOUDSTACK-5301: --- If we don't show VPC Virtual routers on some other page, we should remove the flag. If VR and VPC VRs are displayed on the diff pages in the UI, then the flag should remain. Router page is not listing VPC types router --- Key: CLOUDSTACK-5301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5301 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: 4.3 build : CloudPlatform-4.3-860-rhel6.3 Reporter: shweta agarwal Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: router.jpg Repro steps : create few VR and VPC VR From infrastructure page select Router view all Bug : Router page is not showing VPC router (router belonging to type VPC)\ this brings a discrepancy in Count shown on infrastructure page and the list shown on router page As in my case infrastructure page shows 16 router but when i select router view all it shows only 12 entries as 4 router belongs to VPC API call http://10.147.40.27:8080/client/api?command=listRouterslistAll=truepage=1pagesize=20response=jsonsessionkey=lYYot5QzbQ89KDvUiFH66cT19hs%3Dforvpc=false_=1385 633369178 Need to make one more call with VPC=true as well This is affecting group by feature on router page introduced recently for upgrading router . Grouping feature is also giving wrong count. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4738) dynamic compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838193#comment-13838193 ] ASF subversion and git services commented on CLOUDSTACK-4738: - Commit 6a23f06217f4e1b702faf38ab40df43373faeddf in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6a23f06 ] CLOUDSTACK-4738: UI VM Wizard deployVM API has been changed to take in one new parameter CUSTOM_PARAMETERS instead of 3 parameters CPU_NUMBER/CPU_SPEED/MEMORY. Here is corresponding UI change. dynamic compute offering - Key: CLOUDSTACK-4738 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4738 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.3.0 Attachments: InstanceDetail_changeServiceOffering_when_selected_computeOffering_is_NOT_custom.jpg, InstanceDetail_changeServiceOffering_when_selected_computeOffering_is_custom.jpg Currently in cloudstack users have to pick a preconfigured service offering for creating VMs. we want to change this by providing a way to specify the custom values for cpu and ram without the need to tie them to some service offering, some thing like the custom disk offering. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4738) dynamic compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838194#comment-13838194 ] ASF subversion and git services commented on CLOUDSTACK-4738: - Commit 2cbaf04b9751f57f6937c87a1cfe2396c2e53910 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2cbaf04 ] CLOUDSTACK-4738: UI VM Wizard deployVM API has been changed to take in one new parameter CUSTOM_PARAMETERS instead of 3 parameters CPU_NUMBER/CPU_SPEED/MEMORY. Here is corresponding UI change. dynamic compute offering - Key: CLOUDSTACK-4738 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4738 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.3.0 Attachments: InstanceDetail_changeServiceOffering_when_selected_computeOffering_is_NOT_custom.jpg, InstanceDetail_changeServiceOffering_when_selected_computeOffering_is_custom.jpg Currently in cloudstack users have to pick a preconfigured service offering for creating VMs. we want to change this by providing a way to specify the custom values for cpu and ram without the need to tie them to some service offering, some thing like the custom disk offering. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-5349: - Assignee: Nitin Mehta [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: ALL branch 4.3 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-5350: - Assignee: frank zhang [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false -- Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Assignee: frank zhang Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) 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 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) 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
[jira] [Updated] (CLOUDSTACK-5353) [Automation] listVpnUsers API returns null
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5353:
-
Assignee: Alena Prokharchyk
[Automation] listVpnUsers API returns null
---
Key: CLOUDSTACK-5353
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5353
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.3.0
Environment: Branch ; 4.3
Reporter: Rayees Namathponnan
Assignee: Alena Prokharchyk
Priority: Blocker
Fix For: 4.3.0
Steps:
***
1.deploy the advance zone with hypervisor as KVM
2.deployvm on new network
3. Acquire new IP
4.enable vpn on Ip
5.create Vpn users
Expected result
Newly created user should be displayed same page
Actual Result
New added user not displayed
also below API call does not return anything
http://10.223.49.195:8096/?command=listVpnUserslistall=true
Firebug
1)
http://10.223.49.195:8080/client/api?command=addVpnUserresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Daccount=admindomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8password=dsdsusername=sddsds
{ addvpnuserresponse :
{id:8cedbb84-e4fa-4508-9465-6ad993377e72,jobid:d3377654-ad52-4b61-b746-525e788224de}
}
2)
http://10.223.49.195:8080/client/api?command=queryAsyncJobResultjobId=d3377654-ad52-4b61-b746-525e788224deresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3D_=1386100530785
{ queryasyncjobresultresponse :
{accountid:d644a994-5bbb-11e3-a447-1a6f7bb0d0a8,userid:d644e0b2-5bbb-11e3-a447-1a6f7bb0d0a8,cmd:org.apache.cloudstack.api.command.user.vpn.AddVpnUserCmd,jobstatus:1,jobprocstatus:0,jobresultcode:0,jobresulttype:object,jobresult:{vpnuser:{id:8cedbb84-e4fa-4508-9465-6ad993377e72,username:sddsds,account:admin,domainid:8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8,domain:ROOT}},created:2013-12-03T11:55:27-0800,jobid:d3377654-ad52-4b61-b746-525e788224de}
3)
http://10.223.49.195:8080/client/api?command=listVpnUsersresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Ddomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8account=admin_=1386100530852
_ 1386100530852
account admin
command listVpnUsers
domainid 8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8
response json
sessionkeyRfqSp9FX7ZZhKDOc6CWZLEekFO4=
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5343) Volume limit applied to project/account does not count root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-5343: - Assignee: Prachi Damle Volume limit applied to project/account does not count root disks - Key: CLOUDSTACK-5343 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5343 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: Gaurav Aradhye Assignee: Prachi Damle Fix For: 4.3.0 1. Create any project or account. 2. Set the volume limit as 1. 3. Deploy an instance without data disk in project/account. 4. Now you can see the root disk in the volumes, but if you list the account/project, then the volume count still shows as 0. 5. Now add new data disk. 6. Check volume count, now it shows it as 1 (But it should have shown as 2, and it should have failed at this stage only saying limit exceeded.) 7. Add another data disk (Now it will fail) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5342:
-
Assignee: Jayapal Reddy
Add NIC to virtual machine fails in KVM
---
Key: CLOUDSTACK-5342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: KVM advanced
Reporter: Gaurav Aradhye
Assignee: Jayapal Reddy
Fix For: 4.3.0
Add network to VM test cases fail in KVM with following error.
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
The same test cases execute successfully on XenServer. As per the feature
specification (see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
Add network to VM feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5114) Select VM for static NAT screen shouldn't have checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-5114: - Attachment: after_Brian_fixed_it_2013_12_03.jpg Select VM for static NAT screen shouldn't have checkbox. Key: CLOUDSTACK-5114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: after_Brian_fixed_it_2013_12_03.jpg, jessica_screenshot_1.jpg The checkboxes shouldn’t be in “Select VM for static NAT” screen. Only one VM is allowed to select, so it should be selected by only radio button. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3364) normal users are not allowed to edit their own iso
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838287#comment-13838287
]
ASF subversion and git services commented on CLOUDSTACK-3364:
-
Commit c1be40492460716502d62525418f1f712525bd7c in branch refs/heads/4.3 from
[~nitinme]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1be404 ]
CLOUDSTACK-3364:
change updateIsoPermissions API to accept isextractable paramter from normal
user
normal users are not allowed to edit their own iso
--
Key: CLOUDSTACK-3364
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3364
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: shweta agarwal
Assignee: Nitin Mehta
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT
admins are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured
field as editable to normal user , which normal user is not allowed to do
and api passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3364) normal users are not allowed to edit their own iso
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta resolved CLOUDSTACK-3364.
-
Resolution: Fixed
UI bug - CLOUDSTACK-5354 created for this
normal users are not allowed to edit their own iso
--
Key: CLOUDSTACK-3364
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3364
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: shweta agarwal
Assignee: Nitin Mehta
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT
admins are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured
field as editable to normal user , which normal user is not allowed to do
and api passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3364) normal users are not allowed to edit their own iso
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838288#comment-13838288
]
ASF subversion and git services commented on CLOUDSTACK-3364:
-
Commit 03c78247ccb8dd260350b8102d6ec415d30e892f in branch refs/heads/master
from [~nitinme]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03c7824 ]
CLOUDSTACK-3364:
change updateIsoPermissions API to accept isextractable paramter from normal
user
normal users are not allowed to edit their own iso
--
Key: CLOUDSTACK-3364
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3364
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: shweta agarwal
Assignee: Nitin Mehta
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT
admins are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured
field as editable to normal user , which normal user is not allowed to do
and api passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5354) CLONE - UI - normal users are not allowed to edit their own iso
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-5354:
Summary: CLONE - UI - normal users are not allowed to edit their own iso
(was: CLONE - normal users are not allowed to edit their own iso)
CLONE - UI - normal users are not allowed to edit their own iso
---
Key: CLOUDSTACK-5354
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5354
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT
admins are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured
field as editable to normal user , which normal user is not allowed to do
and api passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5354) CLONE - UI - normal users are not allowed to edit their own iso
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-5354:
Assignee: Jessica Wang (was: Nitin Mehta)
CLONE - UI - normal users are not allowed to edit their own iso
---
Key: CLOUDSTACK-5354
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5354
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: Nitin Mehta
Assignee: Jessica Wang
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT
admins are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured
field as editable to normal user , which normal user is not allowed to do
and api passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5354) CLONE - normal users are not allowed to edit their own iso
Nitin Mehta created CLOUDSTACK-5354:
---
Summary: CLONE - normal users are not allowed to edit their own iso
Key: CLOUDSTACK-5354
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5354
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.2.0
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Fix For: 4.3.0
Repro steps:
1.Create a domain
2.create a account under that domain
3.create a ISO as a account under the non root domain
4.Edit the ISO
BUg :
gets message:
Only ROOT admins are allowed to modify this attribute.
API:
http://10.147.38.141:8080/client/api?command=updateIsoPermissionsresponse=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Did=2b8c87a0-4325-418d-80af-ce6f691edcd7zoneid=bfdf7ac5-16c3-491e-aabd-f7ad696612b8ispublic=falseisfeatured=falseisextractable=false_=1372941865923
response:
{ updateisopermissionsresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT admins
are allowed to modify this attribute.} }
This may be because in case of edit ISO we show extractable and featured field
as editable to normal user , which normal user is not allowed to do and api
passes these as parameters
In case of template these fields are shown as non editable hence API passed
does not contain isfeatured and isextractable fields
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5301) Router page is not listing VPC types router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-5301. --- Resolution: Fixed Router page is not listing VPC types router --- Key: CLOUDSTACK-5301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5301 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: 4.3 build : CloudPlatform-4.3-860-rhel6.3 Reporter: shweta agarwal Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: router.jpg Repro steps : create few VR and VPC VR From infrastructure page select Router view all Bug : Router page is not showing VPC router (router belonging to type VPC)\ this brings a discrepancy in Count shown on infrastructure page and the list shown on router page As in my case infrastructure page shows 16 router but when i select router view all it shows only 12 entries as 4 router belongs to VPC API call http://10.147.40.27:8080/client/api?command=listRouterslistAll=truepage=1pagesize=20response=jsonsessionkey=lYYot5QzbQ89KDvUiFH66cT19hs%3Dforvpc=false_=1385 633369178 Need to make one more call with VPC=true as well This is affecting group by feature on router page introduced recently for upgrading router . Grouping feature is also giving wrong count. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5301) Router page is not listing VPC types router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838327#comment-13838327 ] ASF subversion and git services commented on CLOUDSTACK-5301: - Commit c77dca2d3e9a662cd8cbd4822976e4743fb16964 in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c77dca2 ] CLOUDSTACK-5301: Show VPC routers on main VR page, to support upgrade feature Router page is not listing VPC types router --- Key: CLOUDSTACK-5301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5301 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: 4.3 build : CloudPlatform-4.3-860-rhel6.3 Reporter: shweta agarwal Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: router.jpg Repro steps : create few VR and VPC VR From infrastructure page select Router view all Bug : Router page is not showing VPC router (router belonging to type VPC)\ this brings a discrepancy in Count shown on infrastructure page and the list shown on router page As in my case infrastructure page shows 16 router but when i select router view all it shows only 12 entries as 4 router belongs to VPC API call http://10.147.40.27:8080/client/api?command=listRouterslistAll=truepage=1pagesize=20response=jsonsessionkey=lYYot5QzbQ89KDvUiFH66cT19hs%3Dforvpc=false_=1385 633369178 Need to make one more call with VPC=true as well This is affecting group by feature on router page introduced recently for upgrading router . Grouping feature is also giving wrong count. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5301) Router page is not listing VPC types router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838326#comment-13838326 ] ASF subversion and git services commented on CLOUDSTACK-5301: - Commit 6ea4e7309db21b8b499302651c12671e9b47ad1d in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ea4e73 ] CLOUDSTACK-5301: Show VPC routers on main VR page, to support upgrade feature Router page is not listing VPC types router --- Key: CLOUDSTACK-5301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5301 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: 4.3 build : CloudPlatform-4.3-860-rhel6.3 Reporter: shweta agarwal Assignee: Brian Federle Priority: Critical Fix For: 4.3.0 Attachments: router.jpg Repro steps : create few VR and VPC VR From infrastructure page select Router view all Bug : Router page is not showing VPC router (router belonging to type VPC)\ this brings a discrepancy in Count shown on infrastructure page and the list shown on router page As in my case infrastructure page shows 16 router but when i select router view all it shows only 12 entries as 4 router belongs to VPC API call http://10.147.40.27:8080/client/api?command=listRouterslistAll=truepage=1pagesize=20response=jsonsessionkey=lYYot5QzbQ89KDvUiFH66cT19hs%3Dforvpc=false_=1385 633369178 Need to make one more call with VPC=true as well This is affecting group by feature on router page introduced recently for upgrading router . Grouping feature is also giving wrong count. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4061) UI issue with Japanese localized ui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle updated CLOUDSTACK-4061: -- Summary: UI issue with Japanese localized ui (was: UI issue with japanses localized ui) UI issue with Japanese localized ui --- Key: CLOUDSTACK-4061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4061 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: Ahmad Emneina Assignee: Brian Federle Fix For: 4.3.0 Attachments: localizationUI.png Localized UI issue. see screenshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4644) Tool Tip information is not provided for the new fields which are added in 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI )
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle reassigned CLOUDSTACK-4644: - Assignee: Jessica Tomechak (was: Brian Federle) Hey Jessica, can you provide copy for the tooltip fields mentioned in this bug? Thanks. Tool Tip information is not provided for the new fields which are added in 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI ) Key: CLOUDSTACK-4644 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4644 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Jessica Tomechak Fix For: 4.3.0 Observation: Tool Tip information is not provided for the new fields which are added in 4.2 ( Ex: Register Template , Compute Offering, Network Offering UI ) 1. Register Template UI : New Fields are : Dynamically Scalable , Routing - There is no quick info provided for these 2. Create Compute Offering UI : isVolatile , Deployment Planner, Planner mode 3. Create Network Offering UI : Persistent , Default egress policy 4. Add Affinity Groups : Name, Description 5. Add Guest Network : Secondary Isolated VLAN ID: 6. Add Region : id, name, end point 7. Configure LDAP : All the fields, Except query filter -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5355) addImageStore should not log password in clear text in the log
Min Chen created CLOUDSTACK-5355: Summary: addImageStore should not log password in clear text in the log Key: CLOUDSTACK-5355 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5355 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 For cifs, addImageStore are currently logging everything including username, password and domain in clear text in the logs, which are specified in query parameter url for the image store. Here's an extract from the logs: (obscured actual pwd) 2013-11-26 12:03:35,703 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52) ===START=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DX%40123%26domain%3DBLR_=1385447356899 2013-11-26 12:03:35,741 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) Trying to add a new data store at cifs://10.102.192.150/SMB-Share/sowmya/secondary?user=sowmyapassword=XXX@123domain=BLR to data center 1 2013-11-26 12:03:35,776 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundUser istrue 2013-11-26 12:03:35,777 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundPswd istrue 2013-11-26 12:03:36,011 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) ===END=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DXXX%40123%26domain%3DBLR_=1385447356899 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4061) UI issue with Japanese localized ui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-4061. --- Resolution: Fixed UI issue with Japanese localized ui --- Key: CLOUDSTACK-4061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4061 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: Ahmad Emneina Assignee: Brian Federle Fix For: 4.3.0 Attachments: localizationUI.png Localized UI issue. see screenshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4061) UI issue with Japanese localized ui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838344#comment-13838344 ] ASF subversion and git services commented on CLOUDSTACK-4061: - Commit 02c7c1ab0784e4d33cfcf51cbbefcfecdc27c414 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=02c7c1a ] CLOUDSTACK-4061: Fix wrapping text with ja ui UI issue with Japanese localized ui --- Key: CLOUDSTACK-4061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4061 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: Ahmad Emneina Assignee: Brian Federle Fix For: 4.3.0 Attachments: localizationUI.png Localized UI issue. see screenshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4061) UI issue with Japanese localized ui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838342#comment-13838342 ] ASF subversion and git services commented on CLOUDSTACK-4061: - Commit 1c4f1deaa88584850c31e1012c7c48aaf3ed7b48 in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c4f1de ] CLOUDSTACK-4061: Fix wrapping text with ja ui UI issue with Japanese localized ui --- Key: CLOUDSTACK-4061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4061 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: Ahmad Emneina Assignee: Brian Federle Fix For: 4.3.0 Attachments: localizationUI.png Localized UI issue. see screenshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5336) [Automation] During regression automation management server hang with out of memory error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5336: Attachment: dump.rar Attaching jmap dump [Automation] During regression automation management server hang with out of memory error Key: CLOUDSTACK-5336 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5336 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Vmware Branch : 4.3 Reporter: Rayees Namathponnan Assignee: Likitha Shetty Priority: Blocker Fix For: 4.3.0 Attachments: CLOUDSTACK-5336.rar, dump.rar Steps to reproduce Steps to reproduce Create build from 4.3 branch and install from RPM Run BVT and Regression automation Result BVT complete without any issues; after start regression MS not responding, observed below out of memory error in MS log 2013-12-01 20:06:27,300 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-398:ctx-55572862 10.223.250.131) Unable to execute NetworkUsage command on DomR (10.223.250.17 4), domR may not be ready yet. failure due to Exception: java.lang.OutOfMemoryError Message: Java heap space java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2219) at java.util.ArrayList.grow(ArrayList.java:242) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208) at java.util.ArrayList.add(ArrayList.java:440) at com.sun.xml.internal.ws.model.wsdl.WSDLOperationImpl.addFault(WSDLOperationImpl.java:126) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parsePortTypeOperationFault(RuntimeWSDLParser.java:740) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parsePortTypeOperation(RuntimeWSDLParser.java:727) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parsePortType(RuntimeWSDLParser.java:697) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:340) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:301) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:677) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:336) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:157) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:120) at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:257) at com.sun.xml.internal.ws.client.WSServiceDelegate.init(WSServiceDelegate.java:220) at com.sun.xml.internal.ws.client.WSServiceDelegate.init(WSServiceDelegate.java:168) at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:96) at javax.xml.ws.Service.init(Service.java:77) at com.vmware.vim25.VimService.init(VimService.java:46) at com.cloud.hypervisor.vmware.util.VmwareClient.connect(VmwareClient.java:129) at com.cloud.hypervisor.vmware.resource.VmwareContextFactory.create(VmwareContextFactory.java:67) at com.cloud.hypervisor.vmware.resource.VmwareContextFactory.getContext(VmwareContextFactory.java:85) at com.cloud.hypervisor.vmware.resource.VmwareResource.getServiceContext(VmwareResource.java:6879) at com.cloud.hypervisor.vmware.resource.VmwareResource.getServiceContext(VmwareResource.java:6861) at com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(VmwareResource.java:6578) at com.cloud.hypervisor.vmware.resource.VmwareResource.getNetworkStats(VmwareResource.java:6596) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:672) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:505) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) 2013-12-01 20:06:27,409 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-32e68e7c) Found 1 routers to update status. 2013-12-01 20:06:27,467 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-32e68e7c) Found 0 networks to update RvR
[jira] [Commented] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838357#comment-13838357 ] Sheng Yang commented on CLOUDSTACK-5295: Rayees, which test cases are fail? I cannot reproduce this issue locally. [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr --- Key: CLOUDSTACK-5295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Sheng Yang Priority: Blocker Fix For: 4.3.0 Attachments: agent1.rar, agent2.rar, management-server.log.2013-11-26.gz, management-server.rar This issue observed in autoamtion environment; many router deployment failed below error 2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to VirtualRouter 2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped: VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb 2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown successfully, cleaning up corresponding resources now. 2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network id=489 2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network Ntwk[489|Guest|8] as a part of network shutdown 2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id 489 as a part of network implement 2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource. com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Unable to start instance due to null at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:960) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1222) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at
[jira] [Commented] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838393#comment-13838393
]
Rayees Namathponnan commented on CLOUDSTACK-5295:
-
integration.component.test_network_offering.TestNetworkUpgrade.test_01_nwupgrade_netscaler_conserve_on
I am able to reproduce this manually
1) Create account
2) Create Network offering with conserve_on
54 network_offering: {
55 name: 'Network offering-VR services',
56 displaytext: 'Network offering-VR
services',
57 guestiptype: 'Isolated',
58 supportedservices:
'Dhcp,Dns,SourceNat,PortForwarding,Vpn,Firewall,Lb,UserData,StaticNat',
59 traffictype: 'GUEST',
60 availability: 'Optional',
61 serviceProviderList: {
62 Dhcp: 'VirtualRouter',
63 Dns: 'VirtualRouter',
64 SourceNat: 'VirtualRouter',
65 PortForwarding:
'VirtualRouter',
66 Vpn: 'VirtualRouter',
67 Firewall: 'VirtualRouter',
68 Lb: 'VirtualRouter',
69 UserData: 'VirtualRouter',
70 StaticNat: 'VirtualRouter',
71 },
72 },
3) Create network with this Network offering
4) Deploy VM
[Automation] Router deployment failed with null pointer exception, while
calling VirtualNetworkApplianceManagerImpl.getVpnCidr
---
Key: CLOUDSTACK-5295
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Reporter: Rayees Namathponnan
Assignee: Sheng Yang
Priority: Blocker
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar,
management-server.log.2013-11-26.gz, management-server.rar
This issue observed in autoamtion environment; many router deployment failed
below error
2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to
VirtualRouter
2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router
VM[DomainRouter|r-586-QA]
2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped:
VM[DomainRouter|r-586-QA]
2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet]
(catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET
signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s
pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb
2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown
successfully, cleaning up corresponding resources now.
2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network
id=489
2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network
Ntwk[489|Guest|8] as a part of network shutdown
2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id
489 as a part of network implement
2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource.
com.cloud.exception.AgentUnavailableException: Resource [Host:2] is
unreachable: Host 2: Unable to start instance due to null
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667)
at
[jira] [Commented] (CLOUDSTACK-5355) addImageStore should not log password in clear text in the log
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838407#comment-13838407 ] ASF subversion and git services commented on CLOUDSTACK-5355: - Commit 8367a8fae19bb883747a8fecfa3b00d022513104 in branch refs/heads/4.3 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8367a8f ] CLOUDSTACK-5355: addImageStore should not log password in clear text in the log. addImageStore should not log password in clear text in the log -- Key: CLOUDSTACK-5355 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5355 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 For cifs, addImageStore are currently logging everything including username, password and domain in clear text in the logs, which are specified in query parameter url for the image store. Here's an extract from the logs: (obscured actual pwd) 2013-11-26 12:03:35,703 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52) ===START=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DX%40123%26domain%3DBLR_=1385447356899 2013-11-26 12:03:35,741 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) Trying to add a new data store at cifs://10.102.192.150/SMB-Share/sowmya/secondary?user=sowmyapassword=XXX@123domain=BLR to data center 1 2013-11-26 12:03:35,776 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundUser istrue 2013-11-26 12:03:35,777 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundPswd istrue 2013-11-26 12:03:36,011 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) ===END=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DXXX%40123%26domain%3DBLR_=1385447356899 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5356) Xenserver - Failed to create snapshot when secondary store was made unavaibale for about 1.5 hour leaving behind snapshot in CreatedOnPrimary state. The subsequen
Sangeetha Hariharan created CLOUDSTACK-5356:
---
Summary: Xenserver - Failed to create snapshot when secondary
store was made unavaibale for about 1.5 hour leaving behind snapshot in
CreatedOnPrimary state. The subsequent scheduled snapshot also failed
Key: CLOUDSTACK-5356
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5356
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Priority: Critical
Fix For: 4.3.0
Xenserver - Failed to create snapshot when secondary store was made unavaibale
for about 1.5 hour leaving behind snapshot in CreatedOnPrimary state. The
subsequent scheduled snapshot also failed
Set up:
Advanced Zone with 2 Xenserver 6.2 hosts:
Steps to reproduce the problem:
1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start
with 10 Vms.
2. Start concurrent hourly snapshots for ROOT volumes of all the Vms.
3. Shutdown the Secondary storage server when the snapshots are in the progress.
4. Bring the Secondary storage server up after 1and 1/2 hour.
We see that the snapshot creation was halted when the Secondary storage server
was down. When it was brought up , snapshots creation continued for all the
volumes except for 1 volume.
Following exception was encountered after about 45 minutes:
2013-12-03 17:53:46,745 DEBUG [c.c.h.x.r.XenServerConnectionPool]
(DirectAgent-258:ctx-981656b0) XmlRpcExceptio
n for method: PBD.unplug due to Failed to create input stream: Read timed out.
Reconnecting...retry=1
2013-12-03 17:53:46,745 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-258:ctx-981656b0) Host 10.223.59.67 O
paqueRef:710e7848-b118-cd69-d8c2-d3e8ffad8429: Catch Exception: Failed to
create input stream: Read timed out
2013-12-03 17:53:46,745 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-258:ctx-981656b0) Host 10.223.59.67 O
paqueRef:710e7848-b118-cd69-d8c2-d3e8ffad8429: Unable to remove SR
2013-12-03 17:53:46,746 WARN [c.c.h.x.r.XenServerStorageProcessor]
(DirectAgent-258:ctx-981656b0) BackupSnapsh
ot Failed due to Task failed! Task record: uuid:
99a9ee1f-645b-8893-5e13-4e16006c57ef
nameLabel: Async.VDI.copy
nameDescription:
allowedOperations: []
currentOperations: {}
created: Tue Dec 03 17:11:16 EST 2013
finished: Tue Dec 03 13:25:23 EST 2013
status: failure
residentOn: com.xensource.xenapi.Host@72f2fe96
progress: 1.0
type: none/
result:
errorInfo: [SR_BACKEND_FAILURE, non-zero exit, , Traceback (most
recent call last):
File /opt/xensource/sm/NFSSR, line 280, in ?
SRCommand.run(NFSSR, DRIVER_INFO)
File /opt/xensource/sm/SRCommand.py, line 327, in run
ret = cmd.run(sr)
File /opt/xensource/sm/SRCommand.py, line 106, in run
return self._run_locked(sr)
File /opt/xensource/sm/SRCommand.py, line 153, in _run_locked
return self._run(sr, target)
File /opt/xensource/sm/SRCommand.py, line 197, in _run
return target.create(self.params['sr_uuid'], self.vdi_uuid,
long(self.params['args'][0]))
File /opt/xensource/sm/FileSR.py, line 487, in create
self.sr._update(self.sr.uuid, self.size)
File /opt/xensource/sm/FileSR.py, line 185, in _update
self.physical_utilisation = self._getutilisation()
File /opt/xensource/sm/FileSR.py, line 270, in _getutilisation
return util.get_fs_utilisation(self.path)
File /opt/xensource/sm/util.py, line 445, in get_fs_utilisation
st = ioretry_stat(lambda: os.statvfs(path))
File /opt/xensource/sm/util.py, line 302, in ioretry_stat
stat = f()
File /opt/xensource/sm/util.py, line 445, in lambda
st = ioretry_stat(lambda: os.statvfs(path))
OSError: [Errno 5] Input/output error:
'/var/run/sr-mount/b9dffc14-d14e-aec2-5609-4c8adee168fa'
]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
99a9ee1f-645b-8893-5e13-4e16006c57ef
nameLabel: Async.VDI.copy
nameDescription:
allowedOperations: []
currentOperations: {}
created: Tue Dec 03 17:11:16 EST 2013
finished: Tue Dec 03 13:25:23 EST 2013
status: failure
residentOn: com.xensource.xenapi.Host@72f2fe96
progress: 1.0
type: none/
result:
errorInfo: [SR_BACKEND_FAILURE, non-zero exit, , Traceback (most
recent call last):
File /opt/xensource/sm/NFSSR, line 280, in ?
SRCommand.run(NFSSR, DRIVER_INFO)
File /opt/xensource/sm/SRCommand.py, line 327, in run
ret = cmd.run(sr)
File
[jira] [Created] (CLOUDSTACK-5357) Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when seconda
Sangeetha Hariharan created CLOUDSTACK-5357: --- Summary: Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when secondary store was unavaiable for 1 and 1/2 hours and then brought up.. Key: CLOUDSTACK-5357 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5357 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when secondary store was unavaiable for 1 and 1/2 hours and then brought up. Set up: Advanced Zone with 2 Xenserver 6.2 hosts: Steps to reproduce the problem: 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Start concurrent hourly snapshots for ROOT volumes of all the Vms. 3. Shutdown the Secondary storage server when the snapshots are in the progress. 4. Bring the Secondary storage server up after 1and 1/2 hour. After the secondary store was brought up , we see the snapshot process continue to be active ( I see the copy command that was halted when the secondary store was down , starts progressing when server is drought up online). I also see that the snapshot process has been completed on the secondary store. But management server throws the following exception and leaves behind the snapshot in CreatedOnPrimary state in DB. 2013-12-03 19:24:36,296 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-252:ctx-8ca50e48) unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) due to You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given. at com.xensource.xenapi.Types.checkResponse(Types.java:209) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool .java:909) at com.xensource.xenapi.Task.destroy(Task.java:616) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.cloudVDIcopy(CitrixResourceBase.java:3920) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.backupSnapshot(XenServerStorageProcessor.java:1268 ) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java: 90) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHan dlerBase.java:50) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:613) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) 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:10 3) 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(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.ja va:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2013-12-03 19:24:36,297 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-252:ctx-8ca50e48) Host 10.223.59.67 OpaqueRef:50d81c75-f239-1746-ae06-c6228e788104: Removing
[jira] [Created] (CLOUDSTACK-5358) API: synchronization on the object is broken
Alena Prokharchyk created CLOUDSTACK-5358:
-
Summary: API: synchronization on the object is broken
Key: CLOUDSTACK-5358
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5358
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
There is a way to synchronize API commands on certain CS object. For example,
when createFirewallRule is called, synchronization on the Network is being
done, so the next command won't be processed till the last one is executed. To
enable it for the certain command, following methods have to be added to
corresponding *Cmd class:
@Override
public String getSyncObjType() {
return BaseAsyncCmd.networkSyncObject;
}
@Override
public Long getSyncObjId() {
return getIp().getAssociatedWithNetworkId();
}
This logic got broken after the changes for vmSync got merged in.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5356) Xenserver - Failed to create snapshot when secondary store was made unavaibale for about 1.5 hour leaving behind snapshot in CreatedOnPrimary state. The subsequen
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5356:
Attachment: Snaposhotfailures.rar
Xenserver - Failed to create snapshot when secondary store was made
unavaibale for about 1.5 hour leaving behind snapshot in CreatedOnPrimary
state. The subsequent scheduled snapshot also failed
--
Key: CLOUDSTACK-5356
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5356
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Priority: Critical
Fix For: 4.3.0
Attachments: Snaposhotfailures.rar
Xenserver - Failed to create snapshot when secondary store was made
unavaibale for about 1.5 hour leaving behind snapshot in CreatedOnPrimary
state. The subsequent scheduled snapshot also failed
Set up:
Advanced Zone with 2 Xenserver 6.2 hosts:
Steps to reproduce the problem:
1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we
start with 10 Vms.
2. Start concurrent hourly snapshots for ROOT volumes of all the Vms.
3. Shutdown the Secondary storage server when the snapshots are in the
progress.
4. Bring the Secondary storage server up after 1and 1/2 hour.
We see that the snapshot creation was halted when the Secondary storage
server was down. When it was brought up , snapshots creation continued for
all the volumes except for 1 volume.
Following exception was encountered after about 45 minutes:
2013-12-03 17:53:46,745 DEBUG [c.c.h.x.r.XenServerConnectionPool]
(DirectAgent-258:ctx-981656b0) XmlRpcExceptio
n for method: PBD.unplug due to Failed to create input stream: Read timed
out. Reconnecting...retry=1
2013-12-03 17:53:46,745 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-258:ctx-981656b0) Host 10.223.59.67 O
paqueRef:710e7848-b118-cd69-d8c2-d3e8ffad8429: Catch Exception: Failed to
create input stream: Read timed out
2013-12-03 17:53:46,745 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-258:ctx-981656b0) Host 10.223.59.67 O
paqueRef:710e7848-b118-cd69-d8c2-d3e8ffad8429: Unable to remove SR
2013-12-03 17:53:46,746 WARN [c.c.h.x.r.XenServerStorageProcessor]
(DirectAgent-258:ctx-981656b0) BackupSnapsh
ot Failed due to Task failed! Task record: uuid:
99a9ee1f-645b-8893-5e13-4e16006c57ef
nameLabel: Async.VDI.copy
nameDescription:
allowedOperations: []
currentOperations: {}
created: Tue Dec 03 17:11:16 EST 2013
finished: Tue Dec 03 13:25:23 EST 2013
status: failure
residentOn: com.xensource.xenapi.Host@72f2fe96
progress: 1.0
type: none/
result:
errorInfo: [SR_BACKEND_FAILURE, non-zero exit, , Traceback (most
recent call last):
File /opt/xensource/sm/NFSSR, line 280, in ?
SRCommand.run(NFSSR, DRIVER_INFO)
File /opt/xensource/sm/SRCommand.py, line 327, in run
ret = cmd.run(sr)
File /opt/xensource/sm/SRCommand.py, line 106, in run
return self._run_locked(sr)
File /opt/xensource/sm/SRCommand.py, line 153, in _run_locked
return self._run(sr, target)
File /opt/xensource/sm/SRCommand.py, line 197, in _run
return target.create(self.params['sr_uuid'], self.vdi_uuid,
long(self.params['args'][0]))
File /opt/xensource/sm/FileSR.py, line 487, in create
self.sr._update(self.sr.uuid, self.size)
File /opt/xensource/sm/FileSR.py, line 185, in _update
self.physical_utilisation = self._getutilisation()
File /opt/xensource/sm/FileSR.py, line 270, in _getutilisation
return util.get_fs_utilisation(self.path)
File /opt/xensource/sm/util.py, line 445, in get_fs_utilisation
st = ioretry_stat(lambda: os.statvfs(path))
File /opt/xensource/sm/util.py, line 302, in ioretry_stat
stat = f()
File /opt/xensource/sm/util.py, line 445, in lambda
st = ioretry_stat(lambda: os.statvfs(path))
OSError: [Errno 5] Input/output error:
'/var/run/sr-mount/b9dffc14-d14e-aec2-5609-4c8adee168fa'
]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
99a9ee1f-645b-8893-5e13-4e16006c57ef
nameLabel: Async.VDI.copy
nameDescription:
allowedOperations: []
currentOperations: {}
created: Tue Dec 03 17:11:16 EST 2013
finished: Tue Dec 03
[jira] [Updated] (CLOUDSTACK-5357) Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when seconda
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-5357: Attachment: Snaposhotfailures.rar Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when secondary store was unavaiable for 1 and 1/2 hours and then brought up.. -- Key: CLOUDSTACK-5357 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5357 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Attachments: Snaposhotfailures.rar Xenserver - Failed to create snapshot due to unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) when secondary store was unavaiable for 1 and 1/2 hours and then brought up. Set up: Advanced Zone with 2 Xenserver 6.2 hosts: Steps to reproduce the problem: 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Start concurrent hourly snapshots for ROOT volumes of all the Vms. 3. Shutdown the Secondary storage server when the snapshots are in the progress. 4. Bring the Secondary storage server up after 1and 1/2 hour. After the secondary store was brought up , we see the snapshot process continue to be active ( I see the copy command that was halted when the secondary store was down , starts progressing when server is drought up online). I also see that the snapshot process has been completed on the secondary store. But management server throws the following exception and leaves behind the snapshot in CreatedOnPrimary state in DB. 2013-12-03 19:24:36,296 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-252:ctx-8ca50e48) unable to destroy task(com.xe nsource.xenapi.Task@67d312d6) on host(23af93a0-93ff-40cb-ba11-a11d1b884d37) due to You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given. at com.xensource.xenapi.Types.checkResponse(Types.java:209) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool .java:909) at com.xensource.xenapi.Task.destroy(Task.java:616) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.cloudVDIcopy(CitrixResourceBase.java:3920) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.backupSnapshot(XenServerStorageProcessor.java:1268 ) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java: 90) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHan dlerBase.java:50) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:613) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) 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:10 3) 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(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.ja va:178) at
