Indra, the issue would impact only existing accounts/domains. For all newly created accounts/domains, you won't see it. By "temporary" Wei meant that in the future the problem should be fixed in the CloudStack upgrade code; so before the fix is in, this temporary solution should be applied by the customer manually.
Answering your other question – how to fix the count. For that, you have to execute the API updateResourceCount. Here is the example: http://localhost:8096/?command=updateResourceCount&account=admin&domainId=1 -Alena. From: Indra Pramana <in...@sg.or.id<mailto:in...@sg.or.id>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Wednesday, October 2, 2013 9:05 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Subject: Re: Unable to create instance after upgrading to CloudStack 4.2.0 Hi Wei Zhou, Thank you for the temporary solution, I tried to execute the scripts and I can see that the records are being inserted into the resource_count table! :) mysql> select * from resource_count where account_id=2; +------+------------+-----------+-------------------+-------+ | id | account_id | domain_id | type | count | +------+------------+-----------+-------------------+-------+ | 17 | 2 | NULL | user_vm | 33 | | 18 | 2 | NULL | public_ip | 4 | | 19 | 2 | NULL | volume | 51 | | 20 | 2 | NULL | snapshot | 0 | | 21 | 2 | NULL | template | 39 | | 22 | 2 | NULL | project | 0 | | 23 | 2 | NULL | network | 1 | | 24 | 2 | NULL | vpc | 0 | | 6342 | 2 | NULL | cpu | 0 | | 6597 | 2 | NULL | memory | 0 | | 6852 | 2 | NULL | primary_storage | 0 | | 7107 | 2 | NULL | secondary_storage | 0 | +------+------------+-----------+-------------------+-------+ 12 rows in set (0.00 sec) When you're saying temporary solution, what do you mean by that and how will that impact us? Do we need to run the temporary solution regularly in the future, or only during upgrade? I also noted that the count value of the newly created records are all 0. How would that impact us, and how it can be updated with the actual value? Will the data/value be updated over time? Any other things we need to take note of? If this solution works for us, then I will schedule another upgrade attempt (the fourth one!) tomorrow. Looking forward to your reply, thank you. Cheers. On Wed, Oct 2, 2013 at 10:47 PM, Wei ZHOU <ustcweiz...@gmail.com<mailto:ustcweiz...@gmail.com>> wrote: For a temporary solution, log in the database, try again after run insert into resource_count(domain_id,type) select id,"cpu" from domain; insert into resource_count(domain_id,type) select id,"memory" from domain; insert into resource_count(domain_id,type) select id,"primary_storage" from domain; insert into resource_count(domain_id,type) select id,"secondary_storage" from domain; insert into resource_count(account_id,type) select id,"cpu" from account; insert into resource_count(account_id,type) select id,"memory" from account; insert into resource_count(account_id,type) select id,"primary_storage" from account; insert into resource_count(account_id,type) select id,"secondary_storage" from account; 2013/10/2 Valery Ciareszka (JIRA) <j...@apache.org<mailto:j...@apache.org>> > > [ https://issues.apache.org/jira/browse/CLOUDSTACK-4627? > page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel& > focusedCommentId=13784006#comment-13784006 ] > > Valery Ciareszka commented on CLOUDSTACK-4627: > ---------------------------------------------- > > Was it really commited to 4.2.0 branch ? I see old version in latest > source package: > > wget http://www.eu.apache.org/dist/cloudstack/releases/4.2.0/ > apache-cloudstack-4.2.0-src.tar.bz2 > tar jxfv apache-cloudstack-4.2.0-src.tar.bz2 > > [root@ad011d apache-cloudstack-4.2.0-src]# grep -A9 > canVmRestartOnAnotherServer > server/src/com/cloud/storage/VolumeManagerImpl.java > public boolean canVmRestartOnAnotherServer(long vmId) { > List<VolumeVO> vols = _volsDao.findCreatedByInstance(vmId); > for (VolumeVO vol : vols) { > if (!vol.isRecreatable() && !vol.getPoolType().isShared()) { > return false; > } > } > return true; > } > > > > HA not working, User VM wasn't Migrated > > --------------------------------------- > > > > Key: CLOUDSTACK-4627 > > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4627 > > Project: CloudStack > > Issue Type: Bug > > Security Level: Public(Anyone can view this level - this is the default.) > > Components: Hypervisor Controller, KVM, Management Server > > Affects Versions: 4.2.0 > > Environment: CentOS 6.3 64bit > > Reporter: Naoki Sakamoto > > Assignee: edison su > > Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, > 20130909_HA_UserVM_Migration_NG.zip > > > > > > 1. We made one of KVM Host Power OFF by push power button of hardware > for High Availability Test. > > 2. Vritual Router / Secodary Storage VM / Console Proxy VM is Migrated. > > But User VM wasn't Migrated. > > > > -- > This message was sent by Atlassian JIRA > (v6.1#6144) > 2013/10/2 Indra Pramana <in...@sg.or.id<mailto:in...@sg.or.id>> > Hi Wei Zhou, > > Thanks for your e-mail. > > Do you have any recommendation or suggestion on how we can resolve the > problem? I am not a CloudStack developer (just a normal user) so we are at > loss on how we can resolve this issue. We are not able to upgrade to 4.2.0 > because of this new problem, after we managed to get around quite a lot of > bumps on our road to 4.2.0. > > Looking forward to your reply, thank you. > > Cheers. > > > > On Wed, Oct 2, 2013 at 10:25 PM, Wei ZHOU > <ustcweiz...@gmail.com<mailto:ustcweiz...@gmail.com>> wrote: > > > Hi Indra, > > > > It is a java file, not a script. > > ./server/src/com/cloud/server/ConfigurationServerImpl.java > > >
