Indra, After executing the scripts for all the existing accounts/domains, you will get the records being inserted into the resource_count table.
Next step is to update the resource counts, for that you can navigate to the root domain detailView page and use "Update Resource Count" action button; or you can use this API command: http://localhost:8096/?command=updateResourceCount&domainId=1 (this API will update all the resources for all accounts/domains present in the resource_count table, don't pass the "account=admin" parameter with this API, it will only update the resource count for admin account). Let me know if you have any other queries. --Sanjay > -----Original Message----- > From: Indra Pramana [mailto:in...@sg.or.id] > Sent: Thursday, October 03, 2013 1:30 PM > To: dev@cloudstack.apache.org > Cc: Alena Prokharchyk > Subject: Re: Unable to create instance after upgrading to CloudStack 4.2.0 > > Hi Sanjay, > > Good day to you, and thank you for your e-mail. > > I am going to perform the upgrade on our production servers in the next 1-2 > hours. Will let you know the outcome. This is our fourth attempt to upgrade > so I hope there's no other issue crop up. > > Can I confirm that this API command will populate all the resources_count > table for all the accounts and domains? > > http://localhost:8096/?command=updateResourceCount&account=admin&d > omainId=1 > > Looking forward to your reply, thank you. > > Cheers. > > > > On Thu, Oct 3, 2013 at 2:07 PM, Sanjay Tripathi > <sanjay.tripa...@citrix.com>wrote: > > > Indra, > > > > The steps are correct. > > Please follow the steps and let me know if you need any help. > > > > This issue got fixed in 4.2-forward branch with this commit: > > 38bbfdc89a50bbb9464700d202d1cfa7b7955953 > > > > --Sanjay > > > > > -----Original Message----- > > > From: Indra Pramana [mailto:in...@sg.or.id] > > > Sent: Thursday, October 03, 2013 10:33 AM > > > To: Alena Prokharchyk > > > Cc: dev@cloudstack.apache.org > > > Subject: Re: Unable to create instance after upgrading to CloudStack > > 4.2.0 > > > > > > Hi Alena, > > > > > > Good day to you, and thank you for your confirmation! > > > > > > Can I confirm that this is what I need to do: > > > > > > (1) Before upgrade, run the script to insert the records into > > resource_count > > > table for existing accounts/domains. > > > (2) Perform the upgrade (from 4.1.1 to 4.2.0); > > > (3) After the upgrade, run the API script to populate the records. > > > > > > The above will fix the issues on the existing accounts/domains, and > > future > > > accounts/domains will not be affected and will run as per normal > > > after > > the > > > upgrade. > > > > > > Can I confirm that my above understanding is correct? > > > > > > Looking forward to your reply, thank you. > > > > > > Cheers. > > > > > > > > > > > > On Thu, Oct 3, 2013 at 11:31 AM, Alena Prokharchyk < > > > alena.prokharc...@citrix.com> wrote: > > > > > > > Hi Indra, > > > > > > > > Please see inline. > > > > > > > > -alena. > > > > > > > > On 10/2/13 8:21 PM, "Indra Pramana" <in...@sg.or.id> wrote: > > > > > > > > >Hi Alena, > > > > > > > > > > > > > > >Good day to you, and thank you for your e-mail. > > > > > > > > > > > > > > >Does it mean that later after the upgrade, for every newly > > > > >created accounts/domains, I will need to apply the temporary fix all > the time? > > > > > > > > No. You should do it just for the accounts/domains existing before > > > > the upgrade. For new accounts, the code should do it automatically > > > > as a part of account creation. > > > > > > > > > > > > > Will it cause any issues if I run the MySQL script again later, e.g. > > > > >will it cause duplicate entries for existing accounts/domains? > > > > > > > > There is a constraint in resource_type table on type/account_id > > > > and type/domain_id, so before running the script, you have to make > > > > sure that the entry doesn't exist already. > > > > > > > > > > > > > > > > > > >Looking forward to your reply, thank you. > > > > > > > > > >Cheers. > > > > > > > > > > > > > > > > > > > > > > > > >On Thu, Oct 3, 2013 at 2:01 AM, Alena Prokharchyk > > > > ><alena.prokharc...@citrix.com> wrote: > > > > > > > > > >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&d > > > omai > > > > nId= > > > > >1 > > > > > > > > > > > > > > >-Alena. > > > > > > > > > > > > > > >From: Indra Pramana <in...@sg.or.id> > > > > >Reply-To: "dev@cloudstack.apache.org" > <dev@cloudstack.apache.org> > > > > >Date: Wednesday, October 2, 2013 9:05 AM > > > > >To: "dev@cloudstack.apache.org" <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> > > > 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> > > > > > > > > > > > > > > >> > > > > >> [ > > > > >https://issues.apache.org/jira/browse/CLOUDSTACK-4627 > > > > ><https://issues.apache.org/jira/browse/CLOUDSTACK-4627>? > > > > >> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-ta > > > > >> bpan > > > > >> el& > > > > >> 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/ > > > > ><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 > > > > ><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> > > > > > > > > > > > > > > >> 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> > > > > wrote: > > > > >> > > > > >> > Hi Indra, > > > > >> > > > > > >> > It is a java file, not a script. > > > > >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
