[jira] [Issue Comment Deleted] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
France updated CLOUDSTACK-8014:
---
Comment: was deleted
(was: Tnx Rohit for your efforts.
I will read your responses with great cate and try to do what you ask of me,
then report back on the jira.
This is just a private mail to you, so you know I am working on it, the problem
is that i have to deal with the customers concurrently on completely different
field. :-/
Regards,
F.
)
> Failed to create a volume from snapshot - Discrepency in the resource count ?
> -
>
> Key: CLOUDSTACK-8014
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.1
>Reporter: France
>Assignee: Rohit Yadav
>
> As sent to mailing list:
> Hi all.
> We are on XS 6.0.2+Hotfixes and CS 4.3.1.
> (All errors we are getting nowadays have come up only after upgrade from
> 4.1.1, 4.1.1 worked perfectly.)
> After successfully creating s snapshot, I want to create a volume from it, so
> it can be downloaded offsite.
> After clicking “Create volume” I get an error Failed to create a volume.
> If i got to list of volumes, there is a volume with name as defined, but
> Status is empty, and only buttons for attach and destroy exist.
> I have taken a look at catalina.out and management-server.log. Here is the
> log detailing a failure.
> Can you see the problem? How should I fix it? Please advise me.
> Should I create a bug report?
> I have also manually checked space on all storages and it seems there is LOTS
> of free space. Resources based on CS Web GUI are:
> Primary Storage Allocated 15%
> Secondary Storage 5%
> 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy
> 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM
> 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET
> command=listZones&available=true&response=json&sessionkey=CENSORED%3D&_=1417605814964
> 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 --
> GET
> command=listZones&available=true&response=json&sessionkey=CENSORED%3D&_=1417605814964
> 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET
> command=createVolume&response=json&sessionkey=CENSORED%3D&snapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4&name=testbrisi567&_=1417605818552
> 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring
> 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59,
> accountId: 60, instanceType: Volume, instanceId: 617, cmd:
> org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
> {"id":"617","response":"json","sessionkey":"CENSORED\u003d","cmdEventType":"VOLUME.CREATE","ctxUserId":"59","snapshotid":"49e4bba9-844d-4b7b-aca2-95a318f17dc4","name":"testbrisi567","httpmethod":"GET","_":"1417605818552","ctxAccountId":"60","ctxStartEventId":"62488"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 95545481387, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl]
> (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242404#comment-14242404 ] France commented on CLOUDSTACK-8014: The template from which this VM was created, has actually been deleted, based on the name of the template (deleteD :-) At first account was not able to create VM, cause it had template limit set to 0. I have since increased this maximum template value to 2 and was able to create template from that Snapshot _successfully_. Then I went on to proceed to create Volume from that snapshot, which _failed again_ with below error. I also tried to download Template, which failed because it was not extractable. I would think, this bug is still not solved, and unless you are convinced otherwise, would recommend to re-open it. I can re-open it, if you wish. _if additional info is required, including monitored access to this ACS setup, it can be arranged. Just let me know._ I believe/guess the key to this issue lies within these two lines: // 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Removing pool Pool[208|IscsiLUN] from avoid set, must have been inserted when searching for another disk's tag 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Removing pool Pool[209|IscsiLUN] from avoid set, must have been inserted when searching for another disk's tag // I guess it has something to do with storage tags. Looks like it can not find a suitable deployment? 2014-12-11 11:46:43,659 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) LocalStoragePoolAllocator trying to find storage pool to fit the vm 2014-12-11 11:46:43,660 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) ClusterScopeStoragePoolAllocator looking for storage pool 2014-12-11 11:46:43,660 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Looking for pools in dc: 1 pod:1 cluster:null having tags:[HAiscsi2] 2014-12-11 11:46:43,662 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Found pools matching tags: [Pool[208|IscsiLUN], Pool[209|IscsiLUN]] 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Adding pool Pool[206|IscsiLUN] to avoid set since it did not match tags 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Adding pool Pool[207|IscsiLUN] to avoid set since it did not match tags 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Adding pool Pool[210|NetworkFilesystem] to avoid set since it did not match tags 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Removing pool Pool[208|IscsiLUN] from avoid set, must have been inserted when searching for another disk's tag 2014-12-11 11:46:43,667 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Removing pool Pool[209|IscsiLUN] from avoid set, must have been inserted when searching for another disk's tag 2014-12-11 11:46:43,668 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Checking if storage pool is suitable, name: null ,poolId: 208 2014-12-11 11:46:43,673 DEBUG [c.c.s.StorageManagerImpl] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Checking pool 208 for storage, totalSize: 1520242262016, usedBytes: 887716052992, usedPct: 0.5839306505101337, disable threshold: 0.95 2014-12-11 11:46:43,678 DEBUG [c.c.s.VolumeApiServiceImpl] (Job-Executor-56:ctx-3adba05f ctx-f361c79d) Failed to create volume: 621 java.lang.NullPointerException at com.cloud.storage.StorageManagerImpl.storagePoolHasEnoughSpace(StorageManagerImpl.java:1570) at org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.filter(AbstractStoragePoolAllocator.java:199) at org.apache.cloudstack.storage.allocator.ClusterScopeStoragePoolAllocator.select(ClusterScopeStoragePoolAllocator.java:110) at org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.allocateToPool(AbstractStoragePoolAllocator.java:109) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.findStoragePool(VolumeOrchestrator.java:256) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeFromSnapshot(VolumeOrchestrator.java:339) at com.cloud.storage.VolumeApiServiceImpl.createVolumeFromSnapshot(VolumeApiServiceImpl.java:785) at com.cloud.storage.VolumeApiServiceImpl.createVolume(VolumeApiServiceImpl.java:735)
[jira] [Commented] (CLOUDSTACK-8062) test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242465#comment-14242465 ] ASF subversion and git services commented on CLOUDSTACK-8062: - Commit 7ff118c90b80a51efea73f87ac70dc686d92753b in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ff118c ] CLOUDSTACK-8062: test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case Signed-off-by: SrikanteswaraRao Talluri > test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP > range in each test case > -- > > Key: CLOUDSTACK-8062 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8062 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Each test case in this test suite uses the same vlan IP range, adds it and > deletes it. In some cases, the vlan IP range deletion fails due to this > operation. > Change the test case to use different vlan IP range each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8062) test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242469#comment-14242469 ] ASF subversion and git services commented on CLOUDSTACK-8062: - Commit b45fe24e5c30360a03adbc4551baf8fe02cdfab6 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b45fe24 ] CLOUDSTACK-8062: test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case Signed-off-by: SrikanteswaraRao Talluri > test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP > range in each test case > -- > > Key: CLOUDSTACK-8062 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8062 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Each test case in this test suite uses the same vlan IP range, adds it and > deletes it. In some cases, the vlan IP range deletion fails due to this > operation. > Change the test case to use different vlan IP range each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242520#comment-14242520
]
Rohit Yadav commented on CLOUDSTACK-8014:
-
Hi France, the failure (NullPointerException) is due to the fact that the
template has been removed (the removed field in the DB will not be NULL) and
the code where it throws NPE was fixed. If you think it's something related to
tags causing this, then you may reopen the ticket. The best way to detect this
would be to go to the db, and in vm_template table set removed=NULL for the
specific template Id and then restart mgmt server(s) and see if you can still
reproduce the NPE.
> Failed to create a volume from snapshot - Discrepency in the resource count ?
> -
>
> Key: CLOUDSTACK-8014
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.1
>Reporter: France
>Assignee: Rohit Yadav
>
> As sent to mailing list:
> Hi all.
> We are on XS 6.0.2+Hotfixes and CS 4.3.1.
> (All errors we are getting nowadays have come up only after upgrade from
> 4.1.1, 4.1.1 worked perfectly.)
> After successfully creating s snapshot, I want to create a volume from it, so
> it can be downloaded offsite.
> After clicking “Create volume” I get an error Failed to create a volume.
> If i got to list of volumes, there is a volume with name as defined, but
> Status is empty, and only buttons for attach and destroy exist.
> I have taken a look at catalina.out and management-server.log. Here is the
> log detailing a failure.
> Can you see the problem? How should I fix it? Please advise me.
> Should I create a bug report?
> I have also manually checked space on all storages and it seems there is LOTS
> of free space. Resources based on CS Web GUI are:
> Primary Storage Allocated 15%
> Secondary Storage 5%
> 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy
> 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM
> 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET
> command=listZones&available=true&response=json&sessionkey=CENSORED%3D&_=1417605814964
> 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 --
> GET
> command=listZones&available=true&response=json&sessionkey=CENSORED%3D&_=1417605814964
> 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet]
> (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET
> command=createVolume&response=json&sessionkey=CENSORED%3D&snapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4&name=testbrisi567&_=1417605818552
> 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl]
> (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to
> com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to
> Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker
> 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring
> 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59,
> accountId: 60, instanceType: Volume, instanceId: 617, cmd:
> org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
> {"id":"617","response":"json","sessionkey":"CENSORED\u003d","cmdEventType":"VOLUME.CREATE","ctxUserId":"59","snapshotid":"49e4bba9-844d-4b7b-aca2-95a318f17dc4","name":"testbrisi567","httpmethod":"GET","_":"1417605818552","ctxAccountId":"60","ctxStartEventId":"62488"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 95545481387, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl]
> (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to
> A
[jira] [Commented] (CLOUDSTACK-8051) updateNetwork fail for NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242553#comment-14242553 ] ASF subversion and git services commented on CLOUDSTACK-8051: - Commit f5619f428b2e8ab25a2ce1ac8c03262714bc32cb in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5619f4 ] CLOUDSTACK-8051: fix NPE in updateNetwork due to static nat rules exist but no StaticNat provider > updateNetwork fail for NPE > -- > > Key: CLOUDSTACK-8051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8051 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > ways to reproduce > (1) create isolated network with StaticNat > (2) acquire IP, enable static nat > (3) create a new network offering without StaticNat > (4) update the offering of the network . > An error raised: > 2014-12-08 17:31:18,614 ERROR [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-37:ctx-6a71b2fd job-1367 ctx-1d6e329d) Cannot find > StaticNat provider for network 211 > 2014-12-08 17:31:18,615 WARN [c.c.n.NetworkServiceImpl] > (API-Job-Executor-37:ctx-6a71b2fd job-1367 ctx-1d6e329d) Failed to implement > network Ntwk[211|Guest|17] elements and resources as a part of network update > due to > java.lang.NullPointerException > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.getStaticNatProviderForNetwork(NetworkOrchestrator.java:3165) > at > com.cloud.network.IpAddressManagerImpl.applyStaticNats(IpAddressManagerImpl.java:1725) > at > com.cloud.network.rules.RulesManagerImpl.applyStaticNatsForNetwork(RulesManagerImpl.java:988) > 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) > .. > 2014-12-09 08:26:54,925 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-2:ctx-208f7944 job-1434) Unexpected exception while > executing > org.apache.cloudstack.api.command.admin.network.UpdateNetworkCmdByAdmin > com.cloud.utils.exception.CloudRuntimeException: Failed to implement network > (with specified id) elements and resources as a part of network update > at > com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2335) > 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) > The restartNetwork also fail with the same error. > Moreover, the virtual router stop/start twice during it. it may be an issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8051) updateNetwork fail for NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-8051. -- Resolution: Fixed Fix Version/s: 4.6.0 > updateNetwork fail for NPE > -- > > Key: CLOUDSTACK-8051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8051 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > Fix For: 4.6.0 > > > ways to reproduce > (1) create isolated network with StaticNat > (2) acquire IP, enable static nat > (3) create a new network offering without StaticNat > (4) update the offering of the network . > An error raised: > 2014-12-08 17:31:18,614 ERROR [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-37:ctx-6a71b2fd job-1367 ctx-1d6e329d) Cannot find > StaticNat provider for network 211 > 2014-12-08 17:31:18,615 WARN [c.c.n.NetworkServiceImpl] > (API-Job-Executor-37:ctx-6a71b2fd job-1367 ctx-1d6e329d) Failed to implement > network Ntwk[211|Guest|17] elements and resources as a part of network update > due to > java.lang.NullPointerException > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.getStaticNatProviderForNetwork(NetworkOrchestrator.java:3165) > at > com.cloud.network.IpAddressManagerImpl.applyStaticNats(IpAddressManagerImpl.java:1725) > at > com.cloud.network.rules.RulesManagerImpl.applyStaticNatsForNetwork(RulesManagerImpl.java:988) > 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) > .. > 2014-12-09 08:26:54,925 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-2:ctx-208f7944 job-1434) Unexpected exception while > executing > org.apache.cloudstack.api.command.admin.network.UpdateNetworkCmdByAdmin > com.cloud.utils.exception.CloudRuntimeException: Failed to implement network > (with specified id) elements and resources as a part of network update > at > com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2335) > 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) > The restartNetwork also fail with the same error. > Moreover, the virtual router stop/start twice during it. it may be an issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8063) list secondary Ips information in VM response
Wei Zhou created CLOUDSTACK-8063: Summary: list secondary Ips information in VM response Key: CLOUDSTACK-8063 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8063 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou Priority: Minor and display it on UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4212) Can not deploy VM on the specific host on CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242757#comment-14242757 ] Wei Zhou commented on CLOUDSTACK-4212: -- fixed by bf9e1ae7e80d143728c8f53633eb82521a003ddb https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=bf9e1ae7 > Can not deploy VM on the specific host on CloudStack UI > --- > > Key: CLOUDSTACK-4212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4212 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Priority: Minor > Fix For: 4.5.0, 4.6.0 > > > When I wanted to add an instance on Infracstrure->Hosts-[select one]->View > Instances->Add Instance, I can not see parameter "hostid" in the > deployvirtualmachinecommand (see below). > Of course, it will be deployed to another host. > 2013-08-09 14:42:27,660 DEBUG [c.c.a.ApiServlet] > (183321020@qtp-1770329462-11:null) ===START=== 192.168.56.1 -- GET > command=deployVirtualMachine&zoneId=62efbd96-89c6-4d55-b9f6-3756c8d8f686&templateId=7f23448a-00ef-11e3-a62f-0800279da712&hypervisor=XenServer&serviceOfferingId=8c6a9fc6-00ef-11e3-a62f-0800279da712&displayname=wei001&name=wei001&response=json&sessionkey=wknKfcA2t1FSDcGNUbbdiayZliE%3D&_=1376052147609 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-4212) Can not deploy VM on the specific host on CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-4212. -- Resolution: Fixed Fix Version/s: 4.6.0 4.5.0 Assignee: Wei Zhou > Can not deploy VM on the specific host on CloudStack UI > --- > > Key: CLOUDSTACK-4212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4212 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou >Priority: Minor > Fix For: 4.5.0, 4.6.0 > > > When I wanted to add an instance on Infracstrure->Hosts-[select one]->View > Instances->Add Instance, I can not see parameter "hostid" in the > deployvirtualmachinecommand (see below). > Of course, it will be deployed to another host. > 2013-08-09 14:42:27,660 DEBUG [c.c.a.ApiServlet] > (183321020@qtp-1770329462-11:null) ===START=== 192.168.56.1 -- GET > command=deployVirtualMachine&zoneId=62efbd96-89c6-4d55-b9f6-3756c8d8f686&templateId=7f23448a-00ef-11e3-a62f-0800279da712&hypervisor=XenServer&serviceOfferingId=8c6a9fc6-00ef-11e3-a62f-0800279da712&displayname=wei001&name=wei001&response=json&sessionkey=wknKfcA2t1FSDcGNUbbdiayZliE%3D&_=1376052147609 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-2733) Add advanced zone with security groups support on Jenkins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou closed CLOUDSTACK-2733. Resolution: Won't Fix > Add advanced zone with security groups support on Jenkins > - > > Key: CLOUDSTACK-2733 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2733 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Infra, Test Tools >Affects Versions: 4.2.0 >Reporter: Wei Zhou >Assignee: Prasanna Santhanam > > advanced zone with security groups should be included in jenkins integration > test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8064) UpdatePortForwardingRuleCmd implementation
Wei Zhou created CLOUDSTACK-8064: Summary: UpdatePortForwardingRuleCmd implementation Key: CLOUDSTACK-8064 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8064 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou it is not implemented -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7950) AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242775#comment-14242775 ] ASF subversion and git services commented on CLOUDSTACK-7950: - Commit 2e76d318aea9211fbb394a606236002aeedd59f6 in cloudstack's branch refs/heads/4.4 from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2e76d31 ] CLOUDSTACK-7950: AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO (cherry picked from commit 4ff3130becd50ab8d44864b651c1b1e235d67e6f) Signed-off-by: Rohit Yadav > AttachIsoCmd shoud give correct messge when trying to attach vmwaretools > installer iso on non supported guestvm deployed by ISO > --- > > Key: CLOUDSTACK-7950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > Deploy vm from iso say centos 6.4 > Try attach vmware iso tools from cloudstack > The log message/UI is not clear about the failure. > INFO [c.c.h.v.m.HostMO] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, > cmd: AttachCommand) VM i-2-8-VM not found in host cache > ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-341:ctx-2492ca8c > 10.102.192.14, job-79, cmd: AttachCommand) AttachIsoCommand(attach) failed > due to Exception: javax.xml.ws.soap.SOAPFaultException > Message: The required VMware Tools ISO image does not exist or is > inaccessible. > javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image > does not exist or is inaccessible. > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > Message should contain info about non supported gues os. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5446) KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason "there is othe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242774#comment-14242774 ] ASF subversion and git services commented on CLOUDSTACK-5446: - Commit 40bc5df0b1f82e5282521a869648b17c4af51558 in cloudstack's branch refs/heads/4.4 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40bc5df ] CLOUDSTACK-5446: delete all the leftover snapshots on primary storage in case of snapshot errors, after a new backup snapshot is finished (cherry picked from commit 2667855ccb932f9a03ddf6639f6411c73fea1b2c) Signed-off-by: Rohit Yadav > KVM-Secondary Store down-Even after secondary store is brought back up after > being down for few hours,snapshot jobs do not get triggered with reason > "there is other active snapshot tasks on the instance to which the volume is > attached" > --- > > Key: CLOUDSTACK-5446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5446 > 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 > > Attachments: agentdown.rar, ssdown.rar > > > KVM - Secondary Store down - Even after secondary store is brought back up > after being down for few hours , snapshot jobs do not get triggered with > reason "here is other active snapshot tasks on the instance to which the > volume is attached, please try again later" > Set up: > Advanced Zone set up with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we > start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > 3. Shutdown the Secondary storage server when the snapshots are in the > progress. > 4. Bring the Secondary storage server up after ~ 12 hours. > When the secondary storage was down: > The snapshot jobs that were in progress timed out after 6 hours. > Even after this , I do not see the hourly snapshots being scheduled due to > the following reason: > > 2013-12-10 13:07:49,285 WARN [c.c.s.s.SnapshotSchedulerImpl] > (SnapshotPollTask:ctx-cf0775f7) Scheduling snapshot failed due to > com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later > Even after the secondary storage was brought up , there is no hourly > snapshots being scheduled due to the same reason - > "com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later" > mysql> select * FROM snapshots; > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status | path | name| > uuid | snapshot_type | type_description | > size| created | removed | backup_snap_id | swift_id | > sechost_id | prev_snap_id | hypervisor_type | version | s3_id | > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | 1 | 1 | 6 | 1 |45 | 18 > | BackedUp | NULL | TestVM-tiny-host-0ps-0-0_ROOT-45_20131209234410 | > ee2c46b7-7623-439a-9a30-63eec1d95c56 | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 2 | 1 | 6 | 1 |43 | 18 > | BackedUp | NULL | TestVM-1_ROOT-43_20131209234410 | > 62c01389-49df-475b-b225-617d3903d25a | 3 | HOURLY
[jira] [Commented] (CLOUDSTACK-7766) Field Validations Missing for Ingress and Egress Rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242776#comment-14242776 ] ASF subversion and git services commented on CLOUDSTACK-7766: - Commit 1971b432c3a4d191956597f9acea2694067c5c06 in cloudstack's branch refs/heads/4.4 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1971b43 ] Revert "CLOUDSTACK-7766: Field Validations Missing for Ingress and Egress Rules" This breaks validations such as ingress/egress rules on Security Group on the UI so reverting this. This reverts commit ca8ecc0470191eb35788429a7afcf604ee3d389c. Signed-off-by: Rohit Yadav > Field Validations Missing for Ingress and Egress Rules > -- > > Key: CLOUDSTACK-7766 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7766 > 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: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > Steps- > 1. For a Network-Security groups, go to the Ingress Rule (or Egress Rule) tab. > There are no Field Validations for the Start Port, End Port and CIDR fields. > This issue exists for both: CIDR and Account. > Additionally, the same applies for both: Ingress and Egress rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8065) Reinstall VM fails to restart instance in VMware
Paul Angus created CLOUDSTACK-8065: -- Summary: Reinstall VM fails to restart instance in VMware Key: CLOUDSTACK-8065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8065 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Hypervisor Controller, Management Server Affects Versions: 4.3.1 Environment: CloudStack 4.3.1 with VMware 5.5 Reporter: Paul Angus Priority: Critical Error: Unable to start VM with specified idUnable to start a VM due to insufficient capacity Is returned when reinstalling a VM to original template state. original disk is deleted, but upon startup the host tries to deleted disk Delete virtual machine - ROOT-366 - Completed Reconfigure virtual machine - CPBM1 - File []/vmfs/volumes/536bc4-ed-d4f59724-e378-00e0-81b92cbe/CPBM1/ROOT-366.vmdk was not found request VM start after this error successfully starts the guest vm.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14242873#comment-14242873 ] Anton Onopriychuk commented on CLOUDSTACK-5809: --- but what's the sense behind storage overprovisioning in case capacity.disablethreshold just dont allow to overprovision ? > 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-8061) Extracting volume when it is in migrating state causes both the operations to fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243004#comment-14243004 ] ASF subversion and git services commented on CLOUDSTACK-8061: - Commit 528bc80b4c03306ab2d15a8bc1bf2bb7fe404988 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=528bc80 ] CLOUDSTACK-8061: Extracting volume when it is in migrating state causes both the operations to fail. > Extracting volume when it is in migrating state causes both the operations to > fail > -- > > Key: CLOUDSTACK-8061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 > 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: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Extracting volume when it is in migrating state causes both the operations to > fail > Steps to Reproduce: > > 1.Bring up CloudStack in advanced zone with xen cluster > 2.Add two shared cluster level primary stores to the cluster > 3.Deploy one vm using the default cent os template > 4.Stop the vm > 5.Migrate volume to another shared store > 6.When the volume is in migrating state try to download the same volume. We > will not see extract volume option in UI while volume is in migrating state. > So please do it using API: > http:/:8096/client/api?command=extractVolume&id=03f4a082-a96c-4195-b74b-7aa602926825&zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557&mode=HTTP_DOWNLOAD > Expected Behavior: > > If there is a race condition either of this operation should succeed. Or > ExtractVolume job should wait for the migration job to finish and then > execute extractvolume. > Actual Behavior: > = > Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8061) Extracting volume when it is in migrating state causes both the operations to fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243020#comment-14243020 ] ASF subversion and git services commented on CLOUDSTACK-8061: - Commit fbe54974c514572d1c224528446618c31952e25a in cloudstack's branch refs/heads/4.5 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fbe5497 ] CLOUDSTACK-8061: Extracting volume when it is in migrating state causes both the operations to fail. > Extracting volume when it is in migrating state causes both the operations to > fail > -- > > Key: CLOUDSTACK-8061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 > 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: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Extracting volume when it is in migrating state causes both the operations to > fail > Steps to Reproduce: > > 1.Bring up CloudStack in advanced zone with xen cluster > 2.Add two shared cluster level primary stores to the cluster > 3.Deploy one vm using the default cent os template > 4.Stop the vm > 5.Migrate volume to another shared store > 6.When the volume is in migrating state try to download the same volume. We > will not see extract volume option in UI while volume is in migrating state. > So please do it using API: > http:/:8096/client/api?command=extractVolume&id=03f4a082-a96c-4195-b74b-7aa602926825&zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557&mode=HTTP_DOWNLOAD > Expected Behavior: > > If there is a race condition either of this operation should succeed. Or > ExtractVolume job should wait for the migration job to finish and then > execute extractvolume. > Actual Behavior: > = > Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7881) Allow VPN IP range to be specified when creating a VPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Logan B updated CLOUDSTACK-7881: Attachment: f74b1a26db4514b9795ed760504351db8b03ef03.patch Patch submitted to review board. > Allow VPN IP range to be specified when creating a VPN > -- > > Key: CLOUDSTACK-7881 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7881 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 > Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS >Reporter: Logan B >Priority: Minor > Fix For: 4.5.0, 4.6.0 > > Attachments: f74b1a26db4514b9795ed760504351db8b03ef03.patch > > > Currently when creating a VPN on an Isolated Network via the UI the default > VPN IP range (specified in Global Settings) is used. The API permits > overriding this range during VPN creation. > I would suggest adding a text box to the VPN creation form in the UI to > specify an IP range that overrides the defaults. While not critical, it can > be useful to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5536) Restarting cloudstack service with template download in progress creates redundant entries in DB for systemVM template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5536: --- Fix Version/s: (was: 4.5.0) 4.6.0 > Restarting cloudstack service with template download in progress creates > redundant entries in DB for systemVM template > --- > > Key: CLOUDSTACK-5536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5536 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.3.0 > Environment: Latest 4.3 MS build > VmWare Host >Reporter: Pavan Kumar Bandarupally >Assignee: Min Chen > Fix For: 4.6.0, 4.4.3 > > Attachments: MS Log.rar > > > My NFS secondary store has been migrated to Object Storage and an S3 > secondary Store is added. At this point the systemVM template will be > downloaded to S3 store. > If we restart cloudstack-management service when download is in progress, the > current entry in template_store_ref which shows status as creating , persists > and a new entry will be created. If we restart the service once again another > entry is created persisting the older two entries as is. > "Removing leftover template routing-8 entry from template store table" is > shown in the traces but this doesn't take effect. > mysql> select template_id, store_id, store_role, state, install_path from > template_store_ref; > +-+--++---+---+ > | template_id | store_id | store_role | state | install_path > | > +-+--++---+---+ > | 8 |1 | ImageCache | Ready | > template/tmpl/1/8/2ad21358-644d-450c-99a1-6c156afa3206.ova| > | 7 |1 | ImageCache | Ready | > template/tmpl/1/7/a970a6d7-b1ed-3d5a-a8ed-661e059d9f30.ova| > | 7 |2 | Image | Ready | NULL > | > | 8 |2 | Image | Creating | > template/tmpl/1/8/routing-8 | > | 202 |2 | Image | Ready | > template/tmpl/2/202/202-2-480dd062-9b5c-3f3d-8bd5-934b160883dc/Win832.ova | > | 8 |2 | Image | Ready | > template/tmpl/1/8/routing-8/systemvmtemplate-4.2-vh7.ova | > | 8 |2 | Image | Allocated | > template/tmpl/1/8/routing-8/systemvmtemplate-4.2-vh7.ova | > | 8 |2 | Image | Allocated | > template/tmpl/1/8/routing-8 | > +-+--++---+---+ > Expected: > --- > Upon service restart, template sync should reset the download of the template > and create only one entry for the systemVM template. > Actual: > - > The older entry persists and new entry is created with status as Allocated or > Creating. > Note: > = > This happens only with SystemVM template. General template downloads are > properly reset and only one entry exists for them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8032) [UI] PF/StaticNat NET2 configure page showing VM NET2 nic ip addresses
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-8032. -- Resolution: Incomplete Jayapal, I do NOT have the environment. Please always provide database dump. Please always provide a database dump when filing an issue, especially UI issue. Jessica > [UI] PF/StaticNat NET2 configure page showing VM NET2 nic ip addresses > --- > > Key: CLOUDSTACK-8032 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8032 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jessica Wang > Fix For: 4.5.0 > > > 1. Deploy VM in isolated network net1 > 2. Attach another nic from the net2 > 3. Acquire secondary ip address from net2 for the VM. > 4. Now got net2 and acquire public ip. > 5. On net2 public ip PF/staticNat select VM page, select the VM. On > selecting the VM, UI is showing net1/default network instead of net2 ip > addresses. > > Tested from the API, there are no issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-8032) [UI] PF/StaticNat NET2 configure page showing VM NET2 nic ip addresses
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243259#comment-14243259 ] Jessica Wang edited comment on CLOUDSTACK-8032 at 12/11/14 11:16 PM: - Jayapal, I do NOT have the environment. Please provide the database dump. Database dump/logs/screenshots should be provided when filing an issue. In this case, I do need the database dump. It's better if you can provide the screenshots as well. Jessica was (Author: jessicawang): Jayapal, I do NOT have the environment. Please always provide database dump. Please always provide a database dump when filing an issue, especially UI issue. Jessica > [UI] PF/StaticNat NET2 configure page showing VM NET2 nic ip addresses > --- > > Key: CLOUDSTACK-8032 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8032 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jessica Wang > Fix For: 4.5.0 > > > 1. Deploy VM in isolated network net1 > 2. Attach another nic from the net2 > 3. Acquire secondary ip address from net2 for the VM. > 4. Now got net2 and acquire public ip. > 5. On net2 public ip PF/staticNat select VM page, select the VM. On > selecting the VM, UI is showing net1/default network instead of net2 ip > addresses. > > Tested from the API, there are no issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14243579#comment-14243579
]
Anton Onopriychuk commented on CLOUDSTACK-5809:
---
In case someone need it works
./server/src/com/cloud/storage/StorageManagerImpl.java
884c884
+ if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
storagePool.getPoolType() == StoragePoolType.Filesystem ||
storagePool.getPoolType() == StoragePoolType.VMFS) {
---
- if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
storagePool.getPoolType() == StoragePoolType.VMFS) {
> 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] [Created] (CLOUDSTACK-8066) There is not way to know the size of the snapshot created
Gaurav Aradhye created CLOUDSTACK-8066: -- Summary: There is not way to know the size of the snapshot created Key: CLOUDSTACK-8066 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8066 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: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The listSnapshots command does not return the size of the snapshot nor the createSnapshot command. There is no way to know the size of the snapshot and hence consider it in the secondary storage limits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8067) NPEs in MS log related to console proxy VM
Anshul Gangwar created CLOUDSTACK-8067: -- Summary: NPEs in MS log related to console proxy VM Key: CLOUDSTACK-8067 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8067 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar I have set up a new VmWare environment and observing Null Pointer Exceptions in the MS Log , related to console proxy VM. Intermittently the agent state for CPVM in cloudstack is going to alert state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7599) Virtual Router not staying in Started State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243769#comment-14243769 ] Sanjay Tripathi commented on CLOUDSTACK-7599: - Verified on couple of setups, but not able to reproduce this issue. Please reopen the issue if you are still facing it. > Virtual Router not staying in Started State > --- > > Key: CLOUDSTACK-7599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.5.0 > Environment: VMware ESX 5.1 > Ubuntu 12.04 for Management Server >Reporter: Mike Tutkowski >Assignee: Sanjay Tripathi > Fix For: 4.5.0 > > > Most recently, I used this template: > http://download.cloud.com/templates/4.5/systemvm64template-4.5-vmware.ova > Checksum: 3106a79a4ce66cd7f6a7c50e93f2db57 > Before using the above template, I also used this template: > http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-vmware.ova > They both ended with similar results. > They work for SSVM and CPVM, but when the VR is brought up, it eventually > gets to a point where it reboots, starts back up, then - at some point - its > VM is shut down. > If you try to restart the VM from the CS GUI, it auto shuts down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7599) Virtual Router not staying in Started State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-7599. - Resolution: Cannot Reproduce > Virtual Router not staying in Started State > --- > > Key: CLOUDSTACK-7599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.5.0 > Environment: VMware ESX 5.1 > Ubuntu 12.04 for Management Server >Reporter: Mike Tutkowski >Assignee: Sanjay Tripathi > Fix For: 4.5.0 > > > Most recently, I used this template: > http://download.cloud.com/templates/4.5/systemvm64template-4.5-vmware.ova > Checksum: 3106a79a4ce66cd7f6a7c50e93f2db57 > Before using the above template, I also used this template: > http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-vmware.ova > They both ended with similar results. > They work for SSVM and CPVM, but when the VR is brought up, it eventually > gets to a point where it reboots, starts back up, then - at some point - its > VM is shut down. > If you try to restart the VM from the CS GUI, it auto shuts down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8067) NPEs in MS log related to console proxy VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243775#comment-14243775 ] ASF GitHub Bot commented on CLOUDSTACK-8067: GitHub user anshul1886 opened a pull request: https://github.com/apache/cloudstack/pull/56 CLOUDSTACK-8067: Fixed NPEs in MS log related to console proxy VM Fixed NPEs in MS log related to console proxy VM You can merge this pull request into a Git repository by running: $ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8067 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/56.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #56 commit 1115bc9cc6ebf2b321bb5a3ff6958d649150cfe5 Author: Anshul Gangwar Date: 2014-12-11T05:42:18Z CLOUDSTACK-8067: Fixed NPEs in MS log related to console proxy VM > NPEs in MS log related to console proxy VM > -- > > Key: CLOUDSTACK-8067 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8067 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > I have set up a new VmWare environment and observing Null Pointer Exceptions > in the MS Log , related to console proxy VM. > Intermittently the agent state for CPVM in cloudstack is going to alert state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
