[jira] [Commented] (CLOUDSTACK-6392) system template always create with name "master" instead of specific branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013391#comment-14013391 ] ASF subversion and git services commented on CLOUDSTACK-6392: - Commit b4021284b853362f414e68e52deb5ba92734a7e2 in cloudstack's branch refs/heads/4.4 from rayeesn [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b402128 ] CLOUDSTACK-6392: system template always create with name master instead of specific branch Signed-off-by: Abhinandan Prateek > system template always create with name "master" instead of specific branch > --- > > Key: CLOUDSTACK-6392 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6392 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > > Create system vm from jenkins.buildacloud.org > in 4.4 System vm always create with same name > "systemvm64template-master-xen.vhd" > it should be create with name "systemvm64template-4.4-xen.vhd" -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
Abhinav Roy created CLOUDSTACK-6810:
---
Summary: Migration of a VM with volumes in local storage to
another host in the same cluster is failing
Key: CLOUDSTACK-6810
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
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 advanced zone setup having 2 clusters and local
storage enabled
Reporter: Abhinav Roy
Priority: Blocker
Fix For: 4.4.0
Steps :
==
1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
enabled
2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
3. Create a VM v1 on h1 with its volume on local storage.
4. now migrate v1 to h2
Expected behavior :
===
Migration of v1 to h2 with storage should succeed.
Observed behavior :
===
1. Migration fails with :
2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet] (catalina-exec-17:ctx-974c06fb
ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
cmdInfo:
{"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
ctxdetails
2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114 execution
on object VmWorkJobQueue.20
2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
(API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find lock
for the key vm_instance20 and thread id 1502122810
2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item: SyncQueueItemVO
{id:49, queueId: 47, contentType: AsyncJob, contentId: 114, lastProcessMsid:
null, lastprocessNumber: null, lastProcessTime: null, created: Fri May 30
12:11:15 IST 2014}
2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
MgmtId: -1, via: 3, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2014-05-30 12:11:16,486 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Add job-114 into job
monitoring
2014-05-30 12:11:16,486 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Executing AsyncJobVO
{id:114, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyACVjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZVdpdGhTdG9yYWdlsew9z6UxtXMCAANKAApkZXN0SG9zdElkSgAJc3JjSG9zdElkTAAMdm9sdW1lVG9Qb29sdAAPTGphdmEvdXRpbC9NYXA7eHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgAUdAAZVmlydHVhbE1hY2hpbmVNYW5hZ2VySW1wbAACAAFzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAHg,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Fri May 30 12:11:15 IST 2014}
2014-05-30 12:11:16,487 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-41:ctx-1
[jira] [Assigned] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh reassigned CLOUDSTACK-6810:
-
Assignee: Devdeep Singh
> Migration of a VM with volumes in local storage to another host in the same
> cluster is failing
> --
>
> Key: CLOUDSTACK-6810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
> 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 advanced zone setup having 2 clusters and local
> storage enabled
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.4.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
> enabled
> 2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
> 3. Create a VM v1 on h1 with its volume on local storage.
> 4. now migrate v1 to h2
> Expected behavior :
> ===
> Migration of v1 to h2 with storage should succeed.
> Observed behavior :
> ===
> 1. Migration fails with :
> 2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-974c06fb ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
> command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
> 2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
> 2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
> cmdInfo:
> {"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
> parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
> ctxdetails
> 2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114
> execution on object VmWorkJobQueue.20
> 2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find
> lock for the key vm_instance20 and thread id 1502122810
> 2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item:
> SyncQueueItemVO {id:49, queueId: 47, contentType: AsyncJob, contentId: 114,
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
> created: Fri May 30 12:11:15 IST 2014}
> 2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
> 2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-05-30 12:11:16,486 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Add job-114 into job
> monitoring
> 2014-05-30 12:11:16,486 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Executing AsyncJobVO
> {id:114, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyACVjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZVdpdGhTdG9yYWdlsew9z6UxtXMCAANKAApkZXN0SG9zdElkSgAJc3JjSG9zdElkTAAMdm9sdW1lVG9Qb29sdAAPTGphdmEvdXRpbC9NYXA7eHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgAUdAAZVmlydHVhbE1hY2hpbmVNYW5hZ2VySW1wb
[jira] [Commented] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013444#comment-14013444
]
ASF subversion and git services commented on CLOUDSTACK-6810:
-
Commit f5ce280da32c4e0837fa39651dc801ba3f906e41 in cloudstack's branch
refs/heads/4.4-forward from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5ce280 ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Migration of a VM with volumes in local storage to another host in the same
> cluster is failing
> --
>
> Key: CLOUDSTACK-6810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
> 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 advanced zone setup having 2 clusters and local
> storage enabled
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.4.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
> enabled
> 2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
> 3. Create a VM v1 on h1 with its volume on local storage.
> 4. now migrate v1 to h2
> Expected behavior :
> ===
> Migration of v1 to h2 with storage should succeed.
> Observed behavior :
> ===
> 1. Migration fails with :
> 2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-974c06fb ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
> command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
> 2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
> 2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
> cmdInfo:
> {"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
> parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
> ctxdetails
> 2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114
> execution on object VmWorkJobQueue.20
> 2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find
> lock for the key vm_instance20 and thread id 1502122810
> 2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item:
> SyncQueueItemVO {id:49, queueId: 47, contentType: AsyncJob, contentId: 114,
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
> created: Fri May 30 12:11:15 IST 2014}
> 2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
> 2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
>
[jira] [Commented] (CLOUDSTACK-6802) Attaching a data disk created on local storage to a VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013445#comment-14013445
]
ASF subversion and git services commented on CLOUDSTACK-6802:
-
Commit f5ce280da32c4e0837fa39651dc801ba3f906e41 in cloudstack's branch
refs/heads/4.4-forward from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5ce280 ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Attaching a data disk created on local storage to a VM is failing
> -
>
> Key: CLOUDSTACK-6802
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6802
> 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
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Critical
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.4.0
>
>
> Steps :
> =
> 1. Deploy a CS advanced zone setup with both local storage and shared storage
> enabled.
> 2. Deploy VMs. ( both on shared and local storage)
> 3. create a disk offering with local storage
> 4. Create a data disk with local storage disk offering.
> 5. attach the datadisk created on step 4 to VM created on step 2
> Expected result :
> ===
> Volume should be attached successfully.
> Observed result :
> ==
> volume attach fails with following error.
> 2014-05-29 13:02:45,410 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22) ===START=== 10.101.254.225 -- GET
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,466 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) submit async job-64, details:
> AsyncJobVO {id:64, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","ctxAccountId":"2","ctxStartEventId":"125","zoneId":"242c701a-43e8-4790-84f3-9112ca0b5db7"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-29 13:02:45,467 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) ===END=== 10.101.254.225 -- GET
>
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,470 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Add job-64 into job monitoring
> 2014-05-29 13:02:45,470 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Executing AsyncJobVO {id:64,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"140134849421
[jira] [Commented] (CLOUDSTACK-6802) Attaching a data disk created on local storage to a VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013458#comment-14013458
]
ASF subversion and git services commented on CLOUDSTACK-6802:
-
Commit 7c2b1deb34c0210f812409b6b0f07b04e0142238 in cloudstack's branch
refs/heads/master from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c2b1de ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Attaching a data disk created on local storage to a VM is failing
> -
>
> Key: CLOUDSTACK-6802
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6802
> 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
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Critical
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.4.0
>
>
> Steps :
> =
> 1. Deploy a CS advanced zone setup with both local storage and shared storage
> enabled.
> 2. Deploy VMs. ( both on shared and local storage)
> 3. create a disk offering with local storage
> 4. Create a data disk with local storage disk offering.
> 5. attach the datadisk created on step 4 to VM created on step 2
> Expected result :
> ===
> Volume should be attached successfully.
> Observed result :
> ==
> volume attach fails with following error.
> 2014-05-29 13:02:45,410 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22) ===START=== 10.101.254.225 -- GET
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,466 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) submit async job-64, details:
> AsyncJobVO {id:64, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","ctxAccountId":"2","ctxStartEventId":"125","zoneId":"242c701a-43e8-4790-84f3-9112ca0b5db7"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-29 13:02:45,467 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) ===END=== 10.101.254.225 -- GET
>
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,470 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Add job-64 into job monitoring
> 2014-05-29 13:02:45,470 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Executing AsyncJobVO {id:64,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","u
[jira] [Commented] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013457#comment-14013457
]
ASF subversion and git services commented on CLOUDSTACK-6810:
-
Commit 7c2b1deb34c0210f812409b6b0f07b04e0142238 in cloudstack's branch
refs/heads/master from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c2b1de ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Migration of a VM with volumes in local storage to another host in the same
> cluster is failing
> --
>
> Key: CLOUDSTACK-6810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
> 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 advanced zone setup having 2 clusters and local
> storage enabled
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.4.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
> enabled
> 2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
> 3. Create a VM v1 on h1 with its volume on local storage.
> 4. now migrate v1 to h2
> Expected behavior :
> ===
> Migration of v1 to h2 with storage should succeed.
> Observed behavior :
> ===
> 1. Migration fails with :
> 2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-974c06fb ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
> command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
> 2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
> 2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
> cmdInfo:
> {"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
> parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
> ctxdetails
> 2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114
> execution on object VmWorkJobQueue.20
> 2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find
> lock for the key vm_instance20 and thread id 1502122810
> 2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item:
> SyncQueueItemVO {id:49, queueId: 47, contentType: AsyncJob, contentId: 114,
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
> created: Fri May 30 12:11:15 IST 2014}
> 2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
> 2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
> MgmtI
[jira] [Resolved] (CLOUDSTACK-6802) Attaching a data disk created on local storage to a VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-6802.
---
Resolution: Fixed
> Attaching a data disk created on local storage to a VM is failing
> -
>
> Key: CLOUDSTACK-6802
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6802
> 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
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Critical
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.4.0
>
>
> Steps :
> =
> 1. Deploy a CS advanced zone setup with both local storage and shared storage
> enabled.
> 2. Deploy VMs. ( both on shared and local storage)
> 3. create a disk offering with local storage
> 4. Create a data disk with local storage disk offering.
> 5. attach the datadisk created on step 4 to VM created on step 2
> Expected result :
> ===
> Volume should be attached successfully.
> Observed result :
> ==
> volume attach fails with following error.
> 2014-05-29 13:02:45,410 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22) ===START=== 10.101.254.225 -- GET
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,466 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) submit async job-64, details:
> AsyncJobVO {id:64, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","ctxAccountId":"2","ctxStartEventId":"125","zoneId":"242c701a-43e8-4790-84f3-9112ca0b5db7"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-29 13:02:45,467 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) ===END=== 10.101.254.225 -- GET
>
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,470 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Add job-64 into job monitoring
> 2014-05-29 13:02:45,470 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Executing AsyncJobVO {id:64,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","ctxAccountId":"2","ctxStartEventId":"125","zoneId":"242c701a-43e8-4790-84f3-9112ca0b5db7"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-29 13:02:45,475 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-14:ctx-23711cb3 job-64 ctx-5e5a2bf1) Received unknown
> parameters for command createVolume. Unknown parameters : ctxdetails
> 2014-05-29 13:02:45,501 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-14:ctx-23711cb3 job-64 ctx-5e5a2bf1) Complete async job-64,
> jobStatus: SUCCEEDED, resultCode: 0, result:
> org.apache.cloudstack.api.response.VolumeResponse/volume/{"id":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","name":"data-local2","zoneid":"242c701a-43e8-4790-84f3-9112ca0b5db7","zonename":"hyperv","type":"DATADISK","s
[jira] [Resolved] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-6810.
---
Resolution: Fixed
> Migration of a VM with volumes in local storage to another host in the same
> cluster is failing
> --
>
> Key: CLOUDSTACK-6810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
> 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 advanced zone setup having 2 clusters and local
> storage enabled
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.4.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
> enabled
> 2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
> 3. Create a VM v1 on h1 with its volume on local storage.
> 4. now migrate v1 to h2
> Expected behavior :
> ===
> Migration of v1 to h2 with storage should succeed.
> Observed behavior :
> ===
> 1. Migration fails with :
> 2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-974c06fb ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
> command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
> 2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
> 2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
> cmdInfo:
> {"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
> parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
> ctxdetails
> 2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114
> execution on object VmWorkJobQueue.20
> 2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find
> lock for the key vm_instance20 and thread id 1502122810
> 2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item:
> SyncQueueItemVO {id:49, queueId: 47, contentType: AsyncJob, contentId: 114,
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
> created: Fri May 30 12:11:15 IST 2014}
> 2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
> 2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-05-30 12:11:16,486 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Add job-114 into job
> monitoring
> 2014-05-30 12:11:16,486 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Work-Job-Executor-41:ctx-18c2968f job-113/job-114) Executing AsyncJobVO
> {id:114, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyACVjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZVdpdGhTdG9yYWdlsew9z6UxtXMCAANKAApkZXN0SG9zdElkSgAJc3JjSG9zdElkTAAMdm9sdW1lVG9Qb29sdAAPTGphdmEvdXRpbC9NYXA7eHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgAUdAAZVmlydHVhbE1hY2hpbmVNYW5hZ2VySW1wbAACAAA
[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013468#comment-14013468 ] ASF subversion and git services commented on CLOUDSTACK-6669: - Commit bdde5335f9988e460a667da97ebe0cde2e74e7a1 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdde533 ] FIXED CLOUDSTACK-6669 Support volume resize in usage server > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013466#comment-14013466 ] ASF subversion and git services commented on CLOUDSTACK-6669: - Commit cc663bb7fc515a4960cd483e8f5697bc141ce95e in cloudstack's branch refs/heads/4.4-forward from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cc663bb ] FIXED CLOUDSTACK-6669 Support volume resize in usage server > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6808) Need to add Database Information to Alter table statements in a commit to schema-430to440.sql
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013465#comment-14013465 ] ASF subversion and git services commented on CLOUDSTACK-6808: - Commit c5a1423d3d02e33c33eb630f6f4df24b731eba69 in cloudstack's branch refs/heads/4.4-forward from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5a1423 ] FIXED CLOUDSTACK-6808 Need to add Database Information to Alter table statements in a commit to schema-430to440.sql > Need to add Database Information to Alter table statements in a commit to > schema-430to440.sql > -- > > Key: CLOUDSTACK-6808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6808 > 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: Chandan Purushothama >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > Database Information is missing in the commit shown below > diff --git a/setup/db/db/schema-430to440.sql b/setup/db/db/schema-430to440.sql > index 3b525c4..2262608 100644 (file) > --- a/setup/db/db/schema-430to440.sql > +++ b/setup/db/db/schema-430to440.sql > @@ -1676,3 +1676,12 @@ CREATE TABLE `cloud`.`network_acl_item_cidrs` ( > ALTER TABLE `cloud`.`load_balancer_healthcheck_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > ALTER TABLE `cloud`.`load_balancer_stickiness_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > + > +alter table user_ip_address add column removed datetime DEFAULT NULL COMMENT > 'date removed'; > +alter table user_ip_address add column created datetime NULL COMMENT 'date > created'; > + > +alter table vlan add column removed datetime DEFAULT NULL COMMENT 'date > removed'; > +alter table vlan add column created datetime NULL COMMENT 'date created'; > + > +alter table user_ip_address drop key public_ip_address; > +alter table user_ip_address add UNIQUE KEY public_ip_address > (public_ip_address,source_network_id, removed); > \ No newline at end of file -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6808) Need to add Database Information to Alter table statements in a commit to schema-430to440.sql
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013467#comment-14013467 ] ASF subversion and git services commented on CLOUDSTACK-6808: - Commit dbd05e3ff5015a867652d805b08965851608e577 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dbd05e3 ] FIXED CLOUDSTACK-6808 Need to add Database Information to Alter table statements in a commit to schema-430to440.sql > Need to add Database Information to Alter table statements in a commit to > schema-430to440.sql > -- > > Key: CLOUDSTACK-6808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6808 > 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: Chandan Purushothama >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > Database Information is missing in the commit shown below > diff --git a/setup/db/db/schema-430to440.sql b/setup/db/db/schema-430to440.sql > index 3b525c4..2262608 100644 (file) > --- a/setup/db/db/schema-430to440.sql > +++ b/setup/db/db/schema-430to440.sql > @@ -1676,3 +1676,12 @@ CREATE TABLE `cloud`.`network_acl_item_cidrs` ( > ALTER TABLE `cloud`.`load_balancer_healthcheck_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > ALTER TABLE `cloud`.`load_balancer_stickiness_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > + > +alter table user_ip_address add column removed datetime DEFAULT NULL COMMENT > 'date removed'; > +alter table user_ip_address add column created datetime NULL COMMENT 'date > created'; > + > +alter table vlan add column removed datetime DEFAULT NULL COMMENT 'date > removed'; > +alter table vlan add column created datetime NULL COMMENT 'date created'; > + > +alter table user_ip_address drop key public_ip_address; > +alter table user_ip_address add UNIQUE KEY public_ip_address > (public_ip_address,source_network_id, removed); > \ No newline at end of file -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6797) volume resize hsould not be allowed for detached volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013481#comment-14013481 ] prashant kumar mishra commented on CLOUDSTACK-6797: --- 1->newly created volume don't get counted in allocated space until it is attached to a vm , so it is not going to affect storage operation even we create huge disk . 2->resized disk get counted it allocated space , so if user create huge disk , it will affects all storage operation . 3->there should be some checks for max size . > volume resize hsould 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] [Comment Edited] (CLOUDSTACK-6797) volume resize hsould not be allowed for detached volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013481#comment-14013481 ] prashant kumar mishra edited comment on CLOUDSTACK-6797 at 5/30/14 10:02 AM: - 1->newly created volumes doesn't get counted in allocated space until it is attached to a vm , so it is not going to affect storage operation even we create huge disk . 2->resized disk get counted it allocated space , so if user create huge disk , it will affects all storage operation . 3->there should be some checks for max size based on current storage size. was (Author: prashantkm): 1->newly created volume don't get counted in allocated space until it is attached to a vm , so it is not going to affect storage operation even we create huge disk . 2->resized disk get counted it allocated space , so if user create huge disk , it will affects all storage operation . 3->there should be some checks for max size . > volume resize hsould 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] [Reopened] (CLOUDSTACK-6797) volume resize hsould not be allowed for detached volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra reopened CLOUDSTACK-6797: --- reopening with my comment , please feel free to close > volume resize hsould not be allowed for detached volumes > > > Key: CLOUDSTACK-6797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6797 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0, 4.4.0 >Reporter: prashant kumar mishra >Assignee: Min Chen >Priority: Critical > Fix For: 4.4.0 > > Attachments: Logs_db.rar, screenshot-1.jpg, screenshot-2.jpg > > > =>since resize space is counted in allocated space even though it cant be > attach to VM , other storage operation will fail because threshold value > If resize is allowed in volume detach > == > 1-since there is no check for how much can be increased , suppose user has > resized it to 1000GB > 2-when user try to attach volume to vm it will fail since available space is > not sufficient . > 3-even though user is not able to use the resized volume ,CS will count > 1000GB in allocated storage . > 4-Dash will show allocated percentage >100% > 5-Because threshold values , we cant perform any operation to that PS > If resize is allowed online ( volume Attach) state it will fail in first > place and will not cause any problem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-6811: -- Summary: Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1 (was: Allocated capacity is greater than the totala capacity for primary storage with overprovisioning 1) > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra > Fix For: 4.4.0 > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6811) Allocated capacity is greater than the totala capacity for primary storage with overprovisioning 1
prashant kumar mishra created CLOUDSTACK-6811: - Summary: Allocated capacity is greater than the totala capacity for primary storage with overprovisioning 1 Key: CLOUDSTACK-6811 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.4.0 Reporter: prashant kumar mishra Fix For: 4.4.0 steps to repo === 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) 2-set over provisioning factor 4 for pm1 and 1 for pm2 3-add a volume of size 40 gb pm1 4-migrate volume to pm2 5-check the allocated and available size for ps2 expected with over provisioning 1 allocated should never be more that available Actual = allocated is >> available -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6529) deployDatacCenter.py script fails when there is more than one host in a cluster.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-6529. - Resolution: Fixed > deployDatacCenter.py script fails when there is more than one host in a > cluster. > > > Key: CLOUDSTACK-6529 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6529 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Bharat kumar >Assignee: Santhosh Kumar Edukulla > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-6811: -- Attachment: Logs_DB.rar > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra > Fix For: 4.4.0 > > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6389) test__01_nic requires advanced zone but it tagged as basic test case
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santhosh Kumar Edukulla resolved CLOUDSTACK-6389.
-
Resolution: Fixed
> test__01_nic requires advanced zone but it tagged as basic test case
>
>
> Key: CLOUDSTACK-6389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6389
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Chethan Krishnappa
>Assignee: Santhosh Kumar Edukulla
>
> test_nic.py which is under smoke tests is tagged as basic mode test but test
> runs only if the zone is advanced.
> if zone.networktype != 'Advanced':
> self.skipTest("Cannot run this test with a basic zone, please
> use advanced!")
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6708) [Automation]: Few suites were failing on simulator run
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-6708. - Resolution: Fixed > [Automation]: Few suites were failing on simulator run > -- > > Key: CLOUDSTACK-6708 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6708 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > integration.smoke.test_deploy_vm.TestDeployVMStartFailure.test_deploy_vm_start_failure > integration.smoke.test_hosts.TestHosts.test_01_clusters > integration.smoke.test_network.TestDeleteAccount.test_delete_account > integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account > integration.smoke.test_network.TestReleaseIP.test_releaseIP > integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm > integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_09_expunge_vm -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6389) test__01_nic requires advanced zone but it tagged as basic test case
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santhosh Kumar Edukulla closed CLOUDSTACK-6389.
---
> test__01_nic requires advanced zone but it tagged as basic test case
>
>
> Key: CLOUDSTACK-6389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6389
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Chethan Krishnappa
>Assignee: Santhosh Kumar Edukulla
>
> test_nic.py which is under smoke tests is tagged as basic mode test but test
> runs only if the zone is advanced.
> if zone.networktype != 'Advanced':
> self.skipTest("Cannot run this test with a basic zone, please
> use advanced!")
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6529) deployDatacCenter.py script fails when there is more than one host in a cluster.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-6529. --- > deployDatacCenter.py script fails when there is more than one host in a > cluster. > > > Key: CLOUDSTACK-6529 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6529 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Bharat kumar >Assignee: Santhosh Kumar Edukulla > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6708) [Automation]: Few suites were failing on simulator run
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-6708. --- > [Automation]: Few suites were failing on simulator run > -- > > Key: CLOUDSTACK-6708 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6708 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > integration.smoke.test_deploy_vm.TestDeployVMStartFailure.test_deploy_vm_start_failure > integration.smoke.test_hosts.TestHosts.test_01_clusters > integration.smoke.test_network.TestDeleteAccount.test_delete_account > integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account > integration.smoke.test_network.TestReleaseIP.test_releaseIP > integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm > integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_09_expunge_vm -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6669: Priority: Critical (was: Major) > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6808) Need to add Database Information to Alter table statements in a commit to schema-430to440.sql
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-6808. - Resolution: Fixed > Need to add Database Information to Alter table statements in a commit to > schema-430to440.sql > -- > > Key: CLOUDSTACK-6808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6808 > 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: Chandan Purushothama >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > Database Information is missing in the commit shown below > diff --git a/setup/db/db/schema-430to440.sql b/setup/db/db/schema-430to440.sql > index 3b525c4..2262608 100644 (file) > --- a/setup/db/db/schema-430to440.sql > +++ b/setup/db/db/schema-430to440.sql > @@ -1676,3 +1676,12 @@ CREATE TABLE `cloud`.`network_acl_item_cidrs` ( > ALTER TABLE `cloud`.`load_balancer_healthcheck_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > ALTER TABLE `cloud`.`load_balancer_stickiness_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > + > +alter table user_ip_address add column removed datetime DEFAULT NULL COMMENT > 'date removed'; > +alter table user_ip_address add column created datetime NULL COMMENT 'date > created'; > + > +alter table vlan add column removed datetime DEFAULT NULL COMMENT 'date > removed'; > +alter table vlan add column created datetime NULL COMMENT 'date created'; > + > +alter table user_ip_address drop key public_ip_address; > +alter table user_ip_address add UNIQUE KEY public_ip_address > (public_ip_address,source_network_id, removed); > \ No newline at end of file -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-6669. - Resolution: Fixed > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6812) For storage type which does not support over provisioning ,over provisioning factor shold be 1
prashant kumar mishra created CLOUDSTACK-6812: - Summary: For storage type which does not support over provisioning ,over provisioning factor shold 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 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-6813) vhd-util is not available on xen servers after adding them to CS
Sanjeev N created CLOUDSTACK-6813: - Summary: vhd-util is not available on xen servers after adding them to CS Key: CLOUDSTACK-6813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.4.0 Environment: Any build from 4.4 branch Hypervisor: Xenserver Reporter: Sanjeev N Priority: Critical Fix For: 4.4.0 vhd-util is not available on xen servers after adding them to CS. 1.Fresh install Xenserver with 6.2 2.Fresh install MS with build from 4.4 branch 3.Create a zone When host is added to CS , as part of host addition CS pushes scripts to Xenserver. However it is not copying vhd-util. So all the volume creations would fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-6813: -- Attachment: management-server.rar > vhd-util is not available on xen servers after adding them to CS > > > Key: CLOUDSTACK-6813 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.4.0 > Environment: Any build from 4.4 branch > Hypervisor: Xenserver >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > vhd-util is not available on xen servers after adding them to CS. > 1.Fresh install Xenserver with 6.2 > 2.Fresh install MS with build from 4.4 branch > 3.Create a zone > When host is added to CS , as part of host addition CS pushes scripts to > Xenserver. However it is not copying vhd-util. > So all the volume creations would fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-6481) Vhd-util is not copied to xenserver from MS...As a result system VMs fail to start in CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori reopened CLOUDSTACK-6481: --- http://nfs1.lab.vmops.com/templates/Goleta_qa/open_ssl_64bit/systemvm64template-master-xen.vhd.bz2 is used vhd-util is already installed under /usr/share/cloudstack-common/scripts/util/vhd-util as a part of management server package installation. vhd-util is not getting copied to xenserver hosts(/opt/cloud/bin) from Management server . Able to reproduce the issue in latest builds as well.CLOUDSTACK-6813 > Vhd-util is not copied to xenserver from MS...As a result system VMs fail to > start in CS. > - > > Key: CLOUDSTACK-6481 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6481 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, XenServer >Affects Versions: 4.4.0 > Environment: Xenserver6.2 added to CS 4.4 >Reporter: manasaveloori >Priority: Blocker > Fix For: 4.4.0 > > Attachments: management-server.log > > > PXE booted the Xenserver. > Added it to CS 4.4. > observed that system vms fails to deploy with Exception: > 2014-04-23 04:23:46,875 WARN [c.c.h.x.r.XenServerStorageProcessor] > (DirectAgent-3:ctx-cf6a380b) Catch Exception > com.cloud.utils.exception.CloudRuntimeException for template + due to > com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr > 5cffabad-fb53-27ad-96eb-a1728623dd7c > com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr > 5cffabad-fb53-27ad-96eb-a1728623dd7c > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:846) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:962) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:77) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:92) > 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 > 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-04-23 04:23:46,883 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-3:ctx-cf6a380b) Seq 1-4533998924855246860: Response Received: > Checked in xenserver the vhd-util file is missing under /opt/cloud/bin. > As work around copied the vhd-util to /opt/cloud/bin. > Attaching the log files -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6813) vhd-util is not available on xen servers after adding them to CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-6813. - Resolution: Fixed duplicate of CLOUDSTACK-6481. Hence closing the issue. > vhd-util is not available on xen servers after adding them to CS > > > Key: CLOUDSTACK-6813 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6813 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.4.0 > Environment: Any build from 4.4 branch > Hypervisor: Xenserver >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > vhd-util is not available on xen servers after adding them to CS. > 1.Fresh install Xenserver with 6.2 > 2.Fresh install MS with build from 4.4 branch > 3.Create a zone > When host is added to CS , as part of host addition CS pushes scripts to > Xenserver. However it is not copying vhd-util. > So all the volume creations would fail. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6802) Attaching a data disk created on local storage to a VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013941#comment-14013941
]
ASF subversion and git services commented on CLOUDSTACK-6802:
-
Commit 3b642c7578109b0d5b13737e75ea8cf294f42a5d in cloudstack's branch
refs/heads/4.4 from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b642c7 ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Attaching a data disk created on local storage to a VM is failing
> -
>
> Key: CLOUDSTACK-6802
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6802
> 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
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Critical
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.4.0
>
>
> Steps :
> =
> 1. Deploy a CS advanced zone setup with both local storage and shared storage
> enabled.
> 2. Deploy VMs. ( both on shared and local storage)
> 3. create a disk offering with local storage
> 4. Create a data disk with local storage disk offering.
> 5. attach the datadisk created on step 4 to VM created on step 2
> Expected result :
> ===
> Volume should be attached successfully.
> Observed result :
> ==
> volume attach fails with following error.
> 2014-05-29 13:02:45,410 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22) ===START=== 10.101.254.225 -- GET
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,466 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) submit async job-64, details:
> AsyncJobVO {id:64, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid":"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d","ctxAccountId":"2","ctxStartEventId":"125","zoneId":"242c701a-43e8-4790-84f3-9112ca0b5db7"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-29 13:02:45,467 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-16:ctx-87ef4f22 ctx-bf1bb5b6) ===END=== 10.101.254.225 -- GET
>
> command=createVolume&response=json&sessionkey=YYidBdJcBJV64kdZ8c%2BKOeSqY14%3D&name=data-local2&zoneId=242c701a-43e8-4790-84f3-9112ca0b5db7&diskOfferingId=8cf4d614-08b8-455c-a99f-814f4b109d24&_=1401348494217
> 2014-05-29 13:02:45,470 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Add job-64 into job monitoring
> 2014-05-29 13:02:45,470 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-14:ctx-23711cb3 job-64) Executing AsyncJobVO {id:64,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 18, cmd:
> org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,
> cmdInfo:
> {"id":"18","response":"json","sessionkey":"YYidBdJcBJV64kdZ8c+KOeSqY14\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":18,\"Volume\":\"dd5d8d32-03b4-4afd-80ca-58586c7c9e8d\",\"com.cloud.dc.DataCenter\":1,\"com.cloud.offering.DiskOffering\":14}","cmdEventType":"VOLUME.CREATE","ctxUserId":"2","name":"data-local2","diskOfferingId":"8cf4d614-08b8-455c-a99f-814f4b109d24","httpmethod":"GET","_":"1401348494217","uuid
[jira] [Commented] (CLOUDSTACK-6810) Migration of a VM with volumes in local storage to another host in the same cluster is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013940#comment-14013940
]
ASF subversion and git services commented on CLOUDSTACK-6810:
-
Commit 3b642c7578109b0d5b13737e75ea8cf294f42a5d in cloudstack's branch
refs/heads/4.4 from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b642c7 ]
CLOUDSTACK-6810: Fix storage migration of a vm with volume on local was
failing. When a plan
with hostid included was passed to the local storage pool allocator, it
returned all the local
storage pools in the cluster, instead of just the local pool on the given host
in the plan.
This was happening the search at a host level was happening only for data disk.
Fixed this.
Additionally, the query to list the storage pools on a host was failing if the
pool did have
tags. Fixed the query too.
CLOUDSTACK-6802: Fix for not being able to attach data disk on local. This
issue gets fixed
with the above issue too. The query to list pools on a host was failing if
there were no
tags on the storage pool.
> Migration of a VM with volumes in local storage to another host in the same
> cluster is failing
> --
>
> Key: CLOUDSTACK-6810
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6810
> 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 advanced zone setup having 2 clusters and local
> storage enabled
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.4.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone Hyper-V setup having 2 clusters and local storage
> enabled
> 2. Cluster1 has 2 hosts h1&h2 and cluster 2 has 1 host h3
> 3. Create a VM v1 on h1 with its volume on local storage.
> 4. now migrate v1 to h2
> Expected behavior :
> ===
> Migration of v1 to h2 with storage should succeed.
> Observed behavior :
> ===
> 1. Migration fails with :
> 2014-05-30 12:11:15,815 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-974c06fb ctx-97ad77c9) ===END=== 10.144.7.13 -- GET
> command=migrateVirtualMachineWithVolume&hostid=a8159199-7d97-4452-8e72-a7a2192bc00a&virtualmachineid=f5c72950-100c-40b7-8a4c-42a10f1e1394&response=json&sessionkey=iBUNgVHSPfj%2F0RJrH4y0VHXcdWY%3D&_=1401431807938
> 2014-05-30 12:11:15,816 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Add job-113 into job monitoring
> 2014-05-30 12:11:15,816 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113) Executing AsyncJobVO {id:113,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd,
> cmdInfo:
> {"response":"json","sessionkey":"iBUNgVHSPfj/0RJrH4y0VHXcdWY\u003d","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":20,\"com.cloud.host.Host\":2}","virtualmachineid":"f5c72950-100c-40b7-8a4c-42a10f1e1394","cmdEventType":"VM.MIGRATE","hostid":"a8159199-7d97-4452-8e72-a7a2192bc00a","ctxUserId":"2","httpmethod":"GET","_":"1401431807938","ctxAccountId":"2","ctxStartEventId":"200"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-30 12:11:15,824 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Received unknown
> parameters for command migrateVirtualMachineWithVolume. Unknown parameters :
> ctxdetails
> 2014-05-30 12:11:15,862 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Sync job-114
> execution on object VmWorkJobQueue.20
> 2014-05-30 12:11:15,864 WARN [c.c.u.d.Merovingian2]
> (API-Job-Executor-37:ctx-cdc57df1 job-113 ctx-c34467bb) Was unable to find
> lock for the key vm_instance20 and thread id 1502122810
> 2014-05-30 12:11:16,455 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Execute sync-queue item:
> SyncQueueItemVO {id:49, queueId: 47, contentType: AsyncJob, contentId: 114,
> lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
> created: Fri May 30 12:11:15 IST 2014}
> 2014-05-30 12:11:16,457 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-79593829) Schedule queued job-114
> 2014-05-30 12:11:16,482 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 3-75336: Processing Seq 3-75336: { Cmd ,
> MgmtId:
[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6669: -- Fix Version/s: 4.4.0 > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013950#comment-14013950 ] ASF subversion and git services commented on CLOUDSTACK-6669: - Commit c476312a10073240c1436664477c10219141ac6e in cloudstack's branch refs/heads/4.4 from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c476312 ] FIXED CLOUDSTACK-6669 Support volume resize in usage server > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6808) Need to add Database Information to Alter table statements in a commit to schema-430to440.sql
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013949#comment-14013949 ] ASF subversion and git services commented on CLOUDSTACK-6808: - Commit fab339e4cf9a058ba33537f70b0d4e10b4359f72 in cloudstack's branch refs/heads/4.4 from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fab339e ] FIXED CLOUDSTACK-6808 Need to add Database Information to Alter table statements in a commit to schema-430to440.sql > Need to add Database Information to Alter table statements in a commit to > schema-430to440.sql > -- > > Key: CLOUDSTACK-6808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6808 > 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: Chandan Purushothama >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > Database Information is missing in the commit shown below > diff --git a/setup/db/db/schema-430to440.sql b/setup/db/db/schema-430to440.sql > index 3b525c4..2262608 100644 (file) > --- a/setup/db/db/schema-430to440.sql > +++ b/setup/db/db/schema-430to440.sql > @@ -1676,3 +1676,12 @@ CREATE TABLE `cloud`.`network_acl_item_cidrs` ( > ALTER TABLE `cloud`.`load_balancer_healthcheck_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > ALTER TABLE `cloud`.`load_balancer_stickiness_policies` ADD COLUMN `display` > tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed > to the end user'; > + > +alter table user_ip_address add column removed datetime DEFAULT NULL COMMENT > 'date removed'; > +alter table user_ip_address add column created datetime NULL COMMENT 'date > created'; > + > +alter table vlan add column removed datetime DEFAULT NULL COMMENT 'date > removed'; > +alter table vlan add column created datetime NULL COMMENT 'date created'; > + > +alter table user_ip_address drop key public_ip_address; > +alter table user_ip_address add UNIQUE KEY public_ip_address > (public_ip_address,source_network_id, removed); > \ No newline at end of file -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6801) Public IP not assigned to eth1 on VR in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013979#comment-14013979 ] Andrija Panic edited comment on CLOUDSTACK-6801 at 5/30/14 5:36 PM: This is bug present while using untagged vlan for Public IP network - issue is (temporarily?) respolved by replacing "untagged" with "vlan://untagged" inside vlan database, vlan_id field. Verified on DEV mailing list together with Joris van Lieshout, Daan, Marcus,etc. Marcus explanation: " In 4.3, some changes were made to BroadcastDomainType, to standardize Broadcast URIs to prepend vlan://. The issue is that your IpAssocVpcCommand doesn't use this new format for the broadcastUri it passes, so it fails to map the plugged device into the broadcastUriToNicNum map, resulting in ethnull." was (Author: andrija): This is bug present wjile to using untagged vlan for Public IP network - issue is (temporarily?) respolved by replacing "untagged" with "vlan://untagged" inside vlan database, vlan_id field. Verified on DEV mailing list together with Joris van Lieshout, Daan, Marcus,etc. Marcus explanation: " In 4.3, some changes were made to BroadcastDomainType, to standardize Broadcast URIs to prepend vlan://. The issue is that your IpAssocVpcCommand doesn't use this new format for the broadcastUri it passes, so it fails to map the plugged device into the broadcastUriToNicNum map, resulting in ethnull." > Public IP not assigned to eth1 on VR in VPC > --- > > Key: CLOUDSTACK-6801 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6801 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.3.0 > Environment: CentOS, KVM. >Reporter: Andrija Panic >Priority: Blocker > Labels: publicip, virtualrouter, vpc > > Hi, > after upgrade from 4.2.1 to 4.3.0, Public IP on eth1 is missing on VR when > creating new (and on existing) VPCs, although eth1 seems present per > /proc/net/dev. > Mangement logs are fine, eth1 plugged in correct bridge, etc. > Manually adding IP on eth1 and starting eth1 does work. > From /var/log/messages inside VR: > May 28 18:27:36 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 0 seconds > May 28 18:27:37 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 1 seconds > May 28 18:27:38 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 2 seconds > May 28 18:27:39 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 3 seconds > May 28 18:27:40 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 4 seconds > May 28 18:27:41 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 5 seconds > May 28 18:27:42 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 6 seconds > May 28 18:27:43 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 7 seconds > May 28 18:27:44 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 8 seconds > May 28 18:27:45 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 9 seconds > May 28 18:27:46 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 10 seconds > May 28 18:27:47 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 11 seconds > May 28 18:27:48 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 12 seconds > May 28 18:27:49 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 13 seconds > May 28 18:27:50 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 14 seconds > May 28 18:27:51 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 15 seconds > May 28 18:27:52 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 16 seconds > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:interface ethnull never > appeared > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Adding ip 46.232.x.246 on > interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Add routing 46.232.x.246 on > interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_privateGateway.sh:Added SourceNAT > 46.232.x.246 on interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_snat.sh:Added SourceNAT 46.232.x.246 on > interface eth1 > May 28 18:27:54 r-799-VM cloud: vpc_guestnw.sh: Create network on interface > eth2, gateway 10.0.1.1, network 10.0.1.1/24 > May 28 18:27:59 r-799-VM cloud: Setting up apache web server for eth2 > May 28 18:27:59 r-799-VM cloud: Setting up password service for network > 10.0.1.1/24, eth eth2 > May
[jira] [Commented] (CLOUDSTACK-6801) Public IP not assigned to eth1 on VR in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013979#comment-14013979 ] Andrija Panic commented on CLOUDSTACK-6801: --- This is bug present wjile to using untagged vlan for Public IP network - issue is (temporarily?) respolved by replacing "untagged" with "vlan://untagged" inside vlan database, vlan_id field. Verified on DEV mailing list together with Joris van Lieshout, Daan, Marcus,etc. Marcus explanation: " In 4.3, some changes were made to BroadcastDomainType, to standardize Broadcast URIs to prepend vlan://. The issue is that your IpAssocVpcCommand doesn't use this new format for the broadcastUri it passes, so it fails to map the plugged device into the broadcastUriToNicNum map, resulting in ethnull." > Public IP not assigned to eth1 on VR in VPC > --- > > Key: CLOUDSTACK-6801 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6801 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.3.0 > Environment: CentOS, KVM. >Reporter: Andrija Panic >Priority: Blocker > Labels: publicip, virtualrouter, vpc > > Hi, > after upgrade from 4.2.1 to 4.3.0, Public IP on eth1 is missing on VR when > creating new (and on existing) VPCs, although eth1 seems present per > /proc/net/dev. > Mangement logs are fine, eth1 plugged in correct bridge, etc. > Manually adding IP on eth1 and starting eth1 does work. > From /var/log/messages inside VR: > May 28 18:27:36 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 0 seconds > May 28 18:27:37 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 1 seconds > May 28 18:27:38 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 2 seconds > May 28 18:27:39 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 3 seconds > May 28 18:27:40 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 4 seconds > May 28 18:27:41 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 5 seconds > May 28 18:27:42 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 6 seconds > May 28 18:27:43 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 7 seconds > May 28 18:27:44 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 8 seconds > May 28 18:27:45 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 9 seconds > May 28 18:27:46 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 10 seconds > May 28 18:27:47 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 11 seconds > May 28 18:27:48 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 12 seconds > May 28 18:27:49 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 13 seconds > May 28 18:27:50 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 14 seconds > May 28 18:27:51 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 15 seconds > May 28 18:27:52 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull > to appear, 16 seconds > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:interface ethnull never > appeared > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Adding ip 46.232.x.246 on > interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Add routing 46.232.x.246 on > interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_privateGateway.sh:Added SourceNAT > 46.232.x.246 on interface ethnull > May 28 18:27:53 r-799-VM cloud: vpc_snat.sh:Added SourceNAT 46.232.x.246 on > interface eth1 > May 28 18:27:54 r-799-VM cloud: vpc_guestnw.sh: Create network on interface > eth2, gateway 10.0.1.1, network 10.0.1.1/24 > May 28 18:27:59 r-799-VM cloud: Setting up apache web server for eth2 > May 28 18:27:59 r-799-VM cloud: Setting up password service for network > 10.0.1.1/24, eth eth2 > May 28 18:27:59 r-799-VM cloud: vpc_guestnw.sh: Create network on interface > eth3, gateway 10.0.3.1, network 10.0.3.1/24 > May 28 18:28:04 r-799-VM cloud: Setting up apache web server for eth3 > May 28 18:28:06 r-799-VM cloud: Setting up password service for network > 10.0.3.1/24, eth eth3 > May 28 18:28:06 r-799-VM cloud: vpc_guestnw.sh: Create network on interface > eth4, gateway 10.0.4.1, network 10.0.4.1/24 > May 28 18:28:11 r-799-VM cloud: Setting up apache web server for eth4 > May 28 18:28:12 r-799-VM cloud: Setting up password service for network > 10.0.4.1/24, eth eth4 > May 28 18:28:13 r-799-VM cloud: vpc_guestnw.sh: Create network on interface >
[jira] [Commented] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013990#comment-14013990 ] ASF subversion and git services commented on CLOUDSTACK-6599: - Commit 48ea9e0b5e87fee067b711890cd5a5d7c9079bf1 in cloudstack's branch refs/heads/4.4-forward from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=48ea9e0 ] CLOUDSTACK-6599: 1. Adding the missing Template/Volume URLs expiration functionality 2. Improvement - While deleting the volume during expiration use rm -rf as vmware now contains directoy 3. Improvement - Use standard Answer so that the error gets logged in case deletion of expiration link didnt work fine. 4. Improvement - In case of domain change, expire the old urls > Template/Volume URLs expiration functionality not working > - > > Key: CLOUDSTACK-6599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Blocker > Fix For: 4.4.0 > > > Template / Volume Donwload URLs should expire - functionality is missing > We have the functionality where we create download urls for volumes and > templates for the users. For security reasons we should expire these urls and > this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that > needs to be implemented. Look at 4.2 for reference. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014002#comment-14014002 ] ASF subversion and git services commented on CLOUDSTACK-6599: - Commit 5393387bbd4e2d3659fb0c7171e6ff347ad6a07b in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5393387 ] CLOUDSTACK-6599: 1. Adding the missing Template/Volume URLs expiration functionality 2. Improvement - While deleting the volume during expiration use rm -rf as vmware now contains directoy 3. Improvement - Use standard Answer so that the error gets logged in case deletion of expiration link didnt work fine. 4. Improvement - In case of domain change, expire the old urls > Template/Volume URLs expiration functionality not working > - > > Key: CLOUDSTACK-6599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Blocker > Fix For: 4.4.0 > > > Template / Volume Donwload URLs should expire - functionality is missing > We have the functionality where we create download urls for volumes and > templates for the users. For security reasons we should expire these urls and > this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that > needs to be implemented. Look at 4.2 for reference. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans
Andrija Panic created CLOUDSTACK-6814: - Summary: Detected overlapping subnets in differents vlans Key: CLOUDSTACK-6814 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6814 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.3.0 Environment: not relevant Reporter: Andrija Panic Priority: Critical I have both Public IP(untagged) and Guest IP range (vlan 500) on same physical network device eth1 (infrastrucure-zones-physical network-eth1public tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 till now... In previous versions I was able to add few additional IP addresses from the /24 subnet to Guest IP range.. In 4.3, there is an error message saying that Guest IP range and Public IP range has overlaping subnets - which IS true - but since those networks ARE on different vlans completely, I'm not sure why there is such check at all (overlaping subnet check). Different vlans means different broadcast domains, why checking IP parameters across different vlans... Existing database records - first row is Public IP range, rest is all smaller ranges of IP addresses added few times for Guest IP range. mysql> select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from cloud.vlan; ++--+-+--+---+---+ | id | uuid | vlan_id | vlan_gateway | vlan_netmask | description | ++--+-+--+---+---+ | 1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 | | 3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 | | 4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 | | 5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 | | 8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 | ++--+-+--+---+---+ Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather Public or Guest network - I can't do that and getting folowing error (tried adding it to Public range here): The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has overlapped with the subnet. Please specify a different gateway/netmask. This subnet check across differenet vlans should be removed, and I'm stuck with over 90% used IP addresses, and can't add more from same /24 range that we got... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6814) Detected overlapping subnets in differents vlans
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrija Panic updated CLOUDSTACK-6814: -- Description: I have both Public IP(untagged) and Guest IP range (vlan 500) on same physical network device eth1 (infrastrucure-zones-physical network-eth1public tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 till now... In previous versions I was able to add few additional IP addresses from the /24 subnet to Guest IP range.. In 4.3, there is an error message saying that Guest IP range and Public IP range has overlaping subnets - which IS true - but since those networks ARE on different vlans completely, I'm not sure why there is such check at all (overlaping subnet check). Different vlans means different broadcast domains, why checking IP parameters across different vlans... Existing database records - first row is Public IP range, rest is all smaller ranges of IP addresses added few times for Guest IP range. mysql> select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from cloud.vlan; ++--+-+--+---+---+ | id | uuid | vlan_id | vlan_gateway | vlan_netmask | description | ++--+-+--+---+---+ | 1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 | | 3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 | | 4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 | | 5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 | | 8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 | ++--+-+--+---+---+ Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather Public or Guest network - I can't do that and getting folowing error (tried adding it to Public range here): "The IP range with tag: 500 in zone DC-ZURICH-GLATTBRUGG has overlapped with the subnet. Please specify a different gateway/netmask." This subnet check across differenet vlans should be removed, and I'm stuck with over 90% used IP addresses, and can't add more from same /24 range that we got... was: I have both Public IP(untagged) and Guest IP range (vlan 500) on same physical network device eth1 (infrastrucure-zones-physical network-eth1public tag...) Don't ask me how/why, but it works and it had worked from CS 4.0.0 till now... In previous versions I was able to add few additional IP addresses from the /24 subnet to Guest IP range.. In 4.3, there is an error message saying that Guest IP range and Public IP range has overlaping subnets - which IS true - but since those networks ARE on different vlans completely, I'm not sure why there is such check at all (overlaping subnet check). Different vlans means different broadcast domains, why checking IP parameters across different vlans... Existing database records - first row is Public IP range, rest is all smaller ranges of IP addresses added few times for Guest IP range. mysql> select id,uuid,vlan_id,vlan_gateway,vlan_netmask,description from cloud.vlan; ++--+-+--+---+---+ | id | uuid | vlan_id | vlan_gateway | vlan_netmask | description | ++--+-+--+---+---+ | 1 | 10a1e453-7369-4645-9e0f-4936c18bfeac | vlan://untagged | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.240-46.232.xxx.248 | | 3 | 76c30667-e4c9-4bfe-84cc-3c8e5c608770 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.220-46.232.xxx.238 | | 4 | e2b2b09b-81f2-4ec0-9323-b4c626fcd63b | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.210-46.232.xxx.219 | | 5 | f810fd59-ea8a-44fb-850e-58eb791191f0 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.202-46.232.xxx.209 | | 8 | f0bec296-3ac8-483c-a23a-b36213fdf846 | 500 | 46.232.xxx.1 | 255.255.255.0 | 46.232.xxx.131-46.232.xxx.201 | ++--+-+--+---+---+ Now when I want to add new range 46.232.xxx.100-46.232.xxx.130 to eather Public or Guest network - I ca
[jira] [Commented] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014269#comment-14014269 ] ASF subversion and git services commented on CLOUDSTACK-6599: - Commit be765ce8680564b743a73dd360c590c0e495c204 in cloudstack's branch refs/heads/4.4-forward from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=be765ce ] CLOUDSTACK-6599: Add the column in Java upgrade path since 4.2 already has the extract template/volume columns > Template/Volume URLs expiration functionality not working > - > > Key: CLOUDSTACK-6599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Blocker > Fix For: 4.4.0 > > > Template / Volume Donwload URLs should expire - functionality is missing > We have the functionality where we create download urls for volumes and > templates for the users. For security reasons we should expire these urls and > this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that > needs to be implemented. Look at 4.2 for reference. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6599) Template/Volume URLs expiration functionality not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014270#comment-14014270 ] ASF subversion and git services commented on CLOUDSTACK-6599: - Commit 81d3a9e3ee64f6f25484865e831b375ce13ec914 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81d3a9e ] CLOUDSTACK-6599: Add the column in Java upgrade path since 4.2 already has the extract template/volume columns (cherry picked from commit be765ce8680564b743a73dd360c590c0e495c204) > Template/Volume URLs expiration functionality not working > - > > Key: CLOUDSTACK-6599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Blocker > Fix For: 4.4.0 > > > Template / Volume Donwload URLs should expire - functionality is missing > We have the functionality where we create download urls for volumes and > templates for the users. For security reasons we should expire these urls and > this functionality existed since 3.0.x. But it doesnt exist in 4.4 and that > needs to be implemented. Look at 4.2 for reference. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6815) CallContext contains incorrect UUID for Account
Mike Tutkowski created CLOUDSTACK-6815: -- Summary: CallContext contains incorrect UUID for Account Key: CLOUDSTACK-6815 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6815 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: Ubuntu 12.04 Reporter: Mike Tutkowski Fix For: Future Copy/paste of an e-mail I sent to CloudStack dev@: Hi, I noticed while executing the createStoragePool command that the following does not work entirely as expected: Account csAccount = CallContext.current().getCallingAccount(); The Account that is returned has the expected name and id, but its UUID is not correct. For example, I see the account name of "admin" and an id of "2" (in my case, both are correct); however, the UUID is different each time I run the createStoragePool command. I assume the UUID should be what's in the account table for the applicable row, right? Anyone have any thoughts on this? Thanks! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014525#comment-14014525 ] Rajesh Battala commented on CLOUDSTACK-6603: last_interval column is created along with the table creation of "autoscale_vmgroups" from ./db/db/schema-40to410.sql In 4.2 and 4.3, deploying db "autoscale_vmgroups" tables don't have "last_interval" column. but in 4.4 code deploying db this column is present. As the column "last_interval" is missing, autoscale manager and autoscalevmgroupvo is referring to this column exception is happening. > [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to > 4.4 > > > Key: CLOUDSTACK-6603 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 >Reporter: manasaveloori >Assignee: Rajesh Battala >Priority: Blocker > Fix For: 4.4.0 > > Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp > > > 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor. > 2. Configured LB rules,firewall rules. > 3. Registered the template for 4.4 (using the naming convention > systemvm-xenserver-4.4,systemvm-kvm-4.4) > 4. Upgraded to 4.4 > Start the management server: > Below are the observations: > 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] > (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running... > 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] > (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling > com.cloud.utils.exception.CloudRuntimeException: DB Exception on: > com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, > autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, > autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, > autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, > autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, > autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, > autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, > autoscale_vmgroups.created, autoscale_vmgroups.state, > autoscale_vmgroups.display FROM autoscale_vmgroups WHERE > autoscale_vmgroups.removed IS NULL > at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127) > at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150) > at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy220.listAll(Unknown Source) > at > com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673) > 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.runAndReset(FutureTask.java:304) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExe
[jira] [Resolved] (CLOUDSTACK-6038) systemvm template for HyperV with jre7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6038. Resolution: Fixed systemvm template for hyperv is running with jre7 > systemvm template for HyperV with jre7 > -- > > Key: CLOUDSTACK-6038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6038 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Labels: hyperv > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6521) [Hyper-V] fix generating of Hyper-v template in jenkins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014528#comment-14014528 ] Rajesh Battala commented on CLOUDSTACK-6521: got fixed with this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=fefddc062486ed0c997309b719fd4b2f89b9b62c > [Hyper-V] fix generating of Hyper-v template in jenkins > --- > > Key: CLOUDSTACK-6521 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6521 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
