date:20140603

Sanjeev N created CLOUDSTACK-6828:
-

 Summary: [OVS] Tunnel ports are not getting deleted even failure 
in vm deployment
 Key: CLOUDSTACK-6828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS] Tunnel ports are not getting deleted even failure in vm deployment

Steps to Reproduce:

1.Bringup CS in advanced zone with Xen cluster
2.Create physical network with GRE isolation
3.Create network offering with virtual networking and ovs as the connectivity 
service provider.
4.Deploy vm with above offering and simulate vm failure
(In my case I was trying with multiple physical networks scenario and because 
of some configuration issues network implement failed so failure in vm 
deployment)

Result:
=
During vm deployment ovs bridge and tunnel ports were created between the two 
hosts. But after the failure there was no clean up of the ovs-bridge and the 
tunnel ports.

Observations:
==
xapi7 and xapi6 were the bridges created for the network.

Following is the log snippet from ovstunnel log from both the hosts:
[root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7
t10016-4-1
[root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log
2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
'--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 
'other_config:gre_key=OVSTunnel10016']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi7', 
'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi7', 'stp_enable=true']
2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'bridge', 'xapi7', 'other_config:gre_key']
2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi7', '--minimal']
2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with 
result:SUCCESS:xapi7
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 
'xapi7', 'name']
2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - VERIFIED
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 
'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13']
2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi7', '--minimal']
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
'add-flow', 'xapi7', 
'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop']
2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
'add-flow', 'xapi7', 
'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop']

[root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6
t10016-1-4
[root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log
2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
'--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 
'other_config:gre_key=OVSTunnel10016']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi6', 
'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
'Bridge', 'xapi6', 'stp_enable=true']
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'bridge', 'xapi6', 'other_config:gre_key']
2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 
'network-list', 'bridge=xapi6', '--minimal']
2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed with 
result:SUCCESS:xapi6
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'--timeout=30', 'wait-until', 'bridge', 'xapi6', '--', 'get', 'bridge', 
'xapi6', 'name']
2014-06-03 05:38:56DEBUG [root] bridge xapi6 for creating tunnel - VERIFIED
2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'add-port', 'xapi6', 't10016-1-4', '--', 'set', 'interface', 't10016-1-4', 
'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.14']

[jira] [Created] (CLOUDSTACK-6829) [UI]If no storage is available for migrate volume UI should popup no storage available if yo utry to migrate volume

prashant kumar mishra created CLOUDSTACK-6829:
-

 Summary: [UI]If no storage is available for migrate volume UI 
should popup no storage available if yo utry to migrate volume 
 Key: CLOUDSTACK-6829
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6829
 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: prashant kumar mishra
 Fix For: 4.4.0


if no storage is available for migration , UI should pop up same message 
instead empty drop down list .  
steps to repo
===
1-prepare a CS setup with one primary storage
2-create a volume and attach to vm
3-and attach to vm
4-try to migrate volume

Expected
===
since there is no other storage UI should pop up no storage available

Actual
==
UI popup show drop down list of storage with nothing in list 

API

http://10.147.38.181:8080/client/api?command=findStoragePoolsForMigrationid=bbedf40d-d2da-40e4-b0d3-55e4a70682d8response=jsonsessionkey=%2B3QBQd4DLtoNPX9sZ%2FfZu2GNiJ8%3D_=1401779685525

response 

{ findstoragepoolsformigrationresponse : { } }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6797) volume resize should not be allowed for detached volumes


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

prashant kumar mishra updated CLOUDSTACK-6797:
--

Summary: volume resize should not be allowed for detached volumes  (was: 
volume resize hsould not be allowed for detached volumes)

 volume resize should not be allowed for detached volumes
 

 Key: CLOUDSTACK-6797
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6797
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller
Affects Versions: 4.2.0, 4.4.0
Reporter: prashant kumar mishra
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0

 Attachments: Logs_db.rar, screenshot-1.jpg, screenshot-2.jpg


 =since resize space is counted in allocated space even though it cant be 
 attach to VM , other storage operation will fail because threshold value 
 If resize is allowed in volume  detach
 ==
 1-since there is no check for how much can be increased , suppose user has 
 resized it to 1000GB
 2-when user try to attach volume to vm it will fail since available space is 
 not sufficient . 
 3-even though user is not able to use the resized volume ,CS will count  
 1000GB in allocated storage .
 4-Dash will show allocated percentage 100%
 5-Because threshold values , we cant  perform any operation to that PS
 If resize is allowed online ( volume  Attach) state it will fail in first 
 place and will not cause any problem



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6829) [UI]If no storage is available for migrate volume UI should popup no storage available if you try to migrate volume


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

prashant kumar mishra updated CLOUDSTACK-6829:
--

Summary: [UI]If no storage is available for migrate volume UI should popup 
no storage available if you try to migrate volume  (was: [UI]If no storage is 
available for migrate volume UI should popup no storage available if yo utry 
to migrate volume )

 [UI]If no storage is available for migrate volume UI should popup no storage 
 available if you try to migrate volume
 -

 Key: CLOUDSTACK-6829
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6829
 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: prashant kumar mishra
 Fix For: 4.4.0

 Attachments: screenshot-1.jpg


 if no storage is available for migration , UI should pop up same message 
 instead empty drop down list .  
 steps to repo
 ===
 1-prepare a CS setup with one primary storage
 2-create a volume and attach to vm
 3-and attach to vm
 4-try to migrate volume
 Expected
 ===
 since there is no other storage UI should pop up no storage available
 Actual
 ==
 UI popup show drop down list of storage with nothing in list 
 API
 
 http://10.147.38.181:8080/client/api?command=findStoragePoolsForMigrationid=bbedf40d-d2da-40e4-b0d3-55e4a70682d8response=jsonsessionkey=%2B3QBQd4DLtoNPX9sZ%2FfZu2GNiJ8%3D_=1401779685525
 response 
 
 { findstoragepoolsformigrationresponse : { } }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6829) [UI]If no storage is available for migrate volume UI should popup no storage available if you try to migrate volume


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

prashant kumar mishra updated CLOUDSTACK-6829:
--

Attachment: screenshot-1.jpg

 [UI]If no storage is available for migrate volume UI should popup no storage 
 available if you try to migrate volume
 -

 Key: CLOUDSTACK-6829
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6829
 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: prashant kumar mishra
 Fix For: 4.4.0

 Attachments: screenshot-1.jpg


 if no storage is available for migration , UI should pop up same message 
 instead empty drop down list .  
 steps to repo
 ===
 1-prepare a CS setup with one primary storage
 2-create a volume and attach to vm
 3-and attach to vm
 4-try to migrate volume
 Expected
 ===
 since there is no other storage UI should pop up no storage available
 Actual
 ==
 UI popup show drop down list of storage with nothing in list 
 API
 
 http://10.147.38.181:8080/client/api?command=findStoragePoolsForMigrationid=bbedf40d-d2da-40e4-b0d3-55e4a70682d8response=jsonsessionkey=%2B3QBQd4DLtoNPX9sZ%2FfZu2GNiJ8%3D_=1401779685525
 response 
 
 { findstoragepoolsformigrationresponse : { } }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6828) [OVS] Tunnel ports are not getting deleted even failure in vm deployment


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

Sanjeev N updated CLOUDSTACK-6828:
--

Attachment: ovstunnel-host14.log
ovstunnel-host13.log
management-server.rar

 [OVS] Tunnel ports are not getting deleted even failure in vm deployment
 

 Key: CLOUDSTACK-6828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: ovs
 Fix For: 4.4.0

 Attachments: management-server.rar, ovstunnel-host13.log, 
 ovstunnel-host14.log


 [OVS] Tunnel ports are not getting deleted even failure in vm deployment
 Steps to Reproduce:
 
 1.Bringup CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create network offering with virtual networking and ovs as the connectivity 
 service provider.
 4.Deploy vm with above offering and simulate vm failure
 (In my case I was trying with multiple physical networks scenario and because 
 of some configuration issues network implement failed so failure in vm 
 deployment)
 Result:
 =
 During vm deployment ovs bridge and tunnel ports were created between the two 
 hosts. But after the failure there was no clean up of the ovs-bridge and the 
 tunnel ports.
 Observations:
 ==
 xapi7 and xapi6 were the bridges created for the network.
 Following is the log snippet from ovstunnel log from both the hosts:
 [root@Rack1Pod1Host14 ~]# ovs-vsctl list-ports xapi7
 t10016-4-1
 [root@Rack1Pod1Host14 ~]# grep xapi7 /var/log/cloud/ovstunnel.log
 2014-06-03 05:38:46DEBUG [root] About to manually create the bridge:xapi7
 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
 '--may-exist', 'add-br', 'xapi7', '--', 'set', 'bridge', 'xapi7', 
 'other_config:gre_key=OVSTunnel10016']
 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
 'Bridge', 'xapi7', 
 'external_ids:xs-network-uuid=127de5bb-a423-2774-98b6-ce1827d261d7']
 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
 'Bridge', 'xapi7', 'stp_enable=true']
 2014-06-03 05:38:46DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
 'bridge', 'xapi7', 'other_config:gre_key']
 2014-06-03 05:38:46DEBUG [root] Executing:['/opt/xensource/bin/xe', 
 'network-list', 'bridge=xapi7', '--minimal']
 2014-06-03 05:38:46DEBUG [root] Setup_ovs_bridge completed with 
 result:SUCCESS:xapi7
 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 '--timeout=30', 'wait-until', 'bridge', 'xapi7', '--', 'get', 'bridge', 
 'xapi7', 'name']
 2014-06-03 05:38:50DEBUG [root] bridge xapi7 for creating tunnel - 
 VERIFIED
 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 'add-port', 'xapi7', 't10016-4-1', '--', 'set', 'interface', 't10016-4-1', 
 'type=gre', 'options:key=10016', 'options:remote_ip=10.147.42.13']
 2014-06-03 05:38:50DEBUG [root] Executing:['/opt/xensource/bin/xe', 
 'network-list', 'bridge=xapi7', '--minimal']
 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
 'add-flow', 'xapi7', 
 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,actions=drop']
 2014-06-03 05:38:50DEBUG [root] Executing:['/usr/bin/ovs-ofctl', 
 'add-flow', 'xapi7', 
 'hard_timeout=0,idle_timeout=0,priority=1000,in_port=1,ip,nw_dst=224.0.0.0/24,actions=drop']
 [root@Rack1Pod1Host13 ~]# ovs-vsctl list-ports xapi6
 t10016-1-4
 [root@Rack1Pod1Host13 ~]# grep xapi6 /var/log/cloud/ovstunnel.log
 2014-06-03 05:38:56DEBUG [root] About to manually create the bridge:xapi6
 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--', 
 '--may-exist', 'add-br', 'xapi6', '--', 'set', 'bridge', 'xapi6', 
 'other_config:gre_key=OVSTunnel10016']
 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
 'Bridge', 'xapi6', 
 'external_ids:xs-network-uuid=ae6fe450-3399-7dad-b972-aa45755c2803']
 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'set', 
 'Bridge', 'xapi6', 'stp_enable=true']
 2014-06-03 05:38:56DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
 'bridge', 'xapi6', 'other_config:gre_key']
 2014-06-03 05:38:56DEBUG [root] Executing:['/opt/xensource/bin/xe', 
 'network-list', 'bridge=xapi6', '--minimal']
 2014-06-03 05:38:56DEBUG [root] Setup_ovs_bridge completed

[jira] [Issue Comment Deleted] (CLOUDSTACK-6612) [Automation] Test cases failing with db connection error

2014-06-03 Thread Girish Shilamkar (JIRA)


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

Girish Shilamkar updated CLOUDSTACK-6612:
-

Comment: was deleted

(was: I see the same failure in other test suites test_snapshot_limits.py and 
test_snapshot_gc.py. And the failures are seen only in KVM and not VMware. Can 
you please check if you can login to the database manually with the password 
provided in the config file?

The test code is same for all hypervisors here.)

 [Automation] Test cases failing with db connection error 
 -

 Key: CLOUDSTACK-6612
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6612
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.4.0


 Test 
 caseintegration.component.test_egress_fw_rules.TestEgressFWRules.test_04_1_egress_fr4
  (from nosetests) failed with below error 
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=ylEuPgkfrfJfwrM8fLVEn7SaBNI%3DapiKey=TKG3-LFUFTPhT_OQ9MPrEdI_UpDMgvR07w8NZCUhWlsIKeSPIrnKBNcn0UgWIPIQLhwcTYMD5jyVpJ7oMdc9GAcommand=queryAsyncJobResultresponse=jsonjobid=42c474a9-a4eb-4b5f-8ea0-e46d332e62c5
  HTTP/1.1 200 621
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 ===Jobid:42c474a9-a4eb-4b5f-8ea0-e46d332e62c5 ; StartTime:Wed May  7 14:23:16 
 2014 ; EndTime:Wed May  7 14:23:22 2014 ; TotalTime:-5===
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Created rule=8b12a8ef-01e6-4dac-b995-1081dceffc2c
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL: 
 EXCEPTION: test_04_1_egress_fr4: ['Traceback (most recent call last):\n', '  
 File /usr/local/lib/python2.7/unittest/case.py, line 318, in run\n
 testMethod()\n', '  File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py,
  line 542, in test_04_1_egress_fr4\nqresultset = 
 self.dbclient.execute(select purpose, traffic_type from firewall_rules where 
 uuid=\'%s\'; % self.egressruleid)\n', '  File 
 /usr/local/lib/python2.7/site-packages/marvin/dbConnection.py, line 48, in 
 execute\ndb=str(self.database))) as conn:\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/__init__.py, line 
 98, in connect\nreturn MySQLConnection(*args, **kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 118, in __init__\nself.connect(**kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 382, in connect\nself._open_connection()\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 349, in _open_connection\nself._ssl)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 176, in _do_auth\nraise errors.get_exception(packet)\n', 
 ProgrammingError: 1045 (28000): Access denied for user 
 'root'@'10.223.240.194' (using password: YES)\n]

[jira] [Commented] (CLOUDSTACK-6612) [Automation] Test cases failing with db connection error

2014-06-03 Thread Girish Shilamkar (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016295#comment-14016295
 ] 

Girish Shilamkar commented on CLOUDSTACK-6612:
--

I see the same failure in other test suites test_snapshot_limits.py and 
test_snapshot_gc.py. And the failures are seen only in KVM and not VMware. Can 
you please check if you can login to the database manually with the password 
provided in the config file?

The test code is same for all hypervisors here.

 [Automation] Test cases failing with db connection error 
 -

 Key: CLOUDSTACK-6612
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6612
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.4.0


 Test 
 caseintegration.component.test_egress_fw_rules.TestEgressFWRules.test_04_1_egress_fr4
  (from nosetests) failed with below error 
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=ylEuPgkfrfJfwrM8fLVEn7SaBNI%3DapiKey=TKG3-LFUFTPhT_OQ9MPrEdI_UpDMgvR07w8NZCUhWlsIKeSPIrnKBNcn0UgWIPIQLhwcTYMD5jyVpJ7oMdc9GAcommand=queryAsyncJobResultresponse=jsonjobid=42c474a9-a4eb-4b5f-8ea0-e46d332e62c5
  HTTP/1.1 200 621
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 ===Jobid:42c474a9-a4eb-4b5f-8ea0-e46d332e62c5 ; StartTime:Wed May  7 14:23:16 
 2014 ; EndTime:Wed May  7 14:23:22 2014 ; TotalTime:-5===
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Created rule=8b12a8ef-01e6-4dac-b995-1081dceffc2c
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL: 
 EXCEPTION: test_04_1_egress_fr4: ['Traceback (most recent call last):\n', '  
 File /usr/local/lib/python2.7/unittest/case.py, line 318, in run\n
 testMethod()\n', '  File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py,
  line 542, in test_04_1_egress_fr4\nqresultset = 
 self.dbclient.execute(select purpose, traffic_type from firewall_rules where 
 uuid=\'%s\'; % self.egressruleid)\n', '  File 
 /usr/local/lib/python2.7/site-packages/marvin/dbConnection.py, line 48, in 
 execute\ndb=str(self.database))) as conn:\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/__init__.py, line 
 98, in connect\nreturn MySQLConnection(*args, **kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 118, in __init__\nself.connect(**kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 382, in connect\nself._open_connection()\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 349, in _open_connection\nself._ssl)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 176, in _do_auth\nraise errors.get_exception(packet)\n', 
 ProgrammingError: 1045 (28000): Access denied for user 
 'root'@'10.223.240.194' (using password:

[jira] [Commented] (CLOUDSTACK-6612) [Automation] Test cases failing with db connection error

2014-06-03 Thread Gaurav Aradhye (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016297#comment-14016297
 ] 

Gaurav Aradhye commented on CLOUDSTACK-6612:


I see the same failure in other test suites test_snapshot_limits.py and 
test_snapshot_gc.py. And the failures are seen only in KVM and not VMware. Can 
you please check if you can login to the database manually with the password 
provided in the config file?

The test code is same for all hypervisors here.

 [Automation] Test cases failing with db connection error 
 -

 Key: CLOUDSTACK-6612
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6612
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.4.0


 Test 
 caseintegration.component.test_egress_fw_rules.TestEgressFWRules.test_04_1_egress_fr4
  (from nosetests) failed with below error 
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=ylEuPgkfrfJfwrM8fLVEn7SaBNI%3DapiKey=TKG3-LFUFTPhT_OQ9MPrEdI_UpDMgvR07w8NZCUhWlsIKeSPIrnKBNcn0UgWIPIQLhwcTYMD5jyVpJ7oMdc9GAcommand=queryAsyncJobResultresponse=jsonjobid=42c474a9-a4eb-4b5f-8ea0-e46d332e62c5
  HTTP/1.1 200 621
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 ===Jobid:42c474a9-a4eb-4b5f-8ea0-e46d332e62c5 ; StartTime:Wed May  7 14:23:16 
 2014 ; EndTime:Wed May  7 14:23:22 2014 ; TotalTime:-5===
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Response : {jobprocstatus : 0, created : u'2014-05-07T18:10:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd',
  userid : u'b1d59b38-d616-11e3-a7c8-1a6f7bb0d0a8', jobstatus : 1, jobid : 
 u'42c474a9-a4eb-4b5f-8ea0-e46d332e62c5', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {networkid : u'72a5c1d3-4120-4139-bef9-4508268d8539', 
 protocol : u'icmp', fordisplay : True, cidrlist : u'10.1.1.0/24', tags : [], 
 icmptype : -1, state : u'Active', icmpcode : -1, id : 
 u'8b12a8ef-01e6-4dac-b995-1081dceffc2c'}, accountid : 
 u'b1d58e04-d616-11e3-a7c8-1a6f7bb0d0a8'}
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG: 
 Created rule=8b12a8ef-01e6-4dac-b995-1081dceffc2c
 test_04_1_egress_fr4 
 (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL: 
 EXCEPTION: test_04_1_egress_fr4: ['Traceback (most recent call last):\n', '  
 File /usr/local/lib/python2.7/unittest/case.py, line 318, in run\n
 testMethod()\n', '  File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py,
  line 542, in test_04_1_egress_fr4\nqresultset = 
 self.dbclient.execute(select purpose, traffic_type from firewall_rules where 
 uuid=\'%s\'; % self.egressruleid)\n', '  File 
 /usr/local/lib/python2.7/site-packages/marvin/dbConnection.py, line 48, in 
 execute\ndb=str(self.database))) as conn:\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/__init__.py, line 
 98, in connect\nreturn MySQLConnection(*args, **kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 118, in __init__\nself.connect(**kwargs)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 382, in connect\nself._open_connection()\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 349, in _open_connection\nself._ssl)\n', '  File 
 /usr/local/lib/python2.7/site-packages/mysql/connector/connection.py, line 
 176, in _do_auth\nraise errors.get_exception(packet)\n', 
 ProgrammingError: 1045 (28000): Access denied for user 
 'root'@'10.223.240.194' (using password: YES)\n]

[jira] [Closed] (CLOUDSTACK-6778) [HyperV] Storage motion/migration is failing if the Hosts are having different NIC names


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

Abhinav Roy closed CLOUDSTACK-6778.
---


Closing this issue based on above comments

 [HyperV] Storage motion/migration is failing if the Hosts are having 
 different NIC names
 

 Key: CLOUDSTACK-6778
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6778
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects Versions: 4.4.0
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0


 Steps :
 ==
 1. Deploy a CS advanced zone setup with HyperV having 2 clusters.
 2. cl1 has 2 hosts h1 and h2, cl2 has 1 host h3,
 3. Deploy a VM on cl1 and the migrate that VM2 to h3.
 Here the NIC names of h1 and h3 are different :
 h1 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #38 - Virtual 
Switch
 h3 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual  
  Switch
 Expected behavior :
 ===
 The migration of VM with storage should succeed.
 Observed behavior :
 ===
 Migration fails with the following error :
 2014-05-27 14:29:09,072 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-434:ctx-960ed94b) POST response is 
 [{com.cloud.agent.api.MigrateWithStorageAnswer:{result:false,volumeTos:[{id:9,name:ROOT-7,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,size:5368709120,type:ROOT,storagePoolType:SMB,storagePoolUuid:38aee7de-07f1-3f23-8f8d-6a772fb9811d,deviceId:0}],details:com.cloud.agent.api.MigrateWithStorageCommand
  failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual 
 machine migration operation for 'i-2-7-VM' failed at migration destination 
 'HYPERV20.blr.cloudstack.org'. (Virtual machine ID 
 FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
 The virtual machine 'i-2-7-VM' is not compatible with physical computer 
 'HYPERV20'. (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
 Could not find Ethernet switch 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD 
 Client) #39 - Virtual Switch'.,contextMap:{}}}]
 2014-05-27 14:29:09,073 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-434:ctx-960ed94b) executeRequest received response 
 [Lcom.cloud.agent.api.Answer;@3ab8553b
 2014-05-27 14:29:09,073 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Response Received:
 2014-05-27 14:29:09,073 DEBUG [c.c.a.t.Request] 
 (DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Processing:  { Ans: 
 , MgmtId: 213737702773493, via: 5, Ver: v1, Flags: 110, 
 [{com.cloud.agent.api.MigrateWithStorageAnswer:{volumeTos:[{name:ROOT-7,size:5368709120,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,accountId:0,id:9,deviceId:0}],result:false,details:com.cloud.agent.api.MigrateWithStorageCommand
  failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual 
 machine migration operation for 'i-2-7-VM' failed at migration destination 
 'HYPERV20.blr.cloudstack.org'. (Virtual machine ID 
 FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nThe virtual machine 'i-2-7-VM' is 
 not compatible with physical computer 'HYPERV20'. (Virtual machine ID 
 FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nCould not find Ethernet switch 
 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual 
 Switch'.,wait:0}}] }
 2014-05-27 14:29:09,074 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Seq 
 5-2135832123280457911: Received:  { Ans: , MgmtId: 213737702773493, via: 5, 
 Ver: v1, Flags: 110, { MigrateWithStorageAnswer } }
 2014-05-27 14:29:09,077 DEBUG [c.c.a.m.AgentAttache] 
 (DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: No more commands 
 found
 2014-05-27 14:29:09,074 ERROR [o.a.c.s.m.HypervStorageMotionStrategy] 
 (Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Migration with 
 storage of vm VM[User|i-2-7-VM] failed. Details: 
 com.cloud.agent.api.MigrateWithStorageCommand failed due to Hyper-V Job 
 failed, Error Code:32784, Description: Virtual machine migration operation 
 for 'i-2-7-VM' failed at migration destination 'HYPERV20.blr.cloudstack.org'. 
 (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
 The virtual machine 'i-2-7-VM' is not compatible with physical computer 
 'HYPERV20'. (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
 Could not find Ethernet switch 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD 
 Client) #39 - Virtual Switch'.
 2014-05-27 14:29:09,077 ERROR [o.a.c.s.m.HypervStorageMotionStrategy]

[jira] [Commented] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans

2014-06-03 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016303#comment-14016303
 ] 

Andrija Panic commented on CLOUDSTACK-6814:
---

Anybody ? This is a in my opinion a bug, comparing IP ranges across different 
broadcast domains doesn't make any sense to me?
thanks

 Detected overlapping subnets in differents vlans
 

 Key: CLOUDSTACK-6814
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6814
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.3.0
 Environment: not relevant
Reporter: Andrija Panic
Priority: Critical
  Labels: guestnetwork, network, overlap, publicip

 I have both Public IP(untagged) and Guest IP range (vlan 500) on same 
 physical network device eth1 (infrastrucure-zones-physical network-eth1public 
 tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 
 till now...
 In previous versions I was able to add few additional IP addresses from the 
 /24 subnet to Guest IP range..
 In 4.3, there is an error message saying that Guest IP range and Public IP 
 range has overlaping subnets - which IS true - but since those networks ARE 
 on different vlans completely, I'm not sure why there is such check at all 
 (overlaping subnet check). Different vlans means different broadcast domains, 
 why checking IP parameters across different vlans...
 Existing database records -  first row is Public IP range, rest is all 
 smaller ranges of IP addresses added few times for Guest IP range.
 mysql select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from 
 cloud.vlan;
 ++--+-+--+---+---+
 | id | uuid | vlan_id | vlan_gateway 
 | vlan_netmask  | description   |
 ++--+-+--+---+---+
 |  1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 |
 |  3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 |
 |  4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 |
 |  5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 |
 |  8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 |
 ++--+-+--+---+---+
 Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather 
 Public or Guest network - I can't do that and getting folowing error (tried 
 adding it to Public range here):
 The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has overlapped with 
 the subnet. Please specify a different gateway/netmask.
 This subnet check across differenet vlans should be removed, and I'm stuck 
 with over 90% used IP addresses, and can't add more from same /24 range that 
 we got...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016310#comment-14016310
 ] 

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

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

CLOUDSTACK-6599: Add the column in Java upgrade path since 4.2 already has the 
extract template/volume columns

Conflicts:
engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java


 Template/Volume URLs expiration functionality not working
 -

 Key: CLOUDSTACK-6599
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.4.0


 Template / Volume Donwload URLs should expire - functionality is missing
 We have the functionality where we create download urls for volumes and 
 templates for the users. For security reasons we should expire these urls and 
 this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that 
 needs to be implemented. Look at 4.2 for reference.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6830) [Hyper-V] If a VM is is created with it's volumes on zone wide primary storage, the migration of that VM always asks for storage migration as well and fails.

Abhinav Roy created CLOUDSTACK-6830:
---

 Summary: [Hyper-V] If a VM is is created with it's volumes on zone 
wide primary storage, the migration of that VM always asks for storage 
migration as well and fails.
 Key: CLOUDSTACK-6830
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6830
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Storage Controller
Affects Versions: 4.4.0
 Environment: Advanced zone
Hypervisor : Hyper-V
Primary storage : cluster wide, zone wide and local


Reporter: Abhinav Roy
Priority: Critical
 Fix For: 4.4.0


Steps :
==
1. Deploy an advanced zone HyperV setup with 2 clusters.
c1 having 2 hosts , h1  h2
2 primary storages ps1  ps2
c2 having 1 host, h3
 2 primary storages ps3  p4
2 zone wide primary storages zwps1  zwps2

2. Create a VM such that its volume lies on zwps1
3. Migrate the VM 

Expected behavior :
=
1. When we try to migrate the VM, the API or UI should list the hosts suitable 
for migration. And the migration should not require storage motion since the 
pool used is a zone wide primary storage

2. Migration should be successful.

Observed behavior :

1. When we try to migrate the VM, the API lists the hosts suitable for 
migration but it also says that the process involved storage motion ( which is 
wrong)

monkey# find hostsformigration virtualmachineid=25
count = 2
host:
id = 6452c7b7-2623-48ec-930f-dc4f98d10e21
name = 10.102.244.20
capabilities = hvm
clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e
clustername = cluster1
clustertype = CloudManaged
cpuallocated = 0%
cpunumber = 4
cpuspeed = 3093
cpuused = 1%
cpuwithoverprovisioning = 12372.0
created = 2014-06-02T11:56:28+0530
disconnected = 2014-06-02T12:28:48+0530
events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; 
Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout
hahost = False
hosttags = tag1
hypervisor = Hyperv
hypervisorversion = 6.2
ipaddress = 10.102.244.20
islocalstorageactive = False
jobstatus = 0
lastpinged = 1970-01-17T01:43:59+0530
managementserverid = 213737702773493
memoryallocated = 3447717888
memorytotal = 8558297088
memoryused = 4933872
networkkbsread = 53356091604
networkkbswrite = 326400170803
podid = 69ba6799-d3f4-482e-93f1-9bdc637c0e51
podname = hyperv
requiresStorageMotion = True
resourcestate = Enabled
state = Up
suitableformigration = True
type = Routing
version = 4.4.0-SNAPSHOT
zoneid = 1259f9d6-87a6-45c1-ad45-0be382c68b4b
zonename = hyperv

id = ee8ca90c-08da-4bae-b04b-83ff8e78ded2
name = 10.102.244.21
capabilities = hvm
clusterid = 46dbf863-d9cb-4a47-be11-8fdb46320a2e
clustername = cluster1
clustertype = CloudManaged
cpuallocated = 0%
cpunumber = 4
cpuspeed = 3093
cpuused = 1%
cpuwithoverprovisioning = 12372.0
created = 2014-06-02T11:57:11+0530
disconnected = 2014-06-02T12:28:48+0530
events = AgentDisconnected; StartAgentRebalance; HostDown; AgentConnected; 
Remove; ShutdownRequested; ManagementServerDown; Ping; PingTimeout
hahost = False
hypervisor = Hyperv
hypervisorversion = 6.2
ipaddress = 10.102.244.21
islocalstorageactive = False
jobstatus = 0
lastpinged = 1970-01-17T01:43:59+0530
managementserverid = 213737702773493
memoryallocated = 1166016512
memorytotal = 8558297088
memoryused = 2956140
networkkbsread = 189444293536
networkkbswrite = 63265905010
podid = 69ba6799-d3f4-482e-93f1-9bdc637c0e51
podname = hyperv
requiresStorageMotion = True
resourcestate = Enabled
state = Up
suitableformigration = True
type = Routing
version = 4.4.0-SNAPSHOT
zoneid = 1259f9d6-87a6-45c1-ad45-0be382c68b4b
zonename = hyperv
==


2. The migration fails :

2014-06-03 13:45:58,082 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-20:ctx-8c9a3f4f) ===START===  10.144.7.13 -- GET  
command=migrateVirtualMachineWithVolumehostid=ee8ca90c-08da-4bae-b04b-83ff8e78ded2virtualmachineid=e9523ccd-28cb-4089-b4cd-c5cbb8658120response=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401782981308
2014-06-03 13:45:58,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-20:ctx-8c9a3f4f ctx-81f3bd5c) submit async job-128, details: 
AsyncJobVO {id:128, userId: 2, accountId: 2, instanceType: None, instanceId: 
null, cmd: 
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd, 
cmdInfo:

[jira] [Commented] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans

2014-06-03 Thread Saksham Srivastava (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016330#comment-14016330
 ] 

Saksham Srivastava commented on CLOUDSTACK-6814:


It could be a bug. It will help if you can post the exact api call you are 
trying to make.

 Detected overlapping subnets in differents vlans
 

 Key: CLOUDSTACK-6814
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6814
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.3.0
 Environment: not relevant
Reporter: Andrija Panic
Priority: Critical
  Labels: guestnetwork, network, overlap, publicip

 I have both Public IP(untagged) and Guest IP range (vlan 500) on same 
 physical network device eth1 (infrastrucure-zones-physical network-eth1public 
 tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 
 till now...
 In previous versions I was able to add few additional IP addresses from the 
 /24 subnet to Guest IP range..
 In 4.3, there is an error message saying that Guest IP range and Public IP 
 range has overlaping subnets - which IS true - but since those networks ARE 
 on different vlans completely, I'm not sure why there is such check at all 
 (overlaping subnet check). Different vlans means different broadcast domains, 
 why checking IP parameters across different vlans...
 Existing database records -  first row is Public IP range, rest is all 
 smaller ranges of IP addresses added few times for Guest IP range.
 mysql select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from 
 cloud.vlan;
 ++--+-+--+---+---+
 | id | uuid | vlan_id | vlan_gateway 
 | vlan_netmask  | description   |
 ++--+-+--+---+---+
 |  1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 |
 |  3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 |
 |  4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 |
 |  5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 |
 |  8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 |
 ++--+-+--+---+---+
 Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather 
 Public or Guest network - I can't do that and getting folowing error (tried 
 adding it to Public range here):
 The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has overlapped with 
 the subnet. Please specify a different gateway/netmask.
 This subnet check across differenet vlans should be removed, and I'm stuck 
 with over 90% used IP addresses, and can't add more from same /24 range that 
 we got...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016340#comment-14016340
 ] 

Andrija Panic commented on CLOUDSTACK-6814:
---

I did try to add additional IP addresses from GUI, will try to capture 
management log:

I tried adding Public IP range: 46.232.xxx.106-46.232.xxx.130, same gateway 
and netmask, untagged (empty field), as is existing Public range (first raw in 
original table submited previously):

management logs:

2014-06-03 11:10:11,099 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-23:ctx-038e027a) ===START===  89.216.xxx.189 -- GET  
command=createVlanIpRangezoneId=3d1dcf11-d482-4f28-a2dd-6afcb51545d2vlan=untaggedgateway=46.232.xxx.1netmask=255.255.255.0startip=46.232.xxx.106endip=46.232.xxx.130forVirtualNetwork=trueresponse=jsonsessionkey=aqaaC3snjAp%2B86Dr17D1JWt4O4M%3D_=1401786613222
2014-06-03 11:10:11,110 DEBUG [c.c.c.ConfigurationManagerImpl] 
(catalina-exec-23:ctx-038e027a ctx-08ddd172) Access granted to 
Acct[1272e979-0ccc-4644-b96b-735cb6f81821-admin] to zone:1 by 
AffinityGroupAccessChecker
2014-06-03 11:10:11,113 DEBUG [c.c.u.d.T.Transaction] 
(catalina-exec-23:ctx-038e027a ctx-08ddd172) Rolling back the transaction: Time 
= 3 Name =  catalina-exec-23; called by 
-TransactionLegacy.rollback:896-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-Transaction.execute:41-Transaction.execute:46-ConfigurationManagerImpl.commitVlan:2718-ConfigurationManagerImpl.createVlanAndPublicIpRange:2709-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:57-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:622-AopUtils.invokeJoinpointUsingReflection:317
2014-06-03 11:10:11,119 INFO  [c.c.a.ApiServer] (catalina-exec-23:ctx-038e027a 
ctx-08ddd172) The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has 
overlapped with the subnet. Please specify a different gateway/netmask.
2014-06-03 11:10:11,119 DEBUG [c.c.a.ApiServlet] (catalina-exec-23:ctx-038e027a 
ctx-08ddd172) ===END===  89.216.xxx.189 -- GET  
command=createVlanIpRangezoneId=3d1dcf11-d482-4f28-a2dd-6afcb51545d2vlan=untaggedgateway=46.232.xxx.1netmask=255.255.255.0startip=46.232.xxx.106endip=46.232.xxx.130forVirtualNetwork=trueresponse=jsonsessionkey=aqaaC3snjAp%2B86Dr17D1JWt4O4M%3D_=1401786613222

 Detected overlapping subnets in differents vlans
 

 Key: CLOUDSTACK-6814
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6814
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.3.0
 Environment: not relevant
Reporter: Andrija Panic
Priority: Critical
  Labels: guestnetwork, network, overlap, publicip

 I have both Public IP(untagged) and Guest IP range (vlan 500) on same 
 physical network device eth1 (infrastrucure-zones-physical network-eth1public 
 tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 
 till now...
 In previous versions I was able to add few additional IP addresses from the 
 /24 subnet to Guest IP range..
 In 4.3, there is an error message saying that Guest IP range and Public IP 
 range has overlaping subnets - which IS true - but since those networks ARE 
 on different vlans completely, I'm not sure why there is such check at all 
 (overlaping subnet check). Different vlans means different broadcast domains, 
 why checking IP parameters across different vlans...
 Existing database records -  first row is Public IP range, rest is all 
 smaller ranges of IP addresses added few times for Guest IP range.
 mysql select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from 
 cloud.vlan;
 ++--+-+--+---+---+
 | id | uuid | vlan_id | vlan_gateway 
 | vlan_netmask  | description   |
 ++--+-+--+---+---+
 |  1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 |
 |  3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 |
 |  4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 |
 |  5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 |
 |  8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 |

[jira] [Resolved] (CLOUDSTACK-6661) deployvm failed with NPE


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

Damodar Reddy T resolved CLOUDSTACK-6661.
-

Resolution: Fixed

Issue has been fixed in the commit 7bbad0491f7ec087f693814caadbe6d648d2edf2.

 deployvm failed with NPE 
 -

 Key: CLOUDSTACK-6661
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6661
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.4.0
Reporter: Jayapal Reddy
Assignee: Damodar Reddy T
Priority: Critical
 Fix For: 4.4.0


 While deploying vm observed the NPE
 java.lang.NullPointerException
   at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:96)
 =
 2014-05-14 11:58:59,398 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (867392383@qtp-1655170479-7:ctx-2fd5e67f ctx-20936702) submit async job-178, 
 details: AsyncJobVO {id:178, userId: 2, accountId: 2, instanceType: 
 VirtualMachine, instanceId: 26, cmd: 
 org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin, cmdInfo: 
 {serviceofferingid:baa62f3e-9f44-46ad-a137-7275bcaf8c99,sessionkey:Li3x1YB3+DUERGcuaZ9plLrGSZc\u003d,cmdEventType:VM.CREATE,ctxUserId:2,zoneid:e7d72675-2bf3-4bab-b673-d9d92a735603,httpmethod:GET,templateid:79f647d6-da5c-11e3-80cb-b51f7904a635,response:json,id:26,ctxDetails:{\com.cloud.template.VirtualMachineTemplate\:5,\com.cloud.vm.VirtualMachine\:26,\com.cloud.dc.DataCenter\:1,\VirtualMachine\:\ed6a3bef-8e60-4001-8fc9-d0bd1ad15312\,\com.cloud.offering.ServiceOffering\:1},hypervisor:XenServer,iptonetworklist[0].networkid:4bcc4888-3a5d-4736-8b3e-ad8204606dcd,_:1400048939193,uuid:ed6a3bef-8e60-4001-8fc9-d0bd1ad15312,ctxAccountId:2,ctxStartEventId:197},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: null}
 2014-05-14 11:58:59,399 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-7:job-178) Add job-178 into job monitoring
 2014-05-14 11:58:59,399 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-7:job-178) Executing AsyncJobVO {id:178, userId: 2, 
 accountId: 2, instanceType: VirtualMachine, instanceId: 26, cmd: 
 org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin, cmdInfo: 
 {serviceofferingid:baa62f3e-9f44-46ad-a137-7275bcaf8c99,sessionkey:Li3x1YB3+DUERGcuaZ9plLrGSZc\u003d,cmdEventType:VM.CREATE,ctxUserId:2,zoneid:e7d72675-2bf3-4bab-b673-d9d92a735603,httpmethod:GET,templateid:79f647d6-da5c-11e3-80cb-b51f7904a635,response:json,id:26,ctxDetails:{\com.cloud.template.VirtualMachineTemplate\:5,\com.cloud.vm.VirtualMachine\:26,\com.cloud.dc.DataCenter\:1,\VirtualMachine\:\ed6a3bef-8e60-4001-8fc9-d0bd1ad15312\,\com.cloud.offering.ServiceOffering\:1},hypervisor:XenServer,iptonetworklist[0].networkid:4bcc4888-3a5d-4736-8b3e-ad8204606dcd,_:1400048939193,uuid:ed6a3bef-8e60-4001-8fc9-d0bd1ad15312,ctxAccountId:2,ctxStartEventId:197},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: null}
 2014-05-14 11:58:59,400 DEBUG [c.c.a.ApiServlet] 
 (867392383@qtp-1655170479-7:ctx-2fd5e67f ctx-20936702) ===END===  
 10.252.192.19 -- GET  
 command=deployVirtualMachineresponse=jsonsessionkey=Li3x1YB3%2BDUERGcuaZ9plLrGSZc%3Dzoneid=e7d72675-2bf3-4bab-b673-d9d92a735603templateid=79f647d6-da5c-11e3-80cb-b51f7904a635hypervisor=XenServerserviceofferingid=baa62f3e-9f44-46ad-a137-7275bcaf8c99iptonetworklist%5B0%5D.networkid=4bcc4888-3a5d-4736-8b3e-ad8204606dcd_=1400048939193
 2014-05-14 11:58:59,407 DEBUG [c.c.a.d.ParamProcessWorker] 
 (API-Job-Executor-7:job-178 ctx-836ec730) Access granted to 
 Acct[7aa84a4e-da5c-11e3-80cb-b51f7904a635-admin] to service offering:1 by 
 RoleBasedEntityAccessChecker
 2014-05-14 11:58:59,409 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] 
 (API-Job-Executor-7:job-178 ctx-836ec730) IAM access check for 
 2-null-null-SystemCapability from cache: true
 2014-05-14 11:58:59,409 DEBUG [c.c.u.AccountManagerImpl] 
 (API-Job-Executor-7:job-178 ctx-836ec730) Root Access granted to 
 Acct[7aa84a4e-da5c-11e3-80cb-b51f7904a635-admin] by 
 RoleBasedEntityAccessChecker
 2014-05-14 11:58:59,411 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] 
 (API-Job-Executor-7:job-178 ctx-836ec730) IAM access check for 
 2-null-null-DomainCapability from cache: false
 2014-05-14 11:58:59,413 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] 
 (API-Job-Executor-7:job-178 ctx-836ec730) IAM access check for 
 2-null-null-DomainResourceCapability from cache: false
 2014-05-14 11:58:59,414 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] 
 (API-Job-Executor-7:job-178 ctx-836ec730) IAM access check for

[jira] [Created] (CLOUDSTACK-6831) [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs

Abhinav Roy created CLOUDSTACK-6831:
---

 Summary: [Hyper-V] Improve the logging for VM snapshot failures as 
it is not supported. Right now it is throwing NPEs
 Key: CLOUDSTACK-6831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: HyperV
Reporter: Abhinav Roy
 Fix For: 4.4.0


Steps :

1. Deploy a advanced zone hyperv setup.
2. Create a VM v1.
3. Create a VM snapshot on v1

Expected behavior :

Since VM snapshot is not supported in 4.4.0 for HyperV, the operation should 
fail gracefully with appropriate error message.


Observed behavior :
===
VM snapshot operation fails with a NPE 

2014-06-03 15:21:25,150 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-8ce4a754) 
===START===  10.144.7.13 -- GET  
command=createVMSnapshotvirtualmachineid=fb624f96-c70f-4e25-94a0-65f9daf145aasnapshotmemory=falsequiescevm=falsename=ssresponse=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401788814498
2014-06-03 15:21:25,168 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-8ce4a754 
ctx-ce4443a6) unhandled exception executing api command: 
[Ljava.lang.String;@7cfb6b51
java.lang.NullPointerException
at 
com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.isVmSnapshotEnabled(HypervisorCapabilitiesDaoImpl.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy179.isVmSnapshotEnabled(Unknown Source)
at 
com.cloud.vm.snapshot.VMSnapshotManagerImpl.allocVMSnapshot(VMSnapshotManagerImpl.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy182.allocVMSnapshot(Unknown Source)
at 
org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd.create(CreateVMSnapshotCmd.java:92)
at 
com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at

[jira] [Assigned] (CLOUDSTACK-6508) impossible to list projects from API with domainid set

2014-06-03 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava reassigned CLOUDSTACK-6508:
--

Assignee: Saksham Srivastava

 impossible to list projects from API with domainid set
 --

 Key: CLOUDSTACK-6508
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6508
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.2.1, 4.3.0
Reporter: ivan derbenev
Assignee: Saksham Srivastava

 Hello, it's my first issue ever, so sorry if i made smth wrong.
 Today we was trying to setup jCloud module for jenkins, and stuck with error.
 it throws GET request:
 /client/api/?response=jsoncommand=listProjectslistAll=trueaccount=jenkinsdomainid=%domainid%apiKey=%apikey%signature=%sig%
 and returns error:
 Can't list domain id= 1 projects; unauthorized
 i have only one ROOT domain, and this user belongs to this domain
 if i go into cloudmonkey and call:
 list projects listall=true account=jenkins domainid=%domainid%
 it throws error too. If i don't use domainid attribute, query works properly
 if i call any other api function with domainid attribute, query works 
 properly
 i looked into cloudstack sources and found this function:
 https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/api/query/QueryManagerImpl.java
 listProjectsInternal function
 line 1309
  if (domainId != null  domainId.equals(caller.getDomainId())) {
 throw new PermissionDeniedException(Can't list domain id=  
 + domainId +  projects; unauthorized);
 }
 so if i understand it well it check whether i provide a domainid and if user 
 belongs to domain with this domainid it throws exception
 I don't think this is how this API function should work.
 Am i mistaken anywhere or this is really a bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted

Sanjeev N created CLOUDSTACK-6832:
-

 Summary: [OVS]vnet is not released even the network is deleted
 Key: CLOUDSTACK-6832
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0


[OVS]vnet is not released even the network is deleted

Steps to reproduce:
===
1.Bring up CS in advanced zone with xen cluster
2.Create physical network with GRE isolation and specify some VNIs as GRE keys 
for guest traffic
3.Create network offering with virtual networking and OVS as the service 
provider
4.Deploy few vms with the above network
5.Delete the network after expunging all the vms

Result:
=
Network deletion was successful but the vnet allocated for the network was not 
released.

VNI range specified for the guest traffic was 981-1000 and 992 was taken for 
the implemented network. But the vnet id 992 was not released back to the pool 
even after deleting the network.

mysql select * from op_dc_vnet_alloc;
+-+--+-++--++-+-+
| id  | vnet | physical_network_id | data_center_id | reservation_id
   | account_id | taken   | account_vnet_map_id |
+-+--+-++--++-+-+
| 122 | 989  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 123 | 988  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 124 | 987  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 125 | 982  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 126 | 981  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 127 | 986  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 128 | 985  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 129 | 984  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 130 | 983  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 131 | 996  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 132 | 997  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 133 | 994  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 134 | 995  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 135 | 992  | 203 |  2 | 
8edad56a-a59d-4477-8741-9e91a8ef9052 |  2 | 2014-06-03 15:12:55 |   
 NULL |
| 136 | 993  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 137 | 990  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 138 | 991  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 139 | 1000 | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 140 | 998  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |
| 141 | 999  | 203 |  2 | NULL  
   |   NULL | NULL|NULL |

[jira] [Updated] (CLOUDSTACK-6832) [OVS]vnet is not released even the network is deleted


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

Sanjeev N updated CLOUDSTACK-6832:
--

Attachment: management-server.rar

 [OVS]vnet is not released even the network is deleted
 -

 Key: CLOUDSTACK-6832
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6832
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: ovs
 Fix For: 4.4.0

 Attachments: management-server.rar


 [OVS]vnet is not released even the network is deleted
 Steps to reproduce:
 ===
 1.Bring up CS in advanced zone with xen cluster
 2.Create physical network with GRE isolation and specify some VNIs as GRE 
 keys for guest traffic
 3.Create network offering with virtual networking and OVS as the service 
 provider
 4.Deploy few vms with the above network
 5.Delete the network after expunging all the vms
 Result:
 =
 Network deletion was successful but the vnet allocated for the network was 
 not released.
 VNI range specified for the guest traffic was 981-1000 and 992 was taken for 
 the implemented network. But the vnet id 992 was not released back to the 
 pool even after deleting the network.
 mysql select * from op_dc_vnet_alloc;
 +-+--+-++--++-+-+
 | id  | vnet | physical_network_id | data_center_id | reservation_id  
  | account_id | taken   | account_vnet_map_id |
 +-+--+-++--++-+-+
 | 122 | 989  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 123 | 988  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 124 | 987  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 125 | 982  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 126 | 981  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 127 | 986  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 128 | 985  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 129 | 984  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 130 | 983  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 131 | 996  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 132 | 997  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 133 | 994  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 134 | 995  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 135 | 992  | 203 |  2 | 
 8edad56a-a59d-4477-8741-9e91a8ef9052 |  2 | 2014-06-03 15:12:55 | 
NULL |
 | 136 | 993  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 137 | 990  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 138 | 991  | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 139 | 1000 | 203 |  2 | NULL
  |   NULL | NULL|NULL |
 | 140 | 998  |

[jira] [Updated] (CLOUDSTACK-6776) [Automation]: Test case failure in test_non_contigiousvlan.py

2014-06-03 Thread Girish Shilamkar (JIRA)


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

Girish Shilamkar updated CLOUDSTACK-6776:
-

Assignee: Ashutosk Kelkar  (was: Girish Shilamkar)

 [Automation]: Test case failure in test_non_contigiousvlan.py
 -

 Key: CLOUDSTACK-6776
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6776
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, KVM
Affects Versions: 4.4.0
Reporter: Harikrishna Patnala
Assignee: Ashutosk Kelkar
 Fix For: 4.4.0

 Attachments: test_extendPhysicalNetworkVlan .rtf, vmops.log


 There is test case failure in test_non_contigiousvlan.py
 1) 
 integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork.test_extendPhysicalNetworkVlan
 Error Message
 Job failed: {jobprocstatus : 0, created : u'2014-05-26T13:36:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd', 
 userid : u'40470752-e504-11e3-af30-00163e5d4a0e', jobstatus : 2, jobid : 
 u'168af076-cd18-44f2-997d-bbb55b7c12ad', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'physicalnetwork 200 
 has allocated vnets in the range 4090-4095'}, accountid : 
 u'4046c30a-e504-11e3-af30-00163e5d4a0e'}
 Attached Test Report and management server logs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6833) [Hyper-V] Volume snapshot creation returns success even though snapshots are not supported for Hyper-V

Abhinav Roy created CLOUDSTACK-6833:
---

 Summary: [Hyper-V] Volume snapshot creation returns success even 
though snapshots are not supported for Hyper-V
 Key: CLOUDSTACK-6833
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6833
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller, Snapshot
Affects Versions: 4.4.0
 Environment: Hyper-V
Reporter: Abhinav Roy
 Fix For: 4.4.0


Steps :

1. Deploy an advanced zone CS setup with hyperv .
2. Create a VM.
3. Goto the ROOT volume of the VM created in above step and take a snapshot.
Expected behavior :

Since snapshots are not supported for Hyper-V in Felton, the operation should 
error out with a valid exception/error and the job should fail.
Observed behaviour :
===
Exception is thrown in MS but the async job succeeds. In the UI also job 
succeeds but snapshots are in error state.

2014-06-03 15:31:30,360 DEBUG [o.a.c.s.s.SnapshotServiceImpl] 
(Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) create 
snapshot stag4_ROOT-23_20140603100128 failed: 
org.apache.cloudstack.storage.command.CreateObjectCommand failed on exception, 
Object reference not set to an instance of an object.
2014-06-03 15:31:30,382 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) Failed to take 
snapshot: org.apache.cloudstack.storage.command.CreateObjectCommand failed on 
exception, Object reference not set to an instance of an object.
2014-06-03 15:31:30,398 DEBUG [c.c.s.s.SnapshotManagerImpl] 
(Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) Failed to 
create snapshot
com.cloud.utils.exception.CloudRuntimeException: 
org.apache.cloudstack.storage.command.CreateObjectCommand failed on exception, 
Object reference not set to an instance of an object.
at 
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:287)
at 
com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy177.takeSnapshot(Unknown Source)
at 
org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503)
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1769)
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2504)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2512)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at

[jira] [Created] (CLOUDSTACK-6834) [Windows] Feedback Items

Damodar Reddy T created CLOUDSTACK-6834:
---

 Summary: [Windows] Feedback Items
 Key: CLOUDSTACK-6834
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6834
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: Future
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
 Fix For: 4.5.0


The feed back items received internally.

1. Need to add more fields to the database creation wizard
2. Remove Complete Option
3. Some description changes words like CloudStack etc
4. Change Default installation location if possible include version number
5. Mysql Connector Installer along with other dependecies
6. Add run Service Checkbox
7. Add ReadMe checkbox



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6835) db abstraction layer in upgrade path

2014-06-03 Thread Rajani Karuturi (JIRA)

Rajani Karuturi created CLOUDSTACK-6835:
---

 Summary: db abstraction layer in upgrade path
 Key: CLOUDSTACK-6835
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6835
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rajani Karuturi
Priority: Critical


about 198 of the issues reported by covery scan[1] on 26 May, 2014 are in the 
Upgrade###to###.java code
and many of them related to Resource leaks and not closing the prepared 
statements. 

I think we should have a DB abstraction layer in the upgrade path so the the 
developer who needs to do select/insert/update data in the upgrade path need 
not write native sqls and worry about these recurring issues.

[1] https://scan.coverity.com/projects/943



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6831) [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs

2014-06-03 Thread Rajesh Battala (JIRA)


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

Rajesh Battala reassigned CLOUDSTACK-6831:
--

Assignee: Rajesh Battala

 [Hyper-V] Improve the logging for VM snapshot failures as it is not 
 supported. Right now it is throwing NPEs
 

 Key: CLOUDSTACK-6831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: HyperV
Reporter: Abhinav Roy
Assignee: Rajesh Battala
 Fix For: 4.4.0


 Steps :
 
 1. Deploy a advanced zone hyperv setup.
 2. Create a VM v1.
 3. Create a VM snapshot on v1
 Expected behavior :
 
 Since VM snapshot is not supported in 4.4.0 for HyperV, the operation should 
 fail gracefully with appropriate error message.
 Observed behavior :
 ===
 VM snapshot operation fails with a NPE 
 2014-06-03 15:21:25,150 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-7:ctx-8ce4a754) ===START===  10.144.7.13 -- GET  
 command=createVMSnapshotvirtualmachineid=fb624f96-c70f-4e25-94a0-65f9daf145aasnapshotmemory=falsequiescevm=falsename=ssresponse=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401788814498
 2014-06-03 15:21:25,168 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-8ce4a754 
 ctx-ce4443a6) unhandled exception executing api command: 
 [Ljava.lang.String;@7cfb6b51
 java.lang.NullPointerException
 at 
 com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.isVmSnapshotEnabled(HypervisorCapabilitiesDaoImpl.java:104)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy179.isVmSnapshotEnabled(Unknown Source)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.allocVMSnapshot(VMSnapshotManagerImpl.java:265)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy182.allocVMSnapshot(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd.create(CreateVMSnapshotCmd.java:92)
 at 
 com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
 at 
 com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
 at 
 com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506)
 at

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread Gerolamo Valcamonica (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016522#comment-14016522
 ] 

Gerolamo Valcamonica commented on CLOUDSTACK-6464:
--

It's worse than I described 2 days ago:
 
we have advanced networking and every time we apply a new rule to a guest 
network (i.e. adding a new static route, open or close a port on firewall, ..) 
the router hangs, VMs become unreachable and the quicker solution is to restart 
the router and re-apply Bob's workaround

In addition, some rules seems not to works: i.e. FTP server in a guest VM 
become unreachable either in active and in passive mode and the only workaround 
we found is to modprobe nf_conntrack_ftp and ip_nat_ftp on the VR. FTP worked 
correctly before upgrading to 4.3

It seems to me that Cloudstack Devs needs to give a clear message to the world:
YOU CANNOT UPGRADE TO CLOUDSTACK 4.3 IF YOU ARE USING TRAFFIC LABELS IN YOUR 
NETWORK SETUP

do you agree, Devs?

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse'

[jira] [Updated] (CLOUDSTACK-6820) VPC router ICMP acl

2014-06-03 Thread John Kinsella (JIRA)


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

John Kinsella updated CLOUDSTACK-6820:
--

Security: Public  (was: Non-Public)

 VPC router ICMP acl
 ---

 Key: CLOUDSTACK-6820
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6820
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.3.0
Reporter: Thijs Houtenbos
Priority: Minor
  Labels: security

 There is a default allow icmp any any on the VPC router vm which cannot be 
 controlled with the network ACLs. This makes it impossible to block certain 
 icmp traffic.
 root@r-4135-VM:~# iptables -L -v | grep icmp
 10784  901K ACCEPT icmp --  anyany anywhere anywhere



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6820) VPC router ICMP acl

2014-06-03 Thread John Kinsella (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016569#comment-14016569
 ] 

John Kinsella commented on CLOUDSTACK-6820:
---

Chatted with Daan about this on security@ - doesn't look like this affects the 
security of ACS, so I'm leaving it public.

So - the firewall setup on the SSVMs in general is sort of annoying, in that 
without 
building a new image there’s not currently a way to update those rulesets 
without
manual tweaking. Seems like there should be a default ruleset, with the ability 
to
override the ruleset either per-VM or in general.

Now that I think about it - what seems ideal would be to have an “advanced” 
option 
to instruct a SSVM to connect to a puppet/chef/whatever server to get it’s 
configuration data.

Also - just a reminder to not block all ICMP as a whole. Block echo/reply and
the time-realted messages if you wish, but you want things like MTU negotiation 
to go through.

 VPC router ICMP acl
 ---

 Key: CLOUDSTACK-6820
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6820
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.3.0
Reporter: Thijs Houtenbos
Priority: Minor
  Labels: security

 There is a default allow icmp any any on the VPC router vm which cannot be 
 controlled with the network ACLs. This makes it impossible to block certain 
 icmp traffic.
 root@r-4135-VM:~# iptables -L -v | grep icmp
 10784  901K ACCEPT icmp --  anyany anywhere anywhere



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016580#comment-14016580
 ] 

Andrija Panic commented on CLOUDSTACK-6464:
---

Can you check your agent conf if there are changes to it ? I also use advanced 
zone, kvm traffic labels, and I don't have this bug for some reason...

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel type='none'/
 /domain
 its also applicable to new vm deployments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016580#comment-14016580
 ] 

Andrija Panic edited comment on CLOUDSTACK-6464 at 6/3/14 2:54 PM:
---

Can you check your agent conf if there are changes to it ? I also use advanced 
zone, kvm traffic labels, and I don't have this bug for some reason...but I'm 
using vlan separation...


was (Author: andrija):
Can you check your agent conf if there are changes to it ? I also use advanced 
zone, kvm traffic labels, and I don't have this bug for some reason...

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00'

[jira] [Comment Edited] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016580#comment-14016580
 ] 

Andrija Panic edited comment on CLOUDSTACK-6464 at 6/3/14 2:57 PM:
---

Can you check your agent conf if there are changes to it ? I also use advanced 
zone, kvm traffic labels, and I don't have this bug for some reason...but I'm 
using vlan separation... And I'm using 1 bridge for guest traffic (private 
though) and second bridge for another guest traffic (public) and also first 
bridge for management/storage traffic...


was (Author: andrija):
Can you check your agent conf if there are changes to it ? I also use advanced 
zone, kvm traffic labels, and I don't have this bug for some reason...but I'm 
using vlan separation...

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016597#comment-14016597
 ] 

Marcus Sorensen commented on CLOUDSTACK-6464:
-

This is a shot in the dark, but there have been some issues around upgrades 
that involve the cloud.vlan table expected contents changing. New 4.3 installs 
using vlan isolation don't seem to reproduce the issue. I'll see if I can 
reproduce anything like this with basic and/or non-vlan isolated 
upgrades/installs.  Can anyone experiencing an issue look at their database via 
something like select * from cloud.vlan and look at the vlan_id. If you see 
something like untagged instead of vlan://untagged, please try changing it 
and see if that helps.

I should note as well that it sounds like there might be several different 
issues represented here.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics

[jira] [Created] (CLOUDSTACK-6836) problem with VPN Site2Site - multinets

2014-06-03 Thread Tomasz Zieba (JIRA)

Tomasz Zieba created CLOUDSTACK-6836:


 Summary: problem with VPN Site2Site - multinets
 Key: CLOUDSTACK-6836
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6836
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.2.1, 4.3.0
 Environment: ACS 4.2.1, ACS4.3
Reporter: Tomasz Zieba


There is a typo in /opt/cloud/bin/ipsectunnel.sh script on virtual router. 
When using multiple nets (CIDR list) in VPN connection, ipsectunnel.sh script 
create line as follows:

rightsubnets={192.168.6.0/24 10.13.1.0/24}

but this line should be:
rightsubnets={192.168.6.0/24,10.13.1.0/24}

Please change /opt/cloud/bin/ipsectunnel.sh, for example as follows:

add:
rightnets=${rightnets// /,}

befor lines:
sudo echo conn vpn-$rightpeer  $vpnconffile 
sudo echo   left=$leftpeer  $vpnconffile 
sudo echo   leftsubnet=$leftnet  $vpnconffile 
sudo echo   leftnexthop=$leftgw  $vpnconffile 
sudo echo   right=$rightpeer  $vpnconffile 
sudo echo   rightsubnets={$rightnets}  $vpnconffile 
sudo echo   type=tunnel  $vpnconffile 
sudo echo   authby=secret  $vpnconffile 
sudo echo   keyexchange=ike  $vpnconffile 
sudo echo   ike=$ikepolicy  $vpnconffile 
sudo echo   ikelifetime=${ikelifetime}s  $vpnconffile 
sudo echo   esp=$esppolicy  $vpnconffile 
sudo echo   salifetime=${esplifetime}s  $vpnconffile 
sudo echo   pfs=$pfs  $vpnconffile 
sudo echo   keyingtries=2  $vpnconffile 
sudo echo   auto=add  $vpnconffile 
sudo echo $leftpeer $rightpeer: PSK \$secret\  $vpnsecretsfile 
sudo chmod 0400 $vpnsecretsfile




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016611#comment-14016611
 ] 

Andrija Panic commented on CLOUDSTACK-6814:
---

I was able to manually fix my issue:

I made new records/rows in vlan and user_ip_addresses  tables and after 
that I have sucessfully used that single ip adress  (I added single IP address 
instead of whole range, for testing purposes)
1. generate UUID on Management server console with: uuidgen
2. Then duplicate 1st row from vlan table (in my case 1st row correspond to 
Public range, that I want to extend with additional IP range)
3. Then duplicate 1 row with some IP address from user_ip_addresses table, that 
belongs to my Public network - I used existing IP that was free/not 
allocated, and just changed uuid and mac fields...CS GUI shows these fine 
now, as new range...

This should be fixed in my opinion - I don't understand comparing IP parameters 
accross different broadcast domains (vlans)...
Andrija


 Detected overlapping subnets in differents vlans
 

 Key: CLOUDSTACK-6814
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6814
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.3.0
 Environment: not relevant
Reporter: Andrija Panic
Priority: Critical
  Labels: guestnetwork, network, overlap, publicip

 I have both Public IP(untagged) and Guest IP range (vlan 500) on same 
 physical network device eth1 (infrastrucure-zones-physical network-eth1public 
 tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 
 till now...
 In previous versions I was able to add few additional IP addresses from the 
 /24 subnet to Guest IP range..
 In 4.3, there is an error message saying that Guest IP range and Public IP 
 range has overlaping subnets - which IS true - but since those networks ARE 
 on different vlans completely, I'm not sure why there is such check at all 
 (overlaping subnet check). Different vlans means different broadcast domains, 
 why checking IP parameters across different vlans...
 Existing database records -  first row is Public IP range, rest is all 
 smaller ranges of IP addresses added few times for Guest IP range.
 mysql select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from 
 cloud.vlan;
 ++--+-+--+---+---+
 | id | uuid | vlan_id | vlan_gateway 
 | vlan_netmask  | description   |
 ++--+-+--+---+---+
 |  1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 |
 |  3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 |
 |  4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 |
 |  5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 |
 |  8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 
 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 |
 ++--+-+--+---+---+
 Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather 
 Public or Guest network - I can't do that and getting folowing error (tried 
 adding it to Public range here):
 The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has overlapped with 
 the subnet. Please specify a different gateway/netmask.
 This subnet check across differenet vlans should be removed, and I'm stuck 
 with over 90% used IP addresses, and can't add more from same /24 range that 
 we got...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6837) Template order changes are not permanent

2014-06-03 Thread Nick Sindlinger (JIRA)

Nick Sindlinger created CLOUDSTACK-6837:
---

 Summary: Template order changes are not permanent
 Key: CLOUDSTACK-6837
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6837
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.2.1
 Environment: KVM Environment running CS 4.2.1.1
Reporter: Nick Sindlinger
Priority: Trivial


When using the Template Order buttons in the UI the changes can be seen 
immediately. However upon leaving the template menu and returning to it you 
will find that they have returned to the default order and that your changes 
have not take effect. 

I can see the API calls taking place in the management logs to reorder all the 
templates however the changes are not permanent. 

2014-06-03 10:44:54,981 DEBUG [cloud.api.ApiServlet] (TP-Processor11:null) 
===START===  69.170.148.179 -- GET  
command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=a7668b03-d998-46d2-9044-d9c9f54dd03esortKey=14_=1401810294947
2014-06-03 10:44:55,001 DEBUG [cloud.api.ApiServlet] (TP-Processor5:null) 
===END===  69.170.148.179 -- GET  
command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=fd635fc6-599c-41a3-ae88-b4fb9d4d9f0dsortKey=19_=1401810294940




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6837) Template order changes are not permanent

2014-06-03 Thread Nick Sindlinger (JIRA)


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

Nick Sindlinger updated CLOUDSTACK-6837:


Affects Version/s: 4.1.1

 Template order changes are not permanent
 

 Key: CLOUDSTACK-6837
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6837
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.1.1, 4.2.1
 Environment: KVM Environment running CS 4.2.1.1
Reporter: Nick Sindlinger
Priority: Trivial

 When using the Template Order buttons in the UI the changes can be seen 
 immediately. However upon leaving the template menu and returning to it you 
 will find that they have returned to the default order and that your changes 
 have not take effect. 
 I can see the API calls taking place in the management logs to reorder all 
 the templates however the changes are not permanent. 
 2014-06-03 10:44:54,981 DEBUG [cloud.api.ApiServlet] (TP-Processor11:null) 
 ===START===  69.170.148.179 -- GET  
 command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=a7668b03-d998-46d2-9044-d9c9f54dd03esortKey=14_=1401810294947
 2014-06-03 10:44:55,001 DEBUG [cloud.api.ApiServlet] (TP-Processor5:null) 
 ===END===  69.170.148.179 -- GET  
 command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=fd635fc6-599c-41a3-ae88-b4fb9d4d9f0dsortKey=19_=1401810294940



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6837) Template order changes are not permanent

2014-06-03 Thread Nick Sindlinger (JIRA)


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

Nick Sindlinger updated CLOUDSTACK-6837:


Fix Version/s: 4.4.0

 Template order changes are not permanent
 

 Key: CLOUDSTACK-6837
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6837
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.1.1, 4.2.1
 Environment: KVM Environment running CS 4.2.1.1
Reporter: Nick Sindlinger
Priority: Trivial
 Fix For: 4.4.0


 When using the Template Order buttons in the UI the changes can be seen 
 immediately. However upon leaving the template menu and returning to it you 
 will find that they have returned to the default order and that your changes 
 have not take effect. 
 I can see the API calls taking place in the management logs to reorder all 
 the templates however the changes are not permanent. 
 2014-06-03 10:44:54,981 DEBUG [cloud.api.ApiServlet] (TP-Processor11:null) 
 ===START===  69.170.148.179 -- GET  
 command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=a7668b03-d998-46d2-9044-d9c9f54dd03esortKey=14_=1401810294947
 2014-06-03 10:44:55,001 DEBUG [cloud.api.ApiServlet] (TP-Processor5:null) 
 ===END===  69.170.148.179 -- GET  
 command=updateTemplateresponse=jsonsessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3Did=fd635fc6-599c-41a3-ae88-b4fb9d4d9f0dsortKey=19_=1401810294940



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016864#comment-14016864
 ] 

Marcus Sorensen commented on CLOUDSTACK-6464:
-

See my comment on

https://reviews.apache.org/r/21908/

If this chunk of code solves the issue, then it IS in fact related to the 
cloud.vlan table's vlan_id issue that Daan and I are discussing, and yet 
another place where the mgmt server passes broadcastUri in one format for one 
Command and in another format for a different Command. Generally we've seen 
these getting fixed by updating the vlan table and prepending vlan:// to each 
item, but we're still discussing whether or not that's a good permanent 
solution.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02'

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016888#comment-14016888
 ] 

Marcus Sorensen commented on CLOUDSTACK-6464:
-

Bob, I think your issue is related, but different. I'm trying to reproduce that 
now.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel type='none'/
 /domain
 its also applicable to new vm deployments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working

2014-06-03 Thread Nitin Mehta (JIRA)


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

Nitin Mehta resolved CLOUDSTACK-6599.
-

Resolution: Fixed

 Template/Volume URLs expiration functionality not working
 -

 Key: CLOUDSTACK-6599
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.4.0


 Template / Volume Donwload URLs should expire - functionality is missing
 We have the functionality where we create download urls for volumes and 
 templates for the users. For security reasons we should expire these urls and 
 this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that 
 needs to be implemented. Look at 4.2 for reference.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016888#comment-14016888
 ] 

Marcus Sorensen edited comment on CLOUDSTACK-6464 at 6/3/14 5:27 PM:
-

Bob, I think your issue is related, but different. I'm trying to reproduce that 
now. Can you describe your network layout? Which nics, vlans? Is this a VPC 
you're launching or just an isolated network?


was (Author: mlsorensen):
Bob, I think your issue is related, but different. I'm trying to reproduce that 
now.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/

[jira] [Updated] (CLOUDSTACK-6823) Brocade Network plugin to orchestrate Brocade VDX switches

2014-06-03 Thread Ritu Sabharwal (JIRA)

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

Ritu Sabharwal updated CLOUDSTACK-6823:
---

Description:
This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be configured on the physical switches as well, so that
when a VLAN-tagged packet arrives on a switch-port, the switch know which ports
to flood the packet. When the last VM is destroyed for an isolated Network, the
VLAN Id for the network is disabled from the switches as well. The plugin also
enables the periodic monitoring of the switch when it is configured first time.
If there are no VMs running for any of the isolated Networks using the physical
switch, the monitoring is disabled for the switch.
The Brocade Network Plugin orchestrates Brocade’s switches directly using
NETCONF. The plugin uses pre-configured properties file to provide the details
of Brocade switches (IP Address, UserName, Password).
In order to find out which switch-ports are connected to the hypervisor hosts,
the plugin uses the properties file to specify the guest-traffic-label to
switch-port mapping.

was:
This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be propagated to the physical switches as well, so that
when a VLAN-tagged packet arrives on a switch-port, the switch know which ports
to flood the packet. When the last VM is destroyed for an isolated Network, the
VLAN Id for the network is disabled from the switches as well. The plugin also
enables the periodic monitoring of the switch when it is configured first time.
If there are no VMs running for any of the isolated Networks using the physical
switch, the monitoring is disabled for the switch.
The Brocade Network Plugin orchestrates Brocade’s switches directly using
NETCONF. The plugin uses pre-configured properties file to provide the details
of Brocade switches (IP Address, UserName, Password).
In order to find out which switch-ports are connected to the hypervisor hosts,
the plugin uses the properties file to specify the guest-traffic-label to
switch-port mapping.

Environment:
• CloudStack supported KVM Hypervisor, VMWare, XenServer
• Brocade VDX switches running Network Operating System 4.1.1 or above.
The following models are supported:
VDX 8770, VDX 8770-8, VDX 8770-4, VDX 6740, VDX 6740T, VDX 6730, VDX 6720, VDX
6710

was:
• CloudStack supported KVM Hypervisor, VMWare, XenServer
• Brocade switches running NOS (e.g. VDX 67xx, VDX 87xx)

Brocade Network plugin to orchestrate Brocade VDX switches
--

Key: CLOUDSTACK-6823
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6823
Project: CloudStack
Issue Type: New Feature
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Environment: •CloudStack supported KVM Hypervisor, VMWare,
XenServer
• Brocade VDX switches running Network Operating System 4.1.1 or above.
The following models are supported:
VDX 8770, VDX 8770-8, VDX 8770-4, VDX 6740, VDX 6740T, VDX 6730, VDX 6720,
VDX 6710
Reporter: Ritu Sabharwal
Assignee: Ritu Sabharwal
Labels: Brocade
Fix For: 4.5.0

This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be configured on the physical switches as well, so
that when a VLAN-tagged packet arrives on a switch-port, the switch know
which ports to flood the packet. When the last VM is destroyed for an
isolated Network, the VLAN Id for the network is disabled from the switches
as well. The plugin also enables the periodic monitoring of the switch when
it is configured first time. If there are no VMs running for any of the
isolated Networks using the physical switch, the monitoring is disabled for
the switch.
The Brocade Network Plugin orchestrates Brocade’s switches directly using
NETCONF. The plugin uses pre-configured properties

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016911#comment-14016911
 ] 

Marcus Sorensen commented on CLOUDSTACK-6464:
-

Bob, unfortunately, I cannot reproduce the issue given the info provided. I did 
a fresh 4.3 install with cloudbr0 and cloudbr1, with cloudbr0 hosting an 
untagged mgmt network and guest networks (vlan isolated), while cloudbr1 was 
untagged public network. I deployed an isolated network router as well as VPC 
router with one isolated network, and only got the expected networks. Then I 
added vms to the isolated networks on both of these, added static nats to them, 
rebooted the routers, and never got the situation you describe.

If you'd be willing to create a separate bug and document the steps to 
reproduce from fresh install, that would help significantly.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/

[jira] [Updated] (CLOUDSTACK-6823) Brocade Network plugin to orchestrate Brocade VDX switches

2014-06-03 Thread Ritu Sabharwal (JIRA)

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

Ritu Sabharwal updated CLOUDSTACK-6823:
---

Description:
This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be configured on the physical switches as well, so that
when a VLAN-tagged packet arrives on a switch-port, the switch know which ports
to flood the packet. When the last VM is destroyed for an isolated Network, the
VLAN Id for the network is disabled from the switches as well. The plugin also
implements the capability to monitor the availability of the switch when it is
configured first time. When the switch is configured it is added to ClousStack
ResourceManager which enables the periodic pinging(monitoring) of the switch.
The Plugin would provide the implementation for getting the switch status. It
would be getting the current configuration.
If there are no VMs running for any of the isolated Networks using the physical
switch, the monitoring capability is disabled for the switch.
The Brocade Network Plugin orchestrates Brocade’s switches directly using
NETCONF. The plugin uses pre-configured properties file to provide the details
of Brocade switches (IP Address, UserName, Password).
In order to find out which switch-ports are connected to the hypervisor hosts,
the plugin uses the properties file to specify the guest-traffic-label to
switch-port mapping.

