You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Abhinav Roy (JIRA)" <ji...@apache.org> on 2013/04/02 08:35:15 UTC
[jira] [Created] (CLOUDSTACK-1881) [Upgrade 4.0 to 4.2] After
upgrading from 4.0 to 4.2 the 'storage provide name' and 'scope' fields in
the cloud.storage_pool table is left blank, due to which we get a NPE while
doing any operation involving primary storage.
Abhinav Roy created CLOUDSTACK-1881:
---------------------------------------
Summary: [Upgrade 4.0 to 4.2] After upgrading from 4.0 to 4.2 the 'storage provide name' and 'scope' fields in the cloud.storage_pool table is left blank, due to which we get a NPE while doing any operation involving primary storage.
Key: CLOUDSTACK-1881
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1881
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Install and Setup
Affects Versions: 4.2.0
Environment: 4.0 to 4.2 upgrade
Host : XEN
Reporter: Abhinav Roy
Priority: Blocker
Fix For: 4.2.0
After doing upgrade from 4.0 to 4.2 , if we try to restart domain router, ssvm or cpvm we get the following NPE
2013-04-01 19:43:20,808 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-4:job-30) Unexpected exception while executing org.apache.cloudstack.api.command.admin.router.RebootRouterCmd
java.lang.NullPointerException
at org.apache.cloudstack.storage.datastore.manager.DefaultPrimaryDataStoreProviderManagerImpl.getPrimaryDataStore(DefaultPrimaryDataStoreProviderManagerImpl.java:62)
at org.apache.cloudstack.storage.datastore.DataStoreManagerImpl.getPrimaryDataStore(DataStoreManagerImpl.java:71)
at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:662)
at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:462)
at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2625)
at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1834)
at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouter(VirtualNetworkApplianceManagerImpl.java:2883)
at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.rebootRouter(VirtualNetworkApplianceManagerImpl.java:610)
at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at org.apache.cloudstack.api.command.admin.router.RebootRouterCmd.execute(RebootRouterCmd.java:99)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:164)
at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
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:679)
Reason :
===================================
1. In a CS 4.2 setup , when we look at the cloud.storage_pool table contents, we have something like this ..............
mysql> SELECT * FROM cloud.storage_pool;
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+---------------------+---------+
| id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | available_bytes | capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_id | scope |
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+---------------------+---------+
| 200 | xen-pri | cfc506df-7966-3f22-91c9-98b1a617ea56 | NetworkFilesystem | 2049 | 1 | NULL | NULL | 0 | 0 | 10.102.192.100 | NULL | /cpg_vol/abhinav/xen-pri | 2013-03-26 08:25:11 | NULL | NULL | Up | 3 | ZONE |
| 201 | xen-pri2 | 337e7421-d2a1-3367-9786-2fd56ca55c35 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 291308044288 | 879609315328 | 10.102.192.100 | NULL | /cpg_vol/abhinav/xen-pri2 | 2013-03-26 08:27:55 | NULL | NULL | Up | 3 | CLUSTER |
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+---------------------+---------+
2 rows in set (0.00 sec)
Here we see that there are 2 columns 'storage_provider_id' and 'scope' which define the storage provider and scope [zone, cluster, host] for any primary storage.
**********************************************************************************************************************************************************************************************
Now, lets look at the same table on an upgraded setup [4.0 to 4.2]
mysql> SELECT * FROM cloud.storage_pool;
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+-------------------------------------+---------+
| id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | available_bytes | capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope |
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+-------------------------------------+---------+
| 200 | xen-pri | 8ceba66c-26ab-31cc-b0c8-e31574b3fa25 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 221016424448 | 879609315328 | 10.102.192.100 | NULL | /cpg_vol/abhinav/xen-pri3 | 2013-04-01 10:56:47 | NULL | NULL | Up | | |
| 201 | xen-pri4 | 6424ea9d-4de5-3507-93fe-b2ccd082effb | NetworkFilesystem | 2049 | 1 | 1 | 1 | 223764348928 | 879609315328 | 10.102.192.100 | NULL | /cpg_vol/abhinav/xen-pri4 | 2013-04-02 05:22:18 | NULL | NULL | Up | ancient primary data store provider | CLUSTER |
+-----+----------+--------------------------------------+-------------------+------+----------------+--------+------------+-----------------+----------------+----------------+-----------+---------------------------+---------------------+---------+-------------+--------+-------------------------------------+---------+
2 rows in set (0.00 sec)
i) Again here if we take a look at the 1st entry(1st row) in this table then we find that first of all instead of 'storage_provider_id' we have 'storage_provider_name' and that field is left blank, and the 'scope' field also is left blank, due to which the MS is not able to get the scope of the primary storage and hence the NPE.
ii) The 2nd entry in this table is for another primary storage which i added after upgrade and there we can see that the value for
storage_provider_name = ancient primary data store provider
scope = CLUSTER
Workaround :
=======================================================
After upgrade if we go to the cloud DB and manually edit the fields 'storage_provider_name' and 'scope' to appropriate values we can get the setup working.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira