date:20140612

Abhinav Roy created CLOUDSTACK-6897:
---

 Summary: [Hyper-V] In a Multi cluster setup attach of a uploaded 
volume to a VM on zwps is failing with scope conflict
 Key: CLOUDSTACK-6897
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6897
 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: Hyper-V multi-cluster setup, having cluster wide storage, 
local storage and zone wide storage.
Reporter: Abhinav Roy
Priority: Critical
 Fix For: 4.4.0


Steps :
=
1. Deploy a hyperv advanced zone setup with 2 clusters , c1 and c2
2. In C1 have 2 hosts h1  h2 and 2 cluster wide primary storages p1  p2
in C2 have 1 host h3 and 2 cluster wide primary storage p2  p4
Also, have 2 zone wide primary stoarages, z1  z2
3. Deploy a VM v1 on host h3 with volumes on z1.
4. Upload a volume upload1
5. Attach upload1 to v1


Expected behavior :
===
The attach should be successful.

Observed behavior :
==
The attach fails with the following error :

2014-06-12 11:39:10,974 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-15:ctx-c4877d18) ===START===  10.144.6.9 -- GET  
command=attachVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75cvirtualMachineId=69781acf-f85e-4499-8d52-ccf768ac41e4response=jsonsessionkey=cSJpXdHESvwd9ahj2OVVUqECfOw%3D_=1402553090360
2014-06-12 11:39:11,031 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-15:ctx-c4877d18 ctx-86f37de4) submit async job-217, details: 
AsyncJobVO {id:217, userId: 2, accountId: 2, instanceType: Volume, instanceId: 
18, cmd: org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
cmdInfo: 
{id:7282784d-75bf-46a4-b6a5-33fae5cda75c,response:json,sessionkey:cSJpXdHESvwd9ahj2OVVUqECfOw\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.vm.VirtualMachine\:15},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:69781acf-f85e-4499-8d52-ccf768ac41e4,httpmethod:GET,_:1402553090360,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:360},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-12 11:39:11,032 DEBUG [c.c.a.ApiServlet] (catalina-exec-15:ctx-c4877d18 
ctx-86f37de4) ===END===  10.144.6.9 -- GET  
command=attachVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75cvirtualMachineId=69781acf-f85e-4499-8d52-ccf768ac41e4response=jsonsessionkey=cSJpXdHESvwd9ahj2OVVUqECfOw%3D_=1402553090360
2014-06-12 11:39:11,034 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217) Add job-217 into job monitoring
2014-06-12 11:39:11,034 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217) Executing AsyncJobVO {id:217, userId: 
2, accountId: 2, instanceType: Volume, instanceId: 18, cmd: 
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, cmdInfo: 
{id:7282784d-75bf-46a4-b6a5-33fae5cda75c,response:json,sessionkey:cSJpXdHESvwd9ahj2OVVUqECfOw\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.vm.VirtualMachine\:15},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:69781acf-f85e-4499-8d52-ccf768ac41e4,httpmethod:GET,_:1402553090360,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:360},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-12 11:39:11,045 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Received unknown 
parameters for command attachVolume. Unknown parameters : ctxdetails
2014-06-12 11:39:11,059 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Sync job-218 execution 
on object VmWorkJobQueue.15
2014-06-12 11:39:11,062 DEBUG [c.c.s.VolumeApiServiceImpl] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) New job 218, result 
field: null
2014-06-12 11:39:11,062 WARN  [c.c.u.d.Merovingian2] 
(API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Was unable to find lock 
for the key vm_instance15 and thread id 124496084
2014-06-12 11:39:12,123 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-e35af8d6) Execute sync-queue item: SyncQueueItemVO 
{id:87, queueId: 86, contentType: AsyncJob, contentId: 218, lastProcessMsid: 
null, lastprocessNumber: null, lastProcessTime: null, created: Thu Jun 12 
11:39:11 IST 2014}
2014-06-12 11:39:12,125 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]

[jira] [Assigned] (CLOUDSTACK-6868) [Hyper-V] Download of an uploaded volume is failing


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

Anshul Gangwar reassigned CLOUDSTACK-6868:
--

Assignee: Anshul Gangwar

 [Hyper-V] Download of an uploaded volume is failing
 ---

 Key: CLOUDSTACK-6868
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6868
 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: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0


 Steps:
 =
 1. Deploy an advanced zone Hyper-V setup.
 2. Create a VM v1
 3. Upload a volume upload1
 4. Download upload1
 Expected behavior :
 =
 Download should pass.
 Observed behavior :
 =
 Download fails with 
 2014-06-09 14:06:16,740 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-13:ctx-2b2fe04f) ===START===  10.144.7.13 -- GET  
 command=extractVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75czoneid=622e7c06-e62e-4a6b-8de6-a462a3ee7cf7mode=HTTP_DOWNLOADresponse=jsonsessionkey=RGKWL0km%2FibmrEZH39fWJsmJeeU%3D_=1402302332046
 2014-06-09 14:06:16,783 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-13:ctx-2b2fe04f ctx-676b8816) submit async job-113, details: 
 AsyncJobVO {id:113, userId: 2, accountId: 2, instanceType: Volume, 
 instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo: 
 {response:json,id:7282784d-75bf-46a4-b6a5-33fae5cda75c,sessionkey:RGKWL0km/ibmrEZH39fWJsmJeeU\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.dc.DataCenter\:1},cmdEventType:VOLUME.EXTRACT,ctxUserId:2,zoneid:622e7c06-e62e-4a6b-8de6-a462a3ee7cf7,httpmethod:GET,_:1402302332046,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:197,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 14:06:16,783 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-13:ctx-2b2fe04f ctx-676b8816) ===END===  10.144.7.13 -- GET  
 command=extractVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75czoneid=622e7c06-e62e-4a6b-8de6-a462a3ee7cf7mode=HTTP_DOWNLOADresponse=jsonsessionkey=RGKWL0km%2FibmrEZH39fWJsmJeeU%3D_=1402302332046
 2014-06-09 14:06:16,785 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-28:ctx-774021c1 job-113) Add job-113 into job monitoring
 2014-06-09 14:06:16,786 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-28:ctx-774021c1 job-113) Executing AsyncJobVO {id:113, 
 userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo: 
 {response:json,id:7282784d-75bf-46a4-b6a5-33fae5cda75c,sessionkey:RGKWL0km/ibmrEZH39fWJsmJeeU\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.dc.DataCenter\:1},cmdEventType:VOLUME.EXTRACT,ctxUserId:2,zoneid:622e7c06-e62e-4a6b-8de6-a462a3ee7cf7,httpmethod:GET,_:1402302332046,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:197,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 14:06:16,795 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) Received unknown 
 parameters for command extractVolume. Unknown parameters : ctxdetails
 2014-06-09 14:06:16,833 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) copyAsync inspecting 
 src type VOLUME copyAsync inspecting dest type VOLUME
 2014-06-09 14:06:16,850 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) Seq 
 1-9177491615650939381: Sending  { Cmd , MgmtId: 213737702773493, via: 
 1(10.102.244.20), Ver: v1, Flags: 100011,

[jira] [Updated] (CLOUDSTACK-6868) [Hyper-V] Download of an uploaded volume is failing


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

Anshul Gangwar updated CLOUDSTACK-6868:
---

Status: Reviewable  (was: In Progress)

 [Hyper-V] Download of an uploaded volume is failing
 ---

 Key: CLOUDSTACK-6868
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6868
 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: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0


 Steps:
 =
 1. Deploy an advanced zone Hyper-V setup.
 2. Create a VM v1
 3. Upload a volume upload1
 4. Download upload1
 Expected behavior :
 =
 Download should pass.
 Observed behavior :
 =
 Download fails with 
 2014-06-09 14:06:16,740 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-13:ctx-2b2fe04f) ===START===  10.144.7.13 -- GET  
 command=extractVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75czoneid=622e7c06-e62e-4a6b-8de6-a462a3ee7cf7mode=HTTP_DOWNLOADresponse=jsonsessionkey=RGKWL0km%2FibmrEZH39fWJsmJeeU%3D_=1402302332046
 2014-06-09 14:06:16,783 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-13:ctx-2b2fe04f ctx-676b8816) submit async job-113, details: 
 AsyncJobVO {id:113, userId: 2, accountId: 2, instanceType: Volume, 
 instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo: 
 {response:json,id:7282784d-75bf-46a4-b6a5-33fae5cda75c,sessionkey:RGKWL0km/ibmrEZH39fWJsmJeeU\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.dc.DataCenter\:1},cmdEventType:VOLUME.EXTRACT,ctxUserId:2,zoneid:622e7c06-e62e-4a6b-8de6-a462a3ee7cf7,httpmethod:GET,_:1402302332046,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:197,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 14:06:16,783 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-13:ctx-2b2fe04f ctx-676b8816) ===END===  10.144.7.13 -- GET  
 command=extractVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75czoneid=622e7c06-e62e-4a6b-8de6-a462a3ee7cf7mode=HTTP_DOWNLOADresponse=jsonsessionkey=RGKWL0km%2FibmrEZH39fWJsmJeeU%3D_=1402302332046
 2014-06-09 14:06:16,785 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-28:ctx-774021c1 job-113) Add job-113 into job monitoring
 2014-06-09 14:06:16,786 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-28:ctx-774021c1 job-113) Executing AsyncJobVO {id:113, 
 userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo: 
 {response:json,id:7282784d-75bf-46a4-b6a5-33fae5cda75c,sessionkey:RGKWL0km/ibmrEZH39fWJsmJeeU\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.dc.DataCenter\:1},cmdEventType:VOLUME.EXTRACT,ctxUserId:2,zoneid:622e7c06-e62e-4a6b-8de6-a462a3ee7cf7,httpmethod:GET,_:1402302332046,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:197,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 14:06:16,795 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) Received unknown 
 parameters for command extractVolume. Unknown parameters : ctxdetails
 2014-06-09 14:06:16,833 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) copyAsync inspecting 
 src type VOLUME copyAsync inspecting dest type VOLUME
 2014-06-09 14:06:16,850 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-28:ctx-774021c1 job-113 ctx-351bc29f) Seq 
 1-9177491615650939381: Sending  { Cmd , MgmtId: 213737702773493, via: 
 1(10.102.244.20), Ver: v1, Flags: 100011,

[jira] [Assigned] (CLOUDSTACK-6865) [Hyper-V]attach of an uploaded volume is failing as it is looking for a .vhdx volume even though the volume present is .vhd


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

Anshul Gangwar reassigned CLOUDSTACK-6865:
--

Assignee: Anshul Gangwar

 [Hyper-V]attach of an  uploaded volume is failing as it is looking for a 
 .vhdx volume even though the volume present is .vhd
 

 Key: CLOUDSTACK-6865
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6865
 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: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0

 Attachments: management-server-6865.zip


 Steps :
 ==
 1. Deploy an advanced zone Hyper-V setup.
 2. Create a VM v1
 3. Upload a volume upload1
 4. Attach upload1 to v1
 Expected Behavior :
 ==
 Attach should be successful.
 Observed behavior :
 ==
 Attach fails with the following error :
 2014-06-09 11:32:47,684 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-02af10fb) ===START===  10.144.7.13 -- GET  
 command=attachVolumeid=ddcaf328-0e71-462b-9ce6-e520dc8f15ccvirtualMachineId=ea78d7ec-6fed-4c3e-bff1-29219c70bdddresponse=jsonsessionkey=4MQxLlvkRgcp%2FMBl6tf6TodmICI%3D_=1402293458440
 2014-06-09 11:32:47,726 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-8:ctx-02af10fb ctx-dce1c925) submit async job-66, details: 
 AsyncJobVO {id:66, userId: 2, accountId: 2, instanceType: Volume, instanceId: 
 7, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {response:json,id:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,sessionkey:4MQxLlvkRgcp/MBl6tf6TodmICI\u003d,ctxDetails:{\com.cloud.storage.Volume\:7,\Volume\:\ddcaf328-0e71-462b-9ce6-e520dc8f15cc\,\com.cloud.vm.VirtualMachine\:5},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:ea78d7ec-6fed-4c3e-bff1-29219c70bddd,httpmethod:GET,_:1402293458440,uuid:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 11:32:47,727 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-02af10fb ctx-dce1c925) ===END===  10.144.7.13 -- GET  
 command=attachVolumeid=ddcaf328-0e71-462b-9ce6-e520dc8f15ccvirtualMachineId=ea78d7ec-6fed-4c3e-bff1-29219c70bdddresponse=jsonsessionkey=4MQxLlvkRgcp%2FMBl6tf6TodmICI%3D_=1402293458440
 2014-06-09 11:32:47,729 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66) Add job-66 into job monitoring
 2014-06-09 11:32:47,734 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66) Executing AsyncJobVO {id:66, 
 userId: 2, accountId: 2, instanceType: Volume, instanceId: 7, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {response:json,id:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,sessionkey:4MQxLlvkRgcp/MBl6tf6TodmICI\u003d,ctxDetails:{\com.cloud.storage.Volume\:7,\Volume\:\ddcaf328-0e71-462b-9ce6-e520dc8f15cc\,\com.cloud.vm.VirtualMachine\:5},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:ea78d7ec-6fed-4c3e-bff1-29219c70bddd,httpmethod:GET,_:1402293458440,uuid:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 11:32:47,744 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Received unknown 
 parameters for command attachVolume. Unknown parameters : ctxdetails
 2014-06-09 11:32:47,769 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Sync job-67 execution 
 on object VmWorkJobQueue.5
 2014-06-09 11:32:47,772 DEBUG [c.c.s.VolumeApiServiceImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) New job 67, result 
 field: null
 2014-06-09 11:32:47,773 WARN  [c.c.u.d.Merovingian2] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Was unable to find 
 lock for the key vm_instance5 and thread id 1700504230
 2014-06-09 11:32:49,461 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-04e089b1) Execute sync-queue item: 
 SyncQueueItemVO {id:24, queueId: 4, contentType: AsyncJob, contentId: 67, 
 lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,

[jira] [Updated] (CLOUDSTACK-6865) [Hyper-V]attach of an uploaded volume is failing as it is looking for a .vhdx volume even though the volume present is .vhd


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

Anshul Gangwar updated CLOUDSTACK-6865:
---

Status: Reviewable  (was: In Progress)

 [Hyper-V]attach of an  uploaded volume is failing as it is looking for a 
 .vhdx volume even though the volume present is .vhd
 

 Key: CLOUDSTACK-6865
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6865
 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: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0

 Attachments: management-server-6865.zip


 Steps :
 ==
 1. Deploy an advanced zone Hyper-V setup.
 2. Create a VM v1
 3. Upload a volume upload1
 4. Attach upload1 to v1
 Expected Behavior :
 ==
 Attach should be successful.
 Observed behavior :
 ==
 Attach fails with the following error :
 2014-06-09 11:32:47,684 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-02af10fb) ===START===  10.144.7.13 -- GET  
 command=attachVolumeid=ddcaf328-0e71-462b-9ce6-e520dc8f15ccvirtualMachineId=ea78d7ec-6fed-4c3e-bff1-29219c70bdddresponse=jsonsessionkey=4MQxLlvkRgcp%2FMBl6tf6TodmICI%3D_=1402293458440
 2014-06-09 11:32:47,726 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-8:ctx-02af10fb ctx-dce1c925) submit async job-66, details: 
 AsyncJobVO {id:66, userId: 2, accountId: 2, instanceType: Volume, instanceId: 
 7, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {response:json,id:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,sessionkey:4MQxLlvkRgcp/MBl6tf6TodmICI\u003d,ctxDetails:{\com.cloud.storage.Volume\:7,\Volume\:\ddcaf328-0e71-462b-9ce6-e520dc8f15cc\,\com.cloud.vm.VirtualMachine\:5},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:ea78d7ec-6fed-4c3e-bff1-29219c70bddd,httpmethod:GET,_:1402293458440,uuid:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 11:32:47,727 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-02af10fb ctx-dce1c925) ===END===  10.144.7.13 -- GET  
 command=attachVolumeid=ddcaf328-0e71-462b-9ce6-e520dc8f15ccvirtualMachineId=ea78d7ec-6fed-4c3e-bff1-29219c70bdddresponse=jsonsessionkey=4MQxLlvkRgcp%2FMBl6tf6TodmICI%3D_=1402293458440
 2014-06-09 11:32:47,729 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66) Add job-66 into job monitoring
 2014-06-09 11:32:47,734 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66) Executing AsyncJobVO {id:66, 
 userId: 2, accountId: 2, instanceType: Volume, instanceId: 7, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {response:json,id:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,sessionkey:4MQxLlvkRgcp/MBl6tf6TodmICI\u003d,ctxDetails:{\com.cloud.storage.Volume\:7,\Volume\:\ddcaf328-0e71-462b-9ce6-e520dc8f15cc\,\com.cloud.vm.VirtualMachine\:5},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:ea78d7ec-6fed-4c3e-bff1-29219c70bddd,httpmethod:GET,_:1402293458440,uuid:ddcaf328-0e71-462b-9ce6-e520dc8f15cc,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 11:32:47,744 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Received unknown 
 parameters for command attachVolume. Unknown parameters : ctxdetails
 2014-06-09 11:32:47,769 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Sync job-67 execution 
 on object VmWorkJobQueue.5
 2014-06-09 11:32:47,772 DEBUG [c.c.s.VolumeApiServiceImpl] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) New job 67, result 
 field: null
 2014-06-09 11:32:47,773 WARN  [c.c.u.d.Merovingian2] 
 (API-Job-Executor-24:ctx-976a0ed5 job-66 ctx-1d0f4aec) Was unable to find 
 lock for the key vm_instance5 and thread id 1700504230
 2014-06-09 11:32:49,461 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-04e089b1) Execute sync-queue item: 
 SyncQueueItemVO {id:24, queueId: 4, contentType: AsyncJob, contentId: 67, 
 lastProcessMsid: null, lastprocessNumber: null,

[jira] [Assigned] (CLOUDSTACK-6897) [Hyper-V] In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict


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

Anshul Gangwar reassigned CLOUDSTACK-6897:
--

Assignee: Anshul Gangwar

 [Hyper-V] In a Multi cluster setup attach of a uploaded volume to a VM on 
 zwps is failing with scope conflict
 -

 Key: CLOUDSTACK-6897
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6897
 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: Hyper-V multi-cluster setup, having cluster wide 
 storage, local storage and zone wide storage.
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0


 Steps :
 =
 1. Deploy a hyperv advanced zone setup with 2 clusters , c1 and c2
 2. In C1 have 2 hosts h1  h2 and 2 cluster wide primary storages p1  p2
 in C2 have 1 host h3 and 2 cluster wide primary storage p2  p4
 Also, have 2 zone wide primary stoarages, z1  z2
 3. Deploy a VM v1 on host h3 with volumes on z1.
 4. Upload a volume upload1
 5. Attach upload1 to v1
 Expected behavior :
 ===
 The attach should be successful.
 Observed behavior :
 ==
 The attach fails with the following error :
 2014-06-12 11:39:10,974 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-15:ctx-c4877d18) ===START===  10.144.6.9 -- GET  
 command=attachVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75cvirtualMachineId=69781acf-f85e-4499-8d52-ccf768ac41e4response=jsonsessionkey=cSJpXdHESvwd9ahj2OVVUqECfOw%3D_=1402553090360
 2014-06-12 11:39:11,031 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-15:ctx-c4877d18 ctx-86f37de4) submit async job-217, details: 
 AsyncJobVO {id:217, userId: 2, accountId: 2, instanceType: Volume, 
 instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {id:7282784d-75bf-46a4-b6a5-33fae5cda75c,response:json,sessionkey:cSJpXdHESvwd9ahj2OVVUqECfOw\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.vm.VirtualMachine\:15},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:69781acf-f85e-4499-8d52-ccf768ac41e4,httpmethod:GET,_:1402553090360,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:360},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-12 11:39:11,032 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-15:ctx-c4877d18 ctx-86f37de4) ===END===  10.144.6.9 -- GET  
 command=attachVolumeid=7282784d-75bf-46a4-b6a5-33fae5cda75cvirtualMachineId=69781acf-f85e-4499-8d52-ccf768ac41e4response=jsonsessionkey=cSJpXdHESvwd9ahj2OVVUqECfOw%3D_=1402553090360
 2014-06-12 11:39:11,034 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217) Add job-217 into job monitoring
 2014-06-12 11:39:11,034 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217) Executing AsyncJobVO {id:217, 
 userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd: 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin, 
 cmdInfo: 
 {id:7282784d-75bf-46a4-b6a5-33fae5cda75c,response:json,sessionkey:cSJpXdHESvwd9ahj2OVVUqECfOw\u003d,ctxDetails:{\com.cloud.storage.Volume\:18,\Volume\:\7282784d-75bf-46a4-b6a5-33fae5cda75c\,\com.cloud.vm.VirtualMachine\:15},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:69781acf-f85e-4499-8d52-ccf768ac41e4,httpmethod:GET,_:1402553090360,uuid:7282784d-75bf-46a4-b6a5-33fae5cda75c,ctxAccountId:2,ctxStartEventId:360},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-12 11:39:11,045 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Received unknown 
 parameters for command attachVolume. Unknown parameters : ctxdetails
 2014-06-12 11:39:11,059 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Sync job-218 execution 
 on object VmWorkJobQueue.15
 2014-06-12 11:39:11,062 DEBUG [c.c.s.VolumeApiServiceImpl] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) New job 218, result 
 field: null
 2014-06-12 11:39:11,062 WARN  [c.c.u.d.Merovingian2] 
 (API-Job-Executor-2:ctx-f62aa4c4 job-217 ctx-39e46132) Was unable to find 
 lock for the key vm_instance15 and thread id 124496084

[jira] [Updated] (CLOUDSTACK-6867) [Hyper-V][UI] No option to upload a volume with .vhdx format


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

Anshul Gangwar updated CLOUDSTACK-6867:
---

Status: Reviewable  (was: In Progress)

 [Hyper-V][UI] No option to upload a volume with .vhdx format
 

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

 Attachments: CS-6867.jpg


 Steps :
 ===
 1. Deploy a advanced zone hyperv setup.
 2. Try to upload a volume with .vhdx format
  There is no option in the UI to upload .vhdx format volumes, only vhd is 
 there
 3. Try to upload the .vhdx volume by selecting the format as .vhd 
  Then we get this error 
  2014-06-09 13:23:28,381 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-9:ctx-c149c622 job-84) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin
 com.cloud.exception.InvalidParameterValueException: Please specify a valid 
 URL. URL:http://10.144.7.13/upload-data.vhdx is an invalid for the format vhd
 at 
 com.cloud.storage.VolumeApiServiceImpl.validateVolume(VolumeApiServiceImpl.java:314)
 at 
 com.cloud.storage.VolumeApiServiceImpl.uploadVolume(VolumeApiServiceImpl.java:252)
 at 
 com.cloud.storage.VolumeApiServiceImpl.uploadVolume(VolumeApiServiceImpl.java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy181.uploadVolume(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin.execute(UploadVolumeCmdByAdmin.java:46)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at

[jira] [Assigned] (CLOUDSTACK-6872) [Hyper-V]Create template T1 from a volume, then deploy V1 from T1, now try to create a template T2 from V1's root volume. It is failing


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

Anshul Gangwar reassigned CLOUDSTACK-6872:
--

Assignee: Anshul Gangwar

 [Hyper-V]Create template T1 from a volume, then  deploy V1 from T1, now try 
 to create a template T2 from V1's root volume. It is failing
 

 Key: CLOUDSTACK-6872
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6872
 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: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0

 Attachments: CS-6872.zip


 Steps :
 
 1. Deploy Hyper-V advanced zone setup.
 2. Create a VM v1 from default centos template.
 3. Stop v1 and create template T1 from v1's root volume.
 4. create a VM v2 from T1.
 5. Stop v2 and create template T2 from v2's root volume.
 Expected Behavior :
 
 All the above steps should have succeeded.
 Observed Behavior :
 
 Step 5 is failing with the following error :
 2014-06-09 15:40:09,269 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-43436526) ===START===  10.144.7.13 -- GET  
 command=createTemplateresponse=jsonsessionkey=fGX4uIHoj2mx%2BzfKOA579EC%2FQjM%3DvolumeId=d33b806d-8c96-4aff-8e3f-2efa78083a7fname=tempfromvol-root12displayText=tempfromvol-root12osTypeId=a000795a-ebce-11e3-b00a-c264afd952f5isPublic=truepasswordEnabled=falseisdynamicallyscalable=falseisfeatured=true_=1402308159938
 2014-06-09 15:40:09,296 DEBUG [c.c.t.TemplateManagerImpl] 
 (catalina-exec-4:ctx-43436526 ctx-b0e507ef) This template is getting created 
 from other template, setting source template Id to: 202
 2014-06-09 15:40:09,367 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-4:ctx-43436526 ctx-b0e507ef) submit async job-122, details: 
 AsyncJobVO {id:122, userId: 2, accountId: 2, instanceType: Template, 
 instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin, 
 cmdInfo: 
 {sessionkey:fGX4uIHoj2mx+zfKOA579EC/QjM\u003d,cmdEventType:TEMPLATE.CREATE,ctxUserId:2,volumeId:d33b806d-8c96-4aff-8e3f-2efa78083a7f,httpmethod:GET,osTypeId:a000795a-ebce-11e3-b00a-c264afd952f5,isPublic:true,isfeatured:true,id:203,isdynamicallyscalable:false,response:json,ctxDetails:{\com.cloud.template.VirtualMachineTemplate\:203,\com.cloud.storage.Volume\:24,\VirtualMachineTemplate\:\77913d8e-99f9-43f9-9dd2-a498ebe37d75\,\com.cloud.storage.GuestOS\:182},displayText:tempfromvol-root12,passwordEnabled:false,name:tempfromvol-root12,_:1402308159938,uuid:77913d8e-99f9-43f9-9dd2-a498ebe37d75,ctxAccountId:2,ctxStartEventId:218},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-06-09 15:40:09,368 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-43436526 ctx-b0e507ef) ===END===  10.144.7.13 -- GET  
 command=createTemplateresponse=jsonsessionkey=fGX4uIHoj2mx%2BzfKOA579EC%2FQjM%3DvolumeId=d33b806d-8c96-4aff-8e3f-2efa78083a7fname=tempfromvol-root12displayText=tempfromvol-root12osTypeId=a000795a-ebce-11e3-b00a-c264afd952f5isPublic=truepasswordEnabled=falseisdynamicallyscalable=falseisfeatured=true_=1402308159938
 2014-06-09 15:40:09,370 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-34:ctx-c3c1954c job-122) Add job-122 into job monitoring
 2014-06-09 15:40:09,370 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-34:ctx-c3c1954c job-122) Executing AsyncJobVO {id:122, 
 userId: 2, accountId: 2, instanceType: Template, instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin, 
 cmdInfo: 
 {sessionkey:fGX4uIHoj2mx+zfKOA579EC/QjM\u003d,cmdEventType:TEMPLATE.CREATE,ctxUserId:2,volumeId:d33b806d-8c96-4aff-8e3f-2efa78083a7f,httpmethod:GET,osTypeId:a000795a-ebce-11e3-b00a-c264afd952f5,isPublic:true,isfeatured:true,id:203,isdynamicallyscalable:false,response:json,ctxDetails:{\com.cloud.template.VirtualMachineTemplate\:203,\com.cloud.storage.Volume\:24,\VirtualMachineTemplate\:\77913d8e-99f9-43f9-9dd2-a498ebe37d75\,\com.cloud.storage.GuestOS\:182},displayText:tempfromvol-root12,passwordEnabled:false,name:tempfromvol-root12,_:1402308159938,uuid:77913d8e-99f9-43f9-9dd2-a498ebe37d75,ctxAccountId:2,ctxStartEventId:218},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 213737702773493, completeMsid: null,

[jira] [Assigned] (CLOUDSTACK-6867) [Hyper-V][UI] No option to upload a volume with .vhdx format

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


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

Anshul Gangwar reassigned CLOUDSTACK-6867:
--

Assignee: Anshul Gangwar

 [Hyper-V][UI] No option to upload a volume with .vhdx format
 

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

 Attachments: CS-6867.jpg


 Steps :
 ===
 1. Deploy a advanced zone hyperv setup.
 2. Try to upload a volume with .vhdx format
  There is no option in the UI to upload .vhdx format volumes, only vhd is 
 there
 3. Try to upload the .vhdx volume by selecting the format as .vhd 
  Then we get this error 
  2014-06-09 13:23:28,381 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-9:ctx-c149c622 job-84) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin
 com.cloud.exception.InvalidParameterValueException: Please specify a valid 
 URL. URL:http://10.144.7.13/upload-data.vhdx is an invalid for the format vhd
 at 
 com.cloud.storage.VolumeApiServiceImpl.validateVolume(VolumeApiServiceImpl.java:314)
 at 
 com.cloud.storage.VolumeApiServiceImpl.uploadVolume(VolumeApiServiceImpl.java:252)
 at 
 com.cloud.storage.VolumeApiServiceImpl.uploadVolume(VolumeApiServiceImpl.java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy181.uploadVolume(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin.execute(UploadVolumeCmdByAdmin.java:46)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at

[jira] [Commented] (CLOUDSTACK-6777) [Automation]: Test case failure in test_secondary_storage.py


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

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

Commit 79364afcf59f8317aa211959aa2d7ac0959a8d53 in cloudstack's branch 
refs/heads/4.4-forward from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=79364af ]

CLOUDSTACK-6777: Enable testcase as it looks to be env issue


 [Automation]: Test case failure in test_secondary_storage.py
 

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

 Attachments: KVM_test_02_sys_template_ready_REPORT.rtf, vmops.log


 There is test case failure in test_secondary_storage.py
 1) 
 integration.smoke.test_secondary_storage.TestSecStorageServices.test_02_sys_template_ready
 Error Message
 Builtin template is not ready No route to host in zone 
 9459d36e-a477-4a60-890b-2bc48edf1410
   begin captured stdout  -
 === TestName: test_02_sys_template_ready | Status : FAILED ===
 Attached Test reports and Management server logs



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

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

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


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

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

Commit 0f2c66e6c981567367650d78d5b09c6f7ad04ce6 in cloudstack's branch 
refs/heads/master from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f2c66e ]

CLOUDSTACK-6834: [Windows] 1. Added Port to the wizard to capture input from 
the admin.

Signed-off-by: Koushik Das kous...@apache.org


 [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] [Commented] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

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


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

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

Commit 9e4e62466a8c3d00ab5381d7ebfeb70466192a55 in cloudstack's branch 
refs/heads/4.4-forward from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9e4e624 ]

CLOUDSTACK-6755: [OVS] Can't create more than 7 GRE tunnel networks in
xen cluster

XenServer does not create a bridge automatically when VIF from domU is connected
to internal network. So there is logic to force bridge creation by
creating VIF in dom0 connected to GRE tunnel network. But there is no
logic to delete the VIF after bridge gets created. So this fix ensure
VIF is delted when atleast there is one domU VIF connected to the
network.


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

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

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
 at

[jira] [Commented] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

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


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

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

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

CLOUDSTACK-6755: [OVS] Can't create more than 7 GRE tunnel networks in
xen cluster

XenServer does not create a bridge automatically when VIF from domU is connected
to internal network. So there is logic to force bridge creation by
creating VIF in dom0 connected to GRE tunnel network. But there is no
logic to delete the VIF after bridge gets created. So this fix ensure
VIF is delted when atleast there is one domU VIF connected to the
network.


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

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

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
 at

[jira] [Resolved] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

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


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

Murali Reddy resolved CLOUDSTACK-6755.
--

Resolution: Fixed

 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

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

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at

[jira] [Commented] (CLOUDSTACK-6895) Populate firstclass entities as uuids in the context instead of dbids for performance.


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

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

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

CLOUDSTACK-6895: 1. Populate firstclass entities as uuids in the context 
instead of dbids for performance.
2. Add ctxDetails in the ParamGenericValidationWorker to avoid warning for api 
validation
3. Add some missing events.
4. Correcting mapping for ResourceObjectType.NetworkACL and 
ResourceObjectType.NetworkACLItem

(cherry picked from commit 8a9092c3cd4e3c034f9f4d0a7491875dc080e9dc)

Conflicts:
api/src/com/cloud/event/EventTypes.java
api/src/org/apache/cloudstack/api/BaseCmd.java


 Populate firstclass entities as uuids in the context instead of dbids for 
 performance.
 --

 Key: CLOUDSTACK-6895
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6895
 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


 Populate firstclass entities as uuids in the context instead of dbids for 
 performance.



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

[jira] [Commented] (CLOUDSTACK-6602) [UI] createNetworkACL API action param value passed incorrectly

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


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

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

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

CLOUDSTACK-6602: UI - VPC - createNetworkACL - fix a bug that caused wrong 
value being passed to action parameter in API call.

(cherry picked from commit 95b7330d5696aa150f1845b76c6021885c919aea)


 [UI] createNetworkACL API action param value passed incorrectly
 ---

 Key: CLOUDSTACK-6602
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6602
 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: Jayapal Reddy
Assignee: Jessica Wang
Priority: Blocker
 Fix For: 4.4.0

 Attachments: regression_caused_by.PNG


 createNetworkACLresponse=jsonsessionkey=9PnsnXugAKpfi24BgcTNguWYMt0%3Dnumber=1cidrlist=0.0.0.0%2F0action=label.allowprotocol=tcpstartport=22endport=22traffictype=Ingressaclid=f3022110-80fc-4f77-943c-33f7103a6aa3_=1399524604770
 The action parameter from UI is passed incorrectly 'label.allow'. It supposed 
 to 'allow' or 'deny'.



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

[jira] [Updated] (CLOUDSTACK-6864) UploadSSlCert API requires double encoding of URL params

2014-06-12 Thread Daan Hoogland (JIRA)


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

Daan Hoogland updated CLOUDSTACK-6864:
--

Fix Version/s: 4.4.0

 UploadSSlCert API requires double encoding of URL params
 

 Key: CLOUDSTACK-6864
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6864
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.4.0


 uploadSslCert API requires double UTF-8 encoding of the parameters 
 (certificate, privatekey, certchain) in the URL.
 This is because there are 2 decodes happening (First in API Server : handle
 paramList = URLEncodedUtils.parse )new 
 URI(request.getRequestLine().getUri()), UTF_8)
 and the Second one in the API definition:
 CertServiceImpl:uploadSslCert
 String cert = URLDecoder.decode(certCmd.getCert(), UTF-8); )



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

[jira] [Updated] (CLOUDSTACK-6854) MS:IPv6: IP6 network address with notation differences are treated as same IP

2014-06-12 Thread Daan Hoogland (JIRA)


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

Daan Hoogland updated CLOUDSTACK-6854:
--

Fix Version/s: 4.4.0

 MS:IPv6: IP6 network address with notation differences are treated as same IP
 -

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

 Attachments: Screen Shot 2014-06-05 at 11.42.09 AM.png, 
 management-server.log.zip


 Observed in a dual stack deployment,
 A router and a virtual machines were assigned same IP from IPv6 range.
 The only difference was the notation, so it may be the case that notation 
 differences are not being interpret by management server correctly.
 fc00:0003:1373::0002 was assigned to router and
 fc00:3:1373::2 was assigned to the guest VM.
 Please refer to the attached screen and logs.



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

[jira] [Commented] (CLOUDSTACK-6654) Configkey parameters are not validated

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


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

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

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

CLOUDSTACK-6654: Configkey parameters are not validated

(cherry picked from commit 5bcd017de6f421a6125406120b39fb8602276dc7)


 Configkey parameters are not validated
 --

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


 There is no validation for the values of ConfigKey variables. So one can give 
 anything like -5.6 or “pqr” or ‘#*99abc’  as the value of cpu/memory/storage 
 over-provision factors or any other variables in ConfigKey framework.



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

[jira] [Commented] (CLOUDSTACK-6864) UploadSSlCert API requires double encoding of URL params

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


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

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

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

CLOUDSTACK-6864: UploadSSlCert API requires double encoding of URL params

(cherry picked from commit c5ee5ad5c828d9f0b128e3d7280a30dcf717e045)


 UploadSSlCert API requires double encoding of URL params
 

 Key: CLOUDSTACK-6864
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6864
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.4.0


 uploadSslCert API requires double UTF-8 encoding of the parameters 
 (certificate, privatekey, certchain) in the URL.
 This is because there are 2 decodes happening (First in API Server : handle
 paramList = URLEncodedUtils.parse )new 
 URI(request.getRequestLine().getUri()), UTF_8)
 and the Second one in the API definition:
 CertServiceImpl:uploadSslCert
 String cert = URLDecoder.decode(certCmd.getCert(), UTF-8); )



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

[jira] [Commented] (CLOUDSTACK-6812) For storage type which does not support over provisioning ,over provisioning factor should be 1

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


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

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

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

CLOUDSTACK-6812: Do not allow edit of storage.overprovision.factor for non 
supported types

(cherry picked from commit f14f36170e94c0184ade28a50226b17d25ecf57c)


 For storage type which does not support over provisioning ,over provisioning 
 factor should be 1 
 

 Key: CLOUDSTACK-6812
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6812
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: prashant kumar mishra
Assignee: Saksham Srivastava
 Fix For: 4.4.0


 currently over provisioning is supported for only nfs and vmfs ,for storage 
 type like lvm, iscsi  over provisioning is not supported ,default value of 
 over provisioning factor should be 1 . and it should be non modifiable. 



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

[jira] [Resolved] (CLOUDSTACK-6654) Configkey parameters are not validated

2014-06-12 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava resolved CLOUDSTACK-6654.


Resolution: Fixed

 Configkey parameters are not validated
 --

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


 There is no validation for the values of ConfigKey variables. So one can give 
 anything like -5.6 or “pqr” or ‘#*99abc’  as the value of cpu/memory/storage 
 over-provision factors or any other variables in ConfigKey framework.



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

[jira] [Commented] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

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


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

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

Commit 1c17df853f46adf8af57a9aeb7e32b0eebd27126 in cloudstack's branch 
refs/heads/4.4 from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c17df8 ]

CLOUDSTACK-6755: [OVS] Can't create more than 7 GRE tunnel networks in
xen cluster

XenServer does not create a bridge automatically when VIF from domU is connected
to internal network. So there is logic to force bridge creation by
creating VIF in dom0 connected to GRE tunnel network. But there is no
logic to delete the VIF after bridge gets created. So this fix ensure
VIF is delted when atleast there is one domU VIF connected to the
network.

(cherry picked from commit 9e4e62466a8c3d00ab5381d7ebfeb70466192a55)


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

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

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at

[jira] [Created] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.

Abhinav Roy created CLOUDSTACK-6898:
---

 Summary: [Hyper-V] Open the console of a VM from CS, reboot the VM 
( from CS or from inside the console), the console gets stuck at a point.
 Key: CLOUDSTACK-6898
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6898
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Hyper-V
Reporter: Abhinav Roy
Priority: Critical
 Fix For: 4.4.0


Steps :
==
1. Deploy a Hyper-V setup with advanced zone.
2. Deploy a VM.
3. Now open the console of the VM from CS UI.
4. Now reboot the VM from CS or from inside the console of VM

Expected behavior :
===
1. The console should be accessible when the the VM is rebooting and after it 
boots up.

Observed behavior :
==
The console gets stuck at the point of stopping the VM and remains in that 
state.
Even if you close the console and reopen , it remains in the same state.
Attaching a screenshot for that.


Workaround :

Either close the console or even in the open state don't do any activity on it 
for 3 mins. After that it becomes accessible again.



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

[jira] [Updated] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.

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


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

Abhinav Roy updated CLOUDSTACK-6898:


Attachment: CS-6898.jpg

 [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from 
 inside the console), the console gets stuck at a point.
 ---

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

 Attachments: CS-6898.jpg


 Steps :
 ==
 1. Deploy a Hyper-V setup with advanced zone.
 2. Deploy a VM.
 3. Now open the console of the VM from CS UI.
 4. Now reboot the VM from CS or from inside the console of VM
 Expected behavior :
 ===
 1. The console should be accessible when the the VM is rebooting and after it 
 boots up.
 Observed behavior :
 ==
 The console gets stuck at the point of stopping the VM and remains in that 
 state.
 Even if you close the console and reopen , it remains in the same state.
 Attaching a screenshot for that.
 Workaround :
 
 Either close the console or even in the open state don't do any activity on 
 it for 3 mins. After that it becomes accessible again.



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

[jira] [Commented] (CLOUDSTACK-6791) [Automation] DeleteNetworkCmd fails with NullPointerException


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

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

Commit 62cc238e1276bad1af7934fe5c150fe801b89140 in cloudstack's branch 
refs/heads/4.4-forward from Santhosh Edukulla
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=62cc238 ]

CLOUDSTACK-6791 Fixed the issue


 [Automation] DeleteNetworkCmd fails with NullPointerException
 -

 Key: CLOUDSTACK-6791
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6791
 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: Automation 
 4.4-forward
 vmware 5.0
Reporter: Rayees Namathponnan
Assignee: Santhosh Kumar Edukulla
Priority: Blocker
 Fix For: 4.4.0


 This issue is observed with automation run , while executing test 
 integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_add_ip_to_nic_2_SHARED
 Test case performs below operations 
  225 # Steps:
  226 # 1. Create Account and create network in it (isoalted/ shared/ 
 vpc)
  227 # 2. Deploy a VM in this network and account
  228 # 3. Add secondary IP to the default nic of VM
  229 # 4. Try to add the same IP again
  230 # 5. Try to add secondary IP providing wrong virtual machine id
  231 # 6. Try to add secondary IP with correct virtual machine id but 
 wrong IP address
 # 7 Destroy account 
  232 
  233 # Validations:
  234 # 1. Step 3 should succeed
  235 # 2. Step 4 should fail
  236 # 3. Step 5 should should fail
  237 # 4. Step 6 should fail
 This issue observed during account deletion
 2014-05-26 19:18:52,169 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Network id=616 is 
 destroyed successfully, cleaning up corresponding resources now.
 2014-05-26 19:18:52,170 DEBUG [c.c.n.g.DirectNetworkGuru] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Releasing ip 
 172.16.27.1 of placeholder nic Nic[1645-null-null-172.16.27.1]
 2014-05-26 19:18:52,171 DEBUG [c.c.u.d.T.Transaction] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Rolling back the 
 transaction: Time = 2 Name =  API-Job-Executor-41; called by 
 -TransactionLegacy.rollback:903-TransactionLegacy.removeUpTo:846-TransactionLegacy.close:670-Transaction.execute:41-Transaction.execute:46-DirectNetworkGuru.trash:327-NetworkOrchestrator$10.doInTransactionWithoutResult:2226-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49-Transaction.execute:37-Transaction.execute:46-NetworkOrchestrator.destroyNetwork:2221
 2014-05-26 19:18:52,183 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-41:ctx-b247339e job-5716) Unexpected exception while 
 executing org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd
 java.lang.NullPointerException
 at 
 com.cloud.network.guru.DirectNetworkGuru$3.doInTransactionWithoutResult(DirectNetworkGuru.java:334)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 com.cloud.network.guru.DirectNetworkGuru.trash(DirectNetworkGuru.java:327)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransactionWithoutResult(NetworkOrchestrator.java:2226)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2221)
 at 
 com.cloud.network.NetworkServiceImpl.deleteNetwork(NetworkServiceImpl.java:1828)
 at sun.reflect.GeneratedMethodAccessor729.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

[jira] [Resolved] (CLOUDSTACK-6791) [Automation] DeleteNetworkCmd fails with NullPointerException

2014-06-12 Thread Santhosh Kumar Edukulla (JIRA)


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

Santhosh Kumar Edukulla resolved CLOUDSTACK-6791.
-

Resolution: Fixed

Fixed the issue

 [Automation] DeleteNetworkCmd fails with NullPointerException
 -

 Key: CLOUDSTACK-6791
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6791
 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: Automation 
 4.4-forward
 vmware 5.0
Reporter: Rayees Namathponnan
Assignee: Santhosh Kumar Edukulla
Priority: Blocker
 Fix For: 4.4.0


 This issue is observed with automation run , while executing test 
 integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_add_ip_to_nic_2_SHARED
 Test case performs below operations 
  225 # Steps:
  226 # 1. Create Account and create network in it (isoalted/ shared/ 
 vpc)
  227 # 2. Deploy a VM in this network and account
  228 # 3. Add secondary IP to the default nic of VM
  229 # 4. Try to add the same IP again
  230 # 5. Try to add secondary IP providing wrong virtual machine id
  231 # 6. Try to add secondary IP with correct virtual machine id but 
 wrong IP address
 # 7 Destroy account 
  232 
  233 # Validations:
  234 # 1. Step 3 should succeed
  235 # 2. Step 4 should fail
  236 # 3. Step 5 should should fail
  237 # 4. Step 6 should fail
 This issue observed during account deletion
 2014-05-26 19:18:52,169 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Network id=616 is 
 destroyed successfully, cleaning up corresponding resources now.
 2014-05-26 19:18:52,170 DEBUG [c.c.n.g.DirectNetworkGuru] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Releasing ip 
 172.16.27.1 of placeholder nic Nic[1645-null-null-172.16.27.1]
 2014-05-26 19:18:52,171 DEBUG [c.c.u.d.T.Transaction] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Rolling back the 
 transaction: Time = 2 Name =  API-Job-Executor-41; called by 
 -TransactionLegacy.rollback:903-TransactionLegacy.removeUpTo:846-TransactionLegacy.close:670-Transaction.execute:41-Transaction.execute:46-DirectNetworkGuru.trash:327-NetworkOrchestrator$10.doInTransactionWithoutResult:2226-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49-Transaction.execute:37-Transaction.execute:46-NetworkOrchestrator.destroyNetwork:2221
 2014-05-26 19:18:52,183 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-41:ctx-b247339e job-5716) Unexpected exception while 
 executing org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd
 java.lang.NullPointerException
 at 
 com.cloud.network.guru.DirectNetworkGuru$3.doInTransactionWithoutResult(DirectNetworkGuru.java:334)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 com.cloud.network.guru.DirectNetworkGuru.trash(DirectNetworkGuru.java:327)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransactionWithoutResult(NetworkOrchestrator.java:2226)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2221)
 at 
 com.cloud.network.NetworkServiceImpl.deleteNetwork(NetworkServiceImpl.java:1828)
 at sun.reflect.GeneratedMethodAccessor729.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

[jira] [Updated] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.


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

Abhinav Roy updated CLOUDSTACK-6898:


Attachment: CS-6898.jpg

 [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from 
 inside the console), the console gets stuck at a point.
 ---

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

 Attachments: CS-6898.jpg


 Steps :
 ==
 1. Deploy a Hyper-V setup with advanced zone.
 2. Deploy a VM.
 3. Now open the console of the VM from CS UI.
 4. Now reboot the VM from CS or from inside the console of VM
 Expected behavior :
 ===
 1. The console should be accessible when the the VM is rebooting and after it 
 boots up.
 Observed behavior :
 ==
 The console gets stuck at the point of stopping the VM and remains in that 
 state.
 Even if you close the console and reopen , it remains in the same state.
 Attaching a screenshot for that.
 Workaround :
 
 Either close the console or even in the open state don't do any activity on 
 it for 3 mins. After that it becomes accessible again.



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

[jira] [Created] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

Jayapal Reddy created CLOUDSTACK-6899:
-

 Summary: listNics doesn't have vm id in response but does take vm 
id as a param
 Key: CLOUDSTACK-6899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy


listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Updated] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param


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

Jayapal Reddy updated CLOUDSTACK-6899:
--

Assignee: Jayapal Reddy

 listNics doesn't have vm id in response but does take vm id as a param
 --

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


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Updated] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param


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

Jayapal Reddy updated CLOUDSTACK-6899:
--

Affects Version/s: 4.2.0

 listNics doesn't have vm id in response but does take vm id as a param
 --

 Key: CLOUDSTACK-6899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
 Fix For: 4.4.0


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Updated] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

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


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

Jayapal Reddy updated CLOUDSTACK-6899:
--

Fix Version/s: 4.4.0

 listNics doesn't have vm id in response but does take vm id as a param
 --

 Key: CLOUDSTACK-6899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
 Fix For: 4.4.0


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Commented] (CLOUDSTACK-6791) [Automation] DeleteNetworkCmd fails with NullPointerException


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

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

Commit ce334b4ee58a8da0d75c52521c7e5080ceb429d6 in cloudstack's branch 
refs/heads/4.4 from Santhosh Edukulla
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ce334b4 ]

CLOUDSTACK-6791 Fixed the issue

(cherry picked from commit 62cc238e1276bad1af7934fe5c150fe801b89140)


 [Automation] DeleteNetworkCmd fails with NullPointerException
 -

 Key: CLOUDSTACK-6791
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6791
 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: Automation 
 4.4-forward
 vmware 5.0
Reporter: Rayees Namathponnan
Assignee: Santhosh Kumar Edukulla
Priority: Blocker
 Fix For: 4.4.0


 This issue is observed with automation run , while executing test 
 integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_add_ip_to_nic_2_SHARED
 Test case performs below operations 
  225 # Steps:
  226 # 1. Create Account and create network in it (isoalted/ shared/ 
 vpc)
  227 # 2. Deploy a VM in this network and account
  228 # 3. Add secondary IP to the default nic of VM
  229 # 4. Try to add the same IP again
  230 # 5. Try to add secondary IP providing wrong virtual machine id
  231 # 6. Try to add secondary IP with correct virtual machine id but 
 wrong IP address
 # 7 Destroy account 
  232 
  233 # Validations:
  234 # 1. Step 3 should succeed
  235 # 2. Step 4 should fail
  236 # 3. Step 5 should should fail
  237 # 4. Step 6 should fail
 This issue observed during account deletion
 2014-05-26 19:18:52,169 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Network id=616 is 
 destroyed successfully, cleaning up corresponding resources now.
 2014-05-26 19:18:52,170 DEBUG [c.c.n.g.DirectNetworkGuru] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Releasing ip 
 172.16.27.1 of placeholder nic Nic[1645-null-null-172.16.27.1]
 2014-05-26 19:18:52,171 DEBUG [c.c.u.d.T.Transaction] 
 (API-Job-Executor-41:ctx-b247339e job-5716 ctx-5a0ec179) Rolling back the 
 transaction: Time = 2 Name =  API-Job-Executor-41; called by 
 -TransactionLegacy.rollback:903-TransactionLegacy.removeUpTo:846-TransactionLegacy.close:670-Transaction.execute:41-Transaction.execute:46-DirectNetworkGuru.trash:327-NetworkOrchestrator$10.doInTransactionWithoutResult:2226-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49-Transaction.execute:37-Transaction.execute:46-NetworkOrchestrator.destroyNetwork:2221
 2014-05-26 19:18:52,183 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-41:ctx-b247339e job-5716) Unexpected exception while 
 executing org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd
 java.lang.NullPointerException
 at 
 com.cloud.network.guru.DirectNetworkGuru$3.doInTransactionWithoutResult(DirectNetworkGuru.java:334)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 com.cloud.network.guru.DirectNetworkGuru.trash(DirectNetworkGuru.java:327)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransactionWithoutResult(NetworkOrchestrator.java:2226)
 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 com.cloud.utils.db.Transaction.execute(Transaction.java:46)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2221)
 at 
 com.cloud.network.NetworkServiceImpl.deleteNetwork(NetworkServiceImpl.java:1828)
 at sun.reflect.GeneratedMethodAccessor729.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

[jira] [Commented] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

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


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

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

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

CLOUDSTACK-6899: Added vmId in listnics response


 listNics doesn't have vm id in response but does take vm id as a param
 --

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


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Commented] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

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


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

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

Commit 923c0cd89f9ba35a1cdbc1c4502a04620e9eff79 in cloudstack's branch 
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=923c0cd ]

CLOUDSTACK-6899: Added vmId in listnics response


 listNics doesn't have vm id in response but does take vm id as a param
 --

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


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Commented] (CLOUDSTACK-6812) For storage type which does not support over provisioning ,over provisioning factor should be 1

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


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

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

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

CLOUDSTACK-6812: Do not allow edit of storage.overprovision.factor for non 
supported types


 For storage type which does not support over provisioning ,over provisioning 
 factor should be 1 
 

 Key: CLOUDSTACK-6812
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6812
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: prashant kumar mishra
Assignee: Saksham Srivastava
 Fix For: 4.4.0


 currently over provisioning is supported for only nfs and vmfs ,for storage 
 type like lvm, iscsi  over provisioning is not supported ,default value of 
 over provisioning factor should be 1 . and it should be non modifiable. 



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

[jira] [Created] (CLOUDSTACK-6901) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes

Murali Reddy created CLOUDSTACK-6901:


 Summary: Document in the release notes that OVS plug-in 
functionality is disrupted if ovsdaemon crashes
 Key: CLOUDSTACK-6901
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6901
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Affects Versions: 4.4.0
Reporter: Murali Reddy
 Fix For: 4.4.0


A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it 
is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing 
all the openflow rules added to the bridge. Ovs daemon gets started and creates 
a bridge but configure openflow rules are lost resulting in the disruption of 
connectivity for the VM's on the host.

We need to document it in the release notes as a known issue.



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

[jira] [Created] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes

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

Murali Reddy created CLOUDSTACK-6902:


 Summary: Document in the release notes that OVS plug-in 
functionality is disrupted if ovsdaemon crashes
 Key: CLOUDSTACK-6902
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Affects Versions: 4.4.0
Reporter: Murali Reddy
 Fix For: 4.4.0


A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it 
is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing 
all the openflow rules added to the bridge. Ovs daemon gets started and creates 
a bridge but configure openflow rules are lost resulting in the disruption of 
connectivity for the VM's on the host.

We need to document it in the release notes as a known issue.



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

[jira] [Commented] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param


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

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

Commit 80d8cef240661542cc7c679769a62ca68771d6cf in cloudstack's branch 
refs/heads/4.4 from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=80d8cef ]

CLOUDSTACK-6899: Added vmId in listnics response

(cherry picked from commit e9f60ee292109633ae538694107f3450693716d2)


 listNics doesn't have vm id in response but does take vm id as a param
 --

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


 listNics API doesn't have vm id in response but does take vm id as a param



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

[jira] [Created] (CLOUDSTACK-6903) Allow use of simulator hypervisor from client gui

2014-06-12 Thread Leo Simons (JIRA)

Leo Simons created CLOUDSTACK-6903:
--

 Summary: Allow use of simulator hypervisor from client gui
 Key: CLOUDSTACK-6903
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6903
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Simulator
Affects Versions: 4.4.0
 Environment: simulation
Reporter: Leo Simons
Priority: Minor
 Fix For: 4.5.0


The simulator VM can _almost_ be used properly out of the box from the UI, but 
it
* doesn't show in the drop down lists to select
* doesn't have any possible storage provisioning if you do select it

I have a patch :-)



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

[jira] [Created] (CLOUDSTACK-6904) [Automation] marvin signature generation is going wrong as 'typeInfo' is part of payload

2014-06-12 Thread Srikanteswararao Talluri (JIRA)

Srikanteswararao Talluri created CLOUDSTACK-6904:


 Summary: [Automation] marvin signature generation is going wrong 
as 'typeInfo' is part of payload
 Key: CLOUDSTACK-6904
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6904
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.5.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Priority: Blocker
 Fix For: 4.5.0


Signature generation for the API call is going wrong because newly added 
'typeInfo' is going as part of payload.



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

[jira] [Commented] (CLOUDSTACK-6904) [Automation] marvin signature generation is going wrong as 'typeInfo' is part of payload

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


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

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

Commit 34b177f2b58f2acfa93bdec75d31495b279276a4 in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=34b177f ]

CLOUDSTACK-6904: removed typeInfo key as part of sanitize command

Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Automation] marvin signature generation is going wrong as 'typeInfo' is part 
 of payload
 

 Key: CLOUDSTACK-6904
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6904
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.5.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Priority: Blocker
 Fix For: 4.5.0


 Signature generation for the API call is going wrong because newly added 
 'typeInfo' is going as part of payload.



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

[jira] [Commented] (CLOUDSTACK-6857) Losing the connection from CloudStack Manager to the agent will force a shutdown when connection is re-established

2014-06-12 Thread Koushik Das (JIRA)


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

Koushik Das commented on CLOUDSTACK-6857:
-

Can you share the full logs? Based on the log snippet none of the available 
investigators were able to determine if VM is alive. In such a case something 
called 'fencers' tries to fence off the VM. If fencers fail nothing is done to 
the VM. Full logs will help understand what all happened.

 Losing the connection from CloudStack Manager to the agent will force a 
 shutdown when connection is re-established
 --

 Key: CLOUDSTACK-6857
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6857
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Ubuntu 12.04
Reporter: c-hemp
Priority: Critical

 If a physical host is not pingable that host goes into alert mode. If the 
 physical hosts is unreachable, the virtual router is either unreachable or 
 unable to ping a virtual on the physical host, and the manager is unable to 
 ping the virtual instance it assumes the virtual is down and puts it into a 
 stop state.  
 When the connection is restablished, it gets the state from the database, 
 sees that it is now in a stopped state, and will then shutdown the instance.
 This behavior can cause major outages if there is any type of network loss 
 once the connectivity comes back.  This is especially critical when using 
 CloudStack across multiple colos.
 The logs when it happens:
 14-06-06 02:01:22,259 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) PingInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,259 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] 
 (HA-Worker-1:ctx-be848615 work-1953) Not a System Vm, unable to determine 
 state of VM[User|cephvmstage013] returning null
 2014-06-06 02:01:22,259 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] 
 (HA-Worker-1:ctx-be848615 work-1953) Testing if VM[User|cephvmstage013] is 
 alive
 2014-06-06 02:01:22,260 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] 
 (HA-Worker-1:ctx-be848615 work-1953) Unable to find a management nic, cannot 
 ping this system VM, unable to determine state of VM[User|cephvmstage013] 
 returning null
 2014-06-06 02:01:22,260 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) ManagementIPSysVMInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,263 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) KVMInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,263 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) HypervInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,419 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) KVMInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,419 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) HypervInvestigator found 
 VM[User|cephvmstage013]to be alive? null
 2014-06-06 02:01:22,584 WARN  [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) Unable to actually stop 
 VM[User|cephvmstage013] but continue with release because it's a force stop
 2014-06-06 02:01:22,585 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) VM[User|cephvmstage013] is stopped on 
 the host.  Proceeding to release resource held.
 2014-06-06 02:01:22,648 WARN  [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) Unable to actually stop 
 VM[User|cephvmstage013] but continue with release because it's a force stop
 2014-06-06 02:01:22,650 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) VM[User|cephvmstage013] is stopped on 
 the host.  Proceeding to release resource held.
 2014-06-06 02:01:22,704 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) Successfully released network resources 
 for the vm VM[User|cephvmstage013]
 2014-06-06 02:01:22,704 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-4:ctx-e8eea7fb work-1950) Successfully released storage resources 
 for the vm VM[User|cephvmstage013]
 2014-06-06 02:01:22,774 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953) Successfully released network resources 
 for the vm VM[User|cephvmstage013]
 2014-06-06 02:01:22,774 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (HA-Worker-1:ctx-be848615 work-1953)

[jira] [Updated] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table


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

Murali Reddy updated CLOUDSTACK-6779:
-

Issue Type: Improvement  (was: Bug)

 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 --

 Key: CLOUDSTACK-6779
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
 Project: CloudStack
  Issue Type: Improvement
  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 
 d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: ovs
 Fix For: 4.5.0

 Attachments: management-server.rar, ovstunnel.log_host13, 
 ovstunnel.log_host14


 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
 2.Add physical network with GRE isolation
 3.Create network offering with connectivity service and OVS as the provider
 4.Create an isolated network with above offering and deploy few vms (4-5) in 
 that network and make sure that vms are spanned across both the hosts
 5.After this verify flow table rules on the ovs bridge
 6.Expunge one of the vms created at step4
 7.Again verify flow table rules on the host from where vm was deleted
 Result:
 =
 All the flow table rules were deleted from the OVS bridge. Only default flow 
 rule is present.
 Attaching management server log file and ovstunnel log files from both the 
 hosts. 
 Please look for xapi5 and xapi7 in ovstunnel log files.
 Flow table rules before destroy the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
 priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 After destroying the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, 
 priority=0 actions=NORMAL
 [root@Rack1Pod1Host13 ~]#



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

[jira] [Updated] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table


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

Murali Reddy updated CLOUDSTACK-6779:
-

Fix Version/s: (was: 4.4.0)
   4.5.0

 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 --

 Key: CLOUDSTACK-6779
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
 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 
 d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: ovs
 Fix For: 4.5.0

 Attachments: management-server.rar, ovstunnel.log_host13, 
 ovstunnel.log_host14


 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
 2.Add physical network with GRE isolation
 3.Create network offering with connectivity service and OVS as the provider
 4.Create an isolated network with above offering and deploy few vms (4-5) in 
 that network and make sure that vms are spanned across both the hosts
 5.After this verify flow table rules on the ovs bridge
 6.Expunge one of the vms created at step4
 7.Again verify flow table rules on the host from where vm was deleted
 Result:
 =
 All the flow table rules were deleted from the OVS bridge. Only default flow 
 rule is present.
 Attaching management server log file and ovstunnel log files from both the 
 hosts. 
 Please look for xapi5 and xapi7 in ovstunnel log files.
 Flow table rules before destroy the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
 priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 After destroying the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, 
 priority=0 actions=NORMAL
 [root@Rack1Pod1Host13 ~]#



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

[jira] [Updated] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table


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

Murali Reddy updated CLOUDSTACK-6779:
-

Priority: Critical  (was: Blocker)

 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 --

 Key: CLOUDSTACK-6779
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
 Project: CloudStack
  Issue Type: Improvement
  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 
 d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: ovs
 Fix For: 4.5.0

 Attachments: management-server.rar, ovstunnel.log_host13, 
 ovstunnel.log_host14


 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
 2.Add physical network with GRE isolation
 3.Create network offering with connectivity service and OVS as the provider
 4.Create an isolated network with above offering and deploy few vms (4-5) in 
 that network and make sure that vms are spanned across both the hosts
 5.After this verify flow table rules on the ovs bridge
 6.Expunge one of the vms created at step4
 7.Again verify flow table rules on the host from where vm was deleted
 Result:
 =
 All the flow table rules were deleted from the OVS bridge. Only default flow 
 rule is present.
 Attaching management server log file and ovstunnel log files from both the 
 hosts. 
 Please look for xapi5 and xapi7 in ovstunnel log files.
 Flow table rules before destroy the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
 priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 After destroying the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, 
 priority=0 actions=NORMAL
 [root@Rack1Pod1Host13 ~]#



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

[jira] [Commented] (CLOUDSTACK-6779) [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow table


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

Murali Reddy commented on CLOUDSTACK-6779:
--

OpenFlow rules are not meant to be persisted by OpenVswitch. This applies to 
both XenServer and KVM. So we need a holisitc way in CloudStack to reprogram 
the openflow rules to each bridge when there is a crash of OVS daemon and on 
host restart. This will be bigger effort I am afraid i can not fix it in for 
4.4 release. I opened a bug CLOUDSTACK-6902 to document this behaviour as known 
issue.

I am marking this bug for 4.5

 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 --

 Key: CLOUDSTACK-6779
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6779
 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 
 d130530bd3e1cd6d8249d5045e00e4e4e2201521
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: ovs
 Fix For: 4.5.0

 Attachments: management-server.rar, ovstunnel.log_host13, 
 ovstunnel.log_host14


 [OVS] Expunging VM (deleting vif) deletes all the rules from ovs bridge flow 
 table
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with min of 2 xen hosts in a cluster
 2.Add physical network with GRE isolation
 3.Create network offering with connectivity service and OVS as the provider
 4.Create an isolated network with above offering and deploy few vms (4-5) in 
 that network and make sure that vms are spanned across both the hosts
 5.After this verify flow table rules on the ovs bridge
 6.Expunge one of the vms created at step4
 7.Again verify flow table rules on the host from where vm was deleted
 Result:
 =
 All the flow table rules were deleted from the OVS bridge. Only default flow 
 rule is present.
 Attaching management server log file and ovstunnel log files from both the 
 hosts. 
 Please look for xapi5 and xapi7 in ovstunnel log files.
 Flow table rules before destroy the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=374.111s, table=0, n_packets=4, n_bytes=768, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=300.162s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=6,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=374.122s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=5,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=5350.811s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=4,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6016.913s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=3,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6753.464s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=6890.423s, table=0, n_packets=7594, n_bytes=6858309, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=374.1s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 
 actions=output:1,output:2,output:3,output:4,output:5
  cookie=0x0, duration=374.132s, table=0, n_packets=5, n_bytes=810, 
 priority=1200,in_port=5,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=5350.823s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=4,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=300.173s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=6,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=6016.924s, table=0, n_packets=8, n_bytes=1236, 
 priority=1200,in_port=3,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=6753.474s, table=0, n_packets=6, n_bytes=852, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 After destroying the vm:
 [root@Rack1Pod1Host13 ~]# ovs-ofctl dump-flows xapi5
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=877.901s, table=0, n_packets=46, n_bytes=9748, 
 priority=0 actions=NORMAL
 [root@Rack1Pod1Host13 ~]#



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

[jira] [Commented] (CLOUDSTACK-6903) Allow use of simulator hypervisor from client gui

2014-06-12 Thread Leo Simons (JIRA)


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

Leo Simons commented on CLOUDSTACK-6903:


patch @ https://reviews.apache.org/r/22511/

 Allow use of simulator hypervisor from client gui
 -

 Key: CLOUDSTACK-6903
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6903
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Simulator
Affects Versions: 4.4.0
 Environment: simulation
Reporter: Leo Simons
Priority: Minor
 Fix For: 4.5.0


 The simulator VM can _almost_ be used properly out of the box from the UI, 
 but it
 * doesn't show in the drop down lists to select
 * doesn't have any possible storage provisioning if you do select it
 I have a patch :-)



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

[jira] [Commented] (CLOUDSTACK-6876) test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.

2014-06-12 Thread Alex Brett (JIRA)


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

Alex Brett commented on CLOUDSTACK-6876:


This is a duplicate of CLOUDSTACK-6862

 test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.
 ---

 Key: CLOUDSTACK-6876
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6876
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Bharat Kumar

 Error Message
 Execute cmd: createserviceoffering failed, due to: errorCode: 401, 
 errorText:unable to verify user credentials and/or request signature
   begin captured stdout  -
 === TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
  'command': 'listDomains', 'signature': 'lalPSnJlAM6GkRDFC2sNKSa5T+o=', 
 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAcommand=listDomainsresponse=jsonsignature=lalPSnJlAM6GkRDFC2sNKSa5T%2Bo%3D
  HTTP/1.1 200 159
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{path : u'ROOT', haschild : False, id : 
 u'b5e7af36-ef7f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
  'name': 'zone-xen', 'command': 'listZones', 'signature': 
 'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listZones===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?response=jsonapiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAcommand=listZonesname=zone-xensignature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
  HTTP/1.1 200 446
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen', 
 guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken : 
 u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 : 
 u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled', 
 internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : 
 u'Advanced', id : u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 : 
 u'172.16.88.8'}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
  'templatefilter': 'featured', 'command': 'listTemplates', 'signature': 
 'eIj8lFw1ONlBOoquO50AKcXIBEI=', 'zoneid': 
 u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?templatefilter=featuredapiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAzoneid=243eb08f-31e9-4283-953b-52578d8b1c6acommand=listTemplatessignature=eIj8lFw1ONlBOoquO50AKcXIBEI%3Dresponse=json
  HTTP/1.1 200 818
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{domain : u'ROOT', domainid :

[jira] [Commented] (CLOUDSTACK-6862) [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm faling during BVT

2014-06-12 Thread Alex Brett (JIRA)


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

Alex Brett commented on CLOUDSTACK-6862:


I've created a patch that does the above and posted it at 
https://reviews.apache.org/r/22512/

 [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm 
 faling during BVT 
 -

 Key: CLOUDSTACK-6862
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6862
 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
Priority: Blocker
 Fix For: 4.4.0


 Test case 
 integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
  failing in BVT 
 Error Message
 Execute cmd: createserviceoffering failed, due to: errorCode: 401, 
 errorText:unable to verify user credentials and/or request signature
   begin captured stdout  -
 === TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'command': 'listDomains', 'signature': '8Yh5KlFqCsxhD/NB2fOBHSPL1kI=', 
 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listDomainsresponse=jsonsignature=8Yh5KlFqCsxhD%2FNB2fOBHSPL1kI%3D
  HTTP/1.1 200 159
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{path : u'ROOT', haschild : False, id : 
 u'6b3a436e-ef1f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'name': 'zone-xen', 'command': 'listZones', 'signature': 
 'Z7nIBao2vEVG1YiHM2kVrh6QcPY=', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listZones===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?response=jsonapiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listZonesname=zone-xensignature=Z7nIBao2vEVG1YiHM2kVrh6QcPY%3D
  HTTP/1.1 200 446
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen', 
 guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken : 
 u'562e3c93-9149-38c6-8555-de48e3e6c847', dns2 : u'8.8.4.4', dns1 : 
 u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled', 
 internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : 
 u'Advanced', id : u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', internaldns2 : 
 u'172.16.88.8'}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'templatefilter': 'featured', 'command': 'listTemplates', 'signature': 
 'KGHcOyWgw042qhRsMQWkZ7VdUIM=', 'zoneid': 
 u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET

[jira] [Updated] (CLOUDSTACK-6892) Database HA Config prevents mgmt server from starting

2014-06-12 Thread Adrian Lewis (JIRA)


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

Adrian Lewis updated CLOUDSTACK-6892:
-

Affects Version/s: 4.4.0
   Future

 Database HA Config prevents mgmt server from starting
 -

 Key: CLOUDSTACK-6892
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6892
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: Future, 4.3.0, 4.4.0
 Environment: MySQL configured for DB HA
Reporter: Adrian Lewis
Priority: Critical

 When configuring the database HA feature introduced in 4.3, the manangement 
 server fails to create the DB connection due to the mysql connector jar being 
 loaded using tomcat's common class loader but the 
 cloud-plugin-database-mysqlha-4.3.0.jar is loaded by the webapp class 
 loader.
 The cloud-plugin-database-mysqlha-4.3.0.jar needs to also be loaded from the 
 common class loader instead of webapp class loader.
 Fix is to declare the cloud-plugin-database-mysqlha-4.3.0.jar under the 
 common.loader section in /etc/cloudstack/management/catalina.properties.
 Only tested using a fresh install on Centos 6.5 and the public repo packages.
 Manual fix provided by Damoder Reddy in users mailing list: Looks like we 
 did not change the catalina.properties while refactoring out the mysql 
 connector part



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

[jira] [Commented] (CLOUDSTACK-6892) Database HA Config prevents mgmt server from starting

2014-06-12 Thread Adrian Lewis (JIRA)


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

Adrian Lewis commented on CLOUDSTACK-6892:
--

Added in 4.4 and Future as I assume this hasn't been picked up already.

 Database HA Config prevents mgmt server from starting
 -

 Key: CLOUDSTACK-6892
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6892
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: Future, 4.3.0, 4.4.0
 Environment: MySQL configured for DB HA
Reporter: Adrian Lewis
Priority: Critical

 When configuring the database HA feature introduced in 4.3, the manangement 
 server fails to create the DB connection due to the mysql connector jar being 
 loaded using tomcat's common class loader but the 
 cloud-plugin-database-mysqlha-4.3.0.jar is loaded by the webapp class 
 loader.
 The cloud-plugin-database-mysqlha-4.3.0.jar needs to also be loaded from the 
 common class loader instead of webapp class loader.
 Fix is to declare the cloud-plugin-database-mysqlha-4.3.0.jar under the 
 common.loader section in /etc/cloudstack/management/catalina.properties.
 Only tested using a fresh install on Centos 6.5 and the public repo packages.
 Manual fix provided by Damoder Reddy in users mailing list: Looks like we 
 did not change the catalina.properties while refactoring out the mysql 
 connector part



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

[jira] [Assigned] (CLOUDSTACK-6896) Dynamically added OS Type throws NoSuchElement Exception on Xen

2014-06-12 Thread Santhosh Kumar Edukulla (JIRA)


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

Santhosh Kumar Edukulla reassigned CLOUDSTACK-6896:
---

Assignee: Santhosh Kumar Edukulla

 Dynamically added OS Type throws NoSuchElement Exception on Xen
 ---

 Key: CLOUDSTACK-6896
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6896
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.4.0
 Environment: Managment Server: 4.4.0
 Host: XenServer Hypervisor 6.2
Reporter: Pavan Kumar Bandarupally
Assignee: Santhosh Kumar Edukulla
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log


 A dynamically added OS is used as OS type for an ISO registered in 
 cloudstack. An instance deployed using that ISO doesn't get created throwing 
 an exception.
 MS Exception trace excerpt:
 = 
 2014-06-12 02:03:45,707 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-281:ctx-c47880f2) Seq 1-5437252125119752015: Executing request
 2014-06-12 02:03:45,720 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) 1. The VM i-2-8-VM is in Starting state.
 2014-06-12 02:03:45,723 WARN  [c.c.h.x.r.XenServer620Resource] 
 (DirectAgent-281:ctx-c47880f2) XenServer 6.2.0 DOES NOT support Guest OS type 
 centospavan
 2014-06-12 02:03:45,726 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Cannot find template : null on XS version: 
 com.cloud.hypervisor.xen.resource.XenServer620Resource
 2014-06-12 02:03:45,727 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Catch Exception: class 
 java.util.NoSuchElementException due to java.util.NoSuchElementException
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-06-12 02:03:45,729 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Unable to start i-2-8-VM due to
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at

[jira] [Closed] (CLOUDSTACK-6742) listVolumes - As regularuser , able to list Vms and volumes of other users.


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

Sangeetha Hariharan closed CLOUDSTACK-6742.
---


Tested with latest build from 4.4 (after IAM revert).

As regular users, we are able to list only the vms and volumes that belong to 
this account.


 listVolumes - As regularuser , able to list Vms and volumes of other users.
 ---

 Key: CLOUDSTACK-6742
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6742
 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: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 listVolumes - As regularuser , able to list Vms of other users and as domain 
 admin , able to list Vms from other domains.
 Steps to reproduce the problem:
 Had a set up with 2 domains having few users accounts in each domain.
 Deploy Vms as each of these users.
 As any user , we are able to list Vms and volumes that belong to all other 
 users including ROOT admin and domain Admin users.



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

[jira] [Closed] (CLOUDSTACK-6745) DomainAdmin is not able to deploy Vm for users in his domain/subdomain.


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

Sangeetha Hariharan closed CLOUDSTACK-6745.
---


Tested with latest build from 4.4-forward branch.
DomainAdmin is able to deploy Vm for users in his domain/subdomain by passing 
their account name and domain Id in account and domainId parameter.

 DomainAdmin is not able to deploy Vm for users in his domain/subdomain.
 ---

 Key: CLOUDSTACK-6745
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6745
 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: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 DomainAdmin is not able to deploy Vm for users in his domain/subdomain.
 Steps to reproduce the problem:
 Create a domain d1.
 Create a regular user - d1a
 Deploy a VM as user d1a
 Create a domain admin user - d1
 As d1 , try to deploy a VM for user - d1a in the isolated network he owns by 
 passing asccount and domainId of d1a.
 API fails with the following exception:
 Unable to use network with id= b40ce153-83c6-41f3-905b-90ce22c9ac24, 
 permission denied
 2014-05-21 13:58:48,162 INFO  [a.c.c.a.ApiServer] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) (userId=387 accountId=387 
 sessionId=D51FD2C904EB65D7E1577D9ABAF5AACA) 10.215.2.8 -- GET 
 command=deployVirtualMachineresponse=jsonsessionkey=nEX1TsH7YWMyu7cvElRHR73m8Lc%3Dzoneid=749f7a5f-7a47-4357-bc67-1704936b58eatemplateid=90869df6-e02a-11e3-ac31-4adf980f9414hypervisor=Simulatorserviceofferingid=da56f514-c13d-4c4d-902d-a9342f7e8dc3networkids=b40ce153-83c6-41f3-905b-90ce22c9ac24displayname=test123name=test123_=1400719259855account=test-dom1domainid=b83c7d69-6536-478c-a756-b3d89ac9298a
  531 Unable to use network with id= b40ce153-83c6-41f3-905b-90ce22c9ac24, 
 permission denied
 Management server logs:
 2014-05-21 13:58:48,140 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-17:ctx-8541fadf) ===START===  10.215.2.8 -- GET  
 command=deployVirtualMachi
 neresponse=jsonsessionkey=nEX1TsH7YWMyu7cvElRHR73m8Lc%3Dzoneid=749f7a5f-7a47-4357-bc67-1704936b58eatemplateid=90869df6-e02a-11e3-ac31-4
 adf980f9414hypervisor=Simulatorserviceofferingid=da56f514-c13d-4c4d-902d-a9342f7e8dc3networkids=b40ce153-83c6-41f3-905b-90ce22c9ac24dis
 playname=test123name=test123_=1400719259855account=test-dom1domainid=b83c7d69-6536-478c-a756-b3d89ac9298a
 2014-05-21 13:58:48,143 DEBUG [o.a.c.a.BaseCmd] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) Ignoring paremeter displayvm as 
 the caller is
 not authorized to pass it in
 2014-05-21 13:58:48,144 DEBUG [o.a.c.a.BaseCmd] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) Ignoring paremeter 
 deploymentplanner as the ca
 ller is not authorized to pass it in
 2014-05-21 13:58:48,153 DEBUG [c.c.u.AccountManagerImpl] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) Access to 
 Acct[5afd4de2-2a81-4c40-b7e
 7-b5cb139551c1-test-dom1] granted to 
 Acct[f1f9a82e-f931-4f59-bf93-ae83b6e773e6-dom1-admin] by DomainChecker
 2014-05-21 13:58:48,156 DEBUG [c.c.u.AccountManagerImpl] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) Access to 
 Acct[5afd4de2-2a81-4c40-b7e
 7-b5cb139551c1-test-dom1] granted to 
 Acct[f1f9a82e-f931-4f59-bf93-ae83b6e773e6-dom1-admin] by DomainChecker
 2014-05-21 13:58:48,161 INFO  [c.c.a.ApiServer] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) PermissionDenied: Unable to use 
 network with i
 d= b40ce153-83c6-41f3-905b-90ce22c9ac24, permission denied on objs: []
 2014-05-21 13:58:48,162 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-17:ctx-8541fadf ctx-4320442b) ===END===  10.215.2.8 -- GET  
 command=deployV
 irtualMachineresponse=jsonsessionkey=nEX1TsH7YWMyu7cvElRHR73m8Lc%3Dzoneid=749f7a5f-7a47-4357-bc67-1704936b58eatemplateid=90869df6-e02a-
 11e3-ac31-4adf980f9414hypervisor=Simulatorserviceofferingid=da56f514-c13d-4c4d-902d-a9342f7e8dc3networkids=b40ce153-83c6-41f3-905b-90ce2
 2c9ac24displayname=test123name=test123_=1400719259855account=test-dom1domainid=b83c7d69-6536-478c-a756-b3d89ac9298a



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

[jira] [Created] (CLOUDSTACK-6905) NPE XenServerGuru.java:95 when remove the nic from the vm in Stopped state

2014-06-12 Thread Alena Prokharchyk (JIRA)

Alena Prokharchyk created CLOUDSTACK-6905:
-

 Summary: NPE XenServerGuru.java:95 when remove the nic from the vm 
in Stopped state
 Key: CLOUDSTACK-6905
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6905
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Priority: Critical
 Fix For: 4.5.0


Steps to reproduce:

1) deploy vm with 1 network in Xen environment. Stop it
2) attach nic to the stopped vm from another network
3) Try to delete the nic. Following NPE happens:

java.lang.NullPointerException
at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:95)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:3554)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:5280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)



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

[jira] [Closed] (CLOUDSTACK-6581) IAM - Shared Network -Root Admin user is allowed to deploy VM in a shared network that is scoped for a specific domain/account.

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

Sangeetha Hariharan closed CLOUDSTACK-6581.
---

Tested with latest build form 4.4-forward ( after IAM revert) :

ROOT admin is not able to deploy Vms in shared networks with scope domain/
account (dedicated to a particular domain / account).

API throws the following error when ROOT admin tries to deploy a VM in an
account specific shared network.

{ deployvirtualmachineresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Unable to use
network with id= 89215c78-1526-4d54-9021-8f49d6c991e3, permission denied} }

API throws the following error when ROOT admin tries to deploy a VM in a domain
specific shared network.

{ deployvirtualmachineresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Shared network
id=768a1a01-2caa-4d49-93db-ccba42619cb0 is not available in domain id=1} }

IAM - Shared Network -Root Admin user is allowed to deploy VM in a shared
network that is scoped for a specific domain/account.
---

Key: CLOUDSTACK-6581
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6581
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Prachi Damle
Priority: Critical
Fix For: 4.4.0

IAM - Shared Network -Root Admin user is allowed to deploy VM in a shared
network that is scoped for a specific domain/account.
Steps to reproduce the problem:
Create a admin account for ROOT domain.
Create a domain d1 with account a1.
Create a shared network for domain d1 with sub domain access set to true.
Create a shared network for domain d1 with sub domain access set to false.
Create a shared network for account a1 d1 with sub domain access set to false.
As ROOT admin , try to deploy a VM in the above created shared networks.
Vm deployment succeeds.
Expected Result:
ROOT admin should not be allowed to deploy VMs in shared networks that are
scoped for a specific domain/account.

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

[jira] [Created] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT

2014-06-12 Thread Rayees Namathponnan (JIRA)

Rayees Namathponnan created CLOUDSTACK-6906:
---

 Summary: [Automation] volume resize test cases failing in BVT 
 Key: CLOUDSTACK-6906
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906
 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
Priority: Critical
 Fix For: 4.4.0






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

[jira] [Updated] (CLOUDSTACK-6278) Baremetal Advanced Networking support


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

Animesh Chaturvedi updated CLOUDSTACK-6278:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 Baremetal Advanced Networking support
 -

 Key: CLOUDSTACK-6278
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6278
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Baremetal
Affects Versions: 4.4.0
Reporter: frank zhang
Assignee: frank zhang
 Fix For: 4.4.0


 functional spec link: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support



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

[jira] [Updated] (CLOUDSTACK-1597) Convert Storage Setup section to XML and update in Install Guide


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

Animesh Chaturvedi updated CLOUDSTACK-1597:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 Convert Storage Setup section to XML and update in Install Guide
 --

 Key: CLOUDSTACK-1597
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1597
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.0.0, 4.1.0
Reporter: Jessica Tomechak
Assignee: gavin lee
Priority: Minor
 Fix For: 4.4.0

 Attachments: Apache_CloudStack-4.2.0-Installation_Guide-en-US.pdf, 
 StorageSetup.docx


 The section Storage Setup was missed when converting the installation guide 
 to XML. The section is attached to this bug in the original format. This 
 section will need to be reviewed and updated as well as converted to XML, 
 since storage support has changed.



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

[jira] [Updated] (CLOUDSTACK-4992) Domain/Account/User Sync Up Among Multiple Regions


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

Animesh Chaturvedi updated CLOUDSTACK-4992:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 Domain/Account/User Sync Up Among Multiple Regions
 --

 Key: CLOUDSTACK-4992
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4992
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: Alex Ough
Assignee: Alex Ough
  Labels: features
 Fix For: 4.4.0


 Currently, under the environment of cloudstack with multiple regions, each 
 region has its own management server running with a separate database. So if 
 we want to support multiple regions and provide one point of entry for a 
 customer, we need to duplicate domain/account/user information of that 
 customer to all of the databases of regions the customer accesses, which will 
 cause data discrepancies when users update those data independently in each 
 management server.
 So I'd like to provide a way to sync up the data using the messaging system 
 introduced in 4.1.0. Using the events from each management server, updates 
 from each region can be propagated to the rest regions and they can be 
 executed accordingly.
 Discussion
 http://markmail.org/thread/k4x63ef55chcj4y5
 Wiki page
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions
 The implementation
 https://github.com/alexoughsg/Albatross/tree/albatross



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

[jira] [Updated] (CLOUDSTACK-4197) Allow creating a VM without virtual CD-ROM drive

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

Animesh Chaturvedi updated CLOUDSTACK-4197:
---

BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but
still open. If these are not ready for 4.4 please move them out.

Allow creating a VM without virtual CD-ROM drive

Key: CLOUDSTACK-4197
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4197
Project: CloudStack
Issue Type: Improvement
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller
Affects Versions: 4.2.0
Reporter: Kirk Kosinski
Assignee: Anthony Xu
Priority: Minor
Labels: hypervisor, netscaler
Fix For: 4.4.0

Currently all VMs that CloudStack creates will include a virtual CD-ROM
drive. In some cases, such as with virtual appliances (e.g. NetScaler VPX), a
CD-ROM drive is not needed or even unsupported. It would be useful if
CloudStack could deploy a VM without a CD-ROM drive to allow such cases.
Perhaps such functionality could be added using new OS Types, for example:
Other - No CD-ROM (32-bit)
Other - No CD-ROM (64-bit)
Other PV - No CD-ROM (32-bit)
Other PV - No CD-ROM (64-bit)
Or maybe it could be added on a per VM or per template basis with a new
configuration parameter. This might be more flexible since some customers
might want to use arbitrary OS types for VMs with no CD-ROM.

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

[jira] [Updated] (CLOUDSTACK-6050) A limitations on min-max on CPU/RAM for a dynamic offering


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

Animesh Chaturvedi updated CLOUDSTACK-6050:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 A limitations on min-max on CPU/RAM for a dynamic offering 
 ---

 Key: CLOUDSTACK-6050
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6050
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Abhinandan Prateek
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.4.0






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

[jira] [Commented] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT

2014-06-12 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan commented on CLOUDSTACK-6906:
-

volume test case 
integration.smoke.test_volumes.TestVolumes.test_08_resize_volume  trying resize 
volume without service offering.

if you want to resize volume without service offering , you need to create 
volume with custom diskoffering 

please see the mail from Marcus 

Thanks Marcus, then we need to update volume test cases in our BVT automation 
suite. 

Regards,
Rayees

-Original Message-
From: Marcus [mailto:shadow...@gmail.com]
Sent: Wednesday, June 11, 2014 11:04 PM
To: d...@cloudstack.apache.org
Subject: Re: Resize volume API without service offering failing in 4.4

Service offering is required if current offering is not a 'custom' sized 
offering. That is, if the volume is a locked into a fixed size because of the 
current service offering, the offering needs to be changed to a custom, or to a 
service offering of the desired size.


On Wed, Jun 11, 2014 at 11:39 PM, Rayees Namathponnan  
rayees.namathpon...@citrix.com wrote:

 Hi,

 I am trying to resize data volume in KVM and Xen, created new data 
 volume with 5 GB and trying to resize to 10 GB.

 Followed 4.4 API doc , in this service offering id is not a required 
 field; I am expecting volume should be resized even if we are not 
 passing service offering id, used below API

 http://10.xxx.xxx.xxx:8096/?command=resizeVolumeshrinkok=true
 size=10id=f25a958c-48f7-42aa-bb1f-f3749370d064
 http://10.xx.xxx.xxx:8096/?command=resizeVolumeshrinkok=true%20size
 =10id=f25a958c-48f7-42aa-bb1f-f3749370d064
 

 resize volume failed with below error, is service offering id 
 mandatory field in 4.4 ? is there any change in this area ?


 2014-06-11 22:36:01,710 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
 (API-Job-Executor-51:ctx-eee5edb4 job-5203) Executing AsyncJobVO 
 {id:5203,
 userId: 1, accountId: 1, instanceType: Volume, instanceId: null, cmd:
 org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin,
 cmdInfo:
 {id:f25a958c-48f7-42aa-bb1f-f3749370d064,ctxDetails:{\com.clou
 d.storage.Volume\:710,\Volume\:\f25a958c-48f7-42aa-bb1f-f3749370d0
 64\},shrinkok:true,cmdEventType:VOLUME.RESIZE,ctxUserId:1
 ,httpmethod:GET,uuid:f25a958c-48f7-42aa-bb1f-f3749370d064,ct
 xAccountId:1,ctxStartEventId:15109,size:10},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
 result: null, initMsid: 29066118877352, completeMsid: null, lastUpdated:
 null, lastPolled: null, created: null}
 2014-06-11 22:36:01,718 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
 (ApiServer-6:ctx-b68d99d4 ctx-5a82aa93) submit async job-5203, details:
 AsyncJobVO {id:5203, userId: 1, accountId: 1, instanceType: Volume,
 instanceId: null, cmd:
 org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin,
 cmdInfo:
 {id:f25a958c-48f7-42aa-bb1f-f3749370d064,ctxDetails:{\com.clou
 d.storage.Volume\:710,\Volume\:\f25a958c-48f7-42aa-bb1f-f3749370d0
 64\},shrinkok:true,cmdEventType:VOLUME.RESIZE,ctxUserId:1
 ,httpmethod:GET,uuid:f25a958c-48f7-42aa-bb1f-f3749370d064,ct
 xAccountId:1,ctxStartEventId:15109,size:10},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
 result: null, initMsid: 29066118877352, completeMsid: null, lastUpdated:
 null, lastPolled: null, created: null}
 2014-06-11 22:36:01,721 WARN  [c.c.a.d.ParamGenericValidationWorker]
 (API-Job-Executor-51:ctx-eee5edb4 job-5203 ctx-2e64d0b5) Received 
 unknown parameters for command resizeVolume. Unknown parameters :
 ctxdetails
 2014-06-11 22:36:01,756 ERROR [c.c.a.ApiAsyncJobDispatcher]
 (API-Job-Executor-51:ctx-eee5edb4 job-5203) Unexpected exception while 
 executing 
 org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin
 com.cloud.exception.InvalidParameterValueException: current offering4 
 cannot be resized, need to specify a disk offering
 at
 com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:724)
 at
 com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at

[jira] [Updated] (CLOUDSTACK-6680) AutoScaling without NetScaler


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

Animesh Chaturvedi updated CLOUDSTACK-6680:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 AutoScaling without NetScaler
 -

 Key: CLOUDSTACK-6680
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6680
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: tuna
Assignee: tuna
 Fix For: 4.4.0


 AutoScaling without using Netscaler device. Work only with XenServer.



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

[jira] [Closed] (CLOUDSTACK-6569) IAM - Regular user is able to listNetworks of another user in the same domain , by passing account and domainId.


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

Sangeetha Hariharan closed CLOUDSTACK-6569.
---


Tested with latest build from 4.4-forward (after IAM revert)

Regular user is not allowed to list network of other accounts in the same 
domain:

2014-06-12 10:28:52,820 INFO  [a.c.c.a.ApiServer] (catalina-exec-5:ctx-08e8e4b8 
ctx-ec14d52d) (userId=7 accountId=7 sessionId=05A235CFC99FACA027D130666C218B1C) 
10.216.50.29 -- GET 
command=listNetworksresponse=jsonsessionkey=ZILTwOXY%2BZYac8MZdC%2BthwzVpHE%3DlistAll=truepage=1pagesize=20account=d1-sandomainid=a35f9e43-1707-4ea8-b776-e6e4e75b8fff
 531 Acct[9489582f-092e-44a4-bc97-5ab7c0a3d30b-d1-san2] does not have 
permission to operate with resource 
Acct[f83f6755-7c50-4557-8cbc-5d0b9410f4fe-d1-san]


 IAM - Regular user is able to listNetworks of another user in the same domain 
 ,  by passing account and domainId.
 -

 Key: CLOUDSTACK-6569
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6569
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 Regular user is able to listNetworks of another user in the same domain ,  by 
 passing account and domainId.
 Domain - d1.
 3 users in this domain , testd1 - domainadmin , testd1a and testd1b regular 
 users.
 Each of the users have 1 isolated network.
  
 As testd1a , tried to list network of testd1b by passing account and 
 domainId. ListNetwork returns   testd1b's isolated network.
 2014-05-02 10:21:29,090 INFO  [a.c.c.a.ApiServer] 
 (catalina-exec-15:ctx-bbcf35b4 ctx-f1b42d4e) (userId=4 accountId=4 
 sessionId=AE73B9C62BB908DE5DE16655DAD0CB75) 10.215.2.8 -- GET 
 command=listNetworksresponse=jsonsessionkey=vHQRHlttApujok8Jf73KKKww5XM%3DlistAll=truepage=1pagesize=20domainid=3abd56e8-97da-40f9-b6f5-33fd5b28b43eresponse=jsonaccount=testD1B-TestNetworkList-KOGK49
  200 { listnetworksresponse : { count:4 ,network : [  
 {id:53a9ddfa-ab63-4f87-bdd0-e368e7fd11ca,name:testD1B-TestNetworkList-KOGK49-network,displaytext:testD1B-TestNetworkList-KOGK49-network,broadcastdomaintype:Vlan,traffictype:Guest,gateway:10.1.1.1,netmask:255.255.255.0,cidr:10.1.1.0/24,zoneid:b690dddf-5755-49ab-8a4d-0aff04fa39f7,zonename:BLR1,networkofferingid:fc25eb7b-d884-4cc3-acbb-a321817a3567,networkofferingname:DefaultIsolatedNetworkOfferingWithSourceNatService,networkofferingdisplaytext:Offering
  for Isolated networks with Source Nat service 
 enabled,networkofferingconservemode:true,networkofferingavailability:Required,issystem:false,state:Implemented,related:53a9ddfa-ab63-4f87-bdd0-e368e7fd11ca,dns1:4.2.2.2,type:Isolated,acltype:Account,account:testD1B-TestNetworkList-KOGK49,domainid:3abd56e8-97da-40f9-b6f5-33fd5b28b43e,domain:D1-R549ZO,service:[{name:PortForwarding},{name:UserData},{name:Firewall,capability:[{name:MultipleIps,value:true,canchooseservicecapability:false},{name:SupportedEgressProtocols,value:tcp,udp,icmp,
  
 all,canchooseservicecapability:false},{name:SupportedProtocols,value:tcp,udp,icmp,canchooseservicecapability:false},{name:SupportedTrafficDirection,value:ingress,
  
 egress,canchooseservicecapability:false},{name:TrafficStatistics,value:per
  public 
 ip,canchooseservicecapability:false}]},{name:Lb,capability:[{name:AutoScaleCounters,value:[{\methodname\:\cpu\,\paramlist\:[]},{\methodname\:\memory\,\paramlist\:[]}],canchooseservicecapability:false},{name:SupportedLBIsolation,value:dedicated,canchooseservicecapability:false},{name:SupportedLbAlgorithms,value:roundrobin,leastconn,source,canchooseservicecapability:false},{name:LbSchemes,value:Public,canchooseservicecapability:false},{name:SupportedProtocols,value:tcp,
  
 udp,canchooseservicecapability:false},{name:SupportedStickinessMethods,value:[{\methodname\:\LbCookie\,\paramlist\:[{\paramname\:\cookie-name\,\required\:false,\isflag\:false,\description\:\
  
 \},{\paramname\:\mode\,\required\:false,\isflag\:false,\description\:\
  
 \},{\paramname\:\nocache\,\required\:false,\isflag\:true,\description\:\
  
 \},{\paramname\:\indirect\,\required\:false,\isflag\:true,\description\:\
  
 \},{\paramname\:\postonly\,\required\:false,\isflag\:true,\description\:\
  
 \},{\paramname\:\domain\,\required\:false,\isflag\:false,\description\:\
  \}],\description\:\This is loadbalancer cookie based stickiness 
 method.\},{\methodname\:\AppCookie\,\paramlist\:[{\paramname\:\cookie-name\,\required\:false,\isflag\:false,\description\:\
  
 \},{\paramname\:\length\,\required\:false,\isflag\:false,\description\:\

[jira] [Updated] (CLOUDSTACK-1633) Why do ACS security groups only support TCP, UDP, ICMP?


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

Animesh Chaturvedi updated CLOUDSTACK-1633:
---


BULK EDIT These tickets (new features | improvements) are tagged for 4.4 but 
still open. If these are not ready for 4.4 please move them out.

 Why do ACS security groups only support TCP, UDP, ICMP?
 ---

 Key: CLOUDSTACK-1633
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1633
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.0.0
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 If I attempt to make an API call to authorizeSecurityGroupIngress specifying 
 a protocol of 41, I get an error of Invalid protocol 41.
 Real-world use for this - Windows AD servers attempt to establish an 
 ISATAP[1] connection between servers. Without opening the firewall, packets 
 will be dropped as shown in the log below:
 Mar 11 19:07:27 c10 kernel: DROP:i-2-1711-VM-eg:IN=cloudbr0 OUT=cloudbr0 
 PHYSIN=vnet2 PHYSOUT=bond1 MAC=00:04:e9:ff:f3:90:06:c5:36:00:00:1a:0f:00 
 SRC=192.168.1.10 DST=192.168.1.20 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=2898 
 PROTO=41
 1:http://en.wikipedia.org/wiki/ISATAP



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

[jira] [Closed] (CLOUDSTACK-6533) IAM - Templates - Public templates do not have permissions to be used by ROOT group.


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

Sangeetha Hariharan closed CLOUDSTACK-6533.
---


Tested with latest build from 4.4-forward (after IAM revert)

ROOT admin is able to see and use templates(for VM deployment) that are owned 
by regular users and is marked as Public. 

 IAM - Templates - Public templates do not have permissions to be used by ROOT 
 group.
 

 Key: CLOUDSTACK-6533
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6533
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 IAM - Templates - Public templates do not have permissions to be used by ROOT 
 group.
 As regular user create a public template.
 In iam_policy_permission policy we do not have permission for Admin group.
 mysql  select * from iam_policy_permission where scope_id = 206;
 +--+---+---++--+--+-++---+-+-+
 | id   | policy_id | action| resource_type  | scope_id | 
 scope| access_type | permission | recursive | removed | created   
   |
 +--+---+---++--+--+-++---+-+-+
 | 4949 | 3 | listTemplates | VirtualMachineTemplate |  206 | 
 RESOURCE | UseEntry| Allow  | 0 | NULL| 2014-04-29 
 11:03:52 |
 | 4950 | 1 | listTemplates | VirtualMachineTemplate |  206 | 
 RESOURCE | UseEntry| Allow  | 0 | NULL| 2014-04-29 
 11:03:52 |
 mysql select * from vm_template where id=206;
 +-+--++--++--+--+-+--+-++-+-++--+-+-+---+-+--+-+-+-+-++--+--+-++--+-+--+
 | id  | unique_name  | name   
 | uuid | public | featured | type | hvm | 
 bits | url | format | created | 
 removed | account_id | checksum | display_text| 
 enable_password | enable_sshkey | guest_os_id | bootable | prepopulate | 
 cross_zones | extractable | hypervisor_type | source_template_id | 
 template_tag | sort_key | size| state  | update_count | updated | 
 dynamically_scalable |
 +-+--++--++--+--+-+--+-++-+-++--+-+-+---+-+--+-+-+-+-++--+--+-++--+-+--+
 | 206 | 206-318-179129bc-531f-31fe-a21d-23a8aa7b666f | 
 Public_featured_d2a-G3GJQW | 265192c9-88d3-41d4-b435-6d3c3e5d256a |  1 |  
   1 | USER |   1 |   64 | http://10.223.110.232:/test.vhd | VHD| 
 2014-04-29 11:03:52 | NULL|318 | NULL | public and feature 
 Template |   0 | 0 |  12 |1 | 
   0 |   0 |   1 | Simulator   |   NULL | NULL 
 |0 | 5242880 | Active |0 | NULL|  
   0 |
 +-+--++--++--+--+-+--+-++-+-++--+-+-+---+-+--+-+-+-+-++--+--+-++--+-+--+
 1 row in set (0.00 sec)
 Inspite of not having the required permissions to use the template , admin is 
 able to use this template for vm deployment. Root cause

[jira] [Closed] (CLOUDSTACK-6517) IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have UseEntry permission for IpAddress.


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

Sangeetha Hariharan closed CLOUDSTACK-6517.
---


Testing with latest build from 4.4-forward (after IAM revert):

Steps to reproduce the problem:

As regular user , on a network he owns , acquire an ip address.
As admin , try to create a PF rule on this ip address  without passing account 
and domainId.

http://10.223.49.6:8080/client/api?command=createPortForwardingRuleresponse=jsonsessionkey=kFu73ky%2BPuW%2BBz9dkcSBIHyXwkM%3Dipaddressid=0817bae5-c672-4ea7-a2cd-ce163d3a8727privateport=22privateendport=22publicport=22publicendport=22protocol=tcpvirtualmachineid=308450de-d4be-4c91-9067-b3826e85e9b2openfirewall=falsenetworkid=9fd8bcef-c140-4061-adc0-5c24c5f7dc69_=1402609388398

This succeeds . This is the desired behavior.

Closing this issue.

 IAM - Admin is allowed to create PortFowarding rule for a regular user, when 
 admin does not have  UseEntry permission for IpAddress. 
 ---

 Key: CLOUDSTACK-6517
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6517
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Prachi Damle
 Fix For: 4.4.0


 IAM - Admin is allowed to create PortFowarding rule for a regular user, when 
 admin does not have  UseEntry permission for IpAddress.
 Steps to reproduce the problem:
 As regular user , on a network he owns , acquire an ip address.
 As admin , try to create a PF rule on this ip address  without passing 
 account and domainId.
 Creating PF rule succeeds. 
 Since Admin has only  ListEntry permission for IpAddress owned by other 
 users , we expect this api call to fail. 
 mysql select * from iam_policy_permission where resource_type = 'IpAddress' 
 and policy_id=2;
 +--+---+---+---+--+-+--++---+-+-+
 | id   | policy_id | action| resource_type | scope_id | scope 
   | access_type  | permission | recursive | removed | created |
 +--+---+---+---+--+-+--++---+-+-+
 | 1840 | 2 | listPublicIpAddresses | IpAddress |   -1 | ALL   
   | ListEntry| Allow  | 0 | NULL| 2014-04-22 18:31:03 |
 | 1841 | 2 | listPublicIpAddresses | IpAddress |   -1 | 
 ACCOUNT | UseEntry | Allow  | 0 | NULL| 2014-04-22 
 18:31:03 |
 Admin should be allowed to do this only , when he passes account and domainId 
 of the regular user is passed.



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

[jira] [Closed] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.

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

Sangeetha Hariharan closed CLOUDSTACK-6512.
---

Tested with latest build from 4.4-forward (after IAM revert):

Have shared networks created with scope as domain and account.

Using UI , Log in as a user who has access to both the account specific and
domain specific shared network.

Try to deploy a VM.

Network list shown as part of VM deployment , has both the shared networks
listed:
Following is the API call made for listing networks:
http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=WRY5kiZ461rcInw5KRwr59dPh8U%3DzoneId=8374d5ac-e559-4a36-88cd-ddc32990659ecanusefordeploy=truedomainid=0c61d5a9-59bd-4f61-97ec-6078acd6e231account=d11-san_=1402609700920

Deploying Vms in these shared networks also succeed.

Closing this issue.

IAM - Not able to list shared networks in the Vm deployment flow.
-

Key: CLOUDSTACK-6512
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Environment: Build from 4.4.
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
Fix For: 4.4.0

IAM - Not able to list shared networks in the Vm deployment flow.
Steps to reproduce the problem:
Create a shared network that is domain specific / account specific.
Log in as the account which should have access to this shared network.
Using UI , try to deploy a VM using this shared network.
shared network is not displayed in the list of networks.
This is the call made by UI:
http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911

When Networks are listed using the network tab , then we see the shared
network being listed.
Following API call without the domainid and account paramater is able to
return the shared network.
http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647

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

[jira] [Closed] (CLOUDSTACK-6501) IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed.

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


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

Sangeetha Hariharan closed CLOUDSTACK-6501.
---


Tested with latest build from 4.4-forward (after IAM revert):

As DomainAdmin , when listVirtualMachines is used with listall=true and account 
and domainId , we are able to list all the Vms owned by the account.

Closing this issue.


 IAM - DomainAdmin - When listVirtualMachines is used with listall=true  and 
 account and domainId , Vms owned by the account account is not listed.
 --

 Key: CLOUDSTACK-6501
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6501
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 IAM - DomainAdmin - When listVirtualMachines is used with listall=true  and 
 account and domainId , Vms owned by the account is not listed.
 Steps to reproduce the problem:
 Set up:
 Pre Reqs:
 Admin - Creates object
 Domain Admin for d1 - D1 - Creates object - d1
 Domain Admin for d1 - D1/D11
 User account for d1 - D1/D111 - Creates object - d111a
 Domain Admin for d1 - D1/D12
 Domain Admin for d2 - D2 - Creates object -d2
 User Account in domain D1 - userD1-1 - Creates object -d1a
 User Account in domain D1 - userD1-2 - Creates object - d1b
 Domain Account in domain D1/D11 - D11 - Creates object - d11
 User Account in domain D1/D11 - userD1-a - Creates object - d11a
 User Account in domain D1/D11 - userD1-a - Creates object - d11b
 User Account in domain D1/D12- userD1-b - Creates object - d12a
 User Account in domain D1/D12 - userD-a - Creates object - d12b
 As domain admin  account D1 , try to list all the Vms for d11 (domain admin 
 user) using account and domainId parameters.
 Expected Result:
 Vm owned by the account that is passed in account/domainId parameter.
 Actual Result:
 Empty set is returned.
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=0e8d9d60-c39a-4304-b048-1e63500d0d30account=testD11listAll=trueisrecursive=trueapiKey=bW1FEJkIERji0cWRNQqvmWOgOINjMeBggyoPsMjN9_Qnvq-QtC6L4ORqmbdfQ-XtUYQdSoJIniZrHK3_oi9pcQsignature=5qLgaWzslWKSz%2FXbVSK0zdj%2B49I%3D
  \n\n
 current Time:  Thu Apr 24 14:43:18 PDT 2014
 ?xml version=1.0 encoding=UTF-8?listvirtualmachinesresponse 
 cloud-stack-version=4.4.0-SNAPSHOT/listvirtualmachinesresponseConnection 
 to 10.223.49.6 8080 port [tcp/webcache] succeeded!
 Response Time(in secs) :  0  current Time:  Thu Apr 24 14:43:18 PDT 2014



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

[jira] [Assigned] (CLOUDSTACK-6896) Dynamically added OS Type throws NoSuchElement Exception on Xen

2014-06-12 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar reassigned CLOUDSTACK-6896:
-

Assignee: Amogh Vasekar  (was: Santhosh Kumar Edukulla)

 Dynamically added OS Type throws NoSuchElement Exception on Xen
 ---

 Key: CLOUDSTACK-6896
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6896
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.4.0
 Environment: Managment Server: 4.4.0
 Host: XenServer Hypervisor 6.2
Reporter: Pavan Kumar Bandarupally
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log


 A dynamically added OS is used as OS type for an ISO registered in 
 cloudstack. An instance deployed using that ISO doesn't get created throwing 
 an exception.
 MS Exception trace excerpt:
 = 
 2014-06-12 02:03:45,707 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-281:ctx-c47880f2) Seq 1-5437252125119752015: Executing request
 2014-06-12 02:03:45,720 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) 1. The VM i-2-8-VM is in Starting state.
 2014-06-12 02:03:45,723 WARN  [c.c.h.x.r.XenServer620Resource] 
 (DirectAgent-281:ctx-c47880f2) XenServer 6.2.0 DOES NOT support Guest OS type 
 centospavan
 2014-06-12 02:03:45,726 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Cannot find template : null on XS version: 
 com.cloud.hypervisor.xen.resource.XenServer620Resource
 2014-06-12 02:03:45,727 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Catch Exception: class 
 java.util.NoSuchElementException due to java.util.NoSuchElementException
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-06-12 02:03:45,729 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Unable to start i-2-8-VM due to
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at

[jira] [Commented] (CLOUDSTACK-6907) listVolumes: diskOfferingId is returned for the volume instead of service offering id, if its a root volume detached from the vm


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

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

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

CLOUDSTACK-6907: lisVolumes - make a decision whether to set service or disk 
offering in the response, based on the DiskOfferingVO type entry, not the 
volume Type


 listVolumes: diskOfferingId is returned for the volume instead of service 
 offering id, if its a root volume detached from the vm
 

 Key: CLOUDSTACK-6907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1) Deploy vm. Stop it.
 2) Detach the Root volume. It becomes a DataDisk
 3) execute listVolumes call.
 Bug: volumes that were originally created as Root, reference service offering 
 instead of a disk offering. But the API just assumes that if the disk Type is 
 DataDisk, then diskOffering should be returned.
 Api has to be smarter while figuring out what to return - service or disk 
 offering id - and return the service offering if thats what the id of the 
 offering represents.



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

[jira] [Resolved] (CLOUDSTACK-6896) Dynamically added OS Type throws NoSuchElement Exception on Xen

2014-06-12 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar resolved CLOUDSTACK-6896.
---

Resolution: Won't Fix

 Dynamically added OS Type throws NoSuchElement Exception on Xen
 ---

 Key: CLOUDSTACK-6896
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6896
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.4.0
 Environment: Managment Server: 4.4.0
 Host: XenServer Hypervisor 6.2
Reporter: Pavan Kumar Bandarupally
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log


 A dynamically added OS is used as OS type for an ISO registered in 
 cloudstack. An instance deployed using that ISO doesn't get created throwing 
 an exception.
 MS Exception trace excerpt:
 = 
 2014-06-12 02:03:45,707 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-281:ctx-c47880f2) Seq 1-5437252125119752015: Executing request
 2014-06-12 02:03:45,720 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) 1. The VM i-2-8-VM is in Starting state.
 2014-06-12 02:03:45,723 WARN  [c.c.h.x.r.XenServer620Resource] 
 (DirectAgent-281:ctx-c47880f2) XenServer 6.2.0 DOES NOT support Guest OS type 
 centospavan
 2014-06-12 02:03:45,726 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Cannot find template : null on XS version: 
 com.cloud.hypervisor.xen.resource.XenServer620Resource
 2014-06-12 02:03:45,727 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Catch Exception: class 
 java.util.NoSuchElementException due to java.util.NoSuchElementException
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-06-12 02:03:45,729 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Unable to start i-2-8-VM due to
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at

[jira] [Resolved] (CLOUDSTACK-6907) listVolumes: diskOfferingId is returned for the volume instead of service offering id, if its a root volume detached from the vm

2014-06-12 Thread Alena Prokharchyk (JIRA)


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

Alena Prokharchyk resolved CLOUDSTACK-6907.
---

Resolution: Fixed

 listVolumes: diskOfferingId is returned for the volume instead of service 
 offering id, if its a root volume detached from the vm
 

 Key: CLOUDSTACK-6907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1) Deploy vm. Stop it.
 2) Detach the Root volume. It becomes a DataDisk
 3) execute listVolumes call.
 Bug: volumes that were originally created as Root, reference service offering 
 instead of a disk offering. But the API just assumes that if the disk Type is 
 DataDisk, then diskOffering should be returned.
 Api has to be smarter while figuring out what to return - service or disk 
 offering id - and return the service offering if thats what the id of the 
 offering represents.



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

[jira] [Commented] (CLOUDSTACK-6907) listVolumes: diskOfferingId is returned for the volume instead of service offering id, if its a root volume detached from the vm

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


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

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

Commit 43e479d238649e3ab61259b6b57e56152f1ecb29 in cloudstack's branch 
refs/heads/4.4-forward from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=43e479d ]

CLOUDSTACK-6907: lisVolumes - make a decision whether to set service or disk 
offering in the response, based on the DiskOfferingVO type entry, not the 
volume Type


 listVolumes: diskOfferingId is returned for the volume instead of service 
 offering id, if its a root volume detached from the vm
 

 Key: CLOUDSTACK-6907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
 Fix For: 4.5.0


 Steps to reproduce:
 1) Deploy vm. Stop it.
 2) Detach the Root volume. It becomes a DataDisk
 3) execute listVolumes call.
 Bug: volumes that were originally created as Root, reference service offering 
 instead of a disk offering. But the API just assumes that if the disk Type is 
 DataDisk, then diskOffering should be returned.
 Api has to be smarter while figuring out what to return - service or disk 
 offering id - and return the service offering if thats what the id of the 
 offering represents.



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

[jira] [Commented] (CLOUDSTACK-6896) Dynamically added OS Type throws NoSuchElement Exception on Xen

2014-06-12 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar commented on CLOUDSTACK-6896:
---

Hi,

This is by design - as mentioned in the functional spec at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability+to+add+new+guest+OS+mappings
the admin will be responsible for providing the mapping to hypervisor-specific 
platform names based on his knowledge, which may be enhanced in future

Thanks!

 Dynamically added OS Type throws NoSuchElement Exception on Xen
 ---

 Key: CLOUDSTACK-6896
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6896
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.4.0
 Environment: Managment Server: 4.4.0
 Host: XenServer Hypervisor 6.2
Reporter: Pavan Kumar Bandarupally
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.log


 A dynamically added OS is used as OS type for an ISO registered in 
 cloudstack. An instance deployed using that ISO doesn't get created throwing 
 an exception.
 MS Exception trace excerpt:
 = 
 2014-06-12 02:03:45,707 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-281:ctx-c47880f2) Seq 1-5437252125119752015: Executing request
 2014-06-12 02:03:45,720 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) 1. The VM i-2-8-VM is in Starting state.
 2014-06-12 02:03:45,723 WARN  [c.c.h.x.r.XenServer620Resource] 
 (DirectAgent-281:ctx-c47880f2) XenServer 6.2.0 DOES NOT support Guest OS type 
 centospavan
 2014-06-12 02:03:45,726 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Cannot find template : null on XS version: 
 com.cloud.hypervisor.xen.resource.XenServer620Resource
 2014-06-12 02:03:45,727 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Catch Exception: class 
 java.util.NoSuchElementException due to java.util.NoSuchElementException
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-06-12 02:03:45,729 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-281:ctx-c47880f2) Unable to start i-2-8-VM due to
 java.util.NoSuchElementException
 at 
 java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359)
 at

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

2014-06-12 Thread Min Chen (JIRA)


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

Min Chen updated CLOUDSTACK-6797:
-

Comment: was deleted

(was: Consulted with Alex, newly created volumes should also be counted in 
allocated space even if it is not attached to a VM. So #1 you mentioned here 
may be a bug in our product.)

 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] [Issue Comment Deleted] (CLOUDSTACK-6797) volume resize should not be allowed for detached volumes

2014-06-12 Thread Min Chen (JIRA)


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

Min Chen updated CLOUDSTACK-6797:
-

Comment: was deleted

(was: Prashant, you mean that when you tried resizing volume on an attached 
volume on vmware, even though that our primary storage cannot fulfill the task, 
it is not errored out?)

 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] [Commented] (CLOUDSTACK-6797) volume resize should not be allowed for detached volumes

2014-06-12 Thread Min Chen (JIRA)


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

Min Chen commented on CLOUDSTACK-6797:
--

Assigned to Marcus to investigate this issue since he is the expert on resize 
volume feature. Based on communication with Prashant, the problem is this: 
although resizeVolume did resource limit check and maxVolumeSize check in the 
flow, it didn't really check the real available storage space in a storage 
pool. For attached volume, it replies on sending resizeVolumeCommand to storage 
pool to error out, but for detached volume, it will succeed even though user 
gave a very large size that outnumber our storage pool capacity. Actually 
relying on sending resizeVolumeCommand to storage pool to error out is not an 
ideal solution, the better fix should be checking currently available space on 
storage pool to early abort if a big size is provided, just like how we did in 
StoragePoolAllocator to check whether a pool has enough space.

 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] [Resolved] (CLOUDSTACK-4568) Need to add this to the release note of 4.2


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

Pierre-Luc Dion resolved CLOUDSTACK-4568.
-

Resolution: Fixed

information added in 4.4.0 release-notes in General Upgrade Notes.

 Need to add this to the release note of 4.2
 ---

 Key: CLOUDSTACK-4568
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4568
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.2.0
Reporter: Bharat Kumar
Assignee: Pierre-Luc Dion
  Labels: releasenotes
 Fix For: 4.4.0


 After upgrade to 4.2 the  mem.overporvisioning.factor and 
 cpu.overporvisioning.factor will be set to one that is the default value and 
 are at cluster level now.
 In case if some one prior to the 4.2 was usign mem.overporvisioning.factor 
 and  cpu.overporvisioning.factor after the upgrade these will be reset to one 
 and can be changed by editing the cluster settings.
 All the clusters created after the upgrade will get created with the values 
 overcomit values specified at the global config by default. 



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

[jira] [Commented] (CLOUDSTACK-3381) Wrong instruction in CloudStack release notes


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

Pierre-Luc Dion commented on CLOUDSTACK-3381:
-

Can I close this issue? The script and release-notes are updated and now use:

{code}
nohup cloudstack-sysvmadm -d IP address -u cloud -p password -a  sysvm.log 
21 
{code}

 Wrong instruction in CloudStack release notes
 -

 Key: CLOUDSTACK-3381
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3381
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.1.0
 Environment: Link to particular documentation article: 
 http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Release_Notes/upgrade-instructions.html
Reporter: Aabd
Assignee: Pierre-Luc Dion
  Labels: documentation

 The CloudStack upgrade instructions contains an error. 
 At some point the reader is instructed to execute the command:
 nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r  sysvm.log 
 21 
 This should be:
 nohup cloudstack-sysvmadm -d 192.168.1.5 -u cloud -p password -s -r  
 sysvm.log 21 
 * The cloud-sysvmadm script does not exist, this should be 
 cloudstack-sysvmadm.
 * The -c argument does not exist in the sysvmadm script. As a result of this 
 of this, only the virtual router vm is restarted. A quick glance at the code 
 of the sysvmadm scripts reveals that a reboot of the secondary storage vm and 
 console proxy vm is initiated by the -s parameter.



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

[jira] [Assigned] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes


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

Pierre-Luc Dion reassigned CLOUDSTACK-6902:
---

Assignee: Pierre-Luc Dion

 Document in the release notes that OVS plug-in functionality is disrupted if 
 ovsdaemon crashes
 --

 Key: CLOUDSTACK-6902
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.4.0
Reporter: Murali Reddy
Assignee: Pierre-Luc Dion
 Fix For: 4.4.0


 A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it 
 is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing 
 all the openflow rules added to the bridge. Ovs daemon gets started and 
 creates a bridge but configure openflow rules are lost resulting in the 
 disruption of connectivity for the VM's on the host.
 We need to document it in the release notes as a known issue.



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

[jira] [Closed] (CLOUDSTACK-6349) IAM - No error message presented to the user , when invalid password is provided.


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

Sangeetha Hariharan closed CLOUDSTACK-6349.
---


Tested with latest build from 4.4-forward ( after IAM revert)
When regular user tries to log in with invalid  password, following error 
message is presented to the user:

Invalid username or password

 IAM - No error message presented to the user , when invalid password is 
 provided.
 -

 Key: CLOUDSTACK-6349
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6349
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4.
Reporter: Sangeetha Hariharan
Assignee: Prachi Damle
Priority: Critical
 Fix For: 4.4.0


 Try to log in as regular user , by providing invalid username/password.
 User is not presented with any error message:
 apilog.log:
 2014-04-07 10:51:15,849 INFO  [a.c.c.a.ApiServer] 
 (catalina-exec-6:ctx-5511ac44)  10.215.3.0 -- POST command=login domain=/ 
 unknown exception writing api response
 Management server log:
 2014-04-07 10:47:28,001 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-845578ba) ===START===  10.215.3.0 -- POST
 2014-04-07 10:47:28,003 DEBUG [c.c.u.AccountManagerImpl] 
 (catalina-exec-3:ctx-845578ba) Attempting to log in user: test in domain 1
 2014-04-07 10:47:28,003 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] 
 (catalina-exec-3:ctx-845578ba) Retrieving user: test
 2014-04-07 10:47:28,005 DEBUG [c.c.s.a.MD5UserAuthenticator] 
 (catalina-exec-3:ctx-845578ba) Retrieving user: test
 2014-04-07 10:47:28,009 DEBUG [c.c.s.a.MD5UserAuthenticator] 
 (catalina-exec-3:ctx-845578ba) Password does not match
 2014-04-07 10:47:28,012 DEBUG [c.c.s.a.PlainTextUserAuthenticator] 
 (catalina-exec-3:ctx-845578ba) Retrieving user: test
 2014-04-07 10:47:28,016 DEBUG [c.c.s.a.PlainTextUserAuthenticator] 
 (catalina-exec-3:ctx-845578ba) Password does not match
 2014-04-07 10:47:28,016 DEBUG [c.c.u.AccountManagerImpl] 
 (catalina-exec-3:ctx-845578ba) Unable to authenticate user with username test 
 in domain 1
 2014-04-07 10:47:28,019 ERROR [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-845578ba) unknown exception writing api response
 com.cloud.exception.InvalidParameterValueException: Caller cannot be passed 
 as NULL to IAM!
 at 
 org.apache.cloudstack.iam.RoleBasedEntityAccessChecker.checkAccess(RoleBasedEntityAccessChecker.java:67)
 at 
 com.cloud.user.AccountManagerImpl.isRootAdmin(AccountManagerImpl.java:371)
 at 
 com.cloud.user.AccountManagerImpl.isInternalAccount(AccountManagerImpl.java:420)
 at 
 com.cloud.user.AccountManagerImpl.getUserAccount(AccountManagerImpl.java:2045)
 at 
 com.cloud.user.AccountManagerImpl.authenticateUser(AccountManagerImpl.java:1871)
 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 $Proxy99.authenticateUser(Unknown Source)
 at com.cloud.api.ApiServer.loginUser(ApiServer.java:850)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:231)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
 at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82)

[jira] [Commented] (CLOUDSTACK-4497) [doc] Update Installation Guide

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

Pierre-Luc Dion commented on CLOUDSTACK-4497:
-

Radhika, I think we can close this issue since all references to cloudstack-*
have been updated in the documentation?

[doc] Update Installation Guide
---

Key: CLOUDSTACK-4497
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4497
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Doc
Reporter: Radhika Nair

• Update the supported operating systems and hypervisor versions.
• Where the current documentation directs you to run the script
cloud-setup-databases, use the
following name instead: cloudstack-setup-databases.
• When seeding the system VM template, use the following new path to the
script: /usr/share/
cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt.
• The location of Management Server configuration and properties files is now
/etc/cloudstack/ management/. For example, in database failover setup (an
optional part of installation), where the current documentation shows
/etc/cloud/management/db.properties, use the following path instead:
/etc/cloudstack/management/db.properties.
• The names of the Management Server and Usage Server services have changed
to cloudstack- management and cloudstack-usage. Use this name in commands to
start, stop, or restart these services.
• System VM templates have changed. Be sure to download the latest templates
from Location: To Be Supplied
• The location of the Management Server log file is now
/var/log/cloudstack/management/.
• (XenServer only) The script cloud-setup-bonding.sh is now located at
/usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/.
• (XenServer only) In the procedure for upgrading XenServer versions, you
copy some files from the Management Server to the XenServer host. The new
location of these files on the Management Server is
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver and
/usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/xenserver60.
• (KVM only) During network configuration, where the current documentation
shows /etc/cloud/agent/agent.properties, use the following path instead:
/etc/cloudstack/agent/agent.properties.
• (KVM only) The location of the CloudPlatform KVM agent log file is now
/var/log/cloudstack/agent/.
• (KVM only) The location of configuration and properties files is now
/etc/cloudstack/agent.
• (KVM only) The name of the CloudPlatform agent script has changed to
cloudstack-agent. Use this name if you need to stop or restart the agent on
the KVM host.

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

[jira] [Closed] (CLOUDSTACK-6348) IAM - Regular User is not able to change password.


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

Sangeetha Hariharan closed CLOUDSTACK-6348.
---


Tested with latest build from 4.4-forward ( after IAM revert)
Regular user is able to change his password successfully.

 IAM - Regular User is not able to change password.
 --

 Key: CLOUDSTACK-6348
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6348
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan
Assignee: Prachi Damle
Priority: Critical
 Fix For: 4.4.0


 Steps to reproduce the problem:
 As regular user , try to change password.
 Following error message is presented to the user:
 Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test] does not have permission to 
 access resource Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test]
 Management server log:
 2014-04-07 10:43:58,185 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-3b2e2f03) ===START===  10.215.3.0 -- POST  
 command=updateUserresponse=jsonsessionkey=P7c7ohM5rOC6mJLLima8CXlOAho%3D
 2014-04-07 10:43:58,204 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] 
 (catalina-exec-4:ctx-3b2e2f03 ctx-8030779f) Account 
 Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test] does not have permission to 
 access resource Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test] for access 
 type: OperateEntry
 2014-04-07 10:43:58,211 INFO  [c.c.a.ApiServer] (catalina-exec-4:ctx-3b2e2f03 
 ctx-8030779f) PermissionDenied: 
 Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test] does not have permission to 
 access resource Acct[eb54ae7f-c932-4513-aab6-984f03f9df41-test] on objs: []
 2014-04-07 10:43:58,212 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-3b2e2f03 ctx-8030779f) ===END===  10.215.3.0 -- POST  
 command=updateUserresponse=jsonsessionkey=P7c7ohM5rOC6mJLLima8CXlOAho%3D



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

[jira] [Closed] (CLOUDSTACK-6468) IAM - Templates - Admin user is not allowed to edit template and set isExtractable() paramater.


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

Sangeetha Hariharan closed CLOUDSTACK-6468.
---


Tested with latest build from 4.4-forward ( after IAM revert):

Admin is able to set the isFeatured flag for templates that are owned by 
regular users.

 IAM - Templates - Admin user is not allowed to edit template and set 
 isExtractable() paramater.
 ---

 Key: CLOUDSTACK-6468
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6468
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan
Assignee: Min Chen
 Fix For: 4.4.0


 IAM - Templates - Admin user is not allowed to edit template and set 
 isExtractable() paramater.
 From UI , As admin , tried to update the isFeatured() flag to true for a 
 template that was created by regular user.
 This fails with Only ROOT admins are allowed to modify this attribute.
 http://10.223.49.6:8080/client/api?command=updateTemplatePermissionsresponse=jsonsessionkey=1WTLpcX%2FCiA4QLBY3RZTTB0ceaE%3Did=851cfe02-d91f-4226-b325-b48a09d2a2afispublic=falseisfeatured=trueisextractable=true_=1398114267369
 { updatetemplatepermissionsresponse : 
 {uuidList:[],errorcode:431,cserrorcode:4350,errortext:Only ROOT 
 admins are allowed to modify this attribute.} }



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

[jira] [Assigned] (CLOUDSTACK-4467) [Doc] Enhance the Upgrade Section for Clarity


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

Pierre-Luc Dion reassigned CLOUDSTACK-4467:
---

Assignee: Pierre-Luc Dion

 [Doc] Enhance the Upgrade Section for Clarity
 -

 Key: CLOUDSTACK-4467
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4467
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Pierre-Luc Dion
Priority: Critical
 Fix For: Future


 Suggestion from Frank
 the upgrade instructions should be divided in two parts. mgmt server upgrade 
 and kvm agent upgrade. upgrading cloud-agent is actually upgrading KVM agent 
 running on host. Putting them together will confuse customers who don't use 
 KVM
 the same applies to upgrading xenserver and usage server. we should put them 
 in dedicated chapter, now all stuff are in a single chapter which is quite 
 confusing.
 can we arrange them like this:
 Upgrade management server
 4.0 to 4.2
 2.2.x to 4.2
 Upgrade cloud agent
 4.0 to 4.2
 2.2.x to 4.2
 Upgrade usage server
 4.0 to 4.2
 2.2.x to 4.2
 Upgrade Xenserver host



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

[jira] [Closed] (CLOUDSTACK-6381) IAM - DomainAdmin - When listVirtualMachines is used with listall=true (with out passing isrecursive falg) , all Vms from the subdomain are also listed.


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

Sangeetha Hariharan closed CLOUDSTACK-6381.
---


Tested with latest build from 4.4-forward ( after IAM revert)

Only when domainId is passed to list commands , isrecursive() flag is 
considered. In all other cases , it is defaulted to true.
This behavior is as expected.

Closing this issue.

 IAM - DomainAdmin - When listVirtualMachines is used with listall=true (with 
 out passing isrecursive falg) , all Vms from the subdomain are also listed.
 

 Key: CLOUDSTACK-6381
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6381
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4.
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 IAM - DomainAdmin - When listVirtualMachines is used with listall=true (with 
 out passing isrecursive falg) , all Vms from the subdomain are also listed.
 Set up:
 Pre Reqs:
 Admin - Creates object
 Domain Admin  for d1 - D1  - Creates object - d1
 Domain Admin  for d1 - D1/D11
 User account  for d1 - D1/D111 - Creates object - d111a
 Domain Admin  for d1 - D1/D12
 Domain Admin  for d2 - D2 - Creates object -d2
 User Account in domain D1 - userD1-1 - Creates object -d1a 
 User Account in domain D1 - userD1-2 - Creates object - d1b
 User Account in domain D1/D11 - userD1-a - Creates object - d11a
 User Account in domain D1/D11 - userD1-a - Creates object - d11b
 User Account in domain D1/D12- userD1-b - Creates object - d12a
 User Account in domain D1/D12 - userD-a - Creates object - d12b
 As domain admin - D1 , i tried to listVistualMachines passing listAll=true 
 parameter (no isrecurssive parameter). 
 Expected result:
 only all the Vms that belong to this domain should be listed , which should 
 be 3 Vms , d1,d1a and d1b.
 But I see 8 Vms being returned , which also includes the Vms in the domain, 
 d12 and d111.
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachineslistAll=trueapiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REwsignature=cDqQMD6qlKeiz2g40pSOYqJKqoE%3D
  \n\n
 ?xml version=1.0 encoding=UTF-8?listvirtualmachinesresponse 
 cloud-stack-version=4.4.0-SNAPSHOTcount8/countvirtualmachineid22193996-12f9-46ff-91cd-3d409f7f8c60/idnamed11a/namedisplaynamed11a/displaynameaccounttestD11A-TestVMList-3385RP/accountdomainid0a0f7c09-2f1a-4939-94ce-88388e197949/domainiddomainD11-UFBXGQ/domaincreated2014-04-10T09:01:37-0400/createdstateRunning/statehaenablefalse/haenablezoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenametemplateide65cdfa0-c019-11e3-907f-4adf980f9414/templateidtemplatenameCentOS
  5.3(64-bit) no GUI (Simulator)/templatenametemplatedisplaytextCentOS 
 5.3(64-bit) no GUI 
 (Simulator)/templatedisplaytextpasswordenabledfalse/passwordenabledserviceofferingid49dee9f8-a49a-414d-b8b2-b0d59b5981f0/serviceofferingidserviceofferingnameSmall
  
 Instance/serviceofferingnamecpunumber1/cpunumbercpuspeed100/cpuspeedmemory128/memorycpuused10%/cpuusednetworkkbsread10190848/networkkbsreadnetworkkbswrite5095424/networkkbswriteguestoside5eba5c4-c019-11e3-907f-4adf980f9414/guestosidrootdeviceid0/rootdeviceidrootdevicetypeROOT/rootdevicetypenicida1c079e5-ae0f-4470-b0ed-26895fbcf14d/idnetworkidf1cf7cfb-c354-47c4-854e-af329c54d77e/networkidnetworknametestD11A-TestVMList-3385RP-network/networknamenetmask255.255.255.0/netmaskgateway10.1.1.1/gatewayipaddress10.1.1.217/ipaddressisolationurivlan://1071/isolationuribroadcasturivlan://1071/broadcasturitraffictypeGuest/traffictypetypeIsolated/typeisdefaulttrue/isdefaultmacaddress02:00:06:7b:00:01/macaddress/nichypervisorSimulator/hypervisorisdynamicallyscalablefalse/isdynamicallyscalableostypeid11/ostypeid/virtualmachinevirtualmachineid660a829f-5265-44c3-aa92-957d8bbec8e2/idnamed1a/namedisplaynamed1b/displaynameaccounttestD1B-TestVMList-CB23CT/accountdomainiddc4bf103-27bf-4292-99aa-dc91fa23ee04/domainiddomainD1-NN5QWT/domaincreated2014-04-10T09:01:32-0400/createdstateRunning/statehaenablefalse/haenablezoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenametemplateide65cdfa0-c019-11e3-907f-4adf980f9414/templateidtemplatenameCentOS
  5.3(64-bit) no GUI (Simulator)/templatenametemplatedisplaytextCentOS 
 5.3(64-bit) no GUI 
 (Simulator)/templatedisplaytextpasswordenabledfalse/passwordenabledserviceofferingid49dee9f8-a49a-414d-b8b2-b0d59b5981f0/serviceofferingidserviceofferingnameSmall

[jira] [Closed] (CLOUDSTACK-6429) IAM - As admin , When listAll=false is used to list all Vms under a subdomain , all Vms (even those that are not in this subdmain) are listed.


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

Sangeetha Hariharan closed CLOUDSTACK-6429.
---


 IAM - As admin , When listAll=false is used to list all Vms under a subdomain 
 , all Vms (even those that are not in this subdmain) are listed.
 --

 Key: CLOUDSTACK-6429
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6429
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: IAM
Affects Versions: 4.4.0
 Environment: Build from 4.4
Reporter: Sangeetha Hariharan
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


 IAM - As admin , When listAll=false is used to list all Vms under a subdomain 
 , all Vms (even those that are not in this subdmain) are listed.
 Steps to reproduce the problem:
 Set up:
 Pre Reqs:
 Admin - Creates object
 Domain Admin for d1 - D1 - Creates object - d1
 Domain Admin for d1 - D1/D11
 User account for d1 - D1/D111 - Creates object - d111a
 Domain Admin for d1 - D1/D12
 Domain Admin for d2 - D2 - Creates object -d2
 User Account in domain D1 - userD1-1 - Creates object -d1a
 User Account in domain D1 - userD1-2 - Creates object - d1b
 User Account in domain D1/D11 - userD1-a - Creates object - d11a
 User Account in domain D1/D11 - userD1-a - Creates object - d11b
 User Account in domain D1/D12- userD1-b - Creates object - d12a
 User Account in domain D1/D12 - userD-a - Creates object - d12b
 As ROOT admin , tried to list all the Vms for domain - d1/d11 , this results 
 in all the Vms (even those that are not in this subdmain) being listed.
 All the following API calls as Admin when trying to list Vms from domain - 
 d1/d11 , results in 11 Vms which is all the Vms in the cluouds.
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=7add6894-37ba-4b9a-bc43-12e49c3599c0listAll=falseapiKey=oKz6XB3IKFtUTdw_0rYhGMk4AV0ih4AvpPKCcD-KO51d6qYpyPXLPOjoHp5V02-J-pwnci7khJvhV0c4XDP8agsignature=1S3PA2HyPP70jnv5FiKSp%2FXfqw4%3D
  \n\n
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=7add6894-37ba-4b9a-bc43-12e49c3599c0listAll=falseisrecursive=falseapiKey=oKz6XB3IKFtUTdw_0rYhGMk4AV0ih4AvpPKCcD-KO51d6qYpyPXLPOjoHp5V02-J-pwnci7khJvhV0c4XDP8agsignature=FtoJ8isO896ZkqLJH5YzVjodFdg%3D
  \n\n
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=7add6894-37ba-4b9a-bc43-12e49c3599c0listAll=falseisrecursive=trueapiKey=oKz6XB3IKFtUTdw_0rYhGMk4AV0ih4AvpPKCcD-KO51d6qYpyPXLPOjoHp5V02-J-pwnci7khJvhV0c4XDP8agsignature=4HHrtJo1Cx3yqjdIHUFi43kqZ3E%3D
  \n\n
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=7add6894-37ba-4b9a-bc43-12e49c3599c0isrecursive=falseapiKey=oKz6XB3IKFtUTdw_0rYhGMk4AV0ih4AvpPKCcD-KO51d6qYpyPXLPOjoHp5V02-J-pwnci7khJvhV0c4XDP8agsignature=A6kJuc9XDIp6f9Ha8Bp9Ig3Xigg%3D
  \n\n
 GET 
 http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=7add6894-37ba-4b9a-bc43-12e49c3599c0isrecursive=trueapiKey=oKz6XB3IKFtUTdw_0rYhGMk4AV0ih4AvpPKCcD-KO51d6qYpyPXLPOjoHp5V02-J-pwnci7khJvhV0c4XDP8agsignature=S04gwOtMs0%2F00CV4I1Q7pbCCC08%3D
  \n\n



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

[jira] [Commented] (CLOUDSTACK-6429) IAM - As admin , When listAll=false is used to list all Vms under a subdomain , all Vms (even those that are not in this subdmain) are listed.