[jira] [Updated] (CLOUDSTACK-7957) [Automation] After Assigning a VM to a Different Account - PrimaryStorageTotal value of the Different Account is not Updated properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7957:
---
Assignee: edison su
> [Automation] After Assigning a VM to a Different Account -
> PrimaryStorageTotal value of the Different Account is not Updated properly
> -
>
> Key: CLOUDSTACK-7957
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7957
> 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: Chandan Purushothama
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
>
> *Steps to Reproduce:*
> 1. Create an Account. Observe the primarystoragetotal Information:
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 0,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 0,
> cputotal: 0,
> vpctotal: 0,
> id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
> cpuavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 0,
> volumetotal: 0,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 0,
> accounttype: 2,
> networkavailable: u'Unlimited',
> primarystoragetotal: 0,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> user: [
> {
> username:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> account:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> firstname: u'test',
> created: u'2014-11-19T14: 24: 52+',
> lastname: u'test',
> domain: u'ROOT',
> id: u'3108696d-5bb2-43e4-a5dc-9b7e095e5e6d',
> iscallerchilddomain: False,
> state: u'enabled',
> accounttype: 2,
> email: u'test-acco...@test.com',
> isdefault: False,
> accountid: u'40f4c89b-2964-4c54-9aff-5e537faee4f9'
> }
> ],
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> vmavailable: u'Unlimited',
> ipavailable: u'Unlimited',
> memorylimit: u'Unlimited',
> cpulimit: u'Unlimited',
> snapshotavailable: u'Unlimited'
> }
> {noformat}
> 2. Deploy a VM from the default template (2 GB Size) with a disk offering of
> 2GB. Observe primarystoragetotal Information of the account as 4GB.
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 128,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 1,
> cputotal: 1,
> vpctotal: 0,
> id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
> networkavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 1,
> volumetotal: 2,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 1,
> sentbytes: 0,
> accounttype: 2,
> receivedbytes: 0,
> cpuavailable: u'Unlimited',
> primarystoragetotal: 4,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> vmrunning: 1,
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> vmavailable: u'Unlimited',
> ipavailable: u'Unlimited',
>
[jira] [Updated] (CLOUDSTACK-7961) [Automation] After Deletion of a Volume in an Account - PrimaryStorageTotal value of the Account is not Updated properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7961:
---
Assignee: edison su
> [Automation] After Deletion of a Volume in an Account - PrimaryStorageTotal
> value of the Account is not Updated properly
>
>
> Key: CLOUDSTACK-7961
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7961
> 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: Chandan Purushothama
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
>
> *Steps to Reproduce:*
> 1. Create an Account. Observe the primarystoragetotal Information:
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'58f506ce-7108-11e4-bca3-7640e6bc0920',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 0,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 0,
> cputotal: 0,
> vpctotal: 0,
> id: u'f83b6369-abe7-4cb7-9101-c3e70beee013',
> cpuavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 0,
> volumetotal: 0,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 0,
> accounttype: 2,
> networkavailable: u'Unlimited',
> primarystoragetotal: 0,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> user: [
> {
> username:
> u'test-a-TestVolumeLimits-test_create_multiple_volumes_1_root_domain_admin-QKVX6C',
> account:
> u'test-a-TestVolumeLimits-test_create_multiple_volumes_1_root_domain_admin-QKVX6C',
> domainid: u'58f506ce-7108-11e4-bca3-7640e6bc0920',
> firstname: u'test',
> created: u'2014-11-21T01: 02: 31+',
> lastname: u'test',
> domain: u'ROOT',
> id: u'f04dfdcf-e94e-411a-9d96-a308fae131df',
> iscallerchilddomain: False,
> state: u'enabled',
> accounttype: 2,
> email: u'test-acco...@test.com',
> isdefault: False,
> accountid: u'f83b6369-abe7-4cb7-9101-c3e70beee013'
> }
> ],
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_create_multiple_volumes_1_root_domain_admin-QKVX6C',
> vmavailable: u'Unlimited',
> ipavailable: u'Unlimited',
> memorylimit: u'Unlimited',
> cpulimit: u'Unlimited',
> snapshotavailable: u'Unlimited'
> }
> {noformat}
> 2. Deploy a VM from the default template (2 GB Size) with a disk offering of
> 2GB. Observe primarystoragetotal Information of the account as 4GB.
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'58f506ce-7108-11e4-bca3-7640e6bc0920',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 128,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 1,
> cputotal: 1,
> vpctotal: 0,
> id: u'f83b6369-abe7-4cb7-9101-c3e70beee013',
> networkavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 1,
> volumetotal: 2,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 1,
> sentbytes: 0,
> accounttype: 2,
> receivedbytes: 0,
> cpuavailable: u'Unlimited',
> primarystoragetotal: 4,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> vmrunning: 1,
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_create_multiple_volumes_1_root_domain_admin-QKVX6C',
> vmavailable: u'Unlimited',
> ipavailable: u'Unlimited',
> memorylimit: u'Unlimited',
> cpul
[jira] [Updated] (CLOUDSTACK-7960) [Automation] Creation of Volume from Snapshot fails due to StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7960:
---
Assignee: edison su
> [Automation] Creation of Volume from Snapshot fails due to
> StringIndexOutOfBoundsException
> --
>
> Key: CLOUDSTACK-7960
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7960
> 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: Chandan Purushothama
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
>
> Use Case:
> Validate the following sequence
> # Deploy VM with custom disk offering and check the primary storage
> resource count
> # Stop the VM and create Snapshot from VM's volume
> # Create volume again from this snapshot
> StringIndexOutOfBoundsException:
> {noformat}
> 2014-11-21 01:04:06,153 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-4e287cc2 ctx-e68b28dc ctx-a00dd9d4) ===END===
> 10.220.135.118 -- GET
> account=test-a-TestVolumeLimits-test_create_template_snapshot_1_root_domain_admin-9B6G87&domainid=58f506ce-7108-11e4-bca3-7640e6bc0920&name=Test+Volume-DGE7AV&zoneid=7934f921-50e4-406b-b0dd-8c474907d8cf&apiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzg&command=createVolume&signature=Kb4x7pXEbm2yfoNmKAVZ92bFu1Y%3D&snapshotid=cd663163-8045-43d1-9a88-899d0c1e9182&response=json&size=2
> 2014-11-21 01:04:06,158 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-662f483b) ===START=== 10.220.135.118 -- GET
> jobid=5b446f9d-2056-43f2-9057-2d16b40e926f&apiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzg&command=queryAsyncJobResult&response=json&signature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
> 2014-11-21 01:04:06,175 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-662f483b ctx-ad395747 ctx-b176f4c5) ===END===
> 10.220.135.118 -- GET
> jobid=5b446f9d-2056-43f2-9057-2d16b40e926f&apiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzg&command=queryAsyncJobResult&response=json&signature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
> 2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Looking for pools
> in dc: 1 pod:1 cluster:null
> 2014-11-21 01:04:06,187 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found pools
> matching tags: [Pool[1|NetworkFilesystem], Pool[2|NetworkFilesystem],
> Pool[3|NetworkFilesystem]]
> 2014-11-21 01:04:06,189 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking if storage
> pool is suitable, name: null ,poolId: 1
> 2014-11-21 01:04:06,191 INFO [c.c.s.StorageManagerImpl]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Storage pool null
> (1) does not supply IOPS capacity, assuming enough capacity
> 2014-11-21 01:04:06,193 DEBUG [c.c.s.StorageManagerImpl]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool 1 for
> storage, totalSize: 1099511627776, usedBytes: 0, usedPct: 0.0, disable
> threshold: 0.85
> 2014-11-21 01:04:06,197 DEBUG [c.c.s.StorageManagerImpl]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool: 1
> for volume allocation [Vol[764|vm=null|DATADISK]], maxSize : 219902322,
> totalAllocatedSize : 200, askingSize : 2147483648, allocated disable
> threshold: 0.85
> 2014-11-21 01:04:06,197 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
> ClusterScopeStoragePoolAllocator returning 1 suitable storage pools
> 2014-11-21 01:04:06,198 DEBUG [o.a.c.e.o.VolumeOrchestrator]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found a suitable
> pool for create volume: 1
> 2014-11-21 01:04:06,214 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) copyAsync
> inspecting src type SNAPSHOT copyAsync inspecting dest type VOLUME
> 2014-11-21 01:04:06,225 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Seq
[jira] [Created] (CLOUDSTACK-7967) Need to option in cloudstack to upgrade system vm template
Rayees Namathponnan created CLOUDSTACK-7967: --- Summary: Need to option in cloudstack to upgrade system vm template Key: CLOUDSTACK-7967 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7967 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.6.0 Currently system template script to upgrade system vm templates. we need an option in cloudstack itself to upgrade new system template; its required if there are security fixes and we need to upgrade system vm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5809) Not able to deploy Vm becasue of crossing pool.storage.allocate d.capacity.disablethreshold even though the threshold has not been reached in the primary store.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5809. --- Resolution: Won't Fix It's by design, when planning for the storage resource, we always use virtual size instead of physical size, as the each vm could use up all the virtual size during vm's life time, we have to pre-allocate virtual size for each volume. > Not able to deploy Vm becasue of crossing pool.storage.allocate > d.capacity.disablethreshold even though the threshold has not been reached in > the primary store. > > > Key: CLOUDSTACK-5809 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5809 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > > Not able to deploy Vm because of crossing pool.storage.allocate > d.capacity.disablethreshold even though the threshold has not been reached in > the primary store. > Steps to reproduce the problem: > Xenserver set up with 2 Xensserver hosts: > In my case , Primary storage NFS has 222GB . (storage.overprovisioning.factor > is set to 2). > I tried to deploy 20 Vms with the same template that has Virtual size of > 20.00 GB and actual size is about 10 GB. > I was allowed to deploy only 17 Vms after which Vm deployment fails because > of the following exception because of crossing pool.storage.allocate > d.capacity.disablethreshold : > 2014-01-06 17:34:21,881 DEBUG [c.c.s.StorageManagerImpl] > (Job-Executor-32:ctx-2a944d7f ctx-6e9eaab0) Checking pool 1 for storage, > totalSize: 2 > 3190912, usedBytes: 88645566464, usedPct: 0.3728093772325169, disable > threshold: 0.85 > 2014-01-06 17:34:21,885 DEBUG [c.c.s.StorageManagerImpl] > (Job-Executor-32:ctx-2a944d7f ctx-6e9eaab0) Checking pool: 1 for volume > allocation [V > ol[24|vm=24|ROOT]], maxSize : 475554381824, totalAllocatedSize : > 394411376640, askingSize : 21474836480, allocated disable threshold: 0.85 > 2014-01-06 17:34:21,886 DEBUG [c.c.s.StorageManagerImpl] > (Job-Executor-32:ctx-2a944d7f ctx-6e9eaab0) Insufficient un-allocated > capacity on: 1 > for volume allocation: [Vol[24|vm=24|ROOT]] since its allocated percentage: > 0.8745292421128761 has crossed the allocated pool.storage.allocate > d.capacity.disablethreshold: 0.85, skipping this pool > Since Xenserver uses thin provisioning , the base copy of the template in > primary is 10 GB. All the vhd entries of the Vms are very small and point to > the base copy. We need to allocate only 10 GB space ( 20 GB (virtual size of > template) - 10 gb ( actual size of tenplate) for each of these Vms , in > addition to 10 GB for the base template copy. > But we are allocating 20 GB for each of the Vms deployed. > Reported Primary Storage capacity - 82 % - 367.32 GB / 442.89 GB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7966) Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223662#comment-14223662 ] ASF subversion and git services commented on CLOUDSTACK-7966: - Commit 7175247c5e10eb6c152b2629e5496337e3287afd in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7175247 ] CLOUDSTACK-7966: remove snapshot_store_ref entry, in which role is Primary, during storage GC > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary > -- > > Key: CLOUDSTACK-7966 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7966 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary even after deleting the snapshots > Steps to reproduce: > > 1.Bring up CS in advanced zone with xen/vmware cluster > 2.Deploy few guest vms using default cent os template > 3.Create snapshots on all the root volumes of the vms created above > 4.Verify snapshot_store_ref table entries. For each snapshot there would be > two entries one with store role Primary and another one with Secondary > 5.Delete all the snapshots and wait for the storage cleanup thread to run > Expected Behavior: > > When we destroy snapshots all the snapshot entries should be removed from > snapshot_store_ref table. > Actual Behavior: > = > After deleting snapshots all the snapshot states are marked as Destroyed in > both snapshot_store_ref and snapshots (status field) table. This is expected. > However when the storage cleanup thread runs it is not deleting the entries > from snapshot_store_ref table with store_role primary. It is only marking > removed column in snapshots table and deleting entries from > snapshot_store_ref table with store_role Image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7966) Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-7966. --- Resolution: Fixed 4e5b3d028dc990f27484b79db67926c4371715ac on master > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary > -- > > Key: CLOUDSTACK-7966 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7966 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary even after deleting the snapshots > Steps to reproduce: > > 1.Bring up CS in advanced zone with xen/vmware cluster > 2.Deploy few guest vms using default cent os template > 3.Create snapshots on all the root volumes of the vms created above > 4.Verify snapshot_store_ref table entries. For each snapshot there would be > two entries one with store role Primary and another one with Secondary > 5.Delete all the snapshots and wait for the storage cleanup thread to run > Expected Behavior: > > When we destroy snapshots all the snapshot entries should be removed from > snapshot_store_ref table. > Actual Behavior: > = > After deleting snapshots all the snapshot states are marked as Destroyed in > both snapshot_store_ref and snapshots (status field) table. This is expected. > However when the storage cleanup thread runs it is not deleting the entries > from snapshot_store_ref table with store_role primary. It is only marking > removed column in snapshots table and deleting entries from > snapshot_store_ref table with store_role Image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7966) Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary
edison su created CLOUDSTACK-7966: - Summary: Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary Key: CLOUDSTACK-7966 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7966 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: edison su Assignee: edison su Fix For: 4.5.0 Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary even after deleting the snapshots Steps to reproduce: 1.Bring up CS in advanced zone with xen/vmware cluster 2.Deploy few guest vms using default cent os template 3.Create snapshots on all the root volumes of the vms created above 4.Verify snapshot_store_ref table entries. For each snapshot there would be two entries one with store role Primary and another one with Secondary 5.Delete all the snapshots and wait for the storage cleanup thread to run Expected Behavior: When we destroy snapshots all the snapshot entries should be removed from snapshot_store_ref table. Actual Behavior: = After deleting snapshots all the snapshot states are marked as Destroyed in both snapshot_store_ref and snapshots (status field) table. This is expected. However when the storage cleanup thread runs it is not deleting the entries from snapshot_store_ref table with store_role primary. It is only marking removed column in snapshots table and deleting entries from snapshot_store_ref table with store_role Image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7966) Storage cleanup thread does not delete the entries from snapshot_store_ref with store role Primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223658#comment-14223658 ] ASF subversion and git services commented on CLOUDSTACK-7966: - Commit 4e5b3d028dc990f27484b79db67926c4371715ac in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e5b3d0 ] CLOUDSTACK-7966: remove snapshot_store_ref entry, in which role is Primary, during storage GC > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary > -- > > Key: CLOUDSTACK-7966 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7966 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Storage cleanup thread does not delete the entries from snapshot_store_ref > with store role Primary even after deleting the snapshots > Steps to reproduce: > > 1.Bring up CS in advanced zone with xen/vmware cluster > 2.Deploy few guest vms using default cent os template > 3.Create snapshots on all the root volumes of the vms created above > 4.Verify snapshot_store_ref table entries. For each snapshot there would be > two entries one with store role Primary and another one with Secondary > 5.Delete all the snapshots and wait for the storage cleanup thread to run > Expected Behavior: > > When we destroy snapshots all the snapshot entries should be removed from > snapshot_store_ref table. > Actual Behavior: > = > After deleting snapshots all the snapshot states are marked as Destroyed in > both snapshot_store_ref and snapshots (status field) table. This is expected. > However when the storage cleanup thread runs it is not deleting the entries > from snapshot_store_ref table with store_role primary. It is only marking > removed column in snapshots table and deleting entries from > snapshot_store_ref table with store_role Image. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4200) listSystemVMs API and listRouters API fail to return hypervisor property
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223531#comment-14223531 ] ASF subversion and git services commented on CLOUDSTACK-4200: - Commit 73087bc3ffed4200e4e0a298b9e5539e248449a1 in cloudstack's branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=73087bc ] VM detail view: Disable 'change service offering' action per CLOUDSTACK-4200 > listSystemVMs API and listRouters API fail to return hypervisor property > - > > Key: CLOUDSTACK-4200 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4200 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > listSystemVMs API and listRouters API doesn't return hypervisor property and > this is important for scalevm operation, since its not implemented for all > the hypervisors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6743) Race condition situation in MessageDetector may cause a outer tight loop to spin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223280#comment-14223280 ] ASF subversion and git services commented on CLOUDSTACK-6743: - Commit 2aa9bb6896c51733dc8a321888e1e1cba566e618 in cloudstack's branch refs/heads/4.3 from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2aa9bb6 ] CLOUDSTACK-6743: Use edge-triggering in MessageDetector to handle bogus wakeup gracefully. Level triggering plus bogus wakeup can cause a tight loop to spin (cherry picked from commit 09ec127470febacb45df1e0323a7bd7e7343bd2e) Signed-off-by: Rohit Yadav Conflicts: framework/ipc/src/org/apache/cloudstack/framework/messagebus/MessageDetector.java framework/ipc/test/org/apache/cloudstack/messagebus/TestMessageBus.java > Race condition situation in MessageDetector may cause a outer tight loop to > spin > > > Key: CLOUDSTACK-6743 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6743 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0, 4.4.0 >Reporter: Kelven Yang >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > > MessageDetector current uses level-triggering to wait for messages from > message bus, a bogus wakeup may cause outside loop to become spinning. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14223251#comment-14223251 ] ASF subversion and git services commented on CLOUDSTACK-6669: - Commit ed90e0c751b138acf35ef4af2b46e36f6b2c5b83 in cloudstack's branch refs/heads/4.3 from [~olemasle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ed90e0c ] CLOUDSTACK-6669: Fix support resize in usage server Signed-off-by: Sebastien Goasguen (cherry picked from commit 303e6ffc1e36a5d1ba2a1d48093f996fef1614df) Signed-off-by: Rohit Yadav Conflicts: usage/src/com/cloud/usage/parser/VolumeUsageParser.java > 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.3.4#6332)
[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=14223247#comment-14223247 ] ASF subversion and git services commented on CLOUDSTACK-6669: - Commit 06a664b063d6e55fc969a016a6fc722e95d4bd23 in cloudstack's branch refs/heads/4.3 from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06a664b ] FIXED CLOUDSTACK-6669 Support volume resize in usage server (cherry picked from commit bdde5335f9988e460a667da97ebe0cde2e74e7a1) Signed-off-by: Rohit Yadav Conflicts: usage/src/com/cloud/usage/UsageManagerImpl.java > 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.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7636) Cloudstack 4.4.0 management package for Ubuntu 12.04 has wrong dependencies
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223038#comment-14223038
]
Carles Figuerola commented on CLOUDSTACK-7636:
--
I might've taken some wrong assumptions. I'll recreate the case I saw and dig
deeper on what was the actual problem.
> Cloudstack 4.4.0 management package for Ubuntu 12.04 has wrong dependencies
> ---
>
> Key: CLOUDSTACK-7636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7636
> 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: Carles Figuerola
>
> The management server still depends on tomcat6 and some config files, the
> init script and some links still point to tomcat/java 6.
> {code}
> Package: cloudstack-management
> Priority: extra
> Section: libs
> Installed-Size: 178667
> Maintainer: Wido den Hollander
> Architecture: all
> Source: cloudstack
> Version: 4.4.0
> Depends: cloudstack-common (= 4.4.0), tomcat6, sysvinit-utils, sudo, jsvc,
> python-mysqldb, libmysql-java, python-paramiko, augeas-tools
> Conflicts: cloud-client, cloud-client-ui, cloud-server
> Filename: dists/precise/4.4/pool/cloudstack-management_4.4.0_all.deb
> Size: 165101698
> MD5sum: ab9eb06c6c2c966e2acc647eaf1e8528
> SHA1: 22ab54aa7ff9634781fc33d6531ec6e1d8ba6410
> SHA256: 4cbc39cf3b2ec35e9148a44b13e5aa3f2da51018f88a74633ec16298fa4338a9
> SHA512:
> 5f76492b5396d0838008e6b0bd22afd72faf616b2fa70fa83882cb3f66e86d41d1ea5c30b580d9cf4821b86d431c93a2a64e481e15a7098a494972092a637311
> Description: CloudStack server library
> The CloudStack management server
> Homepage: http://www.cloudstack.org/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5306) scaling up vm fails on xenserver 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222944#comment-14222944
]
prashant kumar mishra edited comment on CLOUDSTACK-5306 at 11/24/14 12:39 PM:
--
For scaling up to work while vm deployment static max will be set which is
4*(memory in service offering).A vm deployed with mem=512 can be scaled up
upto 4*512 . If you want to scale up to 4096 deploy a vm with 1024 memory or
change so of vm to 1 024 and stop start vm
was (Author: prashantkm):
For scaling up to work while vm deployment static max will be set which is
4*(memory in service offering).If you are deploying a vm with mem=512 you can
scale up upto 4*512 . If you want to scale up to 4096 deploy a vm with 1024
memory or change so of vm to 1 024 and stop start
> scaling up vm fails on xenserver 6.2
>
>
> Key: CLOUDSTACK-5306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5306
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Xenserver 6.2 with all rollups / hostfixes and
> Cloudstack 4.2
>Reporter: Adam
>Assignee: prashant kumar mishra
>
> When trying to scale a virtual Machine, Dynamic scaling fails for both
> Windows / Linux machines.
> Steps to reproduce:
> -
> 1. Create vm in advance networking mode
> 2. Create few different Service offering
> 3. Deploy a VM with a small service offering
> (1 CPU, 512 MB RAM, 50 GB Disk)
> 3. Try scaling up to medium instance
> (2 CPU, 4096 RAM, 50 GB Disk).
> Expected:
> -
> Scaling should succeeded and resources will be dynamically increased
> Actual results:
> ---
> Scaling up resources fails (Both Linux and Windows).
> com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
> Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling
> VM:i-2-33-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot
> scale up the vm because of memory constraint violation: 0 <=
> memory-static-min(536870912) <= memory-dynamic-min(4294967296) <=
> memory-dynamic-max(4294967296) <= memory-static-max(2147483648)
> at
> com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3390)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1310)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1225)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1159)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-191:null) Seq 2-1094713440: Response Received:
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (DirectAgent-191:null) Seq 2-1094713440: Processing: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","port":-1,"result":true,"wait":0}}]
> }
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 2-1094713440: Received: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10, { GetVncPortAnswer } }
> 2013-11-28 19:08:50,434 INFO [cloud.servlet.ConsoleProxyServlet]
> (AgentManager-Handler-2:null) Parse host info returned from executing
> GetVNCPortCommand. host info:
> consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 INFO [cloud.consoleproxy.AgentHookBase]
> (AgentManager-Handler-2:nu
[jira] [Closed] (CLOUDSTACK-5306) scaling up vm fails on xenserver 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-5306.
-
Resolution: Invalid
> scaling up vm fails on xenserver 6.2
>
>
> Key: CLOUDSTACK-5306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5306
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Xenserver 6.2 with all rollups / hostfixes and
> Cloudstack 4.2
>Reporter: Adam
>Assignee: prashant kumar mishra
>
> When trying to scale a virtual Machine, Dynamic scaling fails for both
> Windows / Linux machines.
> Steps to reproduce:
> -
> 1. Create vm in advance networking mode
> 2. Create few different Service offering
> 3. Deploy a VM with a small service offering
> (1 CPU, 512 MB RAM, 50 GB Disk)
> 3. Try scaling up to medium instance
> (2 CPU, 4096 RAM, 50 GB Disk).
> Expected:
> -
> Scaling should succeeded and resources will be dynamically increased
> Actual results:
> ---
> Scaling up resources fails (Both Linux and Windows).
> com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
> Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling
> VM:i-2-33-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot
> scale up the vm because of memory constraint violation: 0 <=
> memory-static-min(536870912) <= memory-dynamic-min(4294967296) <=
> memory-dynamic-max(4294967296) <= memory-static-max(2147483648)
> at
> com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3390)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1310)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1225)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1159)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-191:null) Seq 2-1094713440: Response Received:
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (DirectAgent-191:null) Seq 2-1094713440: Processing: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","port":-1,"result":true,"wait":0}}]
> }
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 2-1094713440: Received: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10, { GetVncPortAnswer } }
> 2013-11-28 19:08:50,434 INFO [cloud.servlet.ConsoleProxyServlet]
> (AgentManager-Handler-2:null) Parse host info returned from executing
> GetVNCPortCommand. host info:
> consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 INFO [cloud.consoleproxy.AgentHookBase]
> (AgentManager-Handler-2:null) Re-authentication result. vm: 33, tunnel url:
> https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2, tunnel
> session: OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-2:null) SeqA 8-2857: Sending Seq 8-2857: { Ans: ,
> MgmtId: 236301644265749, via: 8, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.ConsoleAccessAuthenticationAnswer":{"_success":true,"_isReauthenticating":true,"_port":0,"_tunnelUrl":"https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2","_tunnelSession":"OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","result":true,"wait":0}
[jira] [Comment Edited] (CLOUDSTACK-5306) scaling up vm fails on xenserver 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222944#comment-14222944
]
prashant kumar mishra edited comment on CLOUDSTACK-5306 at 11/24/14 12:38 PM:
--
For scaling up to work while vm deployment static max will be set which is
4*(memory in service offering).If you are deploying a vm with mem=512 you can
scale up upto 4*512 . If you want to scale up to 4096 deploy a vm with 1024
memory or change so of vm to 1 024 and stop start
was (Author: prashantkm):
For scaling up to work while vm deployment static max will be set which is
4*(memory in service offering).If you are deploying a vm with mem=512 you can
scale up upto 4*512 . In your case if you want to scale up to 4096 deploy a vm
with 1024 memory or change so of vm to 1 024 and stop start
> scaling up vm fails on xenserver 6.2
>
>
> Key: CLOUDSTACK-5306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5306
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Xenserver 6.2 with all rollups / hostfixes and
> Cloudstack 4.2
>Reporter: Adam
>Assignee: prashant kumar mishra
>
> When trying to scale a virtual Machine, Dynamic scaling fails for both
> Windows / Linux machines.
> Steps to reproduce:
> -
> 1. Create vm in advance networking mode
> 2. Create few different Service offering
> 3. Deploy a VM with a small service offering
> (1 CPU, 512 MB RAM, 50 GB Disk)
> 3. Try scaling up to medium instance
> (2 CPU, 4096 RAM, 50 GB Disk).
> Expected:
> -
> Scaling should succeeded and resources will be dynamically increased
> Actual results:
> ---
> Scaling up resources fails (Both Linux and Windows).
> com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
> Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling
> VM:i-2-33-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot
> scale up the vm because of memory constraint violation: 0 <=
> memory-static-min(536870912) <= memory-dynamic-min(4294967296) <=
> memory-dynamic-max(4294967296) <= memory-static-max(2147483648)
> at
> com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3390)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1310)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1225)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1159)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-191:null) Seq 2-1094713440: Response Received:
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (DirectAgent-191:null) Seq 2-1094713440: Processing: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","port":-1,"result":true,"wait":0}}]
> }
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 2-1094713440: Received: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10, { GetVncPortAnswer } }
> 2013-11-28 19:08:50,434 INFO [cloud.servlet.ConsoleProxyServlet]
> (AgentManager-Handler-2:null) Parse host info returned from executing
> GetVNCPortCommand. host info:
> consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 INFO [cloud.consoleproxy.AgentHookBase]
> (Age
[jira] [Commented] (CLOUDSTACK-5306) scaling up vm fails on xenserver 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222944#comment-14222944
]
prashant kumar mishra commented on CLOUDSTACK-5306:
---
For scaling up to work while vm deployment static max will be set which is
4*(memory in service offering).If you are deploying a vm with mem=512 you can
scale up upto 4*512 . In your case if you want to scale up to 4096 deploy a vm
with 1024 memory or change so of vm to 1 024 and stop start
> scaling up vm fails on xenserver 6.2
>
>
> Key: CLOUDSTACK-5306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5306
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Xenserver 6.2 with all rollups / hostfixes and
> Cloudstack 4.2
>Reporter: Adam
>Assignee: prashant kumar mishra
>
> When trying to scale a virtual Machine, Dynamic scaling fails for both
> Windows / Linux machines.
> Steps to reproduce:
> -
> 1. Create vm in advance networking mode
> 2. Create few different Service offering
> 3. Deploy a VM with a small service offering
> (1 CPU, 512 MB RAM, 50 GB Disk)
> 3. Try scaling up to medium instance
> (2 CPU, 4096 RAM, 50 GB Disk).
> Expected:
> -
> Scaling should succeeded and resources will be dynamically increased
> Actual results:
> ---
> Scaling up resources fails (Both Linux and Windows).
> com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
> Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling
> VM:i-2-33-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot
> scale up the vm because of memory constraint violation: 0 <=
> memory-static-min(536870912) <= memory-dynamic-min(4294967296) <=
> memory-dynamic-max(4294967296) <= memory-static-max(2147483648)
> at
> com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3390)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1310)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1225)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1159)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-191:null) Seq 2-1094713440: Response Received:
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (DirectAgent-191:null) Seq 2-1094713440: Processing: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","port":-1,"result":true,"wait":0}}]
> }
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 2-1094713440: Received: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10, { GetVncPortAnswer } }
> 2013-11-28 19:08:50,434 INFO [cloud.servlet.ConsoleProxyServlet]
> (AgentManager-Handler-2:null) Parse host info returned from executing
> GetVNCPortCommand. host info:
> consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 INFO [cloud.consoleproxy.AgentHookBase]
> (AgentManager-Handler-2:null) Re-authentication result. vm: 33, tunnel url:
> https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2, tunnel
> session: OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-2:null) SeqA 8-2857: Sending Seq 8-2857: { Ans: ,
> MgmtId: 236
[jira] [Updated] (CLOUDSTACK-5306) scaling up vm fails on xenserver 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra updated CLOUDSTACK-5306:
--
Assignee: prashant kumar mishra
> scaling up vm fails on xenserver 6.2
>
>
> Key: CLOUDSTACK-5306
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5306
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Xenserver 6.2 with all rollups / hostfixes and
> Cloudstack 4.2
>Reporter: Adam
>Assignee: prashant kumar mishra
>
> When trying to scale a virtual Machine, Dynamic scaling fails for both
> Windows / Linux machines.
> Steps to reproduce:
> -
> 1. Create vm in advance networking mode
> 2. Create few different Service offering
> 3. Deploy a VM with a small service offering
> (1 CPU, 512 MB RAM, 50 GB Disk)
> 3. Try scaling up to medium instance
> (2 CPU, 4096 RAM, 50 GB Disk).
> Expected:
> -
> Scaling should succeeded and resources will be dynamically increased
> Actual results:
> ---
> Scaling up resources fails (Both Linux and Windows).
> com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
> Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling
> VM:i-2-33-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot
> scale up the vm because of memory constraint violation: 0 <=
> memory-static-min(536870912) <= memory-dynamic-min(4294967296) <=
> memory-dynamic-max(4294967296) <= memory-static-max(2147483648)
> at
> com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3390)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1310)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1225)
> at
> com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1159)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-191:null) Seq 2-1094713440: Response Received:
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (DirectAgent-191:null) Seq 2-1094713440: Processing: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","port":-1,"result":true,"wait":0}}]
> }
> 2013-11-28 19:08:50,434 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 2-1094713440: Received: { Ans: , MgmtId:
> 236301644265749, via: 2, Ver: v1, Flags: 10, { GetVncPortAnswer } }
> 2013-11-28 19:08:50,434 INFO [cloud.servlet.ConsoleProxyServlet]
> (AgentManager-Handler-2:null) Parse host info returned from executing
> GetVNCPortCommand. host info:
> consoleurl=https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2&sessionref=OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 INFO [cloud.consoleproxy.AgentHookBase]
> (AgentManager-Handler-2:null) Re-authentication result. vm: 33, tunnel url:
> https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2, tunnel
> session: OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c
> 2013-11-28 19:08:50,434 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-2:null) SeqA 8-2857: Sending Seq 8-2857: { Ans: ,
> MgmtId: 236301644265749, via: 8, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.ConsoleAccessAuthenticationAnswer":{"_success":true,"_isReauthenticating":true,"_port":0,"_tunnelUrl":"https://10.0.10.65/console?uuid=31bfb8a9-bdb3-f2ae-16f2-ce73bb2a95b2","_tunnelSession":"OpaqueRef:94664fed-e91f-5eac-e8cd-341ae95d802c","result":
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222919#comment-14222919 ] Alireza Eskandari commented on CLOUDSTACK-5696: --- I test for this bug in CS 4.3.1 from ShapeBlue.com RPMs. Steps that I follow: - I turn off vm from vCenter - In CS VM state is still running - I restarted cloudstack-management service - VM state is still Runnig in CS after service restart - I click on "Stop Instance" in CS (while VM is stopped in vCenter) - VM state changes to Stopped in CS - I turn on VM from CS - Again I turn it off from vCenter and its state in CS is "Running" In the following link I put catalina and management-server logs from where I restarted the management-server: https://www.dropbox.com/s/h8wovb79hhh3zb3/log.tar.gz?dl=0 > [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside > of CS. > --- > > Key: CLOUDSTACK-5696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Pre Req: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack ,Stop VM > Vm continues to remain in "Running" state in CS , even though the change in > state is detected. > Following exception seen in management server logs: > 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki > ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] > 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) > alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null > // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly > on host id:1, availability zone id:1, pod id:1 > 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. > 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) > at > com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) > at > com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) > at > com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) > at > com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) > at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) > at > com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) > 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$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thre
[jira] [Commented] (CLOUDSTACK-7636) Cloudstack 4.4.0 management package for Ubuntu 12.04 has wrong dependencies
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222882#comment-14222882
]
Wido den Hollander commented on CLOUDSTACK-7636:
What is the exact problem? We don't support tomcat7 (yet), so we depend on
tomcat6.
What is wrong with that dependency?
> Cloudstack 4.4.0 management package for Ubuntu 12.04 has wrong dependencies
> ---
>
> Key: CLOUDSTACK-7636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7636
> 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: Carles Figuerola
>
> The management server still depends on tomcat6 and some config files, the
> init script and some links still point to tomcat/java 6.
> {code}
> Package: cloudstack-management
> Priority: extra
> Section: libs
> Installed-Size: 178667
> Maintainer: Wido den Hollander
> Architecture: all
> Source: cloudstack
> Version: 4.4.0
> Depends: cloudstack-common (= 4.4.0), tomcat6, sysvinit-utils, sudo, jsvc,
> python-mysqldb, libmysql-java, python-paramiko, augeas-tools
> Conflicts: cloud-client, cloud-client-ui, cloud-server
> Filename: dists/precise/4.4/pool/cloudstack-management_4.4.0_all.deb
> Size: 165101698
> MD5sum: ab9eb06c6c2c966e2acc647eaf1e8528
> SHA1: 22ab54aa7ff9634781fc33d6531ec6e1d8ba6410
> SHA256: 4cbc39cf3b2ec35e9148a44b13e5aa3f2da51018f88a74633ec16298fa4338a9
> SHA512:
> 5f76492b5396d0838008e6b0bd22afd72faf616b2fa70fa83882cb3f66e86d41d1ea5c30b580d9cf4821b86d431c93a2a64e481e15a7098a494972092a637311
> Description: CloudStack server library
> The CloudStack management server
> Homepage: http://www.cloudstack.org/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7965) test_persistent_networks.TestVPCNetworkOperations.test_vpc_force_delete_domain fails with "Failed to delete domain, domain not found"
Ashutosk Kelkar created CLOUDSTACK-7965: --- Summary: test_persistent_networks.TestVPCNetworkOperations.test_vpc_force_delete_domain fails with "Failed to delete domain, domain not found" Key: CLOUDSTACK-7965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7965 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.5.0 The issue arises when the delete domain fails with some reason, but the same domain is added again in cleanup list through the code in except. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222814#comment-14222814 ] Rohit Yadav commented on CLOUDSTACK-6624: - You are allowed to send specifyIpRanges=true while creating network offering for isolated networks. One can use something like cloudmonkey to verify this against 4.4/4.5/master. Perhaps because other changes and UI fixes related to this are not on 4.3; on 4.3 branch this fix works, I'm able to create an isolated networks with specifyIPranges and specifyVlan to true. I cannot confirm the same on 4.5/master branches. > Unable to create new Network Offerings via UI with Specify VLAN option set > -- > > Key: CLOUDSTACK-6624 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Geoff Higgibottom >Assignee: Rohit Yadav >Priority: Critical > Labels: UI > Fix For: 4.3.1 > > > When creating a new network offering with the Specify VLAN option set, the > Specify IP Option should also be set automatically. The UI is no longer > sending this parameter in the API string so the Network Offering has an > invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7964) listAccounts API is not listing correct value of resource limits.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-7964. - Resolution: Fixed > listAccounts API is not listing correct value of resource limits. > - > > Key: CLOUDSTACK-7964 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7964 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.5.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.6.0 > > Attachments: screenshot-1.png > > > In ListAccounts API response, value for resourceLimits for all the resource > types are coming as "Unlimited", it should list the correct limit values set > in resource_limits table per account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7964) listAccounts API is not listing correct value of resource limits.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-7964: Affects Version/s: 4.5.0 > listAccounts API is not listing correct value of resource limits. > - > > Key: CLOUDSTACK-7964 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7964 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.5.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.6.0 > > Attachments: screenshot-1.png > > > In ListAccounts API response, value for resourceLimits for all the resource > types are coming as "Unlimited", it should list the correct limit values set > in resource_limits table per account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7964) listAccounts API is not listing correct value of resource limits.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222771#comment-14222771 ] ASF subversion and git services commented on CLOUDSTACK-7964: - Commit d475b62838878677531d6daab667757baf63604e in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d475b62 ] CLOUDSTACK-7964: listAccounts API is not listing correct value of resource limits. > listAccounts API is not listing correct value of resource limits. > - > > Key: CLOUDSTACK-7964 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7964 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.6.0 > > Attachments: screenshot-1.png > > > In ListAccounts API response, value for resourceLimits for all the resource > types are coming as "Unlimited", it should list the correct limit values set > in resource_limits table per account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7964) listAccounts API is not listing correct value of resource limits.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-7964: Attachment: screenshot-1.png > listAccounts API is not listing correct value of resource limits. > - > > Key: CLOUDSTACK-7964 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7964 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.6.0 > > Attachments: screenshot-1.png > > > In ListAccounts API response, value for resourceLimits for all the resource > types are coming as "Unlimited", it should list the correct limit values set > in resource_limits table per account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7964) listAccounts API is not listing correct value of resource limits.
Sanjay Tripathi created CLOUDSTACK-7964: --- Summary: listAccounts API is not listing correct value of resource limits. Key: CLOUDSTACK-7964 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7964 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 In ListAccounts API response, value for resourceLimits for all the resource types are coming as "Unlimited", it should list the correct limit values set in resource_limits table per account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reopened CLOUDSTACK-7364: > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7364. Resolution: Cannot Reproduce > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Attachment: 10_5_NS_vlan_ip_if.png 10_1NS_vlan_ip_if.png > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222767#comment-14222767 ] Rajesh Battala commented on CLOUDSTACK-7364: Attaching the screenshots of 10.1 and 10.5 version NS VPX. where the public vlan (100) is binded to the public interfance (1/1) and public ip and subnet are bindined to vlan(100) > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: management-server.log.debug.gz, screenshot-1.png, > screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
