[jira] [Updated] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7515:
---
Attachment: agent-router.tar.gz
management-server.log.2014-09-08.gz
agen-user-vm.tar.gz

> [LXC] user VM is getting different mac than the one with router  for the same 
> VM in case of shared network
> --
>
> Key: CLOUDSTACK-7515
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, 
> management-server.log.2014-09-08.gz
>
>
> Repro steps:
> 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster 
> having one host and other having two host .all host are LXC
> 2. Create a shared Network
> 3. Create a VM  using only shared network as default network
> Bug:
> Notice mac address that VM has is different than the one Router has for the 
> same vm 
> router VM shows
> cat /etc/dhcphosts.txt
> 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite
> 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite
> 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite
> 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite
> For USER VM with  IP 10.147.31.144
> router has mac06:45:08:00:00:19 but VM  has mac  06:4d:15:46:f3:c6 
> Ifconfig on VM  shows
>  ifconfig
> eth0: flags=4163  mtu 1500
> inet6 fe80::44d:15ff:fe46:f3c6  prefixlen 64  scopeid 0x20
> ether 06:4d:15:46:f3:c6  txqueuelen 1000  (Ethernet)
> RX packets 1938  bytes 414054 (404.3 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 14  bytes 2700 (2.6 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 0  (Local Loopback)
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 0  bytes 0 (0.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> Notice even IP is not set for such VMs
> Attaching Ms and agent logs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[Abhinandan Prateek (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126694#comment-14126694
 ] 

Abhinandan Prateek commented on CLOUDSTACK-7497:


Stephen,
  Can you have someone look into it ?

> [UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> ---
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Assignee: Stephen Turner
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[Abhinandan Prateek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abhinandan Prateek updated CLOUDSTACK-7497:
---
Assignee: Stephen Turner

> [UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> ---
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Assignee: Stephen Turner
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7506) Secondary Storage LImits test cases are failing while registering template with error "Invalid Parameters - Hypervisor is required"

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126693#comment-14126693
 ] 

ASF subversion and git services commented on CLOUDSTACK-7506:
-

Commit d08d71427bba562aa8b46a54143a783051297494 in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d08d714 ]

CLOUDSTACK-7506: Fix base library to read hypevisor value from dictionary as 
opposed to only from function parameter

Signed-off-by: SrikanteswaraRao Talluri 


> Secondary Storage LImits test cases are failing while registering template 
> with error "Invalid Parameters - Hypervisor is required"
> ---
>
> Key: CLOUDSTACK-7506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7506
> 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
>
>
> Base library function is reading hypervisor value only from function 
> parameter and not from services dictionary. But the test cases are passing 
> hypervisor value from dictionary.
> Solution:
> Read the hypervisor value from the services dict if it's not passed through 
> the function parameter.
> Details:
> test_01_deploy_vm_domain_limit_reached 
> (integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
> DEBUG: CmdName: registerTemplate Parameter : hypervisor is Required
> test_01_deploy_vm_domain_limit_reached 
> (integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
> ERROR: marvinRequest : CmdName: 
>  0x2855a10> Exception: ['Traceback (most recent call last):\n', '  File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 353, in marvinRequest\nraise self.__lastError\n', 
> 'InvalidParameterException: Invalid Parameters\n']
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 353, in marvinRequest
> raise self.__lastError
> InvalidParameterException: Invalid Parameters
> test_01_deploy_vm_domain_limit_reached 
> (integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
> CRITICAL: FAILED: test_01_deploy_vm_domain_limit_reached: ['Traceback (most 
> recent call last):\n', '  File "/usr/local/lib/python2.7/unittest/case.py", 
> line 318, in run\ntestMethod()\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_max_limits.py", 
> line 183, in test_01_deploy_vm_domain_limit_reached\n
> self.assertEqual(response[0], PASS, response[1])\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual\n
> assertion_func(first, second, msg=msg)\n', '  File 
> "/usr/local/lib/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n  
>   raise self.failureException(msg)\n', 'AssertionError: Invalid Parameters\n']
> - >> end captured logging << -



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7516) test_snapshots.py - VM Deploy failed because the account was using template belonging to different account to deploy the instance

[Gaurav Aradhye (JIRA)]

Gaurav Aradhye created CLOUDSTACK-7516:
--

 Summary: 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
 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] [Created] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7515:
--

 Summary: [LXC] user VM is getting different mac than the one with 
router  for the same VM in case of shared network
 Key: CLOUDSTACK-7515
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM, Network Controller
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


Repro steps:

1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having 
one host and other having two host .all host are LXC
2. Create a shared Network
3. Create a VM  using only shared network as default network

Bug:
Notice mac address that VM has is different than the one Router has for the 
same vm 

router VM shows

cat /etc/dhcphosts.txt
06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite
06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite
06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite
06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite

For USER VM with  IP 10.147.31.144
router has mac06:45:08:00:00:19 but VM  has mac  06:4d:15:46:f3:c6 

Ifconfig on VM  shows
 ifconfig
eth0: flags=4163  mtu 1500
inet6 fe80::44d:15ff:fe46:f3c6  prefixlen 64  scopeid 0x20
ether 06:4d:15:46:f3:c6  txqueuelen 1000  (Ethernet)
RX packets 1938  bytes 414054 (404.3 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 14  bytes 2700 (2.6 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 0  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Notice even IP is not set for such VMs

Attaching Ms and agent logs









--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7509) test_ss_limits.TestSecondaryStorageLimits.test_04_copy_template_1_root_domain_admin failed due to missing bound method

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126671#comment-14126671
 ] 

ASF subversion and git services commented on CLOUDSTACK-7509:
-

Commit bbb3ea5983928df66704ab78cef0a1c3e292cbe9 in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbb3ea5 ]

CLOUDSTACK-7509: Added missing bound method in base library for copyTemplate 
operation

Signed-off-by: SrikanteswaraRao Talluri 


> test_ss_limits.TestSecondaryStorageLimits.test_04_copy_template_1_root_domain_admin
>  failed due to missing bound method
> --
>
> Key: CLOUDSTACK-7509
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7509
> 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
>
>
> Bound method for copyTemplate is missing in library, hence test cases failed 
> during copy operation.
> test_04_copy_template_1_root_domain_admin 
> (integration.component.test_ss_limits.TestSecondaryStorageLimits): CRITICAL: 
> EXCEPTION: test_04_copy_template_1_root_domain_admin: ['Traceback (most 
> recent call last):\n', '  File "/usr/local/lib/python2.7/unittest/case.py", 
> line 318, in run\ntestMethod()\n', '  File 
> "/usr/local/lib/python2.7/site-packages/ddt.py", line 114, in wrapper\n
> return func(self, *args, **kwargs)\n', '  File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_limits.py", 
> line 369, in test_04_copy_template\nsourcezoneid = template.zoneid)\n', 
> 'TypeError: copy() takes exactly 5 arguments (4 given)\n']
> - >> end captured logging << -
> Stacktrace
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File "/usr/local/lib/python2.7/site-packages/ddt.py", line 114, in wrapper
> return func(self, *args, **kwargs)
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_limits.py", 
> line 369, in test_04_copy_template
> sourcezoneid = template.zoneid)
> 'copy() takes exactly 5 arguments (4 given)\n >> begin 
> captured stdout << -\n=== TestName: 
> test_04_copy_template_1_root_domain_admin | Status : EXCEPTION 
> ===\n\n\n- >> end captured stdout << 
> --\n >> begin captured logging << 
> \ntest_04_copy_template_1_root_domain_admin 
> (integration.component.test_ss_limits.TestSecondaryStorageLimits): DEBUG: 
> STARTED : TC: test_04_copy_template_1_root_domain_admin 
> :::\ntest_04_copy_template_1_root_domain_admin 
> (integration.component.test_ss_limits.TestSecondaryStorageLimits): DEBUG: 
> Payload: {\'apiKey\': 
> u\'OK1UH4l8UUYHDWdnVSWETzepdzs07VAwZBCYZwS4W2zHupX3PAISs1Ug7oMKUBO17rHHkOr3ZAKFVf2fsKYIvQ\',
>  \'command\': \'listZones\', \'signature\': \'H8DhzBD18g1bf1QQ1r7w5RU+eRU=\', 
> \'response\': \'json\'}\ntest_04_copy_template_1_root_domain_admin 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7393) [Automation] Fix the script "test_vpc_vm_life_cycle.py" - Code is hardcoded to use certain host tags

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1412#comment-1412
 ] 

ASF subversion and git services commented on CLOUDSTACK-7393:
-

Commit 402fc914cf4047b7faf1b1410972bb5a4ae5b29d in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=402fc91 ]

CLOUDSTACK-7393: Expunging VM immediately and removing unncessary wait in 
test_vpc_vm_life_cycle.py

Signed-off-by: SrikanteswaraRao Talluri 


> [Automation] Fix the script "test_vpc_vm_life_cycle.py" - Code is hardcoded 
> to use certain host tags
> 
>
> Key: CLOUDSTACK-7393
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7393
> 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
>
>
> *Script is present at:*
> component/test_vpc_vm_life_cycle.py
> Currently script assumes that the deployment has hosts with host_tags "host1" 
> and "host2" and uses two service offerings with these host_tags. The script 
> is hardcoded with the above information. The proper design and correction 
> should be as follows.
> Find the cluster with two hosts
> If no two host cluster is found error out with proper message
> Edit the host tags on the two hosts to two different unique names
> Create corresponding service offerings with the two different unique names
> Conduct the tests
> In teardown script section of the script, edit the host tags on the hosts 
> to empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

[Francois Gaudreault (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126488#comment-14126488
 ] 

Francois Gaudreault commented on CLOUDSTACK-7364:
-

Rajesh,

Did you make any progress on this?

> NetScaler won't create the Public VLAN and Bind the IP to it
> 
>
> Key: CLOUDSTACK-7364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.4.0, 4.4.1
>Reporter: Francois Gaudreault
>Assignee: Rajesh Battala
>Priority: Critical
> Attachments: management-server.log.debug.gz
>
>
> When adding a Load Balancing rule with the NetScaler, the provider will tag 
> and bind the private IP to the appropriate interface. However, the behaviour 
> for the Public Interface is different. It simply adds the IP untagged on all 
> interfaces. This is wrong.
> The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
> avoid unnecessary ARP on other VLANs.
> NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7122) [Automation] "configureSimulator" is not detected as API on base.py

[Chandan Purushothama (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama closed CLOUDSTACK-7122.


Closing the bug based on Koushik's comment

> [Automation] "configureSimulator" is not detected as API on base.py
> ---
>
> Key: CLOUDSTACK-7122
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7122
> 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: Koushik Das
>Priority: Critical
> Fix For: 4.5.0
>
>
> ==
> TestCase Failure due to the bug on base.py:
> ==
> test_vm_sync (integration.smoke.test_vm_sync.TestDeployVMSync): DEBUG: 
> Response : [{managedstate : u'Managed', name : 
> u'XenRT-Zone-0-Pod-0-Cluster-0', podid : 
> u'076e5c08-bfb0-4f43-9dba-175d4c511023', memoryovercommitratio : u'1.0', 
> clustertype : u'CloudManaged', allocationstate : u'Enabled', zoneid : 
> u'266cd8ee-c11b-45f8-a423-2aa15b4cae49', cpuovercommitratio : u'1.0', podname 
> : u'XenRT-Zone-0-Pod-0', zonename : u'XenRT-Zone-0', id : 
> u'a84e9409-2ce8-441d-944e-3abdbe259e32', hypervisortype : u'XenServer'}]
> test_vm_sync (integration.smoke.test_vm_sync.TestDeployVMSync): CRITICAL: 
> EXCEPTION: test_vm_sync: ['Traceback (most recent call last):\n', '  File 
> "/usr/lib/python2.7/unittest/case.py", line 323, in run\nself.setUp()\n', 
> '  File 
> "/home/jenkins/workspace/xenrt-bvt-adv-xs/cloudstack.git/test/integration/smoke/test_vm_sync.py",
>  line 116, in setUp\nmethod=\'POST\')\n', '  File 
> "/local/jenkins/workspace/xenrt-bvt-adv-xs/work.195/env/local/lib/python2.7/site-packages/marvin/lib/base.py",
>  line 4630, in create\ncmd = 
> configureSimulator.configureSimulatorCmd()\n', "NameError: global name 
> 'configureSimulator' is not defined\n"]
> - >> end captured logging << -
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 323, in run
> self.setUp()
>   File 
> "/home/jenkins/workspace/xenrt-bvt-adv-xs/cloudstack.git/test/integration/smoke/test_vm_sync.py",
>  line 116, in setUp
> method='POST')
>   File 
> "/local/jenkins/workspace/xenrt-bvt-adv-xs/work.195/env/local/lib/python2.7/site-packages/marvin/lib/base.py",
>  line 4630, in create
> cmd = configureSimulator.configureSimulatorCmd()
> 'global name \'configureSimulator\' is not defined\n >> 
> begin captured stdout << -\n=== TestName: test_vm_sync | 
> Status : EXCEPTION ===\n\n\n- >> end captured stdout << 
> --\n >> begin captured logging << 
> \ntest_03_delete_vm_snapshots 
> (integration.smoke.test_vm_snapshots.TestVmSnapshot): DEBUG: Payload: 
> {\'signature\': \'DgDHiZp0tv81xpH1363NAv0bsik=\', \'apiKey\': 
> u\'97q0_edU6-NJOeW0U0R20dn_lNhso2hNVln2LSAUp8dAfo3_9q7HDuA5HkA9v7OWfqL-d8lgUG0PTR67WuLY5A\',
>  \'command\': \'deleteServiceOffering\', \'id\': 
> u\'aa7d3fc8-40ee-4513-8fec-1223c6e7ff4a\', \'response\': 
> \'json\'}\ntest_03_delete_vm_snapshots 
> (integration.smoke.test_vm_snapshots.TestVmSnapshot): DEBUG: Sending 
> GET Cmd : 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7514) Automation] - Automate ACL test cases relating to listSnapshots()

[Sangeetha Hariharan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sangeetha Hariharan updated CLOUDSTACK-7514:

Description: [Automation] - Automate ACL test cases relating to 
listSnapshots()  (was: [Automation] - Automate ACL test cases relating to 
listVolumes())

> Automation] - Automate ACL test cases relating to listSnapshots()
> -
>
> Key: CLOUDSTACK-7514
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7514
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.4.0
>Reporter: Sangeetha Hariharan
>
> [Automation] - Automate ACL test cases relating to listSnapshots()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7514) Automation] - Automate ACL test cases relating to listSnapshots()

[Sangeetha Hariharan (JIRA)]

Sangeetha Hariharan created CLOUDSTACK-7514:
---

 Summary: Automation] - Automate ACL test cases relating to 
listSnapshots()
 Key: CLOUDSTACK-7514
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7514
 Project: CloudStack
  Issue Type: Task
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan


[Automation] - Automate ACL test cases relating to listVolumes()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-5664) XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation VMs deployed before patch installation does not acquire new rules set

[Anthony Xu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Xu resolved CLOUDSTACK-5664.

Resolution: Incomplete

needs more inof
1.  Xe task-list
2.  Where to get CSP
3.  Uname –a ( show kernel version)
4.  Ipset –V


> XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation 
> VMs deployed before patch installation does not acquire new rules set 
> ---
>
> Key: CLOUDSTACK-5664
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5664
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
>Reporter: angeline shen
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: 513SMlog, 513xensource.log, 513xenstored-access.log, 
> 513xenstored-access.log.1, 513xenstored-access.log.2, 
> 513xenstored-access.log.3, 514SMlog, 514xensource.log, 
> 514xenstored-access.log, management-server.log.gz
>
>
>  XEN hotfix installation procedure
> 1. Hosts  master  slave installed with
> XS 6.0.2 base + Hotfix  XS602E001 to XS602E029 + CSPs
> 2. Basic zone with cluster of above master & slave hosts
> security group default  with NO security rules
> Deploy two VMs
> 3. MS: master host put to maintenance mode - VMs migrate to slave host
> 4. MS: unmanage cluster
> 5. master host:  install hotfix  XS602E030 + CSP , reboot master
> 6. MS: master host cancel maintenance mode
> 7. MS: manage cluster
> 8. MS: slave host put to maintenance mode - VMs migrate to master host
> 9. MS: Add security rules:  ingress TCP   1 - 80900.0.0.0/0
>  ingress ICMP   -1  -10.0.0.0/0
>  egress TCP1 - 80900.0.0.0/0
>  egress ICMP   -1  -10.0.0.0/0
> 10. MS: slave host cancel maintenance mode
> 11. stop/start SSVMVR
> 12. Deploy two more VMs
> Test result:
> VMs deployed after HotFix XS602E030 installation correctly acquired 4 new 
> ingress + egress rules
> VMs deployed before  HotFix XS602E030 installation did not acquire 4 new 
> ingress & egress rules - error
> Also there are errors encountered when attempt to apply these rules to old 
> VMs:
> 2013-12-27 12:14:37,294 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-21:job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]) Done 
> executing 
> org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupIngressCmd
>  for job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]
> 2013-12-27 12:14:37,471 WARN  [xen.resource.CitrixResourceBase] 
> (DirectAgent-204:null) callHostPlugin failed for cmd: network_rules with args 
> seqno: 8, vmIP: 10.223.51.30, deflated: true, secIps: 0:, vmID: 5, vmMAC: 
> 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: 
> eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: 
> 8683b82a9b77d8ece0dd135304fbdb8a,  due to There was a failure communicating 
> with the plugin.
> 2013-12-27 12:14:37,472 WARN  [agent.manager.DirectAgentAttache] 
> (DirectAgent-204:null) Seq 1-1198391355: Exception Caught while executing 
> command
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: network_rules with args seqno: 8, vmIP: 10.223.51.30, deflated: true, 
> secIps: 0:, vmID: 5, vmMAC: 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: 
> eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: 
> 8683b82a9b77d8ece0dd135304fbdb8a,  due to There was a failure communicating 
> with the plugin.
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4181)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5775)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:565)
> at 
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at 
> java.util.concurrent

[jira] [Reopened] (CLOUDSTACK-5664) XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation VMs deployed before patch installation does not acquire new rules set

[Anthony Xu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Xu reopened CLOUDSTACK-5664:


> XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation 
> VMs deployed before patch installation does not acquire new rules set 
> ---
>
> Key: CLOUDSTACK-5664
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5664
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
>Reporter: angeline shen
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: 513SMlog, 513xensource.log, 513xenstored-access.log, 
> 513xenstored-access.log.1, 513xenstored-access.log.2, 
> 513xenstored-access.log.3, 514SMlog, 514xensource.log, 
> 514xenstored-access.log, management-server.log.gz
>
>
>  XEN hotfix installation procedure
> 1. Hosts  master  slave installed with
> XS 6.0.2 base + Hotfix  XS602E001 to XS602E029 + CSPs
> 2. Basic zone with cluster of above master & slave hosts
> security group default  with NO security rules
> Deploy two VMs
> 3. MS: master host put to maintenance mode - VMs migrate to slave host
> 4. MS: unmanage cluster
> 5. master host:  install hotfix  XS602E030 + CSP , reboot master
> 6. MS: master host cancel maintenance mode
> 7. MS: manage cluster
> 8. MS: slave host put to maintenance mode - VMs migrate to master host
> 9. MS: Add security rules:  ingress TCP   1 - 80900.0.0.0/0
>  ingress ICMP   -1  -10.0.0.0/0
>  egress TCP1 - 80900.0.0.0/0
>  egress ICMP   -1  -10.0.0.0/0
> 10. MS: slave host cancel maintenance mode
> 11. stop/start SSVMVR
> 12. Deploy two more VMs
> Test result:
> VMs deployed after HotFix XS602E030 installation correctly acquired 4 new 
> ingress + egress rules
> VMs deployed before  HotFix XS602E030 installation did not acquire 4 new 
> ingress & egress rules - error
> Also there are errors encountered when attempt to apply these rules to old 
> VMs:
> 2013-12-27 12:14:37,294 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-21:job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]) Done 
> executing 
> org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupIngressCmd
>  for job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]
> 2013-12-27 12:14:37,471 WARN  [xen.resource.CitrixResourceBase] 
> (DirectAgent-204:null) callHostPlugin failed for cmd: network_rules with args 
> seqno: 8, vmIP: 10.223.51.30, deflated: true, secIps: 0:, vmID: 5, vmMAC: 
> 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: 
> eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: 
> 8683b82a9b77d8ece0dd135304fbdb8a,  due to There was a failure communicating 
> with the plugin.
> 2013-12-27 12:14:37,472 WARN  [agent.manager.DirectAgentAttache] 
> (DirectAgent-204:null) Seq 1-1198391355: Exception Caught while executing 
> command
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for 
> cmd: network_rules with args seqno: 8, vmIP: 10.223.51.30, deflated: true, 
> secIps: 0:, vmID: 5, vmMAC: 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: 
> eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: 
> 8683b82a9b77d8ece0dd135304fbdb8a,  due to There was a failure communicating 
> with the plugin.
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4181)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5775)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:565)
> at 
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-27 12:14:37,473 DEBUG [agen

[jira] [Updated] (CLOUDSTACK-7513) listServiceOfferings API when called with VM's id also returns offerings to which it cant be upgraded

[Nitin Mehta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nitin Mehta updated CLOUDSTACK-7513:

Description: 
When making the listServiceOfferings api call such as follows:
http://localhost:8080/client/api?command=listServiceOfferings&VirtualMachineId=41813941-c7de-4fd3-bd0e-1977bc395f22&response=json&sessionkey=kRxUwlrhNDg6CBX408XeHc40mDg%3D&_=1401878291930

Since the VM id is passed, only compatible offerings for this particular VMs 
should be listed. 
Trying to change the compute offering to 'Tiny Instance' results into error 
shown in attached screenshot.

EXPECTED BEHAVIOR:
If a certain compute offering is lesser in configuration that VM's current 
compute offering and the VM is in running state it should not be listed in the 
listServiceOfferings API response when called with VM id in the first place.

  was:
When making the listServiceOfferings api call such as follows:
http://localhost:8080/client/api?command=listServiceOfferings&VirtualMachineId=41813941-c7de-4fd3-bd0e-1977bc395f22&response=json&sessionkey=kRxUwlrhNDg6CBX408XeHc40mDg%3D&_=1401878291930
Since the VM id is passed, only compatible offerings for this particular VMs 
should be listed. Please find the response in the attachment.
Trying to change the compute offering to 'Tiny Instance' results into error 
shown in attached screenshot.
EXPECTED BEHAVIOR:
If a certain compute offering is lesser in configuration that VM's current 
compute offering and the VM is in running state it should not be listed in the 
listServiceOfferings API response when called with VM id in the first place.


> listServiceOfferings API when called with VM's id also returns offerings to 
> which it cant be upgraded
> -
>
> Key: CLOUDSTACK-7513
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7513
> 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: Nitin Mehta
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.5.0
>
>
> When making the listServiceOfferings api call such as follows:
> http://localhost:8080/client/api?command=listServiceOfferings&VirtualMachineId=41813941-c7de-4fd3-bd0e-1977bc395f22&response=json&sessionkey=kRxUwlrhNDg6CBX408XeHc40mDg%3D&_=1401878291930
> Since the VM id is passed, only compatible offerings for this particular VMs 
> should be listed. 
> Trying to change the compute offering to 'Tiny Instance' results into error 
> shown in attached screenshot.
> EXPECTED BEHAVIOR:
> If a certain compute offering is lesser in configuration that VM's current 
> compute offering and the VM is in running state it should not be listed in 
> the listServiceOfferings API response when called with VM id in the first 
> place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7513) listServiceOfferings API when called with VM's id also returns offerings to which it cant be upgraded

[Nitin Mehta (JIRA)]

Nitin Mehta created CLOUDSTACK-7513:
---

 Summary: listServiceOfferings API when called with VM's id also 
returns offerings to which it cant be upgraded
 Key: CLOUDSTACK-7513
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7513
 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: Nitin Mehta
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


When making the listServiceOfferings api call such as follows:
http://localhost:8080/client/api?command=listServiceOfferings&VirtualMachineId=41813941-c7de-4fd3-bd0e-1977bc395f22&response=json&sessionkey=kRxUwlrhNDg6CBX408XeHc40mDg%3D&_=1401878291930
Since the VM id is passed, only compatible offerings for this particular VMs 
should be listed. Please find the response in the attachment.
Trying to change the compute offering to 'Tiny Instance' results into error 
shown in attached screenshot.
EXPECTED BEHAVIOR:
If a certain compute offering is lesser in configuration that VM's current 
compute offering and the VM is in running state it should not be listed in the 
listServiceOfferings API response when called with VM id in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Alex Brett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Brett resolved CLOUDSTACK-7467.

Resolution: Fixed

Indeed it should, resolving as fixed

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing

[Animesh Chaturvedi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126100#comment-14126100
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-7467:


Should this be resolved now?

> TestVolumes.test_07_resize_fail failing
> ---
>
> Key: CLOUDSTACK-7467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.5.0
>Reporter: Alex Brett
>Assignee: Mike Tutkowski
> Fix For: 4.5.0
>
> Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 
> (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
>  has caused the BVT test 
> integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start 
> failing with:
> {noformat}
> ==
> ERROR: Test resize (negative) non-existent volume
> --
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, 
> in test_07_resize_fail
> self.apiClient.resizeVolume(cmd)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1716, in resizeVolume
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created : 
> u'2014-09-02T12:19:32+', cmd : 
> u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
> userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : 
> u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : 
> u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's 
> size without providing a new disk offering, its current disk offering must be 
> customizable or it must be a root volume."}, accountid : 
> u'71a306cc-3296-11e4-b130-0a474b082b17'}
>  >> begin captured stdout << -
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its 
> command, so the error text doesn't appear to make sense, but I'm not hugely 
> familiar with this area so it is possible the test has always been doing 
> something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this 
> ticket - assigning initially to Mike Tutkowski as the author of the above 
> commit...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7377) [RHEL7] D option is installing mariadb which is incompatible with CS

[Animesh Chaturvedi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7377:
---
Assignee: shweta agarwal  (was: Rayees Namathponnan)

> [RHEL7]  D option is installing mariadb which is incompatible with CS
> -
>
> Key: CLOUDSTACK-7377
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7377
> 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: shweta agarwal
>Assignee: shweta agarwal
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Untar 8.rhel7.tar.gz
> Use D option to install Database server
> use M option to install MS
> Start MS
> Bug:
> MS start will fail as D option has installed mariadb which is incompatible 
> with MS 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7377) [RHEL7] D option is installing mariadb which is incompatible with CS

[Animesh Chaturvedi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi resolved CLOUDSTACK-7377.

Resolution: Invalid

This does not affect CLOUDSTACK as we use rpm not install script

> [RHEL7]  D option is installing mariadb which is incompatible with CS
> -
>
> Key: CLOUDSTACK-7377
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7377
> 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: shweta agarwal
>Assignee: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Untar 8.rhel7.tar.gz
> Use D option to install Database server
> use M option to install MS
> Start MS
> Bug:
> MS start will fail as D option has installed mariadb which is incompatible 
> with MS 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot

[Chandan Purushothama (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama reopened CLOUDSTACK-7496:
--

I see the bug again on the Automation setup.

> [Automation][HyperV] Unable to ssh into the System VMs after Reboot
> ---
>
> Key: CLOUDSTACK-7496
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496
> 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: Critical
> Fix For: 4.5.0
>
> Attachments: runinfo.zip
>
>
> I attached the Automation client log information to this bug report. It shows 
> that the System VMs could not be accessed via ssh after reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6694) [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic primary and secondary IPS.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125935#comment-14125935
 ] 

ASF subversion and git services commented on CLOUDSTACK-6694:
-

Commit d80f6a8d4ad871ecd73bcd64d13bdfa905099419 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d80f6a8 ]

CLOUDSTACK-6694: update related comment after Refactor 'assign vm' action into 
function


> [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic 
> primary and secondary IPS.
> ---
>
> Key: CLOUDSTACK-6694
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6694
> 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: manasaveloori
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: InternalLB.jpg
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 48h
>
> 1. Create VPC.
> 2. Create a tier network using the network offering having internal LB 
> support.
> 3. Deploy VMs under this network.Acquire secondary Ips.
> 4.Goto VPC ->configure->tier-> internal LB.configure internal LB.
> 5. Assign VM to LB rule.
> Observation:
> There is no listing of primary and secondary IPs   for the VM while assigning 
> it  internal LB rule.
> attaching the screen shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7034) [Automation] - Automate ACL test cases relating to listVirtualMachines()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125874#comment-14125874
 ] 

ASF subversion and git services commented on CLOUDSTACK-7034:
-

Commit 5049dd0bf00520a96b31c1ce0f07c3c21c5aee2b in cloudstack's branch 
refs/heads/master from [~sangeethah]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5049dd0 ]

CLOUDSTACK-7034 - [Automation] - Automate ACL test cases relating to 
listVirtualMachines()


> [Automation] - Automate ACL test cases relating to listVirtualMachines()
> 
>
> Key: CLOUDSTACK-7034
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7034
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.4.0
>Reporter: Sangeetha Hariharan
>
> [Automation] - Automate ACL test cases relating to listVirtualMachines()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-6694) [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic primary and secondary IPS.

[Brian Federle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Federle resolved CLOUDSTACK-6694.
---
Resolution: Fixed

> [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic 
> primary and secondary IPS.
> ---
>
> Key: CLOUDSTACK-6694
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6694
> 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: manasaveloori
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: InternalLB.jpg
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 48h
>
> 1. Create VPC.
> 2. Create a tier network using the network offering having internal LB 
> support.
> 3. Deploy VMs under this network.Acquire secondary Ips.
> 4.Goto VPC ->configure->tier-> internal LB.configure internal LB.
> 5. Assign VM to LB rule.
> Observation:
> There is no listing of primary and secondary IPs   for the VM while assigning 
> it  internal LB rule.
> attaching the screen shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6694) [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic primary and secondary IPS.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125807#comment-14125807
 ] 

ASF subversion and git services commented on CLOUDSTACK-6694:
-

Commit e1354878c0c83d9c20c986796c7e9f3e3ba0e00e in cloudstack's branch 
refs/heads/master from [~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e135487 ]

CLOUDSTACK-6694: Refactor 'assign vm' action into function

Makes 'assign vm' action a function, to fix issue where quickview did
not have updated code.


> [UI]while assigning VM to internal LB(VPC),ListVMs is not listing VM nic 
> primary and secondary IPS.
> ---
>
> Key: CLOUDSTACK-6694
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6694
> 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: manasaveloori
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: InternalLB.jpg
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 48h
>
> 1. Create VPC.
> 2. Create a tier network using the network offering having internal LB 
> support.
> 3. Deploy VMs under this network.Acquire secondary Ips.
> 4.Goto VPC ->configure->tier-> internal LB.configure internal LB.
> 5. Assign VM to LB rule.
> Observation:
> There is no listing of primary and secondary IPs   for the VM while assigning 
> it  internal LB rule.
> attaching the screen shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7512) Failing to destroy eth0/bond0 on xenserver hv

[Justyn Shull (JIRA)]

Justyn Shull created CLOUDSTACK-7512:


 Summary: Failing to destroy eth0/bond0 on xenserver hv
 Key: CLOUDSTACK-7512
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7512
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
 Environment: XenServer release 6.1.0-59235p (xenenterprise)

Management server: CentOS release 6.4 (Final)
Cloudstack rpms:
cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
cloudstack-cli-4.4.0-NONOSS_3.el6.x86_64
cloudstack-usage-4.4.0-NONOSS_3.el6.x86_64
cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64
Reporter: Justyn Shull


We are seeing several log messages like "failed to destory VLAN eth0" similar 
to this one:

{quote}
# grep 'ctx-d0cb1a4e' /var/log/cloudstack/management/management-server.log
2014-09-08 00:16:24,492 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: Executing request
2014-09-08 00:16:24,581 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-423:ctx-d0cb1a4e) 9. The VM i-1847-6367-VM is in Stopping state
2014-09-08 00:16:38,328 INFO  [c.c.h.x.r.XenServer56Resource] 
(DirectAgent-423:ctx-d0cb1a4e) Catch com.xensource.xenapi.Types$InternalError: 
failed to destory VLAN eth0 on host 9fcb2c68-6483-4ef9-8842-0b87151346d0 due to 
The server failed to handle your request, due to an internal error.  The given 
message may give details useful for debugging the problem.
2014-09-08 00:16:39,308 INFO  [c.c.h.x.r.XenServer56Resource] 
(DirectAgent-423:ctx-d0cb1a4e) Catch com.xensource.xenapi.Types$InternalError: 
failed to destory VLAN eth0 on host 9fcb2c68-6483-4ef9-8842-0b87151346d0 due to 
The server failed to handle your request, due to an internal error.  The given 
message may give details useful for debugging the problem.
2014-09-08 00:16:39,308 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-423:ctx-d0cb1a4e) 10. The VM i-1847-6367-VM is in Stopped state
2014-09-08 00:16:39,308 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: Response Received:
2014-09-08 00:16:39,309 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
(DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: MgmtId 
33862771676063: Resp: Routing to peer
2014-09-08 00:16:39,309 DEBUG [c.c.a.m.AgentAttache] 
(DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: No more commands 
found
{quote}

On the hypervisor in question, eth0 is used with vlans.   xenbr0 has eth0 in 
it, but any other bridges shown by "brctl show" only have eth0.X for whichever 
vlan it is using.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6484) Unable to expunge VM

[MONTELEONE (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125696#comment-14125696
 ] 

MONTELEONE commented on CLOUDSTACK-6484:


The same problem exist in Cloudstack 4.4.0, XenServer 6.2 SP1, Primary Storage 
SCSI, Secondary Storage NFS.
Is there a way to clear this situation ?

> Unable to expunge VM
> 
>
> Key: CLOUDSTACK-6484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6484
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, XenServer
>Affects Versions: 4.3.0
> Environment: ACS 4.3, XenServer 6.2 SP1, NFS primary and secondary 
> storage
>Reporter: Erik Weber
>Priority: Minor
>
> VM creation failed, and is now unable to expunge the stale vm.
> Log excerpt:
> 2014-04-23 12:37:38,632 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-17:ctx-63a3ec65) ===START===  172.30.86.24 -- GET  
> command=expungeVirtualMachine&id=05c7735f-43ab-4e75-b211-3791bceb77f9&response=json&sessionkey=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256658590
> 2014-04-23 12:37:38,664 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-17:ctx-63a3ec65 ctx-fc4c0a3b) submit async job-827, details: 
> AsyncJobVO {id:827, userId: 2, accountId: 2, instanceType: VirtualMachine, 
> instanceId: 80, cmd: org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd, 
> cmdInfo: 
> {"id":"05c7735f-43ab-4e75-b211-3791bceb77f9","response":"json","sessionkey":"OMJLVfWJLawkctDOi728+2sfpzI\u003d","cmdEventType":"VM.EXPUNGE","ctxUserId":"2","httpmethod":"GET","_":"1398256658590","ctxAccountId":"2","ctxStartEventId":"3505"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345049426471, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-04-23 12:37:38,667 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-6:job-827) Add job-827 into job monitoring
> 2014-04-23 12:37:38,667 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-6:job-827) Executing AsyncJobVO {id:827, userId: 2, 
> accountId: 2, instanceType: VirtualMachine, instanceId: 80, cmd: 
> org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd, cmdInfo: 
> {"id":"05c7735f-43ab-4e75-b211-3791bceb77f9","response":"json","sessionkey":"OMJLVfWJLawkctDOi728+2sfpzI\u003d","cmdEventType":"VM.EXPUNGE","ctxUserId":"2","httpmethod":"GET","_":"1398256658590","ctxAccountId":"2","ctxStartEventId":"3505"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345049426471, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-04-23 12:37:38,668 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-17:ctx-63a3ec65 ctx-fc4c0a3b) ===END===  172.30.86.24 -- GET  
> command=expungeVirtualMachine&id=05c7735f-43ab-4e75-b211-3791bceb77f9&response=json&sessionkey=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256658590
> 2014-04-23 12:37:38,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Sync job-828 execution on object 
> VmWorkJobQueue.80
> 2014-04-23 12:37:38,724 WARN  [c.c.u.d.Merovingian2] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Was unable to find lock for the key 
> vm_instance80 and thread id 2057517175
> 2014-04-23 12:37:41,720 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-309c7bb0) ===START===  172.30.86.24 -- GET  
> command=queryAsyncJobResult&jobId=849b6fb8-c20f-4362-8fc4-6877f36df874&response=json&sessionkey=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256661662
> 2014-04-23 12:37:41,753 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-19:ctx-309c7bb0 ctx-51354ef7) ===END===  172.30.86.24 -- GET  
> command=queryAsyncJobResult&jobId=849b6fb8-c20f-4362-8fc4-6877f36df874&response=json&sessionkey=OMJLVfWJLawkctDOi728%2B2sfpzI%3D&_=1398256661662
> 2014-04-23 12:37:41,821 DEBUG [c.c.c.CapacityManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) VM state transitted from :Expunging 
> to Expunging with event: ExpungeOperationvm's original host id: null new host 
> id: null host id before state transition: null
> 2014-04-23 12:37:41,823 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Destroying vm VM[User|i-9-80-VM]
> 2014-04-23 12:37:41,824 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (API-Job-Executor-6:job-827 ctx-602236ef) Cleaning up NICS
> 2014-04-23 12:37:41,832 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-6:job-827) Unexpected exception while executing 
> org.apache.cloudstack.api.command.admin.vm.ExpungeVMCmd
> java.lang.NullPointerException
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:489)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(Virtu

[jira] [Comment Edited] (CLOUDSTACK-7511) CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates

[Laurent Steff (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125643#comment-14125643
 ] 

Laurent Steff edited comment on CLOUDSTACK-7511 at 9/8/14 2:59 PM:
---

Parsing the code, also for version 4.4.0, for me the problem is a test when 
registering a new ISO/template.

Example given, if I change, manually, the bits column in the vm_template table, 
the virtual machine created
has the correct libvirt option :

---
 CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates
> --
>
> Key: CLOUDSTACK-7511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.0.0, 4.2.0
> Environment: Centos 6.3 KVM
>Reporter: Laurent Steff
>
> When using templates registered as 32bits, virtualized CPU is set to x86_64 
> on the virtual machine. It should be i686.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7511) CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates

[Laurent Steff (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125643#comment-14125643
 ] 

Laurent Steff commented on CLOUDSTACK-7511:
---

Parsing the code, althoug for version 4.4.0, for me the problem is a test when 
registering a new ISO/template.

Example given, if I change, manually, the bits column in the vm_template table, 
the virtual machine created
as the correct libvirt option :

---
 CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates
> --
>
> Key: CLOUDSTACK-7511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.0.0, 4.2.0
> Environment: Centos 6.3 KVM
>Reporter: Laurent Steff
>
> When using templates registered as 32bits, virtualized CPU is set to x86_64 
> on the virtual machine. It should be i686.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7511) CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates

[Laurent Steff (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125643#comment-14125643
 ] 

Laurent Steff edited comment on CLOUDSTACK-7511 at 9/8/14 2:57 PM:
---

Parsing the code, althoug for version 4.4.0, for me the problem is a test when 
registering a new ISO/template.

Example given, if I change, manually, the bits column in the vm_template table, 
the virtual machine created
has the correct libvirt option :

---
 CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates
> --
>
> Key: CLOUDSTACK-7511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.0.0, 4.2.0
> Environment: Centos 6.3 KVM
>Reporter: Laurent Steff
>
> When using templates registered as 32bits, virtualized CPU is set to x86_64 
> on the virtual machine. It should be i686.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7511) CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates

[Laurent Steff (JIRA)]

Laurent Steff created CLOUDSTACK-7511:
-

 Summary: CLONE - Cloudstack should virtualized 32bits CPUs for 
32bits templates
 Key: CLOUDSTACK-7511
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7511
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.0.0
 Environment: Centos 6.3 KVM
Reporter: Laurent Steff


When using templates registered as 32bits, virtualized CPU is set to x86_64 on 
the virtual machine. It should be i686.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7511) CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates

[Laurent Steff (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laurent Steff updated CLOUDSTACK-7511:
--
Affects Version/s: 4.2.0

> CLONE - Cloudstack should virtualized 32bits CPUs for 32bits templates
> --
>
> Key: CLOUDSTACK-7511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.0.0, 4.2.0
> Environment: Centos 6.3 KVM
>Reporter: Laurent Steff
>
> When using templates registered as 32bits, virtualized CPU is set to x86_64 
> on the virtual machine. It should be i686.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7347) Unable to access VM trough ConsoleProxy

[Rayees Namathponnan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan closed CLOUDSTACK-7347.
---
Resolution: Cannot Reproduce

Not found this issue new runs 

> Unable to access VM trough ConsoleProxy
> ---
>
> Key: CLOUDSTACK-7347
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7347
> 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: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: cloud.out
>
>
> Steps to reproduce 
> 1) Deploy advanced zone in KVM 
> 2) Deploy VM
> 3) Access the vm trough console proxy 
> Result 
> Unable to access the VM trough console proxy, observed below error in Console 
> proxy cloud.log
> 2014-08-14 15:40:38,525 ERROR [resource.consoleproxy.ConsoleProxyResource] 
> (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
> post agent control request as link is not available
> com.cloud.exception.AgentControlChannelException: Unable to post agent 
> control request as link is not available
>   at com.cloud.agent.Agent.postRequest(Agent.java:690)
>   at com.cloud.agent.Agent.postRequest(Agent.java:678)
>   at 
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
>   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
>   at 
> com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
> 2014-08-14 15:40:38,525 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
> (Console Proxy GC Thread:null) Report load change : {
>   "connections": []
> }
> 2014-08-14 15:40:41,110 ERROR [utils.nio.NioConnection] (Agent-Selector:null) 
> Unable to initialize the threads.
> java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection 
> closed with -1 on reading size.
>   at com.cloud.utils.nio.NioClient.init(NioClient.java:87)
>   at com.cloud.utils.nio.NioConnection.run(NioConnection.java:111)
>   at java.lang.Thread.run(Thread.java:744)
> 2014-08-14 15:40:43,526 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
> (Console Proxy GC Thread:null) connMap={}
> 2014-08-14 15:40:43,526 INFO  [utils.exception.CSExceptionErrorCode] (Console 
> Proxy GC Thread:null) Could not find exception: 
> com.cloud.exception.AgentControlChannelException in error code list for 
> exceptions
> 2014-08-14 15:40:43,526 ERROR [resource.consoleproxy.ConsoleProxyResource] 
> (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
> post agent control request as link is not available
> com.cloud.exception.AgentControlChannelException: Unable to post agent 
> control request as link is not available
>   at com.cloud.agent.Agent.postRequest(Agent.java:690)
>   at com.cloud.agent.Agent.postRequest(Agent.java:678)
>   at 
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
>   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
>   at 
> com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
> 2014-08-14 15:40:43,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
> (Console Proxy GC Thread:null) Report load change : {
>   "connections": []
> }
> 2014-08-14 15:40:46,110 INFO  [cloud.agent.Agent] (Agent-Handler-1:null) 
> Reconnecting...
> 2014-08-14 15:40:46,111 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
> Connecting to 10.223.49.195:8250
> 2014-08-14 15:40:48,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
> (Console Proxy GC Thread:null) connMap={}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CLOUDSTACK-7491) [Automtation] Test case test_02_deploy_ha_vm_from_iso failed, hypervisor parameter password

[Rayees Namathponnan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan reopened CLOUDSTACK-7491:
-

if its a script issue, then we should fix this in test

> [Automtation] Test case test_02_deploy_ha_vm_from_iso  failed, hypervisor 
> parameter password 
> -
>
> Key: CLOUDSTACK-7491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7491
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM
>Reporter: Rayees Namathponnan
>Assignee: sadhu suresh
> Fix For: 4.5.0
>
>
> Test cases failed with below error 
> Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
> errorText:hypervisor parameter is needed to deploy VM or the hypervisor 
> parameter value passed is invalid
>  >> begin captured stdout << -
> === TestName: test_02_deploy_ha_vm_from_iso | Status : EXCEPTION ===
> - >> end captured stdout << --
>  >> begin captured logging << 



--
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

[Daan Hoogland (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125515#comment-14125515
 ] 

Daan Hoogland commented on CLOUDSTACK-7184:
---

John, is KVM using the same xenheartbeat.sh? it would seem not. Remy and I have 
found that it is actually a wrong number of parameters passed into this script 
which is the problem.

cloudstack calls xenheartbeat.sh  

xenheartbeat.sh parses   and then finds no 

I will go and write a thingy around this.

> 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
>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

[Joris van Lieshout (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125514#comment-14125514
 ] 

Joris van Lieshout commented on CLOUDSTACK-7184:


Hi, I am currently out of office and will be back Tuesday the 23rd of 
September. During this time I will have limited access to e-mail and might not 
be able to take your call. For urgent matter regarding ASR please contact 
int-...@schubergphilis.com instead. For Cloud IaaS matters please contact 
int-cl...@schubergphilis.com.

Kind regards,
Joris van Lieshout


Schuberg Philis
schubergphilis.com

+31207506672
+31651428188


> 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
>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] [Issue Comment Deleted] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[Daan Hoogland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland updated CLOUDSTACK-7184:
--
Comment: was deleted

(was: Hi, I am currently out of office and will be back Wednesday the 27th of 
August. During this time I will have limited access to e-mail and might not be 
able to take your call. For urgent matter regarding ASR please contact 
int-...@schubergphilis.com instead. For other urgent matter please contact one 
of my colleagues.

Kind regards,
Joris van Lieshout


Schuberg Philis
schubergphilis.com

+31207506672
+31651428188
)

> 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
>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-7510) Add "usageid" parameter to the "listUsageRecords" API call

[Ilia Shakitko (JIRA)]

Ilia Shakitko created CLOUDSTACK-7510:
-

 Summary: 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] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-7291:
--
Fix Version/s: (was: 4.5.0)

> LXC: Mgmt server/agent keeps killing systemvms
> --
>
> Key: CLOUDSTACK-7291
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.5.0, 4.3.1
>Reporter: Rohit Yadav
> Fix For: 4.3.1
>
>
> Followed installation and setup docs of 4.3, was unable to get LXC to work on 
> Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
> ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
> mgmt server complained that it was unable to contact agent on the systemvm 
> (ping), while the agent would gracefully shutdown the systemvm (by killing 
> them).
> Relevant log:
> 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
> (secstorage-1:ctx-fc57ef43) Could not find exception: 
> com.cloud.exception.OperationTimedoutException in error code list for 
> exceptions
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
> (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
> Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
> id = 1, name = bluebox1.bhaisaab.org]
> 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Scheduled 
> HAWork[12-CheckStop-2-Starting-Scheduled]
> 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
> vm
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
> unreachable: Host 1: Unable to start s-2-VM
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
> >---at 
> >com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
> ...
> ...
> ...
> Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
> to Host 1 timed out after 3600
> >---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
> > 
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
> >---... 24 more   
> > 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala resolved CLOUDSTACK-7504.
---
Resolution: Fixed

> [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-7291) LXC: Mgmt server/agent keeps killing systemvms

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-7291:
--
Assignee: (was: Kishan Kavala)

> LXC: Mgmt server/agent keeps killing systemvms
> --
>
> Key: CLOUDSTACK-7291
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0, 4.5.0, 4.3.1
>Reporter: Rohit Yadav
> Fix For: 4.3.1
>
>
> Followed installation and setup docs of 4.3, was unable to get LXC to work on 
> Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
> ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
> mgmt server complained that it was unable to contact agent on the systemvm 
> (ping), while the agent would gracefully shutdown the systemvm (by killing 
> them).
> Relevant log:
> 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
> (secstorage-1:ctx-fc57ef43) Could not find exception: 
> com.cloud.exception.OperationTimedoutException in error code list for 
> exceptions
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
> (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
> 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
> Host[-1-Routing]
> 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
> Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
> id = 1, name = bluebox1.bhaisaab.org]
> 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Scheduled 
> HAWork[12-CheckStop-2-Starting-Scheduled]
> 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
> vm
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
> unreachable: Host 1: Unable to start s-2-VM
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
> >---at 
> >com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
> >---at 
> >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
> >---at 
> >com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
> ...
> ...
> ...
> Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
> to Host 1 timed out after 3600
> >---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
> > 
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
> >---at 
> >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
> >---... 24 more   
> > 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala resolved CLOUDSTACK-7507.
---
Resolution: Fixed

> [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] [Commented] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125463#comment-14125463
 ] 

ASF subversion and git services commented on CLOUDSTACK-7504:
-

Commit c773754fdacb4f3ce47e08d6d2f4e62d5db780f3 in cloudstack's branch 
refs/heads/master from [~kishan]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c773754 ]

CLOUDSTACK-7504,CLOUDSTACK-7507: For LXC host maintenance, migrate system Vms 
and schedule restart of users Vms


> [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] [Commented] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125464#comment-14125464
 ] 

ASF subversion and git services commented on CLOUDSTACK-7507:
-

Commit c773754fdacb4f3ce47e08d6d2f4e62d5db780f3 in cloudstack's branch 
refs/heads/master from [~kishan]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c773754 ]

CLOUDSTACK-7504,CLOUDSTACK-7507: For LXC host maintenance, migrate system Vms 
and schedule restart of users Vms


> [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] [Updated] (CLOUDSTACK-7497) [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-7497:
--
Assignee: (was: Kishan Kavala)

> [LXC][UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> 
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7497) [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[Kishan Kavala (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125461#comment-14125461
 ] 

Kishan Kavala commented on CLOUDSTACK-7497:
---

This is not specific to LXC.
UI issue in mixed hypervisor setup.

> [LXC][UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> 
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[Kishan Kavala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-7497:
--
Summary: [UI] deploy VM  failing as hypervisor type passed is KVM instead 
of LXC  (was: [LXC][UI] deploy VM  failing as hypervisor type passed is KVM 
instead of LXC)

> [UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> ---
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7509) test_ss_limits.TestSecondaryStorageLimits.test_04_copy_template_1_root_domain_admin failed due to missing bound method

[Gaurav Aradhye (JIRA)]

Gaurav Aradhye created CLOUDSTACK-7509:
--

 Summary: 
test_ss_limits.TestSecondaryStorageLimits.test_04_copy_template_1_root_domain_admin
 failed due to missing bound method
 Key: CLOUDSTACK-7509
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7509
 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
 Fix For: 4.5.0


Bound method for copyTemplate is missing in library, hence test cases failed 
during copy operation.


test_04_copy_template_1_root_domain_admin 
(integration.component.test_ss_limits.TestSecondaryStorageLimits): CRITICAL: 
EXCEPTION: test_04_copy_template_1_root_domain_admin: ['Traceback (most recent 
call last):\n', '  File "/usr/local/lib/python2.7/unittest/case.py", line 318, 
in run\ntestMethod()\n', '  File 
"/usr/local/lib/python2.7/site-packages/ddt.py", line 114, in wrapper\n
return func(self, *args, **kwargs)\n', '  File 
"/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_limits.py", line 
369, in test_04_copy_template\nsourcezoneid = template.zoneid)\n', 
'TypeError: copy() takes exactly 5 arguments (4 given)\n']
- >> end captured logging << -

Stacktrace

  File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
testMethod()
  File "/usr/local/lib/python2.7/site-packages/ddt.py", line 114, in wrapper
return func(self, *args, **kwargs)
  File 
"/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_limits.py", line 
369, in test_04_copy_template
sourcezoneid = template.zoneid)
'copy() takes exactly 5 arguments (4 given)\n >> begin 
captured stdout << -\n=== TestName: 
test_04_copy_template_1_root_domain_admin | Status : EXCEPTION 
===\n\n\n- >> end captured stdout << 
--\n >> begin captured logging << 
\ntest_04_copy_template_1_root_domain_admin 
(integration.component.test_ss_limits.TestSecondaryStorageLimits): DEBUG: 
STARTED : TC: test_04_copy_template_1_root_domain_admin 
:::\ntest_04_copy_template_1_root_domain_admin 
(integration.component.test_ss_limits.TestSecondaryStorageLimits): DEBUG: 
Payload: {\'apiKey\': 
u\'OK1UH4l8UUYHDWdnVSWETzepdzs07VAwZBCYZwS4W2zHupX3PAISs1Ug7oMKUBO17rHHkOr3ZAKFVf2fsKYIvQ\',
 \'command\': \'listZones\', \'signature\': \'H8DhzBD18g1bf1QQ1r7w5RU+eRU=\', 
\'response\': \'json\'}\ntest_04_copy_template_1_root_domain_admin 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7434) [Automation] Fix the script "test_custom_hostname.py" - Internal name comparision appears to be wrong

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125445#comment-14125445
 ] 

ASF subversion and git services commented on CLOUDSTACK-7434:
-

Commit 40a537fedcbb8c088875ef222c950213909df7f8 in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40a537f ]

CLOUDSTACK-7434: Fixed VM Internal name issue in test_custom_hostname.py

Signed-off-by: SrikanteswaraRao Talluri 


> [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"

[jira] [Closed] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

[Sanjeev N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N closed CLOUDSTACK-7508.
-

> [Automation] Duplicate entries in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> --
>
> Key: CLOUDSTACK-7508
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>  Labels: automation
>
> [Automation] Duplicate entried in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> test_data.py in marvin has two dictionaries with name 
> "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
> one with ispersistent set to False.
> Tests would fail if the test picks the one with ispersistent set to False. So 
> we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125441#comment-14125441
 ] 

ASF subversion and git services commented on CLOUDSTACK-7508:
-

Commit 535e7a667049e37d6a03c7a3e2e5c9645e6ce1f6 in cloudstack's branch 
refs/heads/master from sanjeev
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=535e7a6 ]

CLOUDSTACK-7508: Remove duplicate network offerings from test_data.py


> [Automation] Duplicate entries in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> --
>
> Key: CLOUDSTACK-7508
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>  Labels: automation
>
> [Automation] Duplicate entried in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> test_data.py in marvin has two dictionaries with name 
> "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
> one with ispersistent set to False.
> Tests would fail if the test picks the one with ispersistent set to False. So 
> we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

[Sanjeev N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N resolved CLOUDSTACK-7508.
---
Resolution: Fixed

commit 535e7a667049e37d6a03c7a3e2e5c9645e6ce1f6
Author: sanjeev 
Date:   Mon Sep 8 17:21:11 2014 +0530

CLOUDSTACK-7508: Remove duplicate network offerings from test_data.py


> [Automation] Duplicate entries in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> --
>
> Key: CLOUDSTACK-7508
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: Latest build from master
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>  Labels: automation
>
> [Automation] Duplicate entried in test_data.py for network offering 
> "nw_off_persistent_VPCVR_NoLB"
> test_data.py in marvin has two dictionaries with name 
> "nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
> one with ispersistent set to False.
> Tests would fail if the test picks the one with ispersistent set to False. So 
> we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7423) [Automation] Unable to start Virtual Machine due to - Unable to apply dhcp entry on router

[Murali Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125438#comment-14125438
 ] 

Murali Reddy commented on CLOUDSTACK-7423:
--

There was a communication problem connecting through SSH to VR (169.254.3.229) 
from the XenServer, as noticed in the logs. 
2014-08-24 09:23:03,502 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-381:ctx-cf49055b) Executing command in VR: 
/opt/cloud/bin/router_proxy.sh edithosts.sh 169.254.3.229  -m 02:00:37:9a:00:01 
-4 192.168.200.227 -h VM-f565ab8   2-6d89-416e-9d93-9b04cf2667d0 -d 
192.168.200.1 -n 192.168.200.1

2014-08-24 09:23:03,513 DEBUG [c.c.a.t.Request] (DirectAgent-381:ctx-cf49055b) 
Seq 2-3323656524999428602: Processing:  { Ans: , MgmtId: 33385016016501, via: 
2, Ver: v1, Flags: 10, [{"com.cloud.agent.api.Answer":{"result":false,"d   
etails":"There was a problem while connecting to 10.220.163.7:22","wait":0}}] }

This is interment issue. Root cause why it happened could only be figured if we 
look in the xenserver host where the VM is running.

On subsequent test runs and when i manually launch the vm or run the tests I am 
not seeing any issue.  Please re-open the bug if the test case is failing 
consistently. 

> [Automation] Unable to start Virtual Machine due to - Unable to apply dhcp 
> entry on router
> --
>
> Key: CLOUDSTACK-7423
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7423
> 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: Murali Reddy
>Priority: Critical
> Fix For: 4.5.0
>
>
> Unable to start after stopping a User VM as part of 
> *integration.component.test_cpu_project_limits.TestProjectsCPULimits.test_01_project_counts_start_stop_instance*
> 
> *Error Message*
> 
> Failed to start instance: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-24T09:23:02+', jobresult : {errorcode : 530, errortext : u'Job 
> failed due to exception Unable to create a deployment for 
> VM[User|i-218-404-VM]'}, cmd : 
> u'org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin', userid : 
> u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
> u'76b12bb1-52fc-45f4-933f-31399cefd624', jobresultcode : 530, jobinstanceid : 
> u'f565ab82-6d89-416e-9d93-9b04cf2667d0', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=cpu_project_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File 
> "/root/cloudstack/test/integration/component/test_cpu_project_limits.py", 
> line 263, in test_01_project_counts_start_stop_instance
> self.fail("Failed to start instance: %s" % e)
>   File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Failed to start instance: Job failed: {jobprocstatus : 0, created : 
> u\'2014-08-24T09:23:02+\', jobresult : {errorcode : 530, errortext : 
> u\'Job failed due to exception Unable to create a deployment for 
> VM[User|i-218-404-VM]\'}, cmd : 
> u\'org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin\', userid : 
> u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
> u\'76b12bb1-52fc-45f4-933f-31399cefd624\', jobresultcode : 530, jobinstanceid 
> : u\'f565ab82-6d89-416e-9d93-9b04cf2667d0\', jobresulttype : u\'object\', 
> jobinstancetype : u\'VirtualMachine\', accountid : 
> u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
> ===
> Error of Management Server Log:
> ===
> {code}
> 2014-08-24 09:23:03,513 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-21:ctx-e6e44390 job-2922/job-2923 ctx-2994f1d0) Unable to 
> contact resource.
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Unable to apply dhcp entry on router 
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4031)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3150)
>   at sun.reflect.GeneratedMethodAccessor447.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invo

[jira] [Resolved] (CLOUDSTACK-7423) [Automation] Unable to start Virtual Machine due to - Unable to apply dhcp entry on router

[Murali Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Murali Reddy resolved CLOUDSTACK-7423.
--
Resolution: Cannot Reproduce

> [Automation] Unable to start Virtual Machine due to - Unable to apply dhcp 
> entry on router
> --
>
> Key: CLOUDSTACK-7423
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7423
> 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: Murali Reddy
>Priority: Critical
> Fix For: 4.5.0
>
>
> Unable to start after stopping a User VM as part of 
> *integration.component.test_cpu_project_limits.TestProjectsCPULimits.test_01_project_counts_start_stop_instance*
> 
> *Error Message*
> 
> Failed to start instance: Job failed: {jobprocstatus : 0, created : 
> u'2014-08-24T09:23:02+', jobresult : {errorcode : 530, errortext : u'Job 
> failed due to exception Unable to create a deployment for 
> VM[User|i-218-404-VM]'}, cmd : 
> u'org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin', userid : 
> u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
> u'76b12bb1-52fc-45f4-933f-31399cefd624', jobresultcode : 530, jobinstanceid : 
> u'f565ab82-6d89-416e-9d93-9b04cf2667d0', jobresulttype : u'object', 
> jobinstancetype : u'VirtualMachine', accountid : 
> u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
> http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogs&id=804076&phase=Parallel&test=cpu_project_limits
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
>   File 
> "/root/cloudstack/test/integration/component/test_cpu_project_limits.py", 
> line 263, in test_01_project_counts_start_stop_instance
> self.fail("Failed to start instance: %s" % e)
>   File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Failed to start instance: Job failed: {jobprocstatus : 0, created : 
> u\'2014-08-24T09:23:02+\', jobresult : {errorcode : 530, errortext : 
> u\'Job failed due to exception Unable to create a deployment for 
> VM[User|i-218-404-VM]\'}, cmd : 
> u\'org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin\', userid : 
> u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
> u\'76b12bb1-52fc-45f4-933f-31399cefd624\', jobresultcode : 530, jobinstanceid 
> : u\'f565ab82-6d89-416e-9d93-9b04cf2667d0\', jobresulttype : u\'object\', 
> jobinstancetype : u\'VirtualMachine\', accountid : 
> u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
> ===
> Error of Management Server Log:
> ===
> {code}
> 2014-08-24 09:23:03,513 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-21:ctx-e6e44390 job-2922/job-2923 ctx-2994f1d0) Unable to 
> contact resource.
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
> unreachable: Unable to apply dhcp entry on router 
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4031)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3150)
>   at sun.reflect.GeneratedMethodAccessor447.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>   at $Proxy190.applyDhcpEntry(Unknown Source)
>   at 
> com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:924)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1251)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
>   at 
> org.apache.cloudstack.engi

[jira] [Created] (CLOUDSTACK-7508) [Automation] Duplicate entries in test_data.py for network offering "nw_off_persistent_VPCVR_NoLB"

[Sanjeev N (JIRA)]

Sanjeev N created CLOUDSTACK-7508:
-

 Summary: [Automation] Duplicate entries in test_data.py for 
network offering "nw_off_persistent_VPCVR_NoLB"
 Key: CLOUDSTACK-7508
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7508
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
 Environment: Latest build from master
Reporter: Sanjeev N
Assignee: Sanjeev N


[Automation] Duplicate entried in test_data.py for network offering 
"nw_off_persistent_VPCVR_NoLB"

test_data.py in marvin has two dictionaries with name 
"nw_off_persistent_VPCVR_NoLB" one with ispersistent set to True and another 
one with ispersistent set to False.

Tests would fail if the test picks the one with ispersistent set to False. So 
we should delete the one with ispersistent set to False.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7507:
--

 Summary: [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-7506) Secondary Storage LImits test cases are failing while registering template with error "Invalid Parameters - Hypervisor is required"

[Gaurav Aradhye (JIRA)]

Gaurav Aradhye created CLOUDSTACK-7506:
--

 Summary: Secondary Storage LImits test cases are failing while 
registering template with error "Invalid Parameters - Hypervisor is required"
 Key: CLOUDSTACK-7506
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7506
 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
 Fix For: 4.5.0


Base library function is reading hypervisor value only from function parameter 
and not from services dictionary. But the test cases are passing hypervisor 
value from dictionary.

Solution:
Read the hypervisor value from the services dict if it's not passed through the 
function parameter.

Details:
test_01_deploy_vm_domain_limit_reached 
(integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
DEBUG: CmdName: registerTemplate Parameter : hypervisor is Required
test_01_deploy_vm_domain_limit_reached 
(integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
ERROR: marvinRequest : CmdName: 
 
Exception: ['Traceback (most recent call last):\n', '  File 
"/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
353, in marvinRequest\nraise self.__lastError\n', 
'InvalidParameterException: Invalid Parameters\n']
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", 
line 353, in marvinRequest
raise self.__lastError
InvalidParameterException: Invalid Parameters
test_01_deploy_vm_domain_limit_reached 
(integration.component.test_ss_max_limits.TestMaxSecondaryStorageLimits): 
CRITICAL: FAILED: test_01_deploy_vm_domain_limit_reached: ['Traceback (most 
recent call last):\n', '  File "/usr/local/lib/python2.7/unittest/case.py", 
line 318, in run\ntestMethod()\n', '  File 
"/Repo_30X/ipcl/cloudstack/test/integration/component/test_ss_max_limits.py", 
line 183, in test_01_deploy_vm_domain_limit_reached\n
self.assertEqual(response[0], PASS, response[1])\n', '  File 
"/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual\n
assertion_func(first, second, msg=msg)\n', '  File 
"/usr/local/lib/python2.7/unittest/case.py", line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionError: Invalid Parameters\n']
- >> end captured logging << -



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined

[Sailaja Mada (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada closed CLOUDSTACK-7498.

Resolution: Cannot Reproduce

This is working now. 

> [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] [Resolved] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot

[Rajesh Battala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajesh Battala resolved CLOUDSTACK-7496.

Resolution: Cannot Reproduce

> [Automation][HyperV] Unable to ssh into the System VMs after Reboot
> ---
>
> Key: CLOUDSTACK-7496
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496
> 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: Critical
> Fix For: 4.5.0
>
> Attachments: runinfo.zip
>
>
> I attached the Automation client log information to this bug report. It shows 
> that the System VMs could not be accessed via ssh after reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot

[Rajesh Battala (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125370#comment-14125370
 ] 

Rajesh Battala commented on CLOUDSTACK-7496:


[~chandanp] Can you please check it manually by sshing to systemvm's. 
If sshing to systemvm's wont work then nothing can be deployed in Hyper-V.

I have checked sshing to systemvms before and after reboot. Its working fine.

Attaching the snippet 

root@rajesh-HVM-domU:/home/rajesh/hyperv/client/target/cloud-client-ui-4.5.0-SNAPSHOT/WEB-INF/classes/scripts/vm/systemvm#
 ssh root@10.102.246.15 -p3922 -i ~/.ssh/id_rsa.cloud
Linux s-2-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep  8 09:59:35 2014

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@s-2-VM:~#



> [Automation][HyperV] Unable to ssh into the System VMs after Reboot
> ---
>
> Key: CLOUDSTACK-7496
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496
> 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: Critical
> Fix For: 4.5.0
>
> Attachments: runinfo.zip
>
>
> I attached the Automation client log information to this bug report. It shows 
> that the System VMs could not be accessed via ssh after reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer

[Alex Brett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Brett resolved CLOUDSTACK-7310.

Resolution: Duplicate

Fixed in CLOUDSTACK-7228

> [Automation] XenServer does not support shrink data disk. CloudStack should 
> prevent such an operation on XenServer
> --
>
> Key: CLOUDSTACK-7310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Volumes, XenServer
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: John Dilley
>Priority: Critical
> Fix For: 4.5.0
>
>
> XenServer does not allowing shrinking of disks currently. Please add code on 
> Cloudstack to prevent such an operation (similar to VMWare case). Failing to 
> prevent such an operation on XenServer leads to 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7505) Windows 2012 and Windows 8 instances created with 6.5 PV tools installed template are getting into repair state, Later XenServer 6.5 Is shutting down these instances

[Sailaja Mada (JIRA)]

Sailaja Mada created CLOUDSTACK-7505:


 Summary: Windows 2012 and Windows 8 instances created with 6.5 PV 
tools installed template are getting into repair state, Later XenServer 6.5 Is 
shutting down these instances automatically 
 Key: CLOUDSTACK-7505
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7505
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.5.0
Reporter: Sailaja Mada
Priority: Blocker


Steps:

1. Configure Adv Zone using XenServer 6.5 
2.  Registered Windows 8 and Windows 2012 templates which has XS 6.5 PV tools 
installed.I have enabled option Original XS Version is 6.1+: Yes
3. Deployed VM using this template 
4. VM got started and moved to running state. But  got  into repair state, 
Later XenServer 6.5 Is shutting down these instances automatically.

VM Parameters are : 

  platform (MRW): timeoffset: 0; viridian: true; acpi: 1; ap
ic: true; pae: true; videoram: 8; device_id: 0002; nx: true; vga: std
allowed-operations (SRO): changing_dynamic_range; hard_reboot; hard_
shutdown; pause; snapshot






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7346) iSCSI primary storage test should be skipped on VMWare

[Alex Brett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Brett resolved CLOUDSTACK-7346.

Resolution: Fixed

Resolving as the fix went in in the commit in the comments

> iSCSI primary storage test should be skipped on VMWare
> --
>
> Key: CLOUDSTACK-7346
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7346
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: Future, 4.5.0
>Reporter: John Dilley
>Assignee: John Dilley
>Priority: Critical
> Fix For: 4.5.0
>
>
> As description - VMWare only supports VMFS which must be created in vCenter.
> We should create a smoke test for shared mount points (KVM), VMFS (VMWare) 
> and CIFS (Hyper-V) at some point, however given that no tests exist for the 
> other hypervisors yet, I'll postpone adding VMWare's primary storage test for 
> now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7504:
---
Attachment: Ms.tar.gz

> [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] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125354#comment-14125354
 ] 

ASF subversion and git services commented on CLOUDSTACK-6624:
-

Commit b7b9cd0d2d0dc9973e65c99ade3f550c6dd8dcd7 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=b7b9cd0 ]

CLOUDSTACK-6624: set specifyIpRanges to true if specifyVlan is set to true

Signed-off-by: Rohit Yadav 


> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7504:
--

 Summary: [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


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

[Mihaela Stoica (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica updated CLOUDSTACK-7502:
---
Status: Reviewable  (was: In Progress)

> 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
>
>
> 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] [Resolved] (CLOUDSTACK-7293) UI: Validation message on login page is not user friendly

[Mihaela Stoica (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica resolved CLOUDSTACK-7293.

Resolution: Fixed

> UI: Validation message on login page is not user friendly
> -
>
> Key: CLOUDSTACK-7293
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7293
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Mihaela Stoica
>Assignee: Mihaela Stoica
>Priority: Trivial
> Fix For: 4.5.0
>
>
> When trying to login to cloudstack with empty username or password, the error 
> message displayed "message.validate.fieldrequired" is not user friendly. It 
> should be changed to a proper message like "This field is required".



--
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

[Mihaela Stoica (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125343#comment-14125343
 ] 

Mihaela Stoica commented on CLOUDSTACK-7502:


Review request: https://reviews.apache.org/r/25429/ 

> 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
>
>
> 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-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin

[Bharat Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharat Kumar updated CLOUDSTACK-6099:
-
Status: Reviewable  (was: In Progress)

> 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.servle

[jira] [Reopened] (CLOUDSTACK-7497) [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal reopened CLOUDSTACK-7497:


I am able to reproduce it 

Narrowing it down further

Have a mixed cluster types .One kvm type and one lxc type.
Create first KVM VM and then try to create LXC vm . VM creation will fail

> [LXC][UI] deploy VM  failing as hypervisor type passed is KVM instead of LXC
> 
>
> Key: CLOUDSTACK-7497
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497
> 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: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC zone with 2 cluster one LXc and one KVM
> Create  VM  with LXC template
> Bug:
> Deploy vm fails as hypervisor type is passed as KVM
> 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24) ===START===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:09,581 INFO  [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 
> ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the 
> hypervisor type of the template
> 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END===  10.146.0.131 -- GET  
> command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711
> 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] 
> (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM
> 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
> (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7501:
---
Assignee: Abhinandan Prateek  (was: Kishan Kavala)

> System VM fails to move from one cluster to another cluster when hypervisor 
> type differs
> 
>
> Key: CLOUDSTACK-7501
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501
> 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: shweta agarwal
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: Ms.tar.gz
>
>
> Repro steps:
> 1. Create a LXC advance zone setup with one LXC cluster 
> 2. When system vms are up .add one more KVM cluster
> 3. Put LXC host to maintenance
> Bug:
> System VM is not coming up on KVM  cluster
> Expected result:
> System VMs should come up on KVM cluster 
> Ms log shows :
> Cluster: 2 has HyperVisorType that does not match the VM, skipping this 
> cluster
> which should not be the case in case of SSVM  and CPVM
> attaching MS logs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7501:
---
Summary: System VM fails to move from one cluster to another cluster when 
hypervisor type differs  (was: [LXC] System VM fails to move from one cluster 
to another cluster when hypervisor type differs)

> System VM fails to move from one cluster to another cluster when hypervisor 
> type differs
> 
>
> Key: CLOUDSTACK-7501
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501
> 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: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: Ms.tar.gz
>
>
> Repro steps:
> 1. Create a LXC advance zone setup with one LXC cluster 
> 2. When system vms are up .add one more KVM cluster
> 3. Put LXC host to maintenance
> Bug:
> System VM is not coming up on KVM  cluster
> Expected result:
> System VMs should come up on KVM cluster 
> Ms log shows :
> Cluster: 2 has HyperVisorType that does not match the VM, skipping this 
> cluster
> which should not be the case in case of SSVM  and CPVM
> attaching MS logs



--
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

[Mihaela Stoica (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica updated CLOUDSTACK-7502:
---
Description: 
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.


  was:
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 listHiosts 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.



> 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
>
>
> 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-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Stephen Turner (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125325#comment-14125325
 ] 

Stephen Turner commented on CLOUDSTACK-6624:


Thanks, Rohit.

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav resolved CLOUDSTACK-6624.
-
Resolution: Fixed

Fixed on 4.3, master. Sent request to pick this on 4.4 branch.

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125323#comment-14125323
 ] 

ASF subversion and git services commented on CLOUDSTACK-6624:
-

Commit c68325deb189ebcd79f229d0db25d0cfe842f0dc in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c68325d ]

CLOUDSTACK-6624: set specifyIpRanges to true if specifyVlan is set to true

Signed-off-by: Rohit Yadav 
(cherry picked from commit b7b9cd0d2d0dc9973e65c99ade3f550c6dd8dcd7)
Signed-off-by: Rohit Yadav 

Conflicts:
ui/scripts/configuration.js


> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav reassigned CLOUDSTACK-6624:
---

Assignee: Rohit Yadav

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7503) [Hyper-V] Logging meaningless response string from Hyper-v Agent

[Anshul Gangwar (JIRA)]

Anshul Gangwar created CLOUDSTACK-7503:
--

 Summary: [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] [Updated] (CLOUDSTACK-7502) UI - Host detail page - Display KVM agent version and Qemu version

[Mihaela Stoica (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica updated CLOUDSTACK-7502:
---
Description: 
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 listHiosts 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.


  was:


UI - Host detail page - Display KVM agent version and Qemu version.

For KVM hosts, Host detail page should includeKVM agent version and Qemu 
version.

The information can be found in listhost api, details field: 
CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version is 
the version of kvm agent.



> 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
>
>
> 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 listHiosts 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-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125318#comment-14125318
 ] 

ASF subversion and git services commented on CLOUDSTACK-6624:
-

Commit b7b9cd0d2d0dc9973e65c99ade3f550c6dd8dcd7 in cloudstack's branch 
refs/heads/hotfix/4.4/CLOUDSTACK-6624 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b7b9cd0 ]

CLOUDSTACK-6624: set specifyIpRanges to true if specifyVlan is set to true

Signed-off-by: Rohit Yadav 


> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125316#comment-14125316
 ] 

ASF subversion and git services commented on CLOUDSTACK-6624:
-

Commit c3617f986788186d0a4f1cd98c6d65b48e9f894b 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=c3617f9 ]

CLOUDSTACK-6624: set specifyIpRanges to true if specifyVlan is set to true

Signed-off-by: Rohit Yadav 


> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7502) UI - Host detail page - Display KVM agent version and Qemu version

[Mihaela Stoica (JIRA)]

Mihaela Stoica created CLOUDSTACK-7502:
--

 Summary: 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




UI - Host detail page - Display KVM agent version and Qemu version.

For KVM hosts, Host detail page should includeKVM agent version and Qemu 
version.

The information can be found in listhost api, 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-6926) Usage service fails to start when java 1.6 is not installed

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125314#comment-14125314
 ] 

ASF subversion and git services commented on CLOUDSTACK-6926:
-

Commit ecfe5b5417355eed90d1f3591a1c2349f58b9bf4 in cloudstack's branch 
refs/heads/4.4 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ecfe5b5 ]

CLOUDSTACK-6926: removed hard coded jdk dirs and setting java home using 
readlink and dirname

(cherry picked from commit c468228fe807c621decc5919dadae9bcbb38c753)

Conflicts:
packaging/debian/init/cloud-usage


> Usage service fails to start when java 1.6 is not installed
> ---
>
> Key: CLOUDSTACK-6926
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6926
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup, Usage
>Affects Versions: 4.2.1
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> was able to start only after editing JDK_DIRS in /etc/init.d/cloudstack-usage
> it is searching only 1.6 java install directories by default



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7476) centos cloudstack-usage script does not always pass along $JAVA_HOME

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125312#comment-14125312
 ] 

ASF GitHub Bot commented on CLOUDSTACK-7476:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/17#issuecomment-54790328
  
Leo, you are right but if it is in 4.3 not putting it in 4.4 would make it
a double behavioural change from a user perspective. So I will look at
cherry-picking it anyway


On Mon, Sep 8, 2014 at 9:38 AM, Leo Simons  wrote:

> Hey Daan, *this* change is fine&done as-is. Like Rajani mentioned, the
> other changes to that file could be ported, too. I'm +0 on that -- on the
> one hand, it's a good change and I can't see any way that it would ever
> break anything, on the other hand it's a (however minor) behavioral change
> so I personally wouldn't put that in a point release.
>
> —
> Reply to this email directly or view it on GitHub
> .
>



-- 
Daan


> centos cloudstack-usage script does not always pass along $JAVA_HOME
> 
>
> Key: CLOUDSTACK-7476
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7476
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
> Environment: secured centos/redhat
>Reporter: Leo Simons
> Fix For: 4.5.0
>
>
> /etc/init.d/cloudstack-usage finds a $JAVA_HOME and makes sure the 
> environment variable is set, then assumes this variable will be picked up by 
> JSVC.
> However, on a secured environment (selinux w/ env_reset enabled in sudoers), 
> the runuser command that is invoked by the daemon() function does not pass 
> along environment variables, so $JAVA_HOME is empty, and JSVC falls back to 
> its default behavior, which may not find java or may not find the intended 
> java.
> The simple solution is to pass -home to JSVC, passing it on the command line 
> instead of as an environment variable.
> I'll provide a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7491) [Automtation] Test case test_02_deploy_ha_vm_from_iso failed, hypervisor parameter password

[sadhu suresh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sadhu suresh resolved CLOUDSTACK-7491.
--
Resolution: Not a Problem

Its  the problem with iso used in the script.i.e its script issue. and not a 
product bug

manually able to deploy a vm from iso.

> [Automtation] Test case test_02_deploy_ha_vm_from_iso  failed, hypervisor 
> parameter password 
> -
>
> Key: CLOUDSTACK-7491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7491
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM
>Reporter: Rayees Namathponnan
>Assignee: sadhu suresh
> Fix For: 4.5.0
>
>
> Test cases failed with below error 
> Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
> errorText:hypervisor parameter is needed to deploy VM or the hypervisor 
> parameter value passed is invalid
>  >> begin captured stdout << -
> === TestName: test_02_deploy_ha_vm_from_iso | Status : EXCEPTION ===
> - >> end captured stdout << --
>  >> begin captured logging << 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7491) [Automtation] Test case test_02_deploy_ha_vm_from_iso failed, hypervisor parameter password

[sadhu suresh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sadhu suresh updated CLOUDSTACK-7491:
-
Assignee: sadhu suresh

> [Automtation] Test case test_02_deploy_ha_vm_from_iso  failed, hypervisor 
> parameter password 
> -
>
> Key: CLOUDSTACK-7491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7491
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM
>Reporter: Rayees Namathponnan
>Assignee: sadhu suresh
> Fix For: 4.5.0
>
>
> Test cases failed with below error 
> Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
> errorText:hypervisor parameter is needed to deploy VM or the hypervisor 
> parameter value passed is invalid
>  >> begin captured stdout << -
> === TestName: test_02_deploy_ha_vm_from_iso | Status : EXCEPTION ===
> - >> end captured stdout << --
>  >> begin captured logging << 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav updated CLOUDSTACK-6624:

Fix Version/s: (was: 4.4.1)
   (was: Future)

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: 4.3.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125297#comment-14125297
 ] 

Rohit Yadav commented on CLOUDSTACK-6624:
-

For 4.4/master, CLOUDSTACK-6889 fixes this by removing specifyIpRanges key from 
the query

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: Future, 4.3.1, 4.4.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7501) [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs

[shweta agarwal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7501:
---
Attachment: Ms.tar.gz

> [LXC] System VM fails to move from one cluster to another cluster when 
> hypervisor type differs
> --
>
> Key: CLOUDSTACK-7501
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501
> 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: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: Ms.tar.gz
>
>
> Repro steps:
> 1. Create a LXC advance zone setup with one LXC cluster 
> 2. When system vms are up .add one more KVM cluster
> 3. Put LXC host to maintenance
> Bug:
> System VM is not coming up on KVM  cluster
> Expected result:
> System VMs should come up on KVM cluster 
> Ms log shows :
> Cluster: 2 has HyperVisorType that does not match the VM, skipping this 
> cluster
> which should not be the case in case of SSVM  and CPVM
> attaching MS logs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7501) [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-7501:
--

 Summary: [LXC] System VM fails to move from one cluster to another 
cluster when hypervisor type differs
 Key: CLOUDSTACK-7501
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501
 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: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


Repro steps:
1. Create a LXC advance zone setup with one LXC cluster 
2. When system vms are up .add one more KVM cluster
3. Put LXC host to maintenance

Bug:
System VM is not coming up on KVM  cluster

Expected result:

System VMs should come up on KVM cluster 


Ms log shows :
Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster

which should not be the case in case of SSVM  and CPVM


attaching MS logs




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7476) centos cloudstack-usage script does not always pass along $JAVA_HOME

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125277#comment-14125277
 ] 

ASF GitHub Bot commented on CLOUDSTACK-7476:


Github user lsimons commented on the pull request:

https://github.com/apache/cloudstack/pull/17#issuecomment-54785217
  
Hey Daan, _this_ change is fine&done as-is. Like Rajani mentioned, the 
other changes to that file could be ported, too. I'm +0 on that -- on the one 
hand, it's a good change and I can't see any way that it would ever break 
anything, on the other hand it's a (however minor) behavioral change so I 
personally wouldn't put that in a point release.


> centos cloudstack-usage script does not always pass along $JAVA_HOME
> 
>
> Key: CLOUDSTACK-7476
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7476
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.0
> Environment: secured centos/redhat
>Reporter: Leo Simons
> Fix For: 4.5.0
>
>
> /etc/init.d/cloudstack-usage finds a $JAVA_HOME and makes sure the 
> environment variable is set, then assumes this variable will be picked up by 
> JSVC.
> However, on a secured environment (selinux w/ env_reset enabled in sudoers), 
> the runuser command that is invoked by the daemon() function does not pass 
> along environment variables, so $JAVA_HOME is empty, and JSVC falls back to 
> its default behavior, which may not find java or may not find the intended 
> java.
> The simple solution is to pass -home to JSVC, passing it on the command line 
> instead of as an environment variable.
> I'll provide a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav reassigned CLOUDSTACK-6624:
---

Assignee: (was: Alex Hitchins)

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Priority: Critical
>  Labels: UI
> Fix For: Future, 4.3.1, 4.4.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav updated CLOUDSTACK-6624:

Fix Version/s: 4.4.1
   4.3.1
   Future

> Unable to create new Network Offerings via UI with Specify VLAN option set
> --
>
> Key: CLOUDSTACK-6624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.3.0
>Reporter: Geoff Higgibottom
>Assignee: Alex Hitchins
>Priority: Critical
>  Labels: UI
> Fix For: Future, 4.3.1, 4.4.1
>
>
> When creating a new network offering with the Specify VLAN option set, the 
> Specify IP Option should also be set automatically.  The UI is no longer 
> sending this parameter in the API string so the Network Offering has an 
> invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)