[jira] [Created] (CLOUDSTACK-7535) [Automation][HyperV] SSH Client tries to connect to the private Guest IP Address instead of Public IP Address
Chandan Purushothama created CLOUDSTACK-7535:
Summary: [Automation][HyperV] SSH Client tries to connect to the
private Guest IP Address instead of Public IP Address
Key: CLOUDSTACK-7535
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7535
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Sanjeev N
Priority: Critical
Fix For: 4.5.0
Following two BVT Testcases in two different test suites fail with the same
root cause:
1. test_04_change_offering_small in test_service_offerings.py
2. test_10_attachAndDetach_iso
{noformat}
2014-09-09 05:33:30,778 - DEBUG - Sending GET Cmd :
listVirtualMachines===
2014-09-09 05:33:30,807 - DEBUG - Response : [{domain : u'ROOT', domainid :
u'9df0ddd4-37d3-11e4-a979-ba3c937e668f', haenable : False, templatename :
u'CentOS 6.4(64-bit) GUI (Hyperv)', securitygroup : [], zoneid :
u'd41a93cd-7b6c-432b-9ad4-eb89d8b6e95c', cpunumber : 1, ostypeid : 182,
passwordenabled : False, instancename : u'i-23-43-VM', id :
u'21ca01e4-e737-4a06-a560-5c558387acb0', networkkbswrite : 1, hostname :
u'10.220.163.50', displayvm : True, state : u'Running', guestosid :
u'9e0ec9f2-37d3-11e4-a979-ba3c937e668f', cpuused : u'9%', memory : 256,
serviceofferingid : u'a178853a-56fb-484a-992c-30af0d3ef72b', zonename :
u'XenRT-Zone-0', isdynamicallyscalable : False, displayname : u'testserver',
tags : [], nic : [{networkid : u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e',
macaddress : u'02:00:34:f7:00:01', isolationuri : u'vlan://3027', type :
u'Isolated', broadcasturi : u'vlan://3027', traffictype : u'Guest', netmask :
u'255.255.255.0', ipaddress : u'192.168.200.120', id :
u'970f3e6a-c36c-485d-a891-c89cc743f969', networkname :
u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE-network',
gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid :
u'9df665f6-37d3-11e4-a979-ba3c937e668f', affinitygroup : [], account :
u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE', hostid :
u'e0e128e6-3efc-4080-8d50-c710d33854b8', name :
u'VM-21ca01e4-e737-4a06-a560-5c558387acb0', networkkbsread : 1, created :
u'2014-09-09T05:27:17+', hypervisor : u'Hyperv', rootdevicetype : u'ROOT',
rootdeviceid : 0, serviceofferingname : u'Small Instance', templatedisplaytext
: u'CentOS 6.4 (64-bit) GUI (Hyperv)'}]
2014-09-09 05:33:30,807 - DEBUG - VM state: Running
2014-09-09 05:44:34,402 - CRITICAL - FAILED: test_04_change_offering_small:
['Traceback (most recent call last):\n', ' File
"/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', '
File "/root/cloudstack/test/integration/smoke/test_service_offerings.py", line
326, in test_04_change_offering_small\n
(self.medium_virtual_machine.ipaddress, e)\n', ' File
"/usr/lib/python2.7/unittest/case.py", line 413, in fail\nraise
self.failureException(msg)\n', 'AssertionError: SSH Access failed for
*192.168.200.120: SSH connection has Failed.* Waited 600s. Error is SSH
Connection Failed\n']
2014-09-09 05:44:34,412 - DEBUG - TestCaseName: test_04_change_offering_small;
Time Taken: 678 Seconds; StartTime: Tue Sep 9 05:33:15 2014; EndTime: Tue Sep
9 05:44:34 2014; Result: FAILED
{noformat}
{noformat}
014-09-09 05:37:23,158 - CRITICAL - FAILED: test_10_attachAndDetach_iso:
['Traceback (most recent call last):\n', ' File
"/usr/lib/python2.7/unittest/case.py", line 332, in run\ntestMethod()\n', '
File "/root/cloudstack/test/integration/smoke/test_vm_life_cycle.py", line
692, in test_10_attachAndDetach_iso\n(self.virtual_machine.ipaddress,
e))\n', ' File "/usr/lib/python2.7/unittest/case.py", line 413, in fail\n
raise self.failureException(msg)\n', 'AssertionError: SSH failed for virtual
machine: 192.168.200.149 - SSH connection has Failed. Waited 600s. Error is SSH
Connection Failed\n']
2014-09-09 05:37:23,166 - DEBUG - TestCaseName: test_10_attachAndDetach_iso;
Time Taken: 728 Seconds; StartTime: Tue Sep 9 05:25:14 2014; EndTime: Tue Sep
9 05:37:23 2014; Result: FAILED
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
Harikrishna Patnala created CLOUDSTACK-7534: --- Summary: ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false Key: CLOUDSTACK-7534 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.5.0 ResetVM for a VM having a attached datadisk fails if, 1. there are 2 or more storage pools in the cluster 2. enable.ha.storage.migration is set to false 3. allocator has chosen a different pool for the datadisk than where it currently exists and migration from one pool to another failed because enable.ha.storage.migration set to false. The issue is currently "enable.ha.storage.migration" applies to both normal and HA deployment. We should have another parameter which is specific to normal deployments (say enable.storage.migration) so that during migration check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy resolved CLOUDSTACK-7493.
---
Resolution: Invalid
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on template_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 snapshots to cleanup on snapshot_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 volumes to cleanup on volume_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnect
[jira] [Commented] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129617#comment-14129617
]
Jayapal Reddy commented on CLOUDSTACK-7493:
---
You can ignore the errors in details and check only result.
I was suspecting that you might be looking at the logs in details. So same
thing I have updated in the bug.
But when you file if it has out this explicitly then it might has closed that
day only.
In VR when we run the script we try to delete before creating. Such commands
cause these errors.
We can suppress these messages in the script it self.
With updated calling script mechanism, the script got called from the host
itself. Earlier the script called from
vmops so that error logs are not passed to MS.
Thanks,
Jayapal
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on t
[jira] [Reopened] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada reopened CLOUDSTACK-7498: -- This issue is reproducible. With user logout/login to the UI , it works fine first time. Second time it gets into the issue again. > [UI] Register ISO option is failing to invoke ISO registration page with > ReferenceError: osTypeObjs is not defined > -- > > Key: CLOUDSTACK-7498 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Priority: Critical > Attachments: registerisoUI.png > > > Steps: > 1. Install 4.5 cloudstack > 2. Access Management Server UI and tried register ISO > Observations : > 1. It is not invoking Register ISO page and failing with ReferenceError: > osTypeObjs is not defined > Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129593#comment-14129593
]
Jayapal Reddy edited comment on CLOUDSTACK-7493 at 9/11/14 4:14 AM:
Hi Chandan,
The attached logs did not have information about the failure. All the logs are
showing success.
1. Can you please attach logs for PROVING the rules got failed in VR ? How are
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and
saying it got failed ?
2. Is the rules configuration success when you run manually ?
If you assume failure from the details it is not true. The details is shown
script execution logs which can be ignored. Only see the result.
[{"com.cloud.agent.api.Answer":{"result":true,"details":"iptables v1.4.14:
Couldn't load target `_FW_EGRESS_RULES':No such file or directory\n\nTry
`iptables -h' or 'iptables --help' for more information.\niptables: No
chain/target/match by that name.\niptables: No chain/target/match by that
name.\niptables: No chain/target/match by that name.\niptables v1.4.14:
Couldn't load target `_FW_EGRESS_RULES':No such file or directory\n\nTry
`iptables -h' or 'iptables --help' for more information.\niptables: No
chain/target/match by that name.\niptables: No chain/target/match by that
name.\n","wait":0}}] }
Please provide relevant logs for this bug description.
Thanks,
Jayapal
was (Author: jayapal):
Hi Chandan,
The attached logs did not have information about the failure. All the logs are
showing success.
1. Can you please attach logs for PROVING the rules got failed in VR ? How are
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and
saying it got failed ?
2. Is the rules configuration success when you run manually ?
Please provide relevant logs for this bug description.
Thanks,
Jayapal
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-7493:
--
Assignee: Chandan Purushothama (was: Jayapal Reddy)
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on template_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 snapshots to cleanup on snapshot_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 volumes to cleanup on volume_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,940 DEBUG
[jira] [Commented] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129593#comment-14129593
]
Jayapal Reddy commented on CLOUDSTACK-7493:
---
Hi Chandan,
The attached logs did not have information about the failure. All the logs are
showing success.
1. Can you please attach logs for PROVING the rules got failed in VR ? How are
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and
saying it got failed ?
2. Is the rules configuration success when you run manually ?
Please provide relevant logs for this bug description.
Thanks,
Jayapal
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on template_store_ref for store:
> cifs://10.220.163.36/storage/secon
[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-7493:
---
Assignee: Jayapal Reddy (was: Rajesh Battala)
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on template_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 snapshots to cleanup on snapshot_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 volumes to cleanup on volume_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r
[jira] [Commented] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129450#comment-14129450 ] ASF subversion and git services commented on CLOUDSTACK-7533: - Commit f3b5a6ebc70d5bfb2c77b6aa359d7eb79b4507e5 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f3b5a6e ] CLOUDSTACK-7533: Wrong download URL is generated when using multiple SSVMs in a zone. The public ip of the url would sometime point to the wrong ssvm when the url was created on another one. Fix the bug by removing the command CreateEntityDownloadURLCommand from the host delegation. This results in same ssvm for creating the symlink on ssvm and same public ip being used for generating the url on MS. > Wrong download URL generated when using multiple SSVMs > -- > > Key: CLOUDSTACK-7533 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129447#comment-14129447
]
Nitin Mehta edited comment on CLOUDSTACK-7533 at 9/11/14 12:44 AM:
---
I have multiple SSVMs and when the they try to download a template it fails
because the URL which is generated goes to the wrong SSVM. Repro steps are:
Step1.In GUI
Templates-[Select Template]-Download Template.
Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova
to download template
Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not
found on this server.
In the logs we can see command to s-6-VM(Public IP:x)
2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496:
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.storage.CreateEntityDownloadURLCommand":{"installPath":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","parent":"87db3e8a-360a-3ad1-bfad-ff4edc8e817c","extractLinkUUID":"5de8b2dd-be47-465f-81bc-ee809d805f7d.ova","data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","uuid":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","id":296,"format":"OVA","accountId":9,"hvm":true,"displayText":"10G-TemplateFromVolume","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://jx.local/je01v-xc/standard","_role":"Image"}},"name":"9952142b1-11f7-3cc2-91d1-aa1a0e196453","hypervisorType":"VMware"}},"accountId":0,"wait":0}}]
}
But the Public IP address of the Template-download-URL is 210.140.175.2
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.ExtractResponse/template/
{"id":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","name":"10G-TemplateFromVolume","accountid":"5124ddac-553c-4287-b87b-594bbeed6cc5","state":"DOWNLOAD_URL_CREATED","zoneid":"af9c6a06-b56c-4853-9332-588f8a91d35c","zonename":"je01v","extractMode":"HTTP_DOWNLOAD","url":"http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova"}
was (Author: nitinme):
I have multiple SSVMs and when the they try to download a template it fails
because the URL which is generated goes to the wrong SSVM. Repro steps are:
Step1.In GUI
Templates-[Select Template]-Download Template.
Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova
to download template
Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not
found on this server.
In the logs we can see command to s-6-VM(Public IP:210.140.175.4)
2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496:
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.storage.CreateEntityDownloadURLCommand":{"installPath":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","parent":"87db3e8a-360a-3ad1-bfad-ff4edc8e817c","extractLinkUUID":"5de8b2dd-be47-465f-81bc-ee809d805f7d.ova","data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","uuid":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","id":296,"format":"OVA","accountId":9,"hvm":true,"displayText":"10G-TemplateFromVolume","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://jx.local/je01v-xc/standard","_role":"Image"}},"name":"9952142b1-11f7-3cc2-91d1-aa1a0e196453","hypervisorType":"VMware"}},"accountId":0,"wait":0}}]
}
But the Public IP address of the Template-download-URL is 210.140.175.2
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.ExtractResponse/template/
{"id":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","name":"10G-TemplateFromVolume","accountid":"5124ddac-553c-4287-b87b-594bbeed6cc5","state":"DOWNLOAD_URL_CREATED","zoneid":"af9c6a06-b56c-4853-9332-588f8a91d35c","zonename":"je01v","extractMode":"HTTP_DOWNLOAD","url":"http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova"}
> Wrong download URL generated when using multiple SSVMs
> --
>
> Key: CLOUDSTACK-7533
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
> Project: CloudStack
> Issue Type
[jira] [Commented] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129447#comment-14129447
]
Nitin Mehta commented on CLOUDSTACK-7533:
-
I have multiple SSVMs and when the they try to download a template it fails
because the URL which is generated goes to the wrong SSVM. Repro steps are:
Step1.In GUI
Templates-[Select Template]-Download Template.
Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova
to download template
Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not
found on this server.
In the logs we can see command to s-6-VM(Public IP:210.140.175.4)
2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496:
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.storage.CreateEntityDownloadURLCommand":{"installPath":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","parent":"87db3e8a-360a-3ad1-bfad-ff4edc8e817c","extractLinkUUID":"5de8b2dd-be47-465f-81bc-ee809d805f7d.ova","data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova","uuid":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","id":296,"format":"OVA","accountId":9,"hvm":true,"displayText":"10G-TemplateFromVolume","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://jx.local/je01v-xc/standard","_role":"Image"}},"name":"9952142b1-11f7-3cc2-91d1-aa1a0e196453","hypervisorType":"VMware"}},"accountId":0,"wait":0}}]
}
But the Public IP address of the Template-download-URL is 210.140.175.2
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.ExtractResponse/template/
{"id":"13e155cb-88f5-4ade-8a69-a60cd3e47edc","name":"10G-TemplateFromVolume","accountid":"5124ddac-553c-4287-b87b-594bbeed6cc5","state":"DOWNLOAD_URL_CREATED","zoneid":"af9c6a06-b56c-4853-9332-588f8a91d35c","zonename":"je01v","extractMode":"HTTP_DOWNLOAD","url":"http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova"}
> Wrong download URL generated when using multiple SSVMs
> --
>
> Key: CLOUDSTACK-7533
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.5.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.5.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs
Nitin Mehta created CLOUDSTACK-7533: --- Summary: Wrong download URL generated when using multiple SSVMs Key: CLOUDSTACK-7533 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.5.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129408#comment-14129408 ] Nitin Mehta edited comment on CLOUDSTACK-5685 at 9/11/14 12:07 AM: --- Basically the logic is something like this Kelven has made VirtualNetworkApplianceManagerImpl.java (router's Manager) listener to vm's state transitions. So whenever a state transition happens and if it is a VR and old state = stopped and new state = running and the event which triggered is out of band (FollowAgentPowerOnReport) then reboot the router through CS which would result in reprogramming the rules as well. was (Author: nitinme): Basically the logic is something like this Keleven has made VirtualNetworkApplianceManagerImpl.java (router's Manager) listener to vm's state transitions. So whenever a state transition happens and if it is a VR and old state = stopped and new state = running and the event which triggered is out of band (FollowAgentPowerOnReport) then reboot the router through CS which would result in reprogramming the rules as well. > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not bieng programmed with any > rules. > -- > > Key: CLOUDSTACK-5685 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang > Fix For: 4.4.0 > > > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not being programmed with any > rules. > PreReq: > Have few Vms deployed using Cloudstack. > Have PF,Static NAT,LB and Egress rules programmed for the Vms. > Steps: > Outside of Cloudstack, Reboot VR. > After the successful reboot of VR , there are no rules being programmed in > the VR for the Vms. > Currently , VM sync does not detect any change of state in the router when > router is rebooted. So there is no way for CS to know that the router needs > to be reprogrammed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129406#comment-14129406 ] Nitin Mehta commented on CLOUDSTACK-5685: - commit ee2adab7c7c9cf42eaf93c7eedb6dd32ebd8b501 Author: Kelven Yang Date: Mon Feb 10 16:58:49 2014 -0800 reboot VR if a out-of-band power-on event is detected > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not bieng programmed with any > rules. > -- > > Key: CLOUDSTACK-5685 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang > Fix For: 4.4.0 > > > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not being programmed with any > rules. > PreReq: > Have few Vms deployed using Cloudstack. > Have PF,Static NAT,LB and Egress rules programmed for the Vms. > Steps: > Outside of Cloudstack, Reboot VR. > After the successful reboot of VR , there are no rules being programmed in > the VR for the Vms. > Currently , VM sync does not detect any change of state in the router when > router is rebooted. So there is no way for CS to know that the router needs > to be reprogrammed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129408#comment-14129408 ] Nitin Mehta commented on CLOUDSTACK-5685: - Basically the logic is something like this Keleven has made VirtualNetworkApplianceManagerImpl.java (router's Manager) listener to vm's state transitions. So whenever a state transition happens and if it is a VR and old state = stopped and new state = running and the event which triggered is out of band (FollowAgentPowerOnReport) then reboot the router through CS which would result in reprogramming the rules as well. > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not bieng programmed with any > rules. > -- > > Key: CLOUDSTACK-5685 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang > Fix For: 4.4.0 > > > [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in > state detected by cloudstack resulting in VR not being programmed with any > rules. > PreReq: > Have few Vms deployed using Cloudstack. > Have PF,Static NAT,LB and Egress rules programmed for the Vms. > Steps: > Outside of Cloudstack, Reboot VR. > After the successful reboot of VR , there are no rules being programmed in > the VR for the Vms. > Currently , VM sync does not detect any change of state in the router when > router is rebooted. So there is no way for CS to know that the router needs > to be reprogrammed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7462: - Labels: DEVREV (was: ) > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Labels: DEVREV > Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, > tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7462. > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Labels: DEVREV > Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, > tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129294#comment-14129294 ] Jessica Wang commented on CLOUDSTACK-7462: -- Problem: --- as described in the reporter QA notes: - Steps to reproduce: UI > Network > VPC > Router > Network ACL Lists > click an entry from list > Details tab > ACL List Rules tab > click Edit icon on any existing rule Expected result: - Edit tags pops up successfully (as in my attached screenshot "after_my_checkin_2") > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Labels: DEVREV > Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, > tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7462: - Attachment: after_my_checkin_2.PNG after_my_checkin_1.PNG > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, > tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7462. -- Resolution: Fixed > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Attachments: tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129262#comment-14129262 ] ASF subversion and git services commented on CLOUDSTACK-7462: - Commit a39bf18bc7eb3c55286ed74aa473e32cbe980ec8 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a39bf18 ] CLOUDSTACK-7462: UI > Network > VPC > Router > Network ACL Lists > click an entry from list > Details tab > ACL List Rules tab > click Edit icon on any existing rule > fix the JavaScript error "args.jsonObj is undefined". > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy > Attachments: tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7462: Assignee: Jessica Wang > UI: Edit tags buttons do not work on ACL List tab > - > > Key: CLOUDSTACK-7462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Gabor Apati-Nagy >Assignee: Jessica Wang > Attachments: tags_jsonobj_empty.jpg > > > Steps to reproduce: > -Go to Network > -Select VPC view from the dropdown > -Create a VPC if there is none present > -On a VPC, click on "Configure" button > -If needed, proceed and set the minimal required settings (eg. tier) > -Click on the Routers Network ACL Lists button, the ACLs are now listed > -Click on any item to open its detail view > -Select the ACL List Rules tab > Click on the "Edit tags" button of any the existing entries in the grid > Expected result: > -Tag editor should appear and tags should be editable > Actual result: > -Tag editor appears, but empty. Missing features: list, add, remove tags. > Note: > -Tag editor has a "Done" button, so it can be closed and the user can proceed > using the UI, however tags are not listable and editable. Loss of "tags" > functionality. > -The issue is seems to be related to CLOUDSTACK-5486. > -Screenshot attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6278) Baremetal Advanced Networking support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129162#comment-14129162 ] ASF subversion and git services commented on CLOUDSTACK-6278: - Commit e06fa18ed2ee2ee6a417e089cf5ac6bde11d0079 in cloudstack's branch refs/heads/master from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e06fa18 ] CLOUDSTACK-6278 Baremetal Advanced Networking support > Baremetal Advanced Networking support > - > > Key: CLOUDSTACK-6278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6278 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Baremetal >Affects Versions: 4.5.0 >Reporter: frank zhang >Assignee: frank zhang > Fix For: 4.5.0 > > > functional spec link: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7523) java.lang.NullPointerException when listing accounts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129163#comment-14129163 ] ASF subversion and git services commented on CLOUDSTACK-7523: - Commit 7a555b398fffafcca0a88aed56c6f8d57d8b3ae1 in cloudstack's branch refs/heads/master from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a555b3 ] CLOUDSTACK-7523 java.lang.NullPointerException when listing accounts > java.lang.NullPointerException when listing accounts. > -- > > Key: CLOUDSTACK-7523 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7523 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: frank zhang >Priority: Critical > Fix For: 4.5.0 > > > Deploy a fresh Management server. > After this try to list Accounts , by going to Accounts tab in UI. > There is no entries returned and the UI keeps spinning. > listAccounts() fail with return code - 530 . > > 2014-09-09 12:38:59,932 INFO [a.c.c.a.ApiServer] > (catalina-exec-18:ctx-0c561c21 ctx-dcbc1d59) (userId=2 accountId=2 > sessionId=600DA8E1BD8DC8B8DF75DD5B5FC9E7E9) 10.215.3.17 -- GET > command=listAccounts&response=json&sessionkey=2%2Bf%2BWC0FhPn6j%2BiLp3mj2POhdsY%3D&listAll=true&page=1&pagesize=20&_=1410305103203 > 530 null > Following exception seen in management server logs: > 2014-09-09 08:39:22,417 DEBUG [c.c.a.ApiServlet] > (catalina-exec-7:ctx-d2a3ffdc) ===START=== 10.216.50.29 -- GET > command=listAccounts&response=json&sessionkey=XkWSjL0e3Xe3ckgR5jW2CsSYOeA%3D&listAll=true&page=1&pagesize=20&_=1410290672605 > 2014-09-09 08:39:22,832 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-d2a3ffdc > ctx-9db713ee) unhandled exception executing api command: > [Ljava.lang.String;@1a1bdce4 > java.lang.NullPointerException > at > com.cloud.api.query.dao.AccountJoinDaoImpl.setResourceLimits(AccountJoinDaoImpl.java:144) > at > com.cloud.api.query.dao.AccountJoinDaoImpl.newAccountResponse(AccountJoinDaoImpl.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > 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 com.sun.proxy.$Proxy111.newAccountResponse(Unknown Source) > at com.cloud.api.ApiDBUtils.newAccountResponse(ApiDBUtils.java:1788) > at > com.cloud.api.query.ViewResponseHelper.createAccountResponse(ViewResponseHelper.java:353) > at > com.cloud.api.query.QueryManagerImpl.searchForAccounts(QueryManagerImpl.java:1835) > at > org.apache.cloudstack.api.command.user.account.ListAccountsCmd.execute(ListAccountsCmd.java:93) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:273) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:117) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServl
[jira] [Commented] (CLOUDSTACK-6360) Usage server failed to start with 4.4 build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129160#comment-14129160 ] ASF subversion and git services commented on CLOUDSTACK-6360: - Commit 90287cc60aca81fb9a372584936c557d446739f9 in cloudstack's branch refs/heads/master from rayeesn [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=90287cc ] CLOUDSTACK-6360: adding mysql-connector to class path and it will be loaded while starting cloudstack-usage > Usage server failed to start with 4.4 build > --- > > Key: CLOUDSTACK-6360 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6360 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.3.0, 4.4.0 > Environment: 4.4 Build >Reporter: Rayees Namathponnan >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > > step 1 : Create 4.4 build and install usage server > step 2 : start usage sever > Result > Failed to start usage server with below error > java.lang.UnsupportedClassVersionError: com/cloud/usage/UsageServer : > Unsupported major.minor version 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:634) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) > at java.net.URLClassLoader.access$000(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:212) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:321) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:266) > at > org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:151) > 08/04/2014 12:32:19 5982 jsvc.exec error: Cannot load daemon > 08/04/2014 12:32:19 5980 jsvc.exec error: Service exit with a return value of > 3 > cloudstack-usage.err (END) > We already defined 4.4 support with JAVA IP, but usage server trying to start > with 1.6 > we need to fix this in vi /etc/rc.d/init.d/cloudstack-usage > # The first existing directory is used for JAVA_HOME (if JAVA_HOME is not > defined in $DEFAULT) > JDK_DIRS="/usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-openjdk-i386 > /usr/lib/jvm/java-6-openjdk-amd64 /usr/lib/jvm/java-6-sun > /usr/lib/jvm/jre-1.6.0 /usr/lib/j2sdk1.5-sun /usr/lib/jre-openjdk" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-7493:
-
Attachment: client_managementLogs.zip
Jayapal,
It is the basic use case of egress rule that failed: The log snippet shown
below is taken from client logs. Notice the parameters passed and the jobstatus.
{code}
2014-09-09 05:33:10,240 - DEBUG - Sending GET Cmd :
createEgressFirewallRule===
2014-09-09 05:33:10,286 - DEBUG - === Jobid:
856ae190-e3a6-4eb4-b682-234aeddc3484 Started ===
2014-09-09 05:33:10,286 - DEBUG - Payload: {'signature':
'lsdLVNfCIelufUHs6LixL3riffw=', 'apiKey':
u'nzr3aEbj9wPt-8pe8xsx510O7g_xfhA3xmozRaWajWqYmipFRoCqryYq8akuHmQ8Q-D7Px7ohg-MgRuBjzESbA',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'856ae190-e3a6-4eb4-b682-234aeddc3484'}
2014-09-09 05:33:10,286 - DEBUG - Sending GET Cmd :
queryAsyncJobResult===
2014-09-09 05:33:10,315 - DEBUG - Response : {jobprocstatus : 0, created :
u'2014-09-09T05:33:10+', cmd :
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 0, jobid :
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid :
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobinstancetype : u'FirewallRule',
accountid : u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
2014-09-09 05:33:15,320 - DEBUG - ===
JobId:856ae190-e3a6-4eb4-b682-234aeddc3484 is Still Processing, Will TimeOut
in:3595
2014-09-09 05:33:15,321 - DEBUG - Payload: {'signature':
'lsdLVNfCIelufUHs6LixL3riffw=', 'apiKey':
u'nzr3aEbj9wPt-8pe8xsx510O7g_xfhA3xmozRaWajWqYmipFRoCqryYq8akuHmQ8Q-D7Px7ohg-MgRuBjzESbA',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'856ae190-e3a6-4eb4-b682-234aeddc3484'}
2014-09-09 05:33:15,321 - DEBUG - Sending GET Cmd :
queryAsyncJobResult===
2014-09-09 05:33:15,341 - DEBUG - Response : {jobprocstatus : 0, created :
u'2014-09-09T05:33:10+', jobresult : {networkid :
u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', protocol : u'all', fordisplay : True,
cidrlist : u'0.0.0.0/0', tags : [], state : u'Active', id :
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7'}, cmd :
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 1, jobid :
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid :
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobresulttype : u'object',
jobinstancetype : u'FirewallRule', accountid :
u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
2014-09-09 05:33:15,342 - DEBUG - ===Jobid:856ae190-e3a6-4eb4-b682-234aeddc3484
; StartTime:Tue Sep 9 05:33:10 2014 ; EndTime:Tue Sep 9 05:33:15 2014 ;
TotalTime:-5===
2014-09-09 05:33:15,342 - DEBUG - Response : {jobprocstatus : 0, created :
u'2014-09-09T05:33:10+', jobresult : {networkid :
u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', protocol : u'all', fordisplay : True,
cidrlist : u'0.0.0.0/0', tags : [], state : u'Active', id :
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7'}, cmd :
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 1, jobid :
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid :
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobresulttype : u'object',
jobinstancetype : u'FirewallRule', accountid :
u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
{code}
I attached the management server log and test client execution logs to the bug
report,
Thank you,
Chandan.
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Rajesh Battala
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
[jira] [Updated] (CLOUDSTACK-7522) RPM builds should exit status 1, if there are failure in MVN build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7522: Priority: Blocker (was: Major) > RPM builds should exit status 1, if there are failure in MVN build > --- > > Key: CLOUDSTACK-7522 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7522 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: Rayees Namathponnan >Assignee: Damodar Reddy T >Priority: Blocker > Fix For: 4.5.0 > > > Steps to reproduce > > execute RPM build command > var=$(bash ./package.sh --pack noredist --build) > > while executing MVN command kill java "killall -9 java" > >see the output, echo $var to see the output > Expected result > RPM build should exited error > Actual result > RPM build not exited with error , it return Done, see the output > .cloudstack.framework.config.impl.ConfigDepotAdminTest log4j:WARN No > appenders could be found for logger > (org.apache.cloudstack.framework.config.impl.ConfigDepotImpl). log4j:WARN > Please initialize the log4j system properly. log4j:WARN See > http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests > run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.091 sec Results : > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- > maven-jar-plugin:2.4:jar (default-jar) @ cloud-framework-config --- [INFO] > Building jar: > /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/framework/config/target/cloud-framework-config-4.5.0-SNAPSHOT.jar > [INFO] [INFO] --- maven-site-plugin:3.3:attach-descriptor > (attach-descriptor) @ cloud-framework-config --- [INFO] [INFO] > > [INFO] Building Apache CloudStack API 4.5.0-SNAPSHOT [INFO] > > [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-api > --- [INFO] Deleting > /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api > (includes = [target, dist], excludes = []) [INFO] [INFO] --- > maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-api --- > [INFO] Starting audit... Audit done. [INFO] [INFO] --- > maven-remote-resources-plugin:1.3:process (default) @ cloud-api --- [INFO] > [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ > cloud-api --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to > copy filtered resources. [INFO] Copying 4 resources [INFO] Copying 3 > resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile > (default-compile) @ cloud-api --- [INFO] Compiling 939 source files to > /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api/target/classes > RPM build errors: Done > [root@build-test centos63]# vi package.sh > Looks like this is happening after below commit > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=7ea7deded031b43042c68db0f7c5c6c8b21c18c2 > if revert this commit rpm exit with return 1, if there are issue with mvn -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128418#comment-14128418 ] ASF subversion and git services commented on CLOUDSTACK-7351: - Commit 3411fbaccafbce8f99af4714a26f38a2c17d8a9e in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3411fba ] CLOUDSTACK-7351: Passing hypervisor type while deploying VM using ISO Signed-off-by: SrikanteswaraRao Talluri > [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy > > > Key: CLOUDSTACK-7351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Critical > Fix For: 4.5.0 > > Attachments: CLOUDSTACK-7351.rar > > > This issue observed while running the test case > integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso > This test case deploying VM with below command > 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-4e4260d3) ===START=== 10.223.240.194 -- GET > account=test-TestVMAcc > ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze > Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo > TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543 > e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585 > This deployment failed with below error > 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for > Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y] > 2014-08-14 15:59:45,388 INFO [c.c.a.ApiServer] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor > parameter is needed to deploy VM or the hypervisor parameter value passed is > invalid > Is it required to pass hypervisor type ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7532: -- Attachment: template_status.PNG Attached screenshot to describe the issue. > [Templates] Template status is not shown in UI/API response for non-default > account users > - > > Key: CLOUDSTACK-7532 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Template >Affects Versions: 4.5.0 > Environment: Latest build from master with commit: > c33fea2cd27664db32c1173e98511470bf0a0724 >Reporter: Sanjeev N >Priority: Critical > Labels: api, templates > Attachments: template_status.PNG > > > [Templates] Template status is not shown in UI/API response for non-default > account users > Steps to Reproduce: > === > 1.Bring up CS with latest build > 2.Create one account under root domain > 3.Register template using the account created above > 4.After the template download is completed verify the template status using > the account created at step2 > Expected Result: > == > In UI/API response status field should be there and it should be set to > "Download Complete" after the successful template download. > Actual Behavior: > > Status is shown only for the default admin user. But it is not showed to > other account users. > Impact: > == > Marvin tests which use template register would fail because of the status > filed missing. > Following is the code from base.py where the tests are failing: > elif 'Downloaded' in template.status: > time.sleep(interval) > becasue template.status is NoneType > API: > > http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876 > API Response: > === > cloud-stack-version="4.5.0-SNAPSHOT">1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS > 5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI > (XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS > 5.6 > (64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue > In the above API response status field is missing. > This bug is easily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users
Sanjeev N created CLOUDSTACK-7532: - Summary: [Templates] Template status is not shown in UI/API response for non-default account users Key: CLOUDSTACK-7532 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Template Affects Versions: 4.5.0 Environment: Latest build from master with commit: c33fea2cd27664db32c1173e98511470bf0a0724 Reporter: Sanjeev N Priority: Critical [Templates] Template status is not shown in UI/API response for non-default account users Steps to Reproduce: === 1.Bring up CS with latest build 2.Create one account under root domain 3.Register template using the account created above 4.After the template download is completed verify the template status using the account created at step2 Expected Result: == In UI/API response status field should be there and it should be set to "Download Complete" after the successful template download. Actual Behavior: Status is shown only for the default admin user. But it is not showed to other account users. Impact: == Marvin tests which use template register would fail because of the status filed missing. Following is the code from base.py where the tests are failing: elif 'Downloaded' in template.status: time.sleep(interval) becasue template.status is NoneType API: http://10.147.40.10:8080/client/api?command=listTemplates&sessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3D&templatefilter=self&id=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa&_=1410351906876 API Response: === 1550ad6ac-38d2-11e4-a56e-d4ae527ccfaaCentOS 5.6(64-bit) no GUI (XenServer)CentOS 5.6(64-bit) no GUI (XenServer)true2014-09-10T15:59:38+0530truefalseVHDtruetrue572126ea-38d2-11e4-a56e-d4ae527ccfaaCentOS 5.6 (64-bit)system680f7c3a-a9ee-4ed3-b594-981d56f8da4bz221474836480BUILTINXenServerROOT54e9d4e4-38d2-11e4-a56e-d4ae527ccfaatrue905cec879afd9c9d22ecc8036131a180falsetrue In the above API response status field is missing. This bug is easily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7477) [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is removed when agent shutsdown and restarted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7477. -- > [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is > removed when agent shutsdown and restarted > > > Key: CLOUDSTACK-7477 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7477 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > > Repro steps: > 1. Create a LXC setup > 2. create few vms > 3. shut down host LXC agent > 4. Once Agent states become disconnected start host gain > Bug > Note all the mounts in host > mount > proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) > sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) > devtmpfs on /dev type devtmpfs > (rw,nosuid,seclabel,size=3981488k,nr_inodes=995372,mode=755) > securityfs on /sys/kernel/security type securityfs > (rw,nosuid,nodev,noexec,relatime) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) > devpts on /dev/pts type devpts > (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) > tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) > cgroup on /sys/fs/cgroup/systemd type cgroup > (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) > pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) > cgroup on /sys/fs/cgroup/cpuset type cgroup > (rw,nosuid,nodev,noexec,relatime,cpuset) > cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup > (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) > cgroup on /sys/fs/cgroup/memory type cgroup > (rw,nosuid,nodev,noexec,relatime,memory) > cgroup on /sys/fs/cgroup/devices type cgroup > (rw,nosuid,nodev,noexec,relatime,devices) > cgroup on /sys/fs/cgroup/freezer type cgroup > (rw,nosuid,nodev,noexec,relatime,freezer) > cgroup on /sys/fs/cgroup/net_cls type cgroup > (rw,nosuid,nodev,noexec,relatime,net_cls) > cgroup on /sys/fs/cgroup/blkio type cgroup > (rw,nosuid,nodev,noexec,relatime,blkio) > cgroup on /sys/fs/cgroup/perf_event type cgroup > (rw,nosuid,nodev,noexec,relatime,perf_event) > cgroup on /sys/fs/cgroup/hugetlb type cgroup > (rw,nosuid,nodev,noexec,relatime,hugetlb) > configfs on /sys/kernel/config type configfs (rw,relatime) > /dev/mapper/rhel_rack3pod1host49-root on / type xfs > (rw,relatime,seclabel,attr2,inode64,noquota) > selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) > mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel) > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel) > debugfs on /sys/kernel/debug type debugfs (rw,relatime) > sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) > sunrpc on /proc/fs/nfsd type nfsd (rw,relatime) > /dev/mapper/rhel_rack3pod1host49-home on /home type xfs > (rw,relatime,seclabel,attr2,inode64,noquota) > /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota) > 10.147.28.7:/export/home/shweta/goleta.lxc.primary on > /mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424 type nfs > (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.147.28.7,mountvers=3,mountport=47246,mountproto=udp,local_lock=none,addr=10.147.28.7) > fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) > it again contains all those cgroups mount point which we deleted earlier as a > part of LXC agent instalation . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7531. -- Resolution: Invalid After some time I noticed HA VM restarted > [LXC] ha enabled VM not restarted once a shutdown host is restarted > --- > > Key: CLOUDSTACK-7531 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kiran Koneti > Fix For: 4.5.0 > > > Repro steps: > 1. Create a Zone with two cluster each having one LXC host > 2. Create some ha enabled VM > 3. Shutdown host machine having ha enabled VM and wait till the status of > agent is disconnected on MS > 4. start host machine > Bug: > Ha enabled VM goes to stop state as soon as Host machine comes up and agent > status is up on CS > Expected result: > HA enabled VM should restart > Additional information > For all that time when Host was shutdown the agent state was disconnected and > all the HA enabled is shown as up and running but as soon as I restarted Host > the HA enabled VM stopped . Ideally HA thread should kick in and restart > those VM on other or same host . > Attaching MS and agent log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted
shweta agarwal created CLOUDSTACK-7531: -- Summary: [LXC] ha enabled VM not restarted once a shutdown host is restarted Key: CLOUDSTACK-7531 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kiran Koneti Fix For: 4.5.0 Repro steps: 1. Create a Zone with two cluster each having one LXC host 2. Create some ha enabled VM 3. Shutdown host machine having ha enabled VM and wait till the status of agent is disconnected on MS 4. start host machine Bug: Ha enabled VM goes to stop state as soon as Host machine comes up and agent status is up on CS Expected result: HA enabled VM should restart Additional information For all that time when Host was shutdown the agent state was disconnected and all the HA enabled is shown as up and running but as soon as I restarted Host the HA enabled VM stopped . Ideally HA thread should kick in and restart those VM on other or same host . Attaching MS and agent log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7510) Add "usageid" parameter to the "listUsageRecords" API call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-7510. - Resolution: Fixed Updated Branches: refs/heads/master 75cd79a23 -> 70142c4ac Added "usageid" parameter to the "listUsageRecords" API call. Can be used only together with "type" parameter specified Signed-off-by: Ilia Shakitko Signed-off-by: Rohit Yadav Commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=70142c4acb84a2d2b1fe8806c159493e4a556532 > Add "usageid" parameter to the "listUsageRecords" API call > -- > > Key: CLOUDSTACK-7510 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7510 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Reporter: Ilia Shakitko >Priority: Minor > Fix For: 4.5.0 > > > Working with Usage server and usage records very often I need to get only > records for that particular usage ID. For example when filtering out > network_bytes_received/sent with big amount of data it's not very fast to > process hundreds of objects looking for the only one you need. > It would be useful to have an ability to filter out usage records only for > specific resource ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128388#comment-14128388 ] ASF subversion and git services commented on CLOUDSTACK-6099: - Commit 56c7fc800ad12e2e3ccbf7fc79aaacd709f036b2 in cloudstack's branch refs/heads/4.4 from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=56c7fc8 ] CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute offerings with NPE Signed-off-by: Rohit Yadav > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithCo
[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128387#comment-14128387 ] ASF subversion and git services commented on CLOUDSTACK-7528: - Commit f4f5ea3cc02d931416579514a3289a607f7c5cac in cloudstack's branch refs/heads/4.4 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f4f5ea3 ] CLOUDSTACK-7528: More verbose logging when sending alert fails When sendAlert is called on an AlertManager impl, if it fails it logs that something was wrong but does not log the body of the issue/error. This means we tell the user/admin that there was an issue but don't share the "issue" with them at all as the email alert fail (or that they were not initialized). (cherry picked from commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694) Signed-off-by: Rohit Yadav Conflicts: server/src/com/cloud/alert/AlertManagerImpl.java > When AlertManager fails to sendAlert it does not log the actual issue/error > --- > > Key: CLOUDSTACK-7528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > AlertManager has a sendAlert method, the impls try to send emailAlerts but if > they fail they log it as warning the subject/error but don't log the actual > error. This message in logs is useless for users/admins as we tell them that > there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128389#comment-14128389 ] ASF subversion and git services commented on CLOUDSTACK-6099: - Commit 015276350e41b30bde049ca0852811ed6262da16 in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0152763 ] Merge remote-tracking branch 'origin/hotfix/4.4/CLOUDSTACK-6099' into 4.4 > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > 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.cloud
[jira] [Resolved] (CLOUDSTACK-7433) [Automation] Fix the script "test_deploy_vm_userdata_reg.py" - Host credentials are hardcoded in the script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye resolved CLOUDSTACK-7433.
Resolution: Fixed
> [Automation] Fix the script "test_deploy_vm_userdata_reg.py" - Host
> credentials are hardcoded in the script
> ---
>
> Key: CLOUDSTACK-7433
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7433
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.5.0
>
>
> The host credentials are hardcoded in the script. Please take the host
> specific information from test_data.py which is configurable.
> *Error Message*
> SSH Connection Failed Logs available at
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=deploy_vm_userdata
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File
> "/root/cloudstack/test/integration/component/test_deploy_vm_userdata_reg.py",
> line 209, in test_deployvm_userdata_post
> cmd
> File "/usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py", line
> 198, in get_process_status
> ssh = SshClient(hostip, port, username, password)
> File "/usr/local/lib/python2.7/dist-packages/marvin/sshClient.py", line 81,
> in __init__
> raise internalError("SSH Connection Failed")
> 'SSH Connection Failed\n
> Logs available at
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=deploy_vm_userdata
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7134) [Automation] Fix the script "test_reset_ssh_keypair.py" - Advanced Zone VM is being deployed in a Basic Zone deployment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-7134:
--
Assignee: Gaurav Aradhye (was: Girish Shilamkar)
> [Automation] Fix the script "test_reset_ssh_keypair.py" - Advanced Zone VM is
> being deployed in a Basic Zone deployment
> ---
>
> Key: CLOUDSTACK-7134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7134
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> =
> Error Message:
> =
> est_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-07-11T16:46:43+',
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin',
> userid : u'9f654606-08ed-11e4-887d-928d578f5db8', jobstatus : 1, jobid :
> u'e7c495f1-6324-4253-a453-494e2a36ae02', jobresultcode : 0, jobresulttype :
> u'object', jobresult : {domain : u'ROOT', domainid :
> u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', haenable : False, templatename :
> u'Cent OS Template-9UKJWR', securitygroup : [{egressrule : [], account :
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD',
> description : u'Default Security Group', tags : [], ingressrule : [], id :
> u'980df1d5-b24b-4851-b86c-2fd149692a57', name : u'default'}], zoneid :
> u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', cpunumber : 1, ostypeid : 12,
> passwordenabled : True, instancename : u'i-150-92-VM', id :
> u'e391e779-2efe-4c6a-ad1f-e03d0867165f', hostname : u'swordtail', displayvm :
> True, state : u'Running', guestosid :
> u'7cd2c9a6-08ed-11e4-887d-928d578f5db8', details : {hypervisortoolsversion :
> u'xenserver56'}, memory : 128, serviceofferingid :
> u'5a70bf03-2147-4426-80a9-11d76f658c7b', zonename : u'XenRT-Zone-0',
> isdynamicallyscalable : False, displayname : u'VM', tags : [], nic :
> [{networkid : u'd792af3b-8e8d-4830-aa96-0933f42c71a3', macaddress :
> u'06:95:c6:00:00:12', type : u'Shared', broadcasturi : u'vlan://untagged',
> traffictype : u'Guest', netmask : u'255.255.240.0', ipaddress :
> u'10.220.114.151', id : u'1ba07040-dbaa-419e-8941-a7ba6f922676', networkname
> : u'guestNetworkForBasicZone', gateway : u'10.220.112.1', isdefault : True}],
> cpuspeed : 100, jobstatus : 0, templateid :
> u'b9946974-966c-4a74-8c57-c9a55e08542d', password : u'kU8pbbvtg',
> affinitygroup : [], account :
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', hostid
> : u'71c113f0-a559-4c9f-95b0-1bfeec463a9c', name :
> u'VM-e391e779-2efe-4c6a-ad1f-e03d0867165f', created :
> u'2014-07-11T16:46:43+', hypervisor : u'XenServer', jobid :
> u'e7c495f1-6324-4253-a453-494e2a36ae02', rootdevicetype : u'ROOT',
> rootdeviceid : 0, serviceofferingname : u'Tiny Instance', templatedisplaytext
> : u'Cent OS Template'}, accountid : u'9f6536a2-08ed-11e4-887d-928d578f5db8'}
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Payload: {'account':
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD',
> 'domainid': u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', 'zoneid':
> u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', 'apiKey':
> u'Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA',
> 'command': 'associateIpAddress', 'signature':
> '52qNzGUlB0gK2dd/0r/tdZKGWaE=', 'response': 'json'}
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Sending GET Cmd : associateIpAddress===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.135.73
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?account=test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD&domainid=7ccbf6bc-08ed-11e4-887d-928d578f5db8&zoneid=ae56b8ba-3fd6-4f63-b71f-32128f86688a&apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA&command=associateIpAddress&signature=52qNzGUlB0gK2dd%2F0r%2FtdZKGWaE%3D&response=json
> HTTP/1.1" 533 129
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> ERROR: Exception:['Traceback (most recent call last):\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstack
[jira] [Updated] (CLOUDSTACK-7134) [Automation] Fix the script "test_reset_ssh_keypair.py" - Advanced Zone VM is being deployed in a Basic Zone deployment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye updated CLOUDSTACK-7134:
---
Status: Reviewable (was: In Progress)
> [Automation] Fix the script "test_reset_ssh_keypair.py" - Advanced Zone VM is
> being deployed in a Basic Zone deployment
> ---
>
> Key: CLOUDSTACK-7134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7134
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> =
> Error Message:
> =
> est_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-07-11T16:46:43+',
> cmd : u'org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin',
> userid : u'9f654606-08ed-11e4-887d-928d578f5db8', jobstatus : 1, jobid :
> u'e7c495f1-6324-4253-a453-494e2a36ae02', jobresultcode : 0, jobresulttype :
> u'object', jobresult : {domain : u'ROOT', domainid :
> u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', haenable : False, templatename :
> u'Cent OS Template-9UKJWR', securitygroup : [{egressrule : [], account :
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD',
> description : u'Default Security Group', tags : [], ingressrule : [], id :
> u'980df1d5-b24b-4851-b86c-2fd149692a57', name : u'default'}], zoneid :
> u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', cpunumber : 1, ostypeid : 12,
> passwordenabled : True, instancename : u'i-150-92-VM', id :
> u'e391e779-2efe-4c6a-ad1f-e03d0867165f', hostname : u'swordtail', displayvm :
> True, state : u'Running', guestosid :
> u'7cd2c9a6-08ed-11e4-887d-928d578f5db8', details : {hypervisortoolsversion :
> u'xenserver56'}, memory : 128, serviceofferingid :
> u'5a70bf03-2147-4426-80a9-11d76f658c7b', zonename : u'XenRT-Zone-0',
> isdynamicallyscalable : False, displayname : u'VM', tags : [], nic :
> [{networkid : u'd792af3b-8e8d-4830-aa96-0933f42c71a3', macaddress :
> u'06:95:c6:00:00:12', type : u'Shared', broadcasturi : u'vlan://untagged',
> traffictype : u'Guest', netmask : u'255.255.240.0', ipaddress :
> u'10.220.114.151', id : u'1ba07040-dbaa-419e-8941-a7ba6f922676', networkname
> : u'guestNetworkForBasicZone', gateway : u'10.220.112.1', isdefault : True}],
> cpuspeed : 100, jobstatus : 0, templateid :
> u'b9946974-966c-4a74-8c57-c9a55e08542d', password : u'kU8pbbvtg',
> affinitygroup : [], account :
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', hostid
> : u'71c113f0-a559-4c9f-95b0-1bfeec463a9c', name :
> u'VM-e391e779-2efe-4c6a-ad1f-e03d0867165f', created :
> u'2014-07-11T16:46:43+', hypervisor : u'XenServer', jobid :
> u'e7c495f1-6324-4253-a453-494e2a36ae02', rootdevicetype : u'ROOT',
> rootdeviceid : 0, serviceofferingname : u'Tiny Instance', templatedisplaytext
> : u'Cent OS Template'}, accountid : u'9f6536a2-08ed-11e4-887d-928d578f5db8'}
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Payload: {'account':
> u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD',
> 'domainid': u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', 'zoneid':
> u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', 'apiKey':
> u'Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA',
> 'command': 'associateIpAddress', 'signature':
> '52qNzGUlB0gK2dd/0r/tdZKGWaE=', 'response': 'json'}
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> DEBUG: Sending GET Cmd : associateIpAddress===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.135.73
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?account=test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD&domainid=7ccbf6bc-08ed-11e4-887d-928d578f5db8&zoneid=ae56b8ba-3fd6-4f63-b71f-32128f86688a&apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA&command=associateIpAddress&signature=52qNzGUlB0gK2dd%2F0r%2FtdZKGWaE%3D&response=json
> HTTP/1.1" 533 129
> test_01_reset_keypair_normal_user
> (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights):
> ERROR: Exception:['Traceback (most recent call last):\n', ' File
> "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
>
[jira] [Commented] (CLOUDSTACK-7135) [Automation] Fix the script "test_baremetal.py" - Can't have more than one Guest network in zone with network type Basic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128376#comment-14128376 ] Gaurav Aradhye commented on CLOUDSTACK-7135: Sent mail to Sheng Yang and Frank Zhank on dev list. Reply awaited. Test case tries to create a guest network in basic zone but fails because guest network is already present in the setup. > [Automation] Fix the script "test_baremetal.py" - Can't have more than one > Guest network in zone with network type Basic > > > Key: CLOUDSTACK-7135 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7135 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Gaurav Aradhye >Priority: Critical > Fix For: 4.5.0 > > > > Error Message: > > test_baremetal (integration.component.test_baremetal.TestBaremetal): DEBUG: > Sending GET Cmd : createNetwork=== > requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection > (1): 10.220.135.73 > requests.packages.urllib3.connectionpool: DEBUG: "GET > /client/api?apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA&zoneid=1&displaytext=defaultBaremetalNetwork&networkofferingid=84c3e203-139e-4412-ab81-8a6abecb3e35&response=json&name=defaultBaremetalNetwork&command=createNetwork&signature=alemHuTsxw31sTOaAyaZn2Cw4N8%3D > HTTP/1.1" 431 165 > test_baremetal (integration.component.test_baremetal.TestBaremetal): ERROR: > Exception:['Traceback (most recent call last):\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 308, in __parseAndGetResponse\nresponse_cls)\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 150, in getResultObj\nraise > cloudstackException.CloudstackAPIException(respname, errMsg)\n', > "CloudstackAPIException: Execute cmd: createnetwork failed, due to: > errorCode: 431, errorText:Can't have more than one Guest network in zone with > network type Basic\n"] > Traceback (most recent call last): > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 308, in __parseAndGetResponse > response_cls) > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 150, in getResultObj > raise cloudstackException.CloudstackAPIException(respname, errMsg) > CloudstackAPIException: Execute cmd: createnetwork failed, due to: errorCode: > 431, errorText:Can't have more than one Guest network in zone with network > type Basic > test_baremetal (integration.component.test_baremetal.TestBaremetal): ERROR: > marvinRequest : CmdName: object at 0x302ebd0> Exception: ['Traceback (most recent call last):\n', ' > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 375, in marvinRequest\nraise self.__lastError\n', > "CloudstackAPIException: Execute cmd: createnetwork failed, due to: > errorCode: 431, errorText:Can't have more than one Guest network in zone with > network type Basic\n"] > Traceback (most recent call last): > File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 375, in marvinRequest > raise self.__lastError > CloudstackAPIException: Execute cmd: createnetwork failed, due to: errorCode: > 431, errorText:Can't have more than one Guest network in zone with network > type Basic > test_baremetal (integration.component.test_baremetal.TestBaremetal): > CRITICAL: EXCEPTION: test_baremetal: ['Traceback (most recent call last):\n', > ' File "/usr/lib/python2.7/unittest/case.py", line 332, in run\n > testMethod()\n', ' File > "/home/jenkins/workspace/xenrt-reg-basic-xs/cloudstack.git/test/integration/component/test_baremetal.py", > line 110, in test_baremetal\nnetwork = Network.create(self.apiclient, > self.services["network"], zoneid=self.zoneid, > networkofferingid=networkoffering.id)\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/lib/base.py", > line 2591, in create\nreturn > Network(apiclient.createNetwork(cmd).__dict__)\n', ' File > "/local/jenkins/workspace/xenrt-reg-basic-xs/work.6
[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7351: --- Status: Reviewable (was: In Progress) > [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy > > > Key: CLOUDSTACK-7351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Critical > Fix For: 4.5.0 > > Attachments: CLOUDSTACK-7351.rar > > > This issue observed while running the test case > integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso > This test case deploying VM with below command > 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-4e4260d3) ===START=== 10.223.240.194 -- GET > account=test-TestVMAcc > ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze > Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo > TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543 > e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585 > This deployment failed with below error > 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for > Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y] > 2014-08-14 15:59:45,388 INFO [c.c.a.ApiServer] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor > parameter is needed to deploy VM or the hypervisor parameter value passed is > invalid > Is it required to pass hypervisor type ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-7351: -- Assignee: Gaurav Aradhye (was: Girish Shilamkar) > [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy > > > Key: CLOUDSTACK-7351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Critical > Fix For: 4.5.0 > > Attachments: CLOUDSTACK-7351.rar > > > This issue observed while running the test case > integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso > This test case deploying VM with below command > 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-4e4260d3) ===START=== 10.223.240.194 -- GET > account=test-TestVMAcc > ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y&domainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8&displayname=testserver&signature=4xBMTxK5iiaze > Fgwm2GisNo1SvM%3D&zoneid=a99226f1-d924-4156-8157-90bec0fa6579&apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo > TzASxzSN0OSUnfoQ&startvm=True&templateid=5cc1e055-5f49-4f12-91da-d01bf7ee509c&command=deployVirtualMachine&response=json&diskofferingid=543 > e345e-645a-4bf9-bd4e-af1db46470e7&serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585 > This deployment failed with below error > 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for > Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y] > 2014-08-14 15:59:45,388 INFO [c.c.a.ApiServer] > (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor > parameter is needed to deploy VM or the hypervisor parameter value passed is > invalid > Is it required to pass hypervisor type ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoi
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-6099. - Resolution: Fixed > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.se
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128370#comment-14128370 ] ASF subversion and git services commented on CLOUDSTACK-6099: - Commit 56c7fc800ad12e2e3ccbf7fc79aaacd709f036b2 in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-6099 from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=56c7fc8 ] CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute offerings with NPE Signed-off-by: Rohit Yadav > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultMa
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128369#comment-14128369 ] ASF subversion and git services commented on CLOUDSTACK-6099: - Commit 2b7b837b28f847eedf3cd7bd034dc23ba43d8a63 in cloudstack's branch refs/heads/master from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2b7b837 ] CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute offerings with NPE > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContex
[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128368#comment-14128368 ] ASF subversion and git services commented on CLOUDSTACK-6099: - Commit 57c69a8ba02a9d327629fd8665262efc94813d3a in cloudstack's branch refs/heads/4.3 from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=57c69a8 ] CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute offerings with NPE Signed-off-by: Rohit Yadav > live migration is failing for vm deployed using dynaic compute offerings with > NPE;unhandled exception executing api command: findHostsForMigration > java.lang.NullPointerException > - > > Key: CLOUDSTACK-6099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099 > 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, 4.4.0, 4.3.1, 4.4.1 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > Steps to reproduce > === > 1-Prepare CS setup with xen 6.2 ,two host in a cluster > 2-create a custom service offering > 3-deploy a vm with custom service offering > 4-try to migrate vm > Expected > = > vm should get migrate successfully > Actual > == > Migrate vm is failing with NPE > observation > === > migrate vm is working fine for vms deployed with regular compute offering > Log > === > 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume > allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize > : 115238502400, askingSize : 0, allocated disable threshold: 0.85 > 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator > returning 1 suitable storage pools > 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to > check for allocation: [Host[-4-Routing]] > 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation > after prioritization: [Host[-4-Routing]] > 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] > (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing > api command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267) > at > com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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 > 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithCo
[jira] [Commented] (CLOUDSTACK-755) nTier Apps 2.0 : Ability to give isolated network any IP network, not just unique from super-net
[ https://issues.apache.org/jira/browse/CLOUDSTACK-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128364#comment-14128364 ] Adrian Lewis commented on CLOUDSTACK-755: - Has anything come of this? It does seem like a fairly significant limitation that needs addressing, especially if a potential fix just needs to be committed. > nTier Apps 2.0 : Ability to give isolated network any IP network, not just > unique from super-net > > > Key: CLOUDSTACK-755 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-755 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Kishan Kavala > > This item is a sub task (2.11) of > https://issues.apache.org/jira/browse/CLOUDSTACK-621 > Users want flexibility in defining the IP Network for each of their tiers. > Users can specify a sub-network out of the VPC super-net for any specific > tier and they are limited to specifying only a network out of the super-net > defined while creating a VPC. > Specifying cidr while creating VPC can be made optional. If VPC cidr is not > specified, users can create a tier with any IP network. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7478) [LXC] VM creation should fail when creating LXC VM with data disk and w/o having ceph as primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7478. -- Verified fixed > [LXC] VM creation should fail when creating LXC VM with data disk and w/o > having ceph as primary storage > > > Key: CLOUDSTACK-7478 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7478 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: agent.log.tar.gz, ms.tar.gz > > > Repro steps: > 1. Create a LXC zone with only nfs > 2. Create a VM with data disk > Bug: > VM creations passes without giving error that data disk needs ceph storage > Even usage events for data disk is also generated. > VM shows no data disk with it > dumxml of VM shows: > > i-2-21-VM > 7da917bf-dd91-4185-92ce-a419b6a7e396 > CentOS 6.3 (64-bit) > 524288 > 524288 > 1 > > 500 > > > /machine > > > exe > /sbin/init > > > > > > > > > > > > destroy > restart > destroy > > /usr/libexec/libvirt_lxc > >dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/138ef448-03d7-4344-92a9-3e981b8826b6'/> > > > > > > > > > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7504. -- > [LXC] ha enabled VM not started on other host of cluster when original host > is put to maintenance > - > > Key: CLOUDSTACK-7504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > Create a LXC zone with two lxc host in a cluster > Create a HA enabled Service offering > Create a VM with ha enabled service offerings > Put host on maintenance which has this ha enabled VM > Expected result : > HA enabled VM should start on other available LXC host in the cluster > Bug: > HA enabled VM stops but don't start on other hosts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7502: --- Attachment: XenServer host.png > [UI] Host detail page - Display KVM agent version and Qemu version > -- > > Key: CLOUDSTACK-7502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: KVM host.png, XenServer host.png > > > UI - Host detail page - Display KVM agent version and Qemu version. > For KVM hosts, Host detail page should include KVM agent version and Qemu > version. > The information can be obtained via listHosts API command, details field: > CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version > is the version of kvm agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128329#comment-14128329 ] Mihaela Stoica commented on CLOUDSTACK-7502: Screenshots attached showing the UI change, only visible for KVM hosts. > [UI] Host detail page - Display KVM agent version and Qemu version > -- > > Key: CLOUDSTACK-7502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: KVM host.png, XenServer host.png > > > UI - Host detail page - Display KVM agent version and Qemu version. > For KVM hosts, Host detail page should include KVM agent version and Qemu > version. > The information can be obtained via listHosts API command, details field: > CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version > is the version of kvm agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7502: --- Attachment: KVM host.png > [UI] Host detail page - Display KVM agent version and Qemu version > -- > > Key: CLOUDSTACK-7502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: KVM host.png > > > UI - Host detail page - Display KVM agent version and Qemu version. > For KVM hosts, Host detail page should include KVM agent version and Qemu > version. > The information can be obtained via listHosts API command, details field: > CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version > is the version of kvm agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-6898: --- Fix Version/s: (was: 4.4.0) 4.5.0 > [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from > inside the console), the console gets stuck at a point. > --- > > Key: CLOUDSTACK-6898 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6898 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: Hyper-V >Reporter: Abhinav Roy >Assignee: Anshul Gangwar >Priority: Critical > Labels: hyper-V,, hyper-v, hyperv > Fix For: 4.5.0 > > Attachments: CS-6898.jpg > > > Steps : > == > 1. Deploy a Hyper-V setup with advanced zone. > 2. Deploy a VM. > 3. Now open the console of the VM from CS UI. > 4. Now reboot the VM from CS or from inside the console of VM > Expected behavior : > === > 1. The console should be accessible when the the VM is rebooting and after it > boots up. > Observed behavior : > == > The console gets stuck at the point of stopping the VM and remains in that > state. > Even if you close the console and reopen , it remains in the same state. > Attaching a screenshot for that. > Workaround : > > Either close the console or even in the open state don't do any activity on > it for 3 mins. After that it becomes accessible again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7503) [Hyper-V] Logging meaningless response string from Hyper-v Agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7503. Resolution: Fixed committed to master > [Hyper-V] Logging meaningless response string from Hyper-v Agent > > > Key: CLOUDSTACK-7503 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7503 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > Logging meaningless response string from Hyper-v Agent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6898. Resolution: Fixed > [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from > inside the console), the console gets stuck at a point. > --- > > Key: CLOUDSTACK-6898 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6898 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: Hyper-V >Reporter: Abhinav Roy >Assignee: Anshul Gangwar >Priority: Critical > Labels: hyper-V,, hyper-v, hyperv > Fix For: 4.4.0 > > Attachments: CS-6898.jpg > > > Steps : > == > 1. Deploy a Hyper-V setup with advanced zone. > 2. Deploy a VM. > 3. Now open the console of the VM from CS UI. > 4. Now reboot the VM from CS or from inside the console of VM > Expected behavior : > === > 1. The console should be accessible when the the VM is rebooting and after it > boots up. > Observed behavior : > == > The console gets stuck at the point of stopping the VM and remains in that > state. > Even if you close the console and reopen , it remains in the same state. > Attaching a screenshot for that. > Workaround : > > Either close the console or even in the open state don't do any activity on > it for 3 mins. After that it becomes accessible again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
shweta agarwal created CLOUDSTACK-7530: -- Summary: [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7507. -- Verified fixed. though router VM is not migrating across cluster for which I am filing separate bug > [LXC] router VMs are not migrating to other host in the cluster putting its > original host into maintenance > -- > > Key: CLOUDSTACK-7507 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7507 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > > Repro steps: > Create a Zone with LXC cluster having two host in the LXC cluster > Launch a VM in this cluster > Put LXC host to maintenance which has router VM > Bug; > Router VM does not migrates to other available host > Expected Result: > Router VM should migrate to other host in the cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7529) Make consistent use of CommandType.UUID in api layer
Rohit Yadav created CLOUDSTACK-7529: --- Summary: Make consistent use of CommandType.UUID in api layer Key: CLOUDSTACK-7529 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7529 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: Future, 4.5.0 CommandType.UUID may not be consistently used, we just need to check it across API layer and try to fix it where ever possible. cc Ilia Shakitko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7520) [UI] keep advanced search parameters visible after search has been run
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7520. Resolution: Fixed > [UI] keep advanced search parameters visible after search has been run > -- > > Key: CLOUDSTACK-7520 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7520 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > > After user runs an advanced search, the parameters they have entered into the > search box disappear. > - This causes confusion, because users often can't remember what they have > searched for to get their current search results. > - Parameters entered into the advance search box should remain visible after > user runs the > search, to mitigate confusion and enable way-finding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7520) [UI] keep advanced search parameters visible after search has been run
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128302#comment-14128302 ] ASF subversion and git services commented on CLOUDSTACK-7520: - Commit 75cd79a2382486385b5ae901c5b5c45cbd1505fc in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75cd79a ] CLOUDSTACK-7520: [UI] keep advanced search parameters visible after search has been run. - Preserve the advanced search parameters, so that when the advanced search box is shown again, it is populated with the values selected/entered previously, unless they have navigated away from the search results page, or applied any additional filters/search parameters. Signed-off-by: Mihaela Stoica Signed-off-by: Rajani Karuturi > [UI] keep advanced search parameters visible after search has been run > -- > > Key: CLOUDSTACK-7520 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7520 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > > After user runs an advanced search, the parameters they have entered into the > search box disappear. > - This causes confusion, because users often can't remember what they have > searched for to get their current search results. > - Parameters entered into the advance search box should remain visible after > user runs the > search, to mitigate confusion and enable way-finding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7473.
--
> [LXC]putting host into maintenance is failing
> --
>
> Key: CLOUDSTACK-7473
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Attachments: agent.log.tar.gz, ms.tar.gz
>
>
> Repro stesp:
> 1. create a zone with a LXC cluster having 2 host
> 2. create few LXC vms
> 3. Put one host into maintenance which has some VM running
> Bug:
> Putting host into maintenance will never pass. host will remain in preparing
> for maintenance stage and then goes to disconnect state.
> Agent log shows :
> 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-1:null) Failed to execute while migrating domain:
> org.libvirt.LibvirtException: this function is not supported by the
> connection driver: virDomainMigrate2
> 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 1-3693233169420517550: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
> this function is not supported by the connection driver:
> virDomainMigrate2","wait":0}}] }
> 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551: { Cmd ,
> MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.MigrateCommand":{"vmName":"i-2-7-VM","destIp":"10.147.28.49","hostGuid":"2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource","isWindows":false,"vmTO":{"id":7,"name":"i-2-7-VM","type":"User","cpus":1,"minSpeed":128,"maxSpeed":128,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Red
> Hat Enterprise Linux
> 7.0","platformEmulator":"Other","bootArgs":"","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"QY0cKnTfogzaS49R283f1g==","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"caf07a92-9f6c-49df-a7e4-27289e715448","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"981fe152-6ee5--ae41-474736c881cf","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-7","size":647321600,"path":"981fe152-6ee5--ae41-474736c881cf","volumeId":7,"vmName":"i-2-7-VM","accountId":2,"format":"DIR","provisioningType":"THIN","id":7,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"981fe152-6ee5--ae41-474736c881cf","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"647321600"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"95826449-4163-46b8-91b7-8bf94f19ab8e","uuid":"d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f","ip":"10.147.30.166","netmask":"255.255.255.0","gateway":"10.147.30.1","mac":"06:54:96:00:00:07","dns1":"10.140.50.6","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://30","isolationUri":"vlan://30","isSecurityGroupEnabled":true}]},"executeInSequence":false,"wait":0}}]
> }
> 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Processing command:
> com.cloud.agent.api.MigrateCommand
> 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM,
> continue
> 2014-09-02 19:08:13,018 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
> 2014-09-02 19:08:13,103 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete,
> waited 1000ms
> 2014-09-02 19:08:13,118 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
> 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Failed to execute while migrating domain:
> org.libvirt.LibvirtException: this function i
[jira] [Closed] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7472. -- > Change cloudstack agent.properties file for rhel 7 to include > kvmclock.disable=true > --- > > Key: CLOUDSTACK-7472 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > > We need to minimize manual steps that needs to be done after agent > installation so change cloudstack agent.properties file for rhel 7 to include > kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-7528. --- Resolution: Fixed Fixed on 4.3, 4.4 and master branches. > When AlertManager fails to sendAlert it does not log the actual issue/error > --- > > Key: CLOUDSTACK-7528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > AlertManager has a sendAlert method, the impls try to send emailAlerts but if > they fail they log it as warning the subject/error but don't log the actual > error. This message in logs is useless for users/admins as we tell them that > there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128286#comment-14128286 ] Daan Hoogland commented on CLOUDSTACK-7527: --- included this in branch hotfix/4.4/CLOUDSTACK-7184 > XenServer heartbeat-script: make it reboot faster (when fencing) > > > Key: CLOUDSTACK-7527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.3.0, 4.4.0 >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Minor > > xenheartbeat.sh: > I've seen the 'reboot' command hang, even though it has the force option > specified (last line of the script). Wouldn't it be better to invoke it like > this: > echo b > /proc/sysrq-trigger > Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128284#comment-14128284 ] ASF subversion and git services commented on CLOUDSTACK-7527: - Commit f497fceabb8c200cf2dacd87aa450f429dd9d385 in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7184 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f497fce ] CLOUDSTACK-7527 reboot faster by writing to /proc/sysrq-trigger > XenServer heartbeat-script: make it reboot faster (when fencing) > > > Key: CLOUDSTACK-7527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.3.0, 4.4.0 >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Minor > > xenheartbeat.sh: > I've seen the 'reboot' command hang, even though it has the force option > specified (last line of the script). Wouldn't it be better to invoke it like > this: > echo b > /proc/sysrq-trigger > Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7516) test_snapshots.py - VM Deploy failed because the account was using template belonging to different account to deploy the instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7516: --- Status: Reviewable (was: In Progress) > test_snapshots.py - VM Deploy failed because the account was using template > belonging to different account to deploy the instance > - > > Key: CLOUDSTACK-7516 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7516 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Following test case failed: > integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate > Reason: > Execute cmd: deployvirtualmachine failed, due to: errorCode: 531, > errorText:Acct[51d00171-895e-4893-90c8-6630b98f852a-test-TestCreateVMSnapshotTemplate-BJ9XFN] > does not have permission to operate with resource > Acct[e7b7973c-3512-11e4-9ac6-1a6f7bb0d0a8-admin] > Solution: > Create the template with the api client of the account itself, and not the > api client of root domain account. So that account will have permission to > use the resources (template) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128283#comment-14128283 ] ASF subversion and git services commented on CLOUDSTACK-7528: - Commit f4f5ea3cc02d931416579514a3289a607f7c5cac in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7528 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f4f5ea3 ] CLOUDSTACK-7528: More verbose logging when sending alert fails When sendAlert is called on an AlertManager impl, if it fails it logs that something was wrong but does not log the body of the issue/error. This means we tell the user/admin that there was an issue but don't share the "issue" with them at all as the email alert fail (or that they were not initialized). (cherry picked from commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694) Signed-off-by: Rohit Yadav Conflicts: server/src/com/cloud/alert/AlertManagerImpl.java > When AlertManager fails to sendAlert it does not log the actual issue/error > --- > > Key: CLOUDSTACK-7528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > AlertManager has a sendAlert method, the impls try to send emailAlerts but if > they fail they log it as warning the subject/error but don't log the actual > error. This message in logs is useless for users/admins as we tell them that > there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7519) [Task] Use bound/unbound menthods instead of calling API directly from test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7519. Resolution: Fixed > [Task] Use bound/unbound menthods instead of calling API directly from test > case > > > Key: CLOUDSTACK-7519 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7519 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > test_templates.py file has many instances where direct APIs are called from > the test case. Instead we have the methods in base library that can be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7434) [Automation] Fix the script "test_custom_hostname.py" - Internal name comparision appears to be wrong
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye resolved CLOUDSTACK-7434.
Resolution: Fixed
> [Automation] Fix the script "test_custom_hostname.py" - Internal name
> comparision appears to be wrong
> -
>
> Key: CLOUDSTACK-7434
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7434
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
>
> Error Log from the client results info:
>
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.220.135.69
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzg&response=json&command=listVirtualMachines&signature=J07ySQE7LwJA%2FYsOK4ouiEPsM7Y%3D&id=6548a12c-b999-495b-83bc-b928dcee99eb&listall=True
> HTTP/1.1" 200 1645
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> Response : [{domain : u'ROOT', domainid :
> u'56ab18f0-2b4d-11e4-89bd-1e5d0e053e75', haenable : False, templatename :
> u'CentOS 5.6(64-bit) no GUI (XenServer)', securitygroup : [], zoneid :
> u'eb811e7d-59d4-4c72-a965-80d9e30572d1', cpunumber : 1, ostypeid : 142,
> passwordenabled : False, instancename : u'i-220-406-VM', id :
> u'6548a12c-b999-495b-83bc-b928dcee99eb', hostname : u'cl09-B-02', displayvm :
> True, state : u'Running', guestosid :
> u'56bf8060-2b4d-11e4-89bd-1e5d0e053e75', details : {hypervisortoolsversion :
> u'xenserver56'}, memory : 128, serviceofferingid :
> u'27fc8179-da86-419e-99dd-f438e7b91c63', zonename : u'XenRT-Zone-0',
> isdynamicallyscalable : True, displayname : u'TestVM', tags : [], nic :
> [{networkid : u'435fb179-7868-48bd-bfb7-0efa86ee93ef', macaddress :
> u'02:00:56:8b:00:01', isolationuri : u'vlan://3074', type : u'Isolated',
> broadcasturi : u'vlan://3074', traffictype : u'Guest', netmask :
> u'255.255.255.0', ipaddress : u'192.168.200.171', id :
> u'95c36dd9-31e7-4be1-899b-20d5a36bf322', networkname :
> u'test-TestInstanceNameFlagTrue-test_01_custom_hostname_instancename_false-AWTN42-network',
> gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid :
> u'56af8f20-2b4d-11e4-89bd-1e5d0e053e75', affinitygroup : [], account :
> u'test-TestInstanceNameFlagTrue-test_01_custom_hostname_instancename_false-AWTN42',
> hostid : u'1065d9b2-260a-4642-bffe-b2523db3d798', name :
> u'VM-6548a12c-b999-495b-83bc-b928dcee99eb', created :
> u'2014-08-24T09:17:35+', hypervisor : u'XenServer', rootdevicetype :
> u'ROOT', rootdeviceid : 0, serviceofferingname : u'Tiny Instance',
> templatedisplaytext : u'CentOS 5.6(64-bit) no GUI (XenServer)'}]
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> vm.displayname: TestVM, original: TestVM
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> select id from account where uuid = 'd7313bc7-14ce-4df1-8949-f70c542e98a4';
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> select id from vm_instance where uuid =
> '6548a12c-b999-495b-83bc-b928dcee99eb';
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> Query result: 406
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG:
> Internal name: i-220-406-TestVM
> test_01_user_provided_hostname
> (integration.component.test_custom_hostname.TestInstanceNameFlagTrue):
> CRITICAL: FAILED: test_01_user_provided_hostname: ['Traceback (most recent
> call last):\n', ' File "/usr/lib/python2.7/unittest/case.py", line 332, in
> run\ntestMethod()\n', ' File
> "/root/cloudstack/test/integration/component/test_custom_hostname.py", line
> 289, in test_01_user_provided_hostname\n"VM internal name should match
> with that of the format"\n', ' File "/usr/lib/python2.7/unittest/case.py",
> line 516, in assertEqual\nassertion_func(first, second, msg=msg)\n', '
> File "/usr/lib/python2.7/unittest/case.py", line 927, in
> assertMultiLineEqual\nself.fail(self._formatMessage(msg,
> standardMsg))\n', ' File "/usr/lib/python2.7/unittest/case.py", line 413, in
> fail\nraise self.failureE
[jira] [Assigned] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland reassigned CLOUDSTACK-7527: - Assignee: Daan Hoogland > XenServer heartbeat-script: make it reboot faster (when fencing) > > > Key: CLOUDSTACK-7527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.3.0, 4.4.0 >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Minor > > xenheartbeat.sh: > I've seen the 'reboot' command hang, even though it has the force option > specified (last line of the script). Wouldn't it be better to invoke it like > this: > echo b > /proc/sysrq-trigger > Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128276#comment-14128276 ] ASF subversion and git services commented on CLOUDSTACK-7528: - Commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=91fd8d7 ] CLOUDSTACK-7528: More verbose logging when sending alert fails When sendAlert is called on an AlertManager impl, if it fails it logs that something was wrong but does not log the body of the issue/error. This means we tell the user/admin that there was an issue but don't share the "issue" with them at all as the email alert fail (or that they were not initialized). Signed-off-by: Rohit Yadav (cherry picked from commit 885c02dbd8b40d654f4a84fca8474ff88bc7ca5e) Signed-off-by: Rohit Yadav Conflicts: server/src/com/cloud/alert/AlertManagerImpl.java usage/src/com/cloud/usage/UsageAlertManagerImpl.java > When AlertManager fails to sendAlert it does not log the actual issue/error > --- > > Key: CLOUDSTACK-7528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > AlertManager has a sendAlert method, the impls try to send emailAlerts but if > they fail they log it as warning the subject/error but don't log the actual > error. This message in logs is useless for users/admins as we tell them that > there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128267#comment-14128267 ] ASF subversion and git services commented on CLOUDSTACK-7528: - Commit 885c02dbd8b40d654f4a84fca8474ff88bc7ca5e in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=885c02d ] CLOUDSTACK-7528: More verbose logging when sending alert fails When sendAlert is called on an AlertManager impl, if it fails it logs that something was wrong but does not log the body of the issue/error. This means we tell the user/admin that there was an issue but don't share the "issue" with them at all as the email alert fail (or that they were not initialized). Signed-off-by: Rohit Yadav > When AlertManager fails to sendAlert it does not log the actual issue/error > --- > > Key: CLOUDSTACK-7528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.0, 4.3.1, 4.4.1 > > > AlertManager has a sendAlert method, the impls try to send emailAlerts but if > they fail they log it as warning the subject/error but don't log the actual > error. This message in logs is useless for users/admins as we tell them that > there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128266#comment-14128266 ] Remi Bergsma commented on CLOUDSTACK-7184: -- [~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error
Rohit Yadav created CLOUDSTACK-7528: --- Summary: When AlertManager fails to sendAlert it does not log the actual issue/error Key: CLOUDSTACK-7528 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1 Reporter: Rohit Yadav Assignee: Rohit Yadav Priority: Critical Fix For: 4.5.0, 4.3.1, 4.4.1 AlertManager has a sendAlert method, the impls try to send emailAlerts but if they fail they log it as warning the subject/error but don't log the actual error. This message in logs is useless for users/admins as we tell them that there is an issue but don't share with them at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128266#comment-14128266 ] Remi Bergsma edited comment on CLOUDSTACK-7184 at 9/10/14 9:34 AM: --- @[~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! was (Author: remibergsma): [~dahn] Now that you're working on this script, please also look at CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
Remi Bergsma created CLOUDSTACK-7527: Summary: XenServer heartbeat-script: make it reboot faster (when fencing) Key: CLOUDSTACK-7527 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.3.0, 4.4.0 Reporter: Remi Bergsma Priority: Minor xenheartbeat.sh: I've seen the 'reboot' command hang, even though it has the force option specified (last line of the script). Wouldn't it be better to invoke it like this: echo b > /proc/sysrq-trigger Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128253#comment-14128253 ] Remi Bergsma commented on CLOUDSTACK-7184: -- +1! > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128240#comment-14128240 ] Daan Hoogland commented on CLOUDSTACK-7184: --- Brenn's idea seems sane to me, I will add the config items for the ping-check/fencing as well > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7519) [Task] Use bound/unbound menthods instead of calling API directly from test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128239#comment-14128239 ] ASF subversion and git services commented on CLOUDSTACK-7519: - Commit 81d5dd9bcda185ff83820f8dd6233cf80f8efaed in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81d5dd9 ] CLOUDSTACK-7519: Using bound/unbound methods instead of directly calling API methods from test case Signed-off-by: SrikanteswaraRao Talluri > [Task] Use bound/unbound menthods instead of calling API directly from test > case > > > Key: CLOUDSTACK-7519 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7519 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > test_templates.py file has many instances where direct APIs are called from > the test case. Instead we have the methods in base library that can be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7517) FTP modules are not loaded in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128231#comment-14128231 ] Jayapal Reddy commented on CLOUDSTACK-7517: --- Problem: --- FTP inbound service is not working in isolated networks. Created ingress rules for ftp on public ip and accessing ftp service in VM from the public network got failed. Root cause analysis: - ftp connection tracking modules are missed in VR. Due to which the ftp data connections are failing. Proposed solution: --- loading nf_nat_ftp module in VR using the modprobe command. nf_nat_ftp, nf_conntrack_ftp modules got loaded. root@r-7-QA:~# lsmod | grep ftp root@r-7-QA:~# modprobe nf_nat_ftp root@r-7-QA:~# lsmod | grep ftp nf_nat_ftp 12420 0 nf_conntrack_ftp 12533 1 nf_nat_ftp nf_nat 17924 2 nf_nat_ftp,iptable_nat nf_conntrack 43121 7 nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark root@r-7-QA:~# Verification steps: -- 1. In isolated network enable static nat for VM1 and open firewall port for 20-21 2. a. In VM1 install ftp server. http://ostechnix.wordpress.com/2013/12/15/setup-ftp-server-step-by-step-in-centos-6-x-rhel-6-x-scientific-linux-6-x/ b. stop iptables on the User VM c. add a new file in ftp sever path. ex: /var/ftp/pub/test.txt 3. verify in VR for modules loaded or not, refer commands in proposed solution section 4. Now connect to ftp server from public side and do file transfer. Use both cmd line and browser for connecting. #cmdline: JayMac:~ jayapalreddy$ ftp 10.147.52.115 Connected to 10.147.52.115. 220 (vsFTPd 2.0.5) Name (10.147.52.115:jayapalreddy): anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||20997|) 150 Here comes the directory listing. drwxr-xr-x2 004096 Sep 10 03:52 pub 226 Directory send OK. ftp> ftp> pwd Remote directory: / ftp> cd pub 250 Directory successfully changed. ftp> ls 229 Entering Extended Passive Mode (|||5789|) 150 Here comes the directory listing. -rw-r--r--1 00 35 Sep 10 03:52 test.txt 226 Directory send OK. ftp> get test.txt local: test.txt remote: test.txt 229 Entering Extended Passive Mode (|||21044|) 150 Opening BINARY mode data connection for test.txt (35 bytes). 100% |*| 35 12.43 KiB/s00:00 ETA 226 File send OK. 35 bytes received in 00:00 (1.28 KiB/s) ftp> #From web browser: ftp://10.147.52.115/pub/test.txt > FTP modules are not loaded in VR > > > Key: CLOUDSTACK-7517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > To have Active FTP working in isolated networks VRs need the have the > following modules loaded > modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > root@r-7-QA:~# modprobe nt_nat_ftp > FATAL: Module nt_nat_ftp not found. > root@r-7-QA:~# modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > nf_nat_ftp 12420 0 > nf_conntrack_ftp 12533 1 nf_nat_ftp > nf_nat 17924 2 nf_nat_ftp,iptable_nat > nf_conntrack 43121 7 > nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7517) FTP modules are not loaded in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-7517. --- Resolution: Fixed > FTP modules are not loaded in VR > > > Key: CLOUDSTACK-7517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > To have Active FTP working in isolated networks VRs need the have the > following modules loaded > modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > root@r-7-QA:~# modprobe nt_nat_ftp > FATAL: Module nt_nat_ftp not found. > root@r-7-QA:~# modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > nf_nat_ftp 12420 0 > nf_conntrack_ftp 12533 1 nf_nat_ftp > nf_nat 17924 2 nf_nat_ftp,iptable_nat > nf_conntrack 43121 7 > nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7517) FTP modules are not loaded in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128229#comment-14128229 ] ASF subversion and git services commented on CLOUDSTACK-7517: - Commit b4f03a1339c67438a2a9cf94dd81b98cdfb458b9 in cloudstack's branch refs/heads/master from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b4f03a1 ] CLOUDSTACK-7517: loading ftp modules in VR > FTP modules are not loaded in VR > > > Key: CLOUDSTACK-7517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > To have Active FTP working in isolated networks VRs need the have the > following modules loaded > modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > root@r-7-QA:~# modprobe nt_nat_ftp > FATAL: Module nt_nat_ftp not found. > root@r-7-QA:~# modprobe nf_nat_ftp > root@r-7-QA:~# lsmod | grep ftp > nf_nat_ftp 12420 0 > nf_conntrack_ftp 12533 1 nf_nat_ftp > nf_nat 17924 2 nf_nat_ftp,iptable_nat > nf_conntrack 43121 7 > nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7526: - Description: Steps: 1. Access Management Server UI 2. Go to Templates => Details of any of the template Observation: Observed Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add) Attached screen was: Steps: 1. Access Management Server UI 2. Go to Templates => Details of any of the template Observation: Observed Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add) Attached screen > [UI]Incorrect Field value with Template/ISO/Network/Instance details page > while adding Tags(Key and Value) (label.add) > > > Key: CLOUDSTACK-7526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada > Fix For: 4.5.0 > > Attachments: screenshot-1.png > > > Steps: > 1. Access Management Server UI > 2. Go to Templates => Details of any of the template > Observation: > Observed Incorrect Field value with Template/ISO/Network/Instance details > page while adding Tags(Key and Value) (label.add) > Attached screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7526: - Summary: [UI]Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add) (was: [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)) > [UI]Incorrect Field value with Template/ISO/Network/Instance details page > while adding Tags(Key and Value) (label.add) > > > Key: CLOUDSTACK-7526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada > Fix For: 4.5.0 > > Attachments: screenshot-1.png > > > Steps: > 1. Access Management Server UI > 2. Go to Templates => Details of any of the template > Observation: > Observed Incorrect Field value with Template/ISO details page while adding > Tags(Key and Value) (label.add) > Attached screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)
Sailaja Mada created CLOUDSTACK-7526: Summary: [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add) Key: CLOUDSTACK-7526 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Steps: 1. Access Management Server UI 2. Go to Templates => Details of any of the template Observation: Observed Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add) Attached screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7526: - Fix Version/s: 4.5.0 > [UI]Incorrect Field value with Template/ISO details page while adding > Tags(Key and Value) (label.add) > --- > > Key: CLOUDSTACK-7526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada > Fix For: 4.5.0 > > Attachments: screenshot-1.png > > > Steps: > 1. Access Management Server UI > 2. Go to Templates => Details of any of the template > Observation: > Observed Incorrect Field value with Template/ISO details page while adding > Tags(Key and Value) (label.add) > Attached screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7526: - Attachment: screenshot-1.png > [UI]Incorrect Field value with Template/ISO details page while adding > Tags(Key and Value) (label.add) > --- > > Key: CLOUDSTACK-7526 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada > Fix For: 4.5.0 > > Attachments: screenshot-1.png > > > Steps: > 1. Access Management Server UI > 2. Go to Templates => Details of any of the template > Observation: > Observed Incorrect Field value with Template/ISO details page while adding > Tags(Key and Value) (label.add) > Attached screen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128217#comment-14128217 ] Brenn Oosterbaan edited comment on CLOUDSTACK-7184 at 9/10/14 8:25 AM: --- Implementing the solution above looks like the fastest/easiest fix to me. Ideally you would want a second heartbeat script on the hypervisor. One which checks if Cloudstack has been able to communicate with the hypervisor, and if not fences the hypervisor using the same interval and retry counts as Cloudstack. This would allow us to set different timeouts for different scenario's without the possibility of corrupted VM's: - If the storage is unreachable but the hypervisor is up and running - wait until storage timeout value is reached and reboot. - If the hypervisor has crashed OR the networking stack for that hypervisor is stuck/unreachable - wait until the hypervisor max retry value is met, HA the vm's and reboot the hypervisor. That way we could decide to set the hypervisor.heartbeat.interval to 5 and the hypervisor.heartbeat.max_retry to 6 and the storage timeout to 180. Which would effectively say: if storage is down wait 180 seconds, if something else happened only wait 30 seconds. But this should probably be a feature request. regards, Brenn was (Author: boosterb...@schubergphilis.com): Implementing the solution above looks like the fastest/easiest fix to me. Ideally you would want a second heartbeat script on the hypervisor as well. One which checks if Cloudstack has been able to communicate with the hypervisor, and if not fences the hypervisor using the same interval and retry counts as Cloudstack. This would allow us to set different timeouts for different scenario's without the possibility of corrupted VM's: - If the storage is unreachable but the hypervisor is up and running - wait until storage timeout value is reached and reboot. - If the hypervisor has crashed OR the networking stack for that hypervisor is stuck/unreachable - wait until the hypervisor max retry value is met, HA the vm's and reboot the hypervisor. That way we could decide to set the hypervisor.heartbeat.interval to 5 and the hypervisor.heartbeat.max_retry to 6 and the storage timeout to 180. Which would effectively say: if storage is down wait 180 seconds, if something else happened only wait 30 seconds. But this should probably be a feature request. regards, Brenn > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128217#comment-14128217 ] Brenn Oosterbaan commented on CLOUDSTACK-7184: -- Implementing the solution above looks like the fastest/easiest fix to me. Ideally you would want a second heartbeat script on the hypervisor as well. One which checks if Cloudstack has been able to communicate with the hypervisor, and if not fences the hypervisor using the same interval and retry counts as Cloudstack. This would allow us to set different timeouts for different scenario's without the possibility of corrupted VM's: - If the storage is unreachable but the hypervisor is up and running - wait until storage timeout value is reached and reboot. - If the hypervisor has crashed OR the networking stack for that hypervisor is stuck/unreachable - wait until the hypervisor max retry value is met, HA the vm's and reboot the hypervisor. That way we could decide to set the hypervisor.heartbeat.interval to 5 and the hypervisor.heartbeat.max_retry to 6 and the storage timeout to 180. Which would effectively say: if storage is down wait 180 seconds, if something else happened only wait 30 seconds. But this should probably be a feature request. regards, Brenn > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128206#comment-14128206 ] Brenn Oosterbaan edited comment on CLOUDSTACK-7184 at 9/10/14 8:09 AM: --- "I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd suggest that possibly CS be a little more thorough before deciding a VM is down...maybe via channels other than the agent/VR?" John is right on the money here. Although the patch comitted by Daan does give the possibility to specify a check interval for the Xen storage heartbeat script (instead of using the default of 5 seconds) it is not the root cause of this issue. There are two mechanisms at work here. The xen heartbeat script which checks if the storage is reachable on a specific hypervisors, and Cloudstack which determines if a hypervisor is up or not. When we set the Xen heartbeat interval to 180 seconds we basicly said: it's ok for vm's living on a hypervisor to 'hang' for 180 seconds in case of storage fail-overs or other issues. Cloudstack has its own checking mechanisms to determine if a hypervisor is down or not. Those checks are not in line with the xen heartbeat interval. Which means that even though we decided 180 seconds of unavailability is fine, Cloudstack tries to connect to the hypervisor 3 times (in ~30 seconds) and then decides it is down and starts the vm's on another hypervisor. That is the issue/bug Remi meant to identify when filing this ticket. I personally feel there should be two additional options: hypervisor.heartbeat.interval and hypervisor.heartbeat.max_retry. This would allow us to decide to (for instance) set the interval to 15 seconds and the max_retry to 12. Which would then add up to 180 seconds as well. Since the default heartbeat timeout is 60 seconds I would set the defaults for these to a combination which allows for 60 seconds as well. Otherwise you will never be sure the hypervisor it self has actually rebooted and thus VM corruption could still take place. regards, Brenn was (Author: boosterb...@schubergphilis.com): "I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd suggest that possibly CS be a little more thorough before deciding a VM is down...maybe via channels other than the agent/VR?" John is right on the money here. Although the patch comitted by Daan does give the possibility to specify a check interval for the Xen storage heartbeat script (instead of using the default of 5 seconds) it is not the root cause of this issue. There are two mechanisms at work here. The xen heartbeat script which checks if the storage is reachable on a specific hypervisors, and Cloudstack which determines if a hypervisor is up or not. When we set the Xen heartbeat interval to 180 seconds we basicly said: it's ok for vm's living on a hypervisor to 'hang' for 180 seconds in case of storage fail-overs or other issues. Cloudstack has it's own checking mechanisms to determine if a hypervisor is down or not. Those checks are not in line with the xen heartbeat interval. Which means that even though we decided 180 seconds of unavailability is fine, Cloudstack tries to connect to the hypervisor 3 times (in ~30 seconds) and then decides it is down and starts the vm's on another hypervisor. That is the issue/bug Remi meant to identify when filing this ticket. I personally feel there should be two additional global options: hypervisor.heartbeat.interval and hypervisor.heartbeat.max_retry. This would allow us to decide to (for instance) set the interval to 15 seconds and the max_retry to 12. Which would then add up to 180 seconds as well. Since the default heartbeat timeout is 60 seconds I would set the defaults for these to a combination which allows for 60 seconds as well. Otherwise you will never be sure the hypervisor it self has actually rebooted and thus VM corruption could still take place. regards, Brenn > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and imme
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128206#comment-14128206 ] Brenn Oosterbaan commented on CLOUDSTACK-7184: -- "I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd suggest that possibly CS be a little more thorough before deciding a VM is down...maybe via channels other than the agent/VR?" John is right on the money here. Although the patch comitted by Daan does give the possibility to specify a check interval for the Xen storage heartbeat script (instead of using the default of 5 seconds) it is not the root cause of this issue. There are two mechanisms at work here. The xen heartbeat script which checks if the storage is reachable on a specific hypervisors, and Cloudstack which determines if a hypervisor is up or not. When we set the Xen heartbeat interval to 180 seconds we basicly said: it's ok for vm's living on a hypervisor to 'hang' for 180 seconds in case of storage fail-overs or other issues. Cloudstack has it's own checking mechanisms to determine if a hypervisor is down or not. Those checks are not in line with the xen heartbeat interval. Which means that even though we decided 180 seconds of unavailability is fine, Cloudstack tries to connect to the hypervisor 3 times (in ~30 seconds) and then decides it is down and starts the vm's on another hypervisor. That is the issue/bug Remi meant to identify when filing this ticket. I personally feel there should be two additional global options: hypervisor.heartbeat.interval and hypervisor.heartbeat.max_retry. This would allow us to decide to (for instance) set the interval to 15 seconds and the max_retry to 12. Which would then add up to 180 seconds as well. Since the default heartbeat timeout is 60 seconds I would set the defaults for these to a combination which allows for 60 seconds as well. Otherwise you will never be sure the hypervisor it self has actually rebooted and thus VM corruption could still take place. regards, Brenn > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Assignee: Daan Hoogland >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7525) UI: Edit SecurityGroup rules tags
Ilia Shakitko created CLOUDSTACK-7525: - Summary: UI: Edit SecurityGroup rules tags Key: CLOUDSTACK-7525 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7525 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Ilia Shakitko Priority: Minor Fix For: 4.5.0 Some time back tagging was added for SecurityGroup rules to the API, but it's not available via UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