was:
This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be configured on the physical switches as well, so that
when a VLAN-tagged packet arrives on a switch-port, the switch know which ports
to flood the packet. When the last VM is destroyed for an isolated Network, the
VLAN Id for the network is disabled from the switches as well. The plugin also
enables the periodic monitoring of the switch when it is configured first time.
If there are no VMs running for any of the isolated Networks using the physical
switch, the monitoring is disabled for the switch.
The Brocade Network Plugin orchestrates Brocade’s switches directly using
NETCONF. The plugin uses pre-configured properties file to provide the details
of Brocade switches (IP Address, UserName, Password).
In order to find out which switch-ports are connected to the hypervisor hosts,
the plugin uses the properties file to specify the guest-traffic-label to
switch-port mapping.

Brocade Network plugin to orchestrate Brocade VDX switches
--

This plugin is focused on providing L2 services initially with other services
coming in later. This feature is about a CloudStack network-element plugin to
automatically orchestrate Brocade’s switches to provide tenant isolation via
VLAN. When isolated networks are created from CloudStack and allocated VLAN,
the same VLANs need to be configured on the physical switches as well, so
that when a VLAN-tagged packet arrives on a switch-port, the switch know
which ports to flood the packet. When the last VM is destroyed for an
isolated Network, the VLAN Id for the network is disabled from the switches
as well. The plugin also implements the capability to monitor the
availability of the switch when it is configured first time. When the switch
is configured it is added to ClousStack ResourceManager which enables the
periodic pinging(monitoring) of the switch. The Plugin would provide the
implementation for getting the switch status. It would be getting the current
configuration.
If there are no VMs running for any of the isolated Networks using the
physical switch, the

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread Bob Vanderford (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016919#comment-14016919
 ] 

Bob Vanderford commented on CLOUDSTACK-6464:


Marcus, thanks much for investigating.

Two physical nics, eth0 and eth1.  No VPC.  It is an isolated network using 
vlans.  The OS is CentOS6.5 minimal.

The compute nodes have 2 physical nics.  Eth0 is running the storage and 
management networks, with an untagged vlan and the bridge I named mgmt bridged 
to eth0.  Eth1 is running the guest and public network.  The public bridge I 
named breth1-20 and it runs over vlan 20.  The guest bridge I named cloudbr1 
and the vlans are 100-150.  All these are of course tagged vlans on the compute 
nodes.

If you need more detail let me know.  I can provide the actual network configs 
if needed but they are pretty straightforward and probably what you would 
expect.

It would not surprise me if there are more than one issue among the posts.  If 
mine is difficult to reproduce, I can provide access to the management 
interface for my setup.  I would have to rebuild it though since I am currently 
trying version 4.2, trying to get amysta installed and amysta is requiring 
version 4.2 or else for me to compile in a usage patch for 4.3.  Decided just 
to try 4.2.  But, I am willing, if needed to rebuild the 4.3 setup as I had it, 
give me a few hours for that if needed.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600'

[jira] [Created] (CLOUDSTACK-6838) Add test cases for download url expiration functionality

2014-06-03 Thread Nitin Mehta (JIRA)

Nitin Mehta created CLOUDSTACK-6838:
---

 Summary: Add test cases for download url expiration functionality
 Key: CLOUDSTACK-6838
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6838
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.4.0


Download urls for template/volume should expire after configurable time.
We should add test cases for download url expiration functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor

2014-06-03 Thread Dmitry Komarov (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016925#comment-14016925
 ] 

Dmitry Komarov commented on CLOUDSTACK-5907:


I have the same bug and found a quick and dirty temporary solution. 

Deeper investigation shows the problem appears for those having CEPH RBD 
storage set as Zone-Wide. In this case Pod and Cluster fields of the 
storage_pool table are NULL and API returns incorrect hypervisor values.

As a quick fix you can alter the RBD storage record in the storage_pool table 
and manually set the Pod and Cluster values. Then the system will return 
hypervisor type as set for the Cluster.

This bug is pretty old and annoying, please be so kind to fix it in the 4.4 
release!


 KVM/CLVM volumes are shown as Ovm hypervisor
 

 Key: CLOUDSTACK-5907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, KVM, Oracle VM (OVM), Storage Controller, UI
Affects Versions: 4.2.1, 4.3.0
 Environment: KVM, CLVM
Reporter: Nux
  Labels: clvm, kvm, ovm, storage
 Attachments: storage1.png, storage2.png


 It looks like ACS is showing KVM volumes on CLVM primary storage as being for 
 Oracle hypervisor.
 http://i.imgur.com/E4InCV2.png
 The API shows the same so it's not a UI glitch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-5505) [Automation] Private gateway not getting programmed in VPC router


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016945#comment-14016945
 ] 

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

Commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a in cloudstack's branch 
refs/heads/4.4-forward from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5e80e5d ]

CLOUDSTACK-5505: if vpc public network with snat enabled, then will triger this 
issue


 [Automation] Private gateway not getting programmed in VPC router 
 --

 Key: CLOUDSTACK-5505
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5505
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
 Environment: KVM
 Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.4.0

 Attachments: CLOUDSTACK-5505.rar


 This issue found as part of regression automation 
 integration.component.test_vpc_vms_deployment.TestVMDeployVPC.test_07_delete_network_with_rules
  
 Test cases performing below steps 
 1726 # Validate the following
 1727 # 1. Create a VPC with cidr - 10.1.1.1/16
 1728 # 2. Add network1(10.1.1.1/24) and network2(10.1.2.1/24) to this 
 VPC.
 1729 # 3. Deploy vm1 and vm2 in network1 and vm3 and vm4 in network2.
 1730 # 4. Create a PF /Static Nat/LB rule for vms in network1.
 1731 # 5. Create a PF /Static Nat/LB rule for vms in network2.
 1732 # 6. Create ingress network ACL for allowing all the above rules 
 from
 1733 #public ip range on network1 and network2.
 1734 # 7. Create egress network ACL for network1 and network2 to 
 access
 1735 #google.com.
 1736 # 8. Create a private gateway for this VPC and add a static 
 route to
 1737 #this gateway
 1738 # 9. Create a VPN gateway for this VPC and add a static route to 
 this
 1739 #gateway.
 1740 # 10. Make sure that all the PF,LB, Static NAT rules work as 
 expected
 1741 # 11. Make sure that we are able to access google from all user 
 Vms
 1742 # 12. Make sure that the newly added private gateway's and VPN
 1743 #gateway's static routes work as expected.
 1744 # Steps:
 1745 # 1. Delete the 1st network.
 1746 # 2. Delete account
 1747 # Validations:
 1748 # 1. As part of network deletion all the resources attached with
 1749 #network should get deleted. All other VMs and rules shall 
 work as
 1750 #expected
 1751 # 2. All the resources associated with account should be deleted
 Steps to reproduce 
 Step 1 : Create advanced zone in KVM 
 Step 2 : Create VPC 
 Step 3 : create 2 network inside 
 Step 4 : Create Private Gateway 
 Step 5 : Add static route
 Result 
 Failed to add static route  with error Failed to create static route
 MS log (look lob Job-Executor-102:ctx-12de6228)
 ---
 2013-12-13 15:23:12,952 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-7:ctx-0c9be854) ===START===  10.214.5.33 -- GET  
 command=createStaticRouteresponse=jsonsessionkey=RP7BqoAP0Roa1gkg68z4YhvFAO4%3Dg
 atewayid=528f0ba2-bd3d-4e76-9d45-d567cbd47d67cidr=10.2.3.0%2F24_=1386976993256
 2013-12-13 15:23:12,964 DEBUG [c.c.n.v.VpcManagerImpl] 
 (catalina-exec-7:ctx-0c9be854 ctx-e80dd4b0) Adding static route 
 StaticRoute[7c159911-d38a-4dbf-a98d-708b099c7389|10.2.3.0/24|4]
 2013-12-13 15:23:13,049 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-102:ctx-12de6228) Add job-2928 into job monitoring
 2013-12-13 15:23:13,049 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-102:ctx-12de6228) Executing AsyncJobVO {id:2928, userId: 2, 
 accountId: 2, instanceType: StaticRoute, instanceId: 4, cm
 d: org.apache.cloudstack.api.command.user.vpc.CreateStaticRouteCmd, cmdInfo: 
 {id:4,response:json,sessionkey:RP7BqoAP0Roa1gkg68z4YhvFAO4\u003d,cmdEventType:STATIC.ROUTE.CREATE,ctxU
 serId:2,gatewayid:528f0ba2-bd3d-4e76-9d45-d567cbd47d67,httpmethod:GET,_:1386976993256,ctxAccountId:2,ctxStartEventId:14430,cidr:10.2.3.0/24},
  cmdVersion: 0, status: IN_P
 ROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: null}
 2013-12-13 15:23:13,053 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-7:ctx-0c9be854 ctx-e80dd4b0) submit async job-2928, details: 
 AsyncJobVO {id:2928, userId: 2, accountId: 2, instanceTy
 pe: StaticRoute, instanceId: 4, cmd:

[jira] [Commented] (CLOUDSTACK-6793) [Automation] CreateTagsCmd fails with db exceptions

2014-06-03 Thread Amogh Vasekar (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016968#comment-14016968
 ] 

Amogh Vasekar commented on CLOUDSTACK-6793:
---

Hi,

Seems like a test case issue. The test was not executed previously since a 
related test case was failing. Dont see any change in the codebase, and the 
functionality seems to be working in the UI.
The error here is attempting to insert record for tag for Template reosurce, 
and it is using the default -1 domain ID. 

Thanks!

 [Automation] CreateTagsCmd fails with db exceptions 
 

 Key: CLOUDSTACK-6793
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6793
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
 Environment: KVM 
Reporter: Rayees Namathponnan
Assignee: Amogh Vasekar
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar


 Steps to reproduce 
 Execute the test case integration.component.test_tags.TestResourceTags
 Test case perform below steps 
 # 1. Create a tag on template/ISO using createTags API
 # 2. Delete above created tag using deleteTags API
 2014-05-27 17:41:28,658 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-3b66377c ctx-fdaf9174 ctx-62d4b9d2) ===END===
   10.223.240.193 -- GET  
 apiKey=x3l3u2QJMKK5AzForI9MKkjNWb4V2ewV-UY6qSPZERrS49jXwUFn5WLvN-r_QJZ-z1t-oO1g9F4-EiUZx9Bd
 EQresourcetype=TemplateresourceIds=35e10eef-7980-4085-8b6c-c68174f1b529command=createTagssignature=pIJSk7ekg0Tlf
 RN%2FWfdp8U42Bgs%3Dtags%5B0%5D.key=OSresponse=jsontags%5B0%5D.value=CentOS
 2014-05-27 17:41:28,661 DEBUG [c.c.u.d.T.Transaction] 
 (API-Job-Executor-89:ctx-c924058c job-577 ctx-ec2f3eb8) Rollin
 g back the transaction: Time = 4 Name =  API-Job-Executor-89; called by 
 -TransactionLegacy.rollback:903-TransactionL
 egacy.removeUpTo:846-TransactionLegacy.close:670-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.
 proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:2
 04-$Proxy52.persist:-1-TaggedResourceManagerImpl$1.doInTransactionWithoutResult:245-TransactionCallbackNoReturn.doIn
 Transaction:25-Transaction$2.doInTransaction:49
 2014-05-27 17:41:28,662 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-dbbc3135) ===START===  10.223.240.193 -- GET
  
 jobid=776d2770-db0d-44c8-b2e0-bbe2a9621642apiKey=x3l3u2QJMKK5AzForI9MKkjNWb4V2ewV-UY6qSPZERrS49jXwUFn5WLvN-r_QJZ-z
 1t-oO1g9F4-EiUZx9BdEQcommand=queryAsyncJobResultresponse=jsonsignature=%2Bk9OtkKpdJkU%2BWI7GO48SOrpKf4%3D
 2014-05-27 17:41:28,672 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-89:ctx-c924058c job-577) Unexpected exception while 
 executing org.apache.cloudstack.api.command.user.tag.CreateTagsCmd
 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
 com.mysql.jdbc.JDBC4PreparedStatement@6a7f6c5: INSERT INTO resource_tags 
 (resource_tags.uuid, resource_tags.key, resource_tags.value, 
 resource_tags.domain_id, resource_tags.account_id, resource_tags.resource_id, 
 resource_tags.resource_uuid, resource_tags.resource_type, 
 resource_tags.customer) VALUES 
 (_binary'46408de5-040c-4858-8323-881c358bda20', _binary'OS', _binary'CentOS', 
 -1, 82, 217, _binary'35e10eef-7980-4085-8b6c-c68174f1b529', 'Template', null)
 at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400)
 at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy52.persist(Unknown Source)
 at

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread edison su (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017100#comment-14017100
 ] 

edison su commented on CLOUDSTACK-6464:
---

Back to issue itself: guest network bridge is changed after upgrade to 4.x, if 
guest network is using vlan://untagged.
The root cause is that, in 3.0.x, if guest network is vlan://untagged, then 
kvm agent will use whatever value in private.network.device, while in 4.x, 
kvm agent will use guest.network.device. So if both value are not the same in 
the agent.properties, then kvm agent will use incorrect bridge to create vif.

The fix will be, kvm agent code needs to honor traffic type passed down from 
mgt server in startcommand, in case of vlan://untagged.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci'

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017109#comment-14017109
 ] 

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

Commit 15385948dcdf4c69136e99bf3c602f95fd018f39 in cloudstack's branch 
refs/heads/4.3-forward from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1538594 ]

CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is 
used, kvm agent needs to honor traffic label


 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017116#comment-14017116
 ] 

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

Commit dfb59cd6cc0292a88cb619e53f34cdb713879ffd in cloudstack's branch 
refs/heads/4.4-forward from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dfb59cd ]

CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is 
used, kvm agent needs to honor traffic label


 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread Bob Vanderford (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017137#comment-14017137
 ] 

Bob Vanderford commented on CLOUDSTACK-6464:


Marcus,  I just saw your last post to me, I had posted a response before I saw 
your last response.  I can definitely put in a new bug report, but at this 
point I think I'll wait until I see the final outcome on this one.  If I still 
see a problem after the air clears here, then, I put in the new bug report.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel type='none'/
 /domain
 its also

[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used

2014-06-03 Thread edison su (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017150#comment-14017150
 ] 

edison su commented on CLOUDSTACK-6464:
---

Bob, better create new bug for the issue you have, with both mgt server and 
agent log(with debug level turned on). I think I already fixed the original 
issue.

 [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are 
 plugged to default bridge even though trafiic labels are being used
 --

 Key: CLOUDSTACK-6464
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Priority: Critical
 Fix For: 4.4.0


  Steps:
 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
 2.use cloudbr0 for management and cloudbr1 for guest by specifying the 
 traffic labels in the physical networks.
 3.deploy few vms
 4.upgrade to felton GA build as per the Upgrade instructions.
 actual result:
 Upgrade successful but all the vnets that were attached to cloudbr1 before 
 upgrade are attached to cloudbr0.
 Due to this network connectivity is lost.
 Expected result:
 Even after upgrade ,all the vnets should be attached to the same bridge as 
 before upgrade.
 ex:
 before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after 
 upgrade and VM stop/start.
 the network rules are getting programmed in cloudbr0 .check below output
 ,984 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) Executing: 
 /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
 default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 
 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0:
 dumpxml output for i-5-616-VM after upgrade( after VM restart)
 *
 virsh # dumpxml 38
 domain type='kvm' id='38'
 namei-5-616-VM/name
 uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid
 descriptionOther CentOS (64-bit)/description
 memory unit='KiB'2097152/memory
 currentMemory unit='KiB'2097152/currentMemory
 vcpu placement='static'1/vcpu
 cputune
 shares1000/shares
 /cputune
 os
 type arch='x86_64' machine='rhel6.2.0'hvm/type
 boot dev='cdrom'/
 boot dev='hd'/
 /os
 features
 acpi/
 apic/
 pae/
 /features
 cpu
 /cpu
 clock offset='utc'/
 on_poweroffdestroy/on_poweroff
 on_rebootrestart/on_reboot
 on_crashdestroy/on_crash
 devices
 emulator/usr/libexec/qemu-kvm/emulator
 disk type='file' device='disk'
 driver name='qemu' type='qcow2' cache='none'/
 source 
 file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/
 target dev='hda' bus='ide'/
 alias name='ide0-0-0'/
 address type='drive' controller='0' bus='0' target='0' unit='0'/
 /disk
 disk type='file' device='cdrom'
 driver name='qemu' type='raw' cache='none'/
 target dev='hdc' bus='ide'/
 readonly/
 alias name='ide0-1-0'/
 address type='drive' controller='0' bus='1' target='0' unit='0'/
 /disk
 controller type='usb' index='0'
 alias name='usb0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/
 /controller
 controller type='ide' index='0'
 alias name='ide0'/
 address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/
 /controller
 interface type='bridge'
 mac address='06:14:48:00:00:7f'/
 source bridge='cloudbr0'/
 target dev='vnet15'/
 model type='e1000'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 alias name='net0'/
 address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
 /interface
 serial type='pty'
 source path='/dev/pts/12'/
 target port='0'/
 alias name='serial0'/
 /serial
 console type='pty' tty='/dev/pts/12'
 source path='/dev/pts/12'/
 target type='serial' port='0'/
 alias name='serial0'/
 /console
 input type='tablet' bus='usb'
 alias name='input0'/
 /input
 input type='mouse' bus='ps2'/
 graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'
 listen type='address' address='10.147.37.3'/
 /graphics
 video
 model type='cirrus' vram='9216' heads='1'/
 alias name='video0'/
 address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/
 /video
 memballoon model='virtio'
 alias name='balloon0'/
 address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/
 /memballoon
 /devices
 seclabel type='none'/
 /domain
 its also applicable to new vm deployments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6793) [Automation] CreateTagsCmd fails with db exceptions

2014-06-03 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar updated CLOUDSTACK-6793:
--

Issue Type: Test  (was: Bug)

 [Automation] CreateTagsCmd fails with db exceptions 
 

 Key: CLOUDSTACK-6793
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6793
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
 Environment: KVM 
Reporter: Rayees Namathponnan
Assignee: Amogh Vasekar
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar


 Steps to reproduce 
 Execute the test case integration.component.test_tags.TestResourceTags
 Test case perform below steps 
 # 1. Create a tag on template/ISO using createTags API
 # 2. Delete above created tag using deleteTags API
 2014-05-27 17:41:28,658 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-3b66377c ctx-fdaf9174 ctx-62d4b9d2) ===END===
   10.223.240.193 -- GET  
 apiKey=x3l3u2QJMKK5AzForI9MKkjNWb4V2ewV-UY6qSPZERrS49jXwUFn5WLvN-r_QJZ-z1t-oO1g9F4-EiUZx9Bd
 EQresourcetype=TemplateresourceIds=35e10eef-7980-4085-8b6c-c68174f1b529command=createTagssignature=pIJSk7ekg0Tlf
 RN%2FWfdp8U42Bgs%3Dtags%5B0%5D.key=OSresponse=jsontags%5B0%5D.value=CentOS
 2014-05-27 17:41:28,661 DEBUG [c.c.u.d.T.Transaction] 
 (API-Job-Executor-89:ctx-c924058c job-577 ctx-ec2f3eb8) Rollin
 g back the transaction: Time = 4 Name =  API-Job-Executor-89; called by 
 -TransactionLegacy.rollback:903-TransactionL
 egacy.removeUpTo:846-TransactionLegacy.close:670-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.
 proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:2
 04-$Proxy52.persist:-1-TaggedResourceManagerImpl$1.doInTransactionWithoutResult:245-TransactionCallbackNoReturn.doIn
 Transaction:25-Transaction$2.doInTransaction:49
 2014-05-27 17:41:28,662 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-dbbc3135) ===START===  10.223.240.193 -- GET
  
 jobid=776d2770-db0d-44c8-b2e0-bbe2a9621642apiKey=x3l3u2QJMKK5AzForI9MKkjNWb4V2ewV-UY6qSPZERrS49jXwUFn5WLvN-r_QJZ-z
 1t-oO1g9F4-EiUZx9BdEQcommand=queryAsyncJobResultresponse=jsonsignature=%2Bk9OtkKpdJkU%2BWI7GO48SOrpKf4%3D
 2014-05-27 17:41:28,672 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-89:ctx-c924058c job-577) Unexpected exception while 
 executing org.apache.cloudstack.api.command.user.tag.CreateTagsCmd
 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
 com.mysql.jdbc.JDBC4PreparedStatement@6a7f6c5: INSERT INTO resource_tags 
 (resource_tags.uuid, resource_tags.key, resource_tags.value, 
 resource_tags.domain_id, resource_tags.account_id, resource_tags.resource_id, 
 resource_tags.resource_uuid, resource_tags.resource_type, 
 resource_tags.customer) VALUES 
 (_binary'46408de5-040c-4858-8323-881c358bda20', _binary'OS', _binary'CentOS', 
 -1, 82, 217, _binary'35e10eef-7980-4085-8b6c-c68174f1b529', 'Template', null)
 at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400)
 at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy52.persist(Unknown Source)
 at 
 com.cloud.tags.TaggedResourceManagerImpl$1.doInTransactionWithoutResult(TaggedResourceManagerImpl.java:245)
 at 
 com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
 at 
 com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
 at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
 at

[jira] [Resolved] (CLOUDSTACK-6322) Contrail: Params validation is missing while launching a service instance thru cloudmonkey

2014-06-03 Thread Sachchidanand Vaidya (JIRA)


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

Sachchidanand Vaidya resolved CLOUDSTACK-6322.
--

   Resolution: Fixed
Fix Version/s: 4.4.0

issue fixed and checked in.

 Contrail: Params validation is missing while launching a service instance 
 thru cloudmonkey
 --

 Key: CLOUDSTACK-6322
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6322
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Contrail
Affects Versions: 4.3.0
Reporter: Senthilnathan Murugappan
Assignee: Sachchidanand Vaidya
 Fix For: 4.4.0


 cloudstack management server needs to validate params of create 
 serviceinstance.
 Currently it doesnt check and allow service instances to be created without 
 mandatory fields and which will fail to launch the vm but the api server will 
 still hold the data.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6834) [Windows] Feedback Items

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

Damodar Reddy T updated CLOUDSTACK-6834:

Description:
The feed back items received internally.

1. Need to add more fields to the database creation wizard
2. Remove Complete Option
3. Some description changes words like CloudStack etc
4. Change Default installation location if possible include version number
5. Mysql Connector Installer along with other dependecies
6. Add run Service Checkbox
7. Add ReadMe checkbox
8. If possible enable logs for Custom Actions that are executed as part of
installation

was:
The feed back items received internally.

[Windows] Feedback Items

Key: CLOUDSTACK-6834
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6834
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: Future
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
Fix For: 4.5.0

The feed back items received internally.
1. Need to add more fields to the database creation wizard
2. Remove Complete Option
3. Some description changes words like CloudStack etc
4. Change Default installation location if possible include version number
5. Mysql Connector Installer along with other dependecies
6. Add run Service Checkbox
7. Add ReadMe checkbox
8. If possible enable logs for Custom Actions that are executed as part of
installation

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6839) [Windows] MSI Installer Wizard modifications(Including logos text etc..)

Damodar Reddy T created CLOUDSTACK-6839:
---

 Summary: [Windows] MSI Installer Wizard modifications(Including 
logos text etc..)
 Key: CLOUDSTACK-6839
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6839
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: Future, 4.5.0
Reporter: Damodar Reddy T
Assignee: Stephen Turner
 Fix For: 4.5.0


The attached snapshot contains the steps involved in installation process of 
cloudstack on management server. It has several steps and each step has it's 
own wizard.

We need to change the logo and the look and feel of each wizard based on ACS 
standards.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6839) [Windows] MSI Installer Wizard modifications(Including logos text etc..)


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

Damodar Reddy T updated CLOUDSTACK-6839:


Attachment: windows_installer.jpg

If we click on options button on the first wizard it will lead to the 2nd 
wizard in the screen shot.

If we click on Install on the 1st wizard it will lead to the 3rd wizard in 
the screen shot.

Reamaining wizards will come in the flow while installing apache cloudstack.

 [Windows] MSI Installer Wizard modifications(Including logos text etc..)
 

 Key: CLOUDSTACK-6839
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6839
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: Future, 4.5.0
Reporter: Damodar Reddy T
Assignee: Stephen Turner
 Fix For: 4.5.0

 Attachments: windows_installer.jpg


 The attached snapshot contains the steps involved in installation process of 
 cloudstack on management server. It has several steps and each step has it's 
 own wizard.
 We need to change the logo and the look and feel of each wizard based on ACS 
 standards.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CLOUDSTACK-6839) [Windows] MSI Installer Wizard modifications(Including logos text etc..)