You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Indra Pramana <in...@sg.or.id> on 2013/10/01 18:49:39 UTC
Unable to create instance after upgrading to CloudStack 4.2.0
Dear all,
I am having problems of unable to create new instances after upgrading to
4.2.0. The error message is:
Failed to increment resource count of type primary_storage for account id=2
Excerpt from management-server.log:
====
2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
(catalina-exec-15:null) ===START=== -- GET
command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
(catalina-exec-16:null) InfrastructureEntity name
is:com.cloud.offering.ServiceOffering
2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
(catalina-exec-16:null) ControlledEntity name
is:com.cloud.template.VirtualMachineTemplate
2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
(catalina-exec-16:null) ControlledEntity name is:com.cloud.network.Network
2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
(catalina-exec-16:null) InfrastructureEntity name
is:com.cloud.offering.DiskOffering
2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
(catalina-exec-16:null) Service SecurityGroup is not supported in the
network id=238
2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
(catalina-exec-15:null) ===END=== -- GET
command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
(catalina-exec-16:null) Allocating in the DB for vm
2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(catalina-exec-16:null) Allocating entries for VM: VM[User|Test-Upgrade-420]
2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-16:null) Allocating nic for vm VM[User|Test-Upgrade-420] in
network Ntwk[238|Guest|7] with requested profile
NicProfile[0-0-null-null-null
2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
(catalina-exec-16:null) Service SecurityGroup is not supported in the
network id=238
2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
2013-10-02 00:40:57,930 ERROR
[cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
Failed to update resource count for account id=2
2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
(catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
createVirtualMachine; called by
-Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptComplete:56-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitManagerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplatedVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrator.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125
2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer] (catalina-exec-16:null)
unhandled exception executing api command: deployVirtualMachine
com.cloud.utils.exception.CloudRuntimeException: Failed to increment
resource count of type primary_storage for account id=2
====
Looking forward to your reply, thank you.
Cheers.
RE: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Sanjay Tripathi <sa...@citrix.com>.
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:indra@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
> <sa...@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:indra@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.Prokharchyk@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
> > > > ><Al...@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"
> <de...@cloudstack.apache.org>
> > > > >Date: Wednesday, October 2, 2013 9:05 AM
> > > > >To: "dev@cloudstack.apache.org" <de...@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
> <us...@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) <ji...@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
> > > > >> <us...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> > Hi Indra,
> > > > >> >
> > > > >> > It is a java file, not a script.
> > > > >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
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&domainId=1
Looking forward to your reply, thank you.
Cheers.
On Thu, Oct 3, 2013 at 2:07 PM, Sanjay Tripathi
<sa...@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:indra@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.Prokharchyk@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
> > > ><Al...@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" <de...@cloudstack.apache.org>
> > > >Date: Wednesday, October 2, 2013 9:05 AM
> > > >To: "dev@cloudstack.apache.org" <de...@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 <us...@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) <ji...@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-tabpan
> > > >> 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 <us...@gmail.com>
> > > wrote:
> > > >>
> > > >> > Hi Indra,
> > > >> >
> > > >> > It is a java file, not a script.
> > > >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
>
RE: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Sanjay Tripathi <sa...@citrix.com>.
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:indra@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.Prokharchyk@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
> > ><Al...@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" <de...@cloudstack.apache.org>
> > >Date: Wednesday, October 2, 2013 9:05 AM
> > >To: "dev@cloudstack.apache.org" <de...@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 <us...@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) <ji...@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-tabpan
> > >> 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 <us...@gmail.com>
> > wrote:
> > >>
> > >> > Hi Indra,
> > >> >
> > >> > It is a java file, not a script.
> > >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> > >> >
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
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.Prokharchyk@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
> ><Al...@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&domainId=
> >1
> >
> >
> >-Alena.
> >
> >
> >From: Indra Pramana <in...@sg.or.id>
> >Reply-To: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>
> >Date: Wednesday, October 2, 2013 9:05 AM
> >To: "dev@cloudstack.apache.org" <de...@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 <us...@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) <ji...@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-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/
> ><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 <us...@gmail.com>
> wrote:
> >>
> >> > Hi Indra,
> >> >
> >> > It is a java file, not a script.
> >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> >> >
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Alena Prokharchyk <Al...@citrix.com>.
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
><Al...@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&domainId=
>1
>
>
>-Alena.
>
>
>From: Indra Pramana <in...@sg.or.id>
>Reply-To: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>
>Date: Wednesday, October 2, 2013 9:05 AM
>To: "dev@cloudstack.apache.org" <de...@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 <us...@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) <ji...@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-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/
><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 <us...@gmail.com> wrote:
>>
>> > Hi Indra,
>> >
>> > It is a java file, not a script.
>> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
>> >
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
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? Will
it cause any issues if I run the MySQL script again later, e.g. will it
cause duplicate entries for existing accounts/domains?
Looking forward to your reply, thank you.
Cheers.
On Thu, Oct 3, 2013 at 2:01 AM, Alena Prokharchyk <
Alena.Prokharchyk@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&domainId=1
>
> -Alena.
>
> From: Indra Pramana <in...@sg.or.id>
> Reply-To: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>
> Date: Wednesday, October 2, 2013 9:05 AM
> To: "dev@cloudstack.apache.org" <de...@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 <us...@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) <ji...@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>
>
> > 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 <us...@gmail.com> wrote:
> >
> > > Hi Indra,
> > >
> > > It is a java file, not a script.
> > > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> > >
> >
>
>
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Alena Prokharchyk <Al...@citrix.com>.
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>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Wednesday, October 2, 2013 9:05 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <us...@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) <ji...@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>>
> 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 <us...@gmail.com>> wrote:
>
> > Hi Indra,
> >
> > It is a java file, not a script.
> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
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 <us...@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) <ji...@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>
>
> > 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 <us...@gmail.com> wrote:
> >
> > > Hi Indra,
> > >
> > > It is a java file, not a script.
> > > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> > >
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Wei ZHOU <us...@gmail.com>.
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) <ji...@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>
> 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 <us...@gmail.com> wrote:
>
> > Hi Indra,
> >
> > It is a java file, not a script.
> > ./server/src/com/cloud/server/ConfigurationServerImpl.java
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by 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 <us...@gmail.com> wrote:
> Hi Indra,
>
> It is a java file, not a script.
> ./server/src/com/cloud/server/ConfigurationServerImpl.java
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Wei ZHOU <us...@gmail.com>.
Hi Indra,
It is a java file, not a script.
./server/src/com/cloud/server/ConfigurationServerImpl.java
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Hi Wei Zhou,
Thank you for your e-mail.
May I know where is this script "ConfigurationServerImpl" located? Can we
run this script manually?
Is there a way we can run the script so that it will insert the records
without having to check for any conditions?
Looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 4:26 PM, Wei ZHOU <us...@gmail.com> wrote:
> ConfigurationServerImpl will insert missing records to resource_count table
> at management server startup.
> It is strange you meet some issues others do not meet.
>
>
> 2013/10/2 Indra Pramana <in...@sg.or.id>
>
> > Dear Animesh, Sanjay and all,
> >
> > Latest test that I and Abhinav done earlier this morning:
> >
> > - Abhinav tested upgrade from 4.1.1 to 4.2.0 on his lab and he noticed
> that
> > the additional resource_count types (total 4 of them: cpu, memory,
> > primary_storage and secondary_storage) were added automatically during DB
> > schema upgrade.
> >
> > Excerpts from his management-server.log file:
> >
> > ====
> > 2013-10-01 23:56:46,318 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) resource_count table has records missing for some
> > domains...going to insert them
> > 2013-10-01 23:56:46,339 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for domain id=1
> > 2013-10-01 23:56:46,341 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for domain id=1
> > 2013-10-01 23:56:46,349 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> domain
> > id=1
> > 2013-10-01 23:56:46,351 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > domain id=1
> > 2013-10-01 23:56:46,362 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) resource_count table has records missing for some
> > accounts...going to insert them
> > 2013-10-01 23:56:46,372 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for account id=1
> > 2013-10-01 23:56:46,379 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for account id=1
> > 2013-10-01 23:56:46,381 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> account
> > id=1
> > 2013-10-01 23:56:46,388 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > account id=1
> > 2013-10-01 23:56:46,418 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for account id=2
> > 2013-10-01 23:56:46,420 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for account id=2
> > 2013-10-01 23:56:46,428 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> account
> > id=2
> > 2013-10-01 23:56:46,429 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > account id=2
> > 2013-10-01 23:56:46,439 INFO [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Processing updateSSLKeyStore
> > 2013-10-01 23:56:46,499 INFO [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) SSL keystore located at
> > /etc/cloudstack/management/cloud.keystore
> > ====
> >
> > However, I didn't have the above during the DB schema upgrade.
> >
> > May I know which process triggers the above situation and leads to the
> > additional records to be inserted? Tried to go through the
> > /usr/share/cloudstack-management/setup/db/schema-410to420.sql script and
> > cannot find the above.
> >
> > Any reason why my upgrade didn't trigger the insertion of the additional
> > records?
> >
> > Urgently looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> >
> > On Wed, Oct 2, 2013 at 3:43 AM, Animesh Chaturvedi <
> > animesh.chaturvedi@citrix.com> wrote:
> >
> > > Copying Sanjay
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Indra Pramana [mailto:indra@sg.or.id]
> > > > Sent: Tuesday, October 01, 2013 11:06 AM
> > > > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > > > Subject: Re: Unable to create instance after upgrading to CloudStack
> > > > 4.2.0
> > > >
> > > > Dear all,
> > > >
> > > > Further investigation reveals that there might be some issues with
> the
> > > > schema upgrade. When we check the resource_count table for the
> account
> > > > ID:
> > > >
> > > > mysql> select * from resource_count where account_id=2;
> > > > +----+------------+-----------+-----------+-------+
> > > > | id | account_id | domain_id | type | count |
> > > > +----+------------+-----------+-----------+-------+
> > > > | 17 | 2 | NULL | user_vm | 30 |
> > > > | 18 | 2 | NULL | public_ip | 4 |
> > > > | 19 | 2 | NULL | volume | 40 |
> > > > | 20 | 2 | NULL | snapshot | 1 |
> > > > | 21 | 2 | NULL | template | 40 |
> > > > | 22 | 2 | NULL | project | 0 |
> > > > | 23 | 2 | NULL | network | 2 |
> > > > | 24 | 2 | NULL | vpc | 0 |
> > > > +----+------------+-----------+-----------+-------+
> > > >
> > > > There's no 'primary_storage' type there. In comparison, Abhinav's
> > > > database contains the details:
> > > >
> > > > mysql> SELECT * FROM cloud.resource_count where account_id=2;
> > > > +----+------------+-----------+-------------------+-------------+
> > > > | id | account_id | domain_id | type | count |
> > > > +----+------------+-----------+-------------------+-------------+
> > > > | 17 | 2 | NULL | user_vm | 4 |
> > > > | 18 | 2 | NULL | public_ip | 1 |
> > > > | 19 | 2 | NULL | volume | 3 |
> > > > | 20 | 2 | NULL | snapshot | 3 |
> > > > | 21 | 2 | NULL | template | 1 |
> > > > | 22 | 2 | NULL | project | 0 |
> > > > | 23 | 2 | NULL | network | 2 |
> > > > | 24 | 2 | NULL | vpc | 1 |
> > > > | 33 | 2 | NULL | cpu | 2 |
> > > > | 34 | 2 | NULL | memory | 1536 |
> > > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > > > +----+------------+-----------+-------------------+-------------+
> > > >
> > > > These types are missing from my resource_count table for each of the
> > > > accounts:
> > > >
> > > > | 33 | 2 | NULL | cpu | 2 |
> > > > | 34 | 2 | NULL | memory | 1536 |
> > > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > > >
> > > > I tried to re-do the schema upgrade manually pertaining to that
> > > > particular table, which is part of this section under:
> > > >
> > > > /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> > > >
> > > > DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> > > > `cloud`.`account_view` AS
> > > >
> > > > But I am still not able to get the four types (cpu, memory,
> > > > primary_storage, secondary_storage) to appear on my resource_count
> > > > table.
> > > >
> > > > Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> > > > don't want to revert back again now.
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > > >
> > > >
> > > > On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id>
> wrote:
> > > >
> > > > > Dear all,
> > > > >
> > > > > I am having problems of unable to create new instances after
> > upgrading
> > > > > to 4.2.0. The error message is:
> > > > >
> > > > > Failed to increment resource count of type primary_storage for
> > account
> > > > > id=2
> > > > >
> > > > > Excerpt from management-server.log:
> > > > >
> > > > > ====
> > > > > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > > > > (catalina-exec-15:null) ===START=== -- GET
> > > > >
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > > >
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > > 39
> > > > > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > > is:com.cloud.offering.ServiceOffering
> > > > > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) ControlledEntity name
> > > > > is:com.cloud.template.VirtualMachineTemplate
> > > > > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) ControlledEntity name
> > > > > is:com.cloud.network.Network
> > > > > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > > is:com.cloud.offering.DiskOffering
> > > > > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > > > > (catalina-exec-16:null) Service SecurityGroup is not supported in
> the
> > > > > network id=238
> > > > > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > > > > (catalina-exec-15:null) ===END=== -- GET
> > > > >
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > > >
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > > 39
> > > > > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > > > > (catalina-exec-16:null) Allocating in the DB for vm
> > > > > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating entries for VM:
> > > > > VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating nics for
> VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > > > > (catalina-exec-16:null) Allocating nic for vm
> > > > > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with
> requested
> > > > > profile NicProfile[0-0-null-null-null
> > > > > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > > > > (catalina-exec-16:null) Service SecurityGroup is not supported in
> the
> > > > > network id=238
> > > > > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating disks for
> > VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,930 ERROR
> > > > > [cloud.resourcelimit.ResourceLimitManagerImpl]
> > (catalina-exec-16:null)
> > > > > Failed to update resource count for account id=2
> > > > > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > > > > (catalina-exec-16:null) Rolling back the transaction: Time = 74
> Name
> > =
> > > > > createVirtualMachine; called by
> > > > >
> > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > > > >
> > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > > > >
> > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > > > >
> > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > > > >
> > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > > > >
> > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > > > >
> > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > > > >
> > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > > > > 25
> > > > > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > > > > (catalina-exec-16:null) unhandled exception executing api command:
> > > > > deployVirtualMachine
> > > > > com.cloud.utils.exception.CloudRuntimeException: Failed to
> increment
> > > > > resource count of type primary_storage for account id=2 ====
> > > > >
> > > > > Looking forward to your reply, thank you.
> > > > >
> > > > > Cheers.
> > > > >
> > >
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Hi Wei Zhou,
Thank you for your e-mail.
May I know where is this script "ConfigurationServerImpl" located? Can we
run this script manually?
Is there a way we can run the script so that it will insert the records
without having to check for any conditions?
Looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 4:26 PM, Wei ZHOU <us...@gmail.com> wrote:
> ConfigurationServerImpl will insert missing records to resource_count table
> at management server startup.
> It is strange you meet some issues others do not meet.
>
>
> 2013/10/2 Indra Pramana <in...@sg.or.id>
>
> > Dear Animesh, Sanjay and all,
> >
> > Latest test that I and Abhinav done earlier this morning:
> >
> > - Abhinav tested upgrade from 4.1.1 to 4.2.0 on his lab and he noticed
> that
> > the additional resource_count types (total 4 of them: cpu, memory,
> > primary_storage and secondary_storage) were added automatically during DB
> > schema upgrade.
> >
> > Excerpts from his management-server.log file:
> >
> > ====
> > 2013-10-01 23:56:46,318 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) resource_count table has records missing for some
> > domains...going to insert them
> > 2013-10-01 23:56:46,339 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for domain id=1
> > 2013-10-01 23:56:46,341 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for domain id=1
> > 2013-10-01 23:56:46,349 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> domain
> > id=1
> > 2013-10-01 23:56:46,351 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > domain id=1
> > 2013-10-01 23:56:46,362 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) resource_count table has records missing for some
> > accounts...going to insert them
> > 2013-10-01 23:56:46,372 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for account id=1
> > 2013-10-01 23:56:46,379 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for account id=1
> > 2013-10-01 23:56:46,381 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> account
> > id=1
> > 2013-10-01 23:56:46,388 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > account id=1
> > 2013-10-01 23:56:46,418 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type cpu for account id=2
> > 2013-10-01 23:56:46,420 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type memory for account id=2
> > 2013-10-01 23:56:46,428 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type primary_storage for
> account
> > id=2
> > 2013-10-01 23:56:46,429 DEBUG [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Inserting resource count of type secondary_storage for
> > account id=2
> > 2013-10-01 23:56:46,439 INFO [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) Processing updateSSLKeyStore
> > 2013-10-01 23:56:46,499 INFO [cloud.server.ConfigurationServerImpl]
> > (Timer-2:null) SSL keystore located at
> > /etc/cloudstack/management/cloud.keystore
> > ====
> >
> > However, I didn't have the above during the DB schema upgrade.
> >
> > May I know which process triggers the above situation and leads to the
> > additional records to be inserted? Tried to go through the
> > /usr/share/cloudstack-management/setup/db/schema-410to420.sql script and
> > cannot find the above.
> >
> > Any reason why my upgrade didn't trigger the insertion of the additional
> > records?
> >
> > Urgently looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> >
> > On Wed, Oct 2, 2013 at 3:43 AM, Animesh Chaturvedi <
> > animesh.chaturvedi@citrix.com> wrote:
> >
> > > Copying Sanjay
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Indra Pramana [mailto:indra@sg.or.id]
> > > > Sent: Tuesday, October 01, 2013 11:06 AM
> > > > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > > > Subject: Re: Unable to create instance after upgrading to CloudStack
> > > > 4.2.0
> > > >
> > > > Dear all,
> > > >
> > > > Further investigation reveals that there might be some issues with
> the
> > > > schema upgrade. When we check the resource_count table for the
> account
> > > > ID:
> > > >
> > > > mysql> select * from resource_count where account_id=2;
> > > > +----+------------+-----------+-----------+-------+
> > > > | id | account_id | domain_id | type | count |
> > > > +----+------------+-----------+-----------+-------+
> > > > | 17 | 2 | NULL | user_vm | 30 |
> > > > | 18 | 2 | NULL | public_ip | 4 |
> > > > | 19 | 2 | NULL | volume | 40 |
> > > > | 20 | 2 | NULL | snapshot | 1 |
> > > > | 21 | 2 | NULL | template | 40 |
> > > > | 22 | 2 | NULL | project | 0 |
> > > > | 23 | 2 | NULL | network | 2 |
> > > > | 24 | 2 | NULL | vpc | 0 |
> > > > +----+------------+-----------+-----------+-------+
> > > >
> > > > There's no 'primary_storage' type there. In comparison, Abhinav's
> > > > database contains the details:
> > > >
> > > > mysql> SELECT * FROM cloud.resource_count where account_id=2;
> > > > +----+------------+-----------+-------------------+-------------+
> > > > | id | account_id | domain_id | type | count |
> > > > +----+------------+-----------+-------------------+-------------+
> > > > | 17 | 2 | NULL | user_vm | 4 |
> > > > | 18 | 2 | NULL | public_ip | 1 |
> > > > | 19 | 2 | NULL | volume | 3 |
> > > > | 20 | 2 | NULL | snapshot | 3 |
> > > > | 21 | 2 | NULL | template | 1 |
> > > > | 22 | 2 | NULL | project | 0 |
> > > > | 23 | 2 | NULL | network | 2 |
> > > > | 24 | 2 | NULL | vpc | 1 |
> > > > | 33 | 2 | NULL | cpu | 2 |
> > > > | 34 | 2 | NULL | memory | 1536 |
> > > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > > > +----+------------+-----------+-------------------+-------------+
> > > >
> > > > These types are missing from my resource_count table for each of the
> > > > accounts:
> > > >
> > > > | 33 | 2 | NULL | cpu | 2 |
> > > > | 34 | 2 | NULL | memory | 1536 |
> > > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > > >
> > > > I tried to re-do the schema upgrade manually pertaining to that
> > > > particular table, which is part of this section under:
> > > >
> > > > /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> > > >
> > > > DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> > > > `cloud`.`account_view` AS
> > > >
> > > > But I am still not able to get the four types (cpu, memory,
> > > > primary_storage, secondary_storage) to appear on my resource_count
> > > > table.
> > > >
> > > > Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> > > > don't want to revert back again now.
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > > >
> > > >
> > > > On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id>
> wrote:
> > > >
> > > > > Dear all,
> > > > >
> > > > > I am having problems of unable to create new instances after
> > upgrading
> > > > > to 4.2.0. The error message is:
> > > > >
> > > > > Failed to increment resource count of type primary_storage for
> > account
> > > > > id=2
> > > > >
> > > > > Excerpt from management-server.log:
> > > > >
> > > > > ====
> > > > > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > > > > (catalina-exec-15:null) ===START=== -- GET
> > > > >
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > > >
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > > 39
> > > > > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > > is:com.cloud.offering.ServiceOffering
> > > > > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) ControlledEntity name
> > > > > is:com.cloud.template.VirtualMachineTemplate
> > > > > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) ControlledEntity name
> > > > > is:com.cloud.network.Network
> > > > > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > > is:com.cloud.offering.DiskOffering
> > > > > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > > > > (catalina-exec-16:null) Service SecurityGroup is not supported in
> the
> > > > > network id=238
> > > > > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > > > > (catalina-exec-15:null) ===END=== -- GET
> > > > >
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > > >
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > > 39
> > > > > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > > > > (catalina-exec-16:null) Allocating in the DB for vm
> > > > > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating entries for VM:
> > > > > VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating nics for
> VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > > > > (catalina-exec-16:null) Allocating nic for vm
> > > > > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with
> requested
> > > > > profile NicProfile[0-0-null-null-null
> > > > > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > > > > (catalina-exec-16:null) Service SecurityGroup is not supported in
> the
> > > > > network id=238
> > > > > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > > (catalina-exec-16:null) Allocating disks for
> > VM[User|Test-Upgrade-420]
> > > > > 2013-10-02 00:40:57,930 ERROR
> > > > > [cloud.resourcelimit.ResourceLimitManagerImpl]
> > (catalina-exec-16:null)
> > > > > Failed to update resource count for account id=2
> > > > > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > > > > (catalina-exec-16:null) Rolling back the transaction: Time = 74
> Name
> > =
> > > > > createVirtualMachine; called by
> > > > >
> > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > > > >
> > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > > > >
> > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > > > >
> > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > > > >
> > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > > > >
> > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > > > >
> > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > > > >
> > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > > > > 25
> > > > > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > > > > (catalina-exec-16:null) unhandled exception executing api command:
> > > > > deployVirtualMachine
> > > > > com.cloud.utils.exception.CloudRuntimeException: Failed to
> increment
> > > > > resource count of type primary_storage for account id=2 ====
> > > > >
> > > > > Looking forward to your reply, thank you.
> > > > >
> > > > > Cheers.
> > > > >
> > >
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Wei ZHOU <us...@gmail.com>.
ConfigurationServerImpl will insert missing records to resource_count table
at management server startup.
It is strange you meet some issues others do not meet.
2013/10/2 Indra Pramana <in...@sg.or.id>
> Dear Animesh, Sanjay and all,
>
> Latest test that I and Abhinav done earlier this morning:
>
> - Abhinav tested upgrade from 4.1.1 to 4.2.0 on his lab and he noticed that
> the additional resource_count types (total 4 of them: cpu, memory,
> primary_storage and secondary_storage) were added automatically during DB
> schema upgrade.
>
> Excerpts from his management-server.log file:
>
> ====
> 2013-10-01 23:56:46,318 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) resource_count table has records missing for some
> domains...going to insert them
> 2013-10-01 23:56:46,339 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type cpu for domain id=1
> 2013-10-01 23:56:46,341 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type memory for domain id=1
> 2013-10-01 23:56:46,349 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type primary_storage for domain
> id=1
> 2013-10-01 23:56:46,351 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type secondary_storage for
> domain id=1
> 2013-10-01 23:56:46,362 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) resource_count table has records missing for some
> accounts...going to insert them
> 2013-10-01 23:56:46,372 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type cpu for account id=1
> 2013-10-01 23:56:46,379 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type memory for account id=1
> 2013-10-01 23:56:46,381 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type primary_storage for account
> id=1
> 2013-10-01 23:56:46,388 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type secondary_storage for
> account id=1
> 2013-10-01 23:56:46,418 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type cpu for account id=2
> 2013-10-01 23:56:46,420 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type memory for account id=2
> 2013-10-01 23:56:46,428 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type primary_storage for account
> id=2
> 2013-10-01 23:56:46,429 DEBUG [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Inserting resource count of type secondary_storage for
> account id=2
> 2013-10-01 23:56:46,439 INFO [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) Processing updateSSLKeyStore
> 2013-10-01 23:56:46,499 INFO [cloud.server.ConfigurationServerImpl]
> (Timer-2:null) SSL keystore located at
> /etc/cloudstack/management/cloud.keystore
> ====
>
> However, I didn't have the above during the DB schema upgrade.
>
> May I know which process triggers the above situation and leads to the
> additional records to be inserted? Tried to go through the
> /usr/share/cloudstack-management/setup/db/schema-410to420.sql script and
> cannot find the above.
>
> Any reason why my upgrade didn't trigger the insertion of the additional
> records?
>
> Urgently looking forward to your reply, thank you.
>
> Cheers.
>
>
>
>
> On Wed, Oct 2, 2013 at 3:43 AM, Animesh Chaturvedi <
> animesh.chaturvedi@citrix.com> wrote:
>
> > Copying Sanjay
> >
> > Animesh
> >
> > > -----Original Message-----
> > > From: Indra Pramana [mailto:indra@sg.or.id]
> > > Sent: Tuesday, October 01, 2013 11:06 AM
> > > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > > Subject: Re: Unable to create instance after upgrading to CloudStack
> > > 4.2.0
> > >
> > > Dear all,
> > >
> > > Further investigation reveals that there might be some issues with the
> > > schema upgrade. When we check the resource_count table for the account
> > > ID:
> > >
> > > mysql> select * from resource_count where account_id=2;
> > > +----+------------+-----------+-----------+-------+
> > > | id | account_id | domain_id | type | count |
> > > +----+------------+-----------+-----------+-------+
> > > | 17 | 2 | NULL | user_vm | 30 |
> > > | 18 | 2 | NULL | public_ip | 4 |
> > > | 19 | 2 | NULL | volume | 40 |
> > > | 20 | 2 | NULL | snapshot | 1 |
> > > | 21 | 2 | NULL | template | 40 |
> > > | 22 | 2 | NULL | project | 0 |
> > > | 23 | 2 | NULL | network | 2 |
> > > | 24 | 2 | NULL | vpc | 0 |
> > > +----+------------+-----------+-----------+-------+
> > >
> > > There's no 'primary_storage' type there. In comparison, Abhinav's
> > > database contains the details:
> > >
> > > mysql> SELECT * FROM cloud.resource_count where account_id=2;
> > > +----+------------+-----------+-------------------+-------------+
> > > | id | account_id | domain_id | type | count |
> > > +----+------------+-----------+-------------------+-------------+
> > > | 17 | 2 | NULL | user_vm | 4 |
> > > | 18 | 2 | NULL | public_ip | 1 |
> > > | 19 | 2 | NULL | volume | 3 |
> > > | 20 | 2 | NULL | snapshot | 3 |
> > > | 21 | 2 | NULL | template | 1 |
> > > | 22 | 2 | NULL | project | 0 |
> > > | 23 | 2 | NULL | network | 2 |
> > > | 24 | 2 | NULL | vpc | 1 |
> > > | 33 | 2 | NULL | cpu | 2 |
> > > | 34 | 2 | NULL | memory | 1536 |
> > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > > +----+------------+-----------+-------------------+-------------+
> > >
> > > These types are missing from my resource_count table for each of the
> > > accounts:
> > >
> > > | 33 | 2 | NULL | cpu | 2 |
> > > | 34 | 2 | NULL | memory | 1536 |
> > > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > >
> > > I tried to re-do the schema upgrade manually pertaining to that
> > > particular table, which is part of this section under:
> > >
> > > /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> > >
> > > DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> > > `cloud`.`account_view` AS
> > >
> > > But I am still not able to get the four types (cpu, memory,
> > > primary_storage, secondary_storage) to appear on my resource_count
> > > table.
> > >
> > > Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> > > don't want to revert back again now.
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > >
> > >
> > > On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> > >
> > > > Dear all,
> > > >
> > > > I am having problems of unable to create new instances after
> upgrading
> > > > to 4.2.0. The error message is:
> > > >
> > > > Failed to increment resource count of type primary_storage for
> account
> > > > id=2
> > > >
> > > > Excerpt from management-server.log:
> > > >
> > > > ====
> > > > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > > > (catalina-exec-15:null) ===START=== -- GET
> > > >
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > >
> &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > 39
> > > > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > is:com.cloud.offering.ServiceOffering
> > > > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > > > (catalina-exec-16:null) ControlledEntity name
> > > > is:com.cloud.template.VirtualMachineTemplate
> > > > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > > > (catalina-exec-16:null) ControlledEntity name
> > > > is:com.cloud.network.Network
> > > > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > > > (catalina-exec-16:null) InfrastructureEntity name
> > > > is:com.cloud.offering.DiskOffering
> > > > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > > network id=238
> > > > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > > > (catalina-exec-15:null) ===END=== -- GET
> > > >
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > >
> &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > > 39
> > > > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > > > (catalina-exec-16:null) Allocating in the DB for vm
> > > > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > (catalina-exec-16:null) Allocating entries for VM:
> > > > VM[User|Test-Upgrade-420]
> > > > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> > > > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > > > (catalina-exec-16:null) Allocating nic for vm
> > > > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with requested
> > > > profile NicProfile[0-0-null-null-null
> > > > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > > network id=238
> > > > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > > (catalina-exec-16:null) Allocating disks for
> VM[User|Test-Upgrade-420]
> > > > 2013-10-02 00:40:57,930 ERROR
> > > > [cloud.resourcelimit.ResourceLimitManagerImpl]
> (catalina-exec-16:null)
> > > > Failed to update resource count for account id=2
> > > > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > > > (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name
> =
> > > > createVirtualMachine; called by
> > > >
> -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > > >
> :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > > >
> tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > > >
> agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > > >
> dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > > >
> tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > > >
> r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > > >
> -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > > > 25
> > > > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > > > (catalina-exec-16:null) unhandled exception executing api command:
> > > > deployVirtualMachine
> > > > com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> > > > resource count of type primary_storage for account id=2 ====
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Dear Animesh, Sanjay and all,
Latest test that I and Abhinav done earlier this morning:
- Abhinav tested upgrade from 4.1.1 to 4.2.0 on his lab and he noticed that
the additional resource_count types (total 4 of them: cpu, memory,
primary_storage and secondary_storage) were added automatically during DB
schema upgrade.
Excerpts from his management-server.log file:
====
2013-10-01 23:56:46,318 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) resource_count table has records missing for some
domains...going to insert them
2013-10-01 23:56:46,339 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for domain id=1
2013-10-01 23:56:46,341 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for domain id=1
2013-10-01 23:56:46,349 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for domain
id=1
2013-10-01 23:56:46,351 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
domain id=1
2013-10-01 23:56:46,362 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) resource_count table has records missing for some
accounts...going to insert them
2013-10-01 23:56:46,372 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for account id=1
2013-10-01 23:56:46,379 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for account id=1
2013-10-01 23:56:46,381 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for account
id=1
2013-10-01 23:56:46,388 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
account id=1
2013-10-01 23:56:46,418 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for account id=2
2013-10-01 23:56:46,420 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for account id=2
2013-10-01 23:56:46,428 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for account
id=2
2013-10-01 23:56:46,429 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
account id=2
2013-10-01 23:56:46,439 INFO [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Processing updateSSLKeyStore
2013-10-01 23:56:46,499 INFO [cloud.server.ConfigurationServerImpl]
(Timer-2:null) SSL keystore located at
/etc/cloudstack/management/cloud.keystore
====
However, I didn't have the above during the DB schema upgrade.
May I know which process triggers the above situation and leads to the
additional records to be inserted? Tried to go through the
/usr/share/cloudstack-management/setup/db/schema-410to420.sql script and
cannot find the above.
Any reason why my upgrade didn't trigger the insertion of the additional
records?
Urgently looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 3:43 AM, Animesh Chaturvedi <
animesh.chaturvedi@citrix.com> wrote:
> Copying Sanjay
>
> Animesh
>
> > -----Original Message-----
> > From: Indra Pramana [mailto:indra@sg.or.id]
> > Sent: Tuesday, October 01, 2013 11:06 AM
> > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > Subject: Re: Unable to create instance after upgrading to CloudStack
> > 4.2.0
> >
> > Dear all,
> >
> > Further investigation reveals that there might be some issues with the
> > schema upgrade. When we check the resource_count table for the account
> > ID:
> >
> > mysql> select * from resource_count where account_id=2;
> > +----+------------+-----------+-----------+-------+
> > | id | account_id | domain_id | type | count |
> > +----+------------+-----------+-----------+-------+
> > | 17 | 2 | NULL | user_vm | 30 |
> > | 18 | 2 | NULL | public_ip | 4 |
> > | 19 | 2 | NULL | volume | 40 |
> > | 20 | 2 | NULL | snapshot | 1 |
> > | 21 | 2 | NULL | template | 40 |
> > | 22 | 2 | NULL | project | 0 |
> > | 23 | 2 | NULL | network | 2 |
> > | 24 | 2 | NULL | vpc | 0 |
> > +----+------------+-----------+-----------+-------+
> >
> > There's no 'primary_storage' type there. In comparison, Abhinav's
> > database contains the details:
> >
> > mysql> SELECT * FROM cloud.resource_count where account_id=2;
> > +----+------------+-----------+-------------------+-------------+
> > | id | account_id | domain_id | type | count |
> > +----+------------+-----------+-------------------+-------------+
> > | 17 | 2 | NULL | user_vm | 4 |
> > | 18 | 2 | NULL | public_ip | 1 |
> > | 19 | 2 | NULL | volume | 3 |
> > | 20 | 2 | NULL | snapshot | 3 |
> > | 21 | 2 | NULL | template | 1 |
> > | 22 | 2 | NULL | project | 0 |
> > | 23 | 2 | NULL | network | 2 |
> > | 24 | 2 | NULL | vpc | 1 |
> > | 33 | 2 | NULL | cpu | 2 |
> > | 34 | 2 | NULL | memory | 1536 |
> > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > +----+------------+-----------+-------------------+-------------+
> >
> > These types are missing from my resource_count table for each of the
> > accounts:
> >
> > | 33 | 2 | NULL | cpu | 2 |
> > | 34 | 2 | NULL | memory | 1536 |
> > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> >
> > I tried to re-do the schema upgrade manually pertaining to that
> > particular table, which is part of this section under:
> >
> > /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> >
> > DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> > `cloud`.`account_view` AS
> >
> > But I am still not able to get the four types (cpu, memory,
> > primary_storage, secondary_storage) to appear on my resource_count
> > table.
> >
> > Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> > don't want to revert back again now.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> > On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> >
> > > Dear all,
> > >
> > > I am having problems of unable to create new instances after upgrading
> > > to 4.2.0. The error message is:
> > >
> > > Failed to increment resource count of type primary_storage for account
> > > id=2
> > >
> > > Excerpt from management-server.log:
> > >
> > > ====
> > > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > > (catalina-exec-15:null) ===START=== -- GET
> > > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > 39
> > > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) InfrastructureEntity name
> > > is:com.cloud.offering.ServiceOffering
> > > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) ControlledEntity name
> > > is:com.cloud.template.VirtualMachineTemplate
> > > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) ControlledEntity name
> > > is:com.cloud.network.Network
> > > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) InfrastructureEntity name
> > > is:com.cloud.offering.DiskOffering
> > > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > network id=238
> > > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > > (catalina-exec-15:null) ===END=== -- GET
> > > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > 39
> > > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > > (catalina-exec-16:null) Allocating in the DB for vm
> > > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating entries for VM:
> > > VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > > (catalina-exec-16:null) Allocating nic for vm
> > > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with requested
> > > profile NicProfile[0-0-null-null-null
> > > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > network id=238
> > > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,930 ERROR
> > > [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> > > Failed to update resource count for account id=2
> > > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > > (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> > > createVirtualMachine; called by
> > > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > > 25
> > > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > > (catalina-exec-16:null) unhandled exception executing api command:
> > > deployVirtualMachine
> > > com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> > > resource count of type primary_storage for account id=2 ====
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Dear Animesh, Sanjay and all,
Latest test that I and Abhinav done earlier this morning:
- Abhinav tested upgrade from 4.1.1 to 4.2.0 on his lab and he noticed that
the additional resource_count types (total 4 of them: cpu, memory,
primary_storage and secondary_storage) were added automatically during DB
schema upgrade.
Excerpts from his management-server.log file:
====
2013-10-01 23:56:46,318 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) resource_count table has records missing for some
domains...going to insert them
2013-10-01 23:56:46,339 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for domain id=1
2013-10-01 23:56:46,341 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for domain id=1
2013-10-01 23:56:46,349 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for domain
id=1
2013-10-01 23:56:46,351 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
domain id=1
2013-10-01 23:56:46,362 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) resource_count table has records missing for some
accounts...going to insert them
2013-10-01 23:56:46,372 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for account id=1
2013-10-01 23:56:46,379 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for account id=1
2013-10-01 23:56:46,381 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for account
id=1
2013-10-01 23:56:46,388 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
account id=1
2013-10-01 23:56:46,418 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type cpu for account id=2
2013-10-01 23:56:46,420 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type memory for account id=2
2013-10-01 23:56:46,428 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type primary_storage for account
id=2
2013-10-01 23:56:46,429 DEBUG [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Inserting resource count of type secondary_storage for
account id=2
2013-10-01 23:56:46,439 INFO [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Processing updateSSLKeyStore
2013-10-01 23:56:46,499 INFO [cloud.server.ConfigurationServerImpl]
(Timer-2:null) SSL keystore located at
/etc/cloudstack/management/cloud.keystore
====
However, I didn't have the above during the DB schema upgrade.
May I know which process triggers the above situation and leads to the
additional records to be inserted? Tried to go through the
/usr/share/cloudstack-management/setup/db/schema-410to420.sql script and
cannot find the above.
Any reason why my upgrade didn't trigger the insertion of the additional
records?
Urgently looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 3:43 AM, Animesh Chaturvedi <
animesh.chaturvedi@citrix.com> wrote:
> Copying Sanjay
>
> Animesh
>
> > -----Original Message-----
> > From: Indra Pramana [mailto:indra@sg.or.id]
> > Sent: Tuesday, October 01, 2013 11:06 AM
> > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > Subject: Re: Unable to create instance after upgrading to CloudStack
> > 4.2.0
> >
> > Dear all,
> >
> > Further investigation reveals that there might be some issues with the
> > schema upgrade. When we check the resource_count table for the account
> > ID:
> >
> > mysql> select * from resource_count where account_id=2;
> > +----+------------+-----------+-----------+-------+
> > | id | account_id | domain_id | type | count |
> > +----+------------+-----------+-----------+-------+
> > | 17 | 2 | NULL | user_vm | 30 |
> > | 18 | 2 | NULL | public_ip | 4 |
> > | 19 | 2 | NULL | volume | 40 |
> > | 20 | 2 | NULL | snapshot | 1 |
> > | 21 | 2 | NULL | template | 40 |
> > | 22 | 2 | NULL | project | 0 |
> > | 23 | 2 | NULL | network | 2 |
> > | 24 | 2 | NULL | vpc | 0 |
> > +----+------------+-----------+-----------+-------+
> >
> > There's no 'primary_storage' type there. In comparison, Abhinav's
> > database contains the details:
> >
> > mysql> SELECT * FROM cloud.resource_count where account_id=2;
> > +----+------------+-----------+-------------------+-------------+
> > | id | account_id | domain_id | type | count |
> > +----+------------+-----------+-------------------+-------------+
> > | 17 | 2 | NULL | user_vm | 4 |
> > | 18 | 2 | NULL | public_ip | 1 |
> > | 19 | 2 | NULL | volume | 3 |
> > | 20 | 2 | NULL | snapshot | 3 |
> > | 21 | 2 | NULL | template | 1 |
> > | 22 | 2 | NULL | project | 0 |
> > | 23 | 2 | NULL | network | 2 |
> > | 24 | 2 | NULL | vpc | 1 |
> > | 33 | 2 | NULL | cpu | 2 |
> > | 34 | 2 | NULL | memory | 1536 |
> > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> > +----+------------+-----------+-------------------+-------------+
> >
> > These types are missing from my resource_count table for each of the
> > accounts:
> >
> > | 33 | 2 | NULL | cpu | 2 |
> > | 34 | 2 | NULL | memory | 1536 |
> > | 35 | 2 | NULL | primary_storage | 8589934592 |
> > | 36 | 2 | NULL | secondary_storage | 27866955776 |
> >
> > I tried to re-do the schema upgrade manually pertaining to that
> > particular table, which is part of this section under:
> >
> > /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> >
> > DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> > `cloud`.`account_view` AS
> >
> > But I am still not able to get the four types (cpu, memory,
> > primary_storage, secondary_storage) to appear on my resource_count
> > table.
> >
> > Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> > don't want to revert back again now.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> > On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> >
> > > Dear all,
> > >
> > > I am having problems of unable to create new instances after upgrading
> > > to 4.2.0. The error message is:
> > >
> > > Failed to increment resource count of type primary_storage for account
> > > id=2
> > >
> > > Excerpt from management-server.log:
> > >
> > > ====
> > > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > > (catalina-exec-15:null) ===START=== -- GET
> > > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > 39
> > > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) InfrastructureEntity name
> > > is:com.cloud.offering.ServiceOffering
> > > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) ControlledEntity name
> > > is:com.cloud.template.VirtualMachineTemplate
> > > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) ControlledEntity name
> > > is:com.cloud.network.Network
> > > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > > (catalina-exec-16:null) InfrastructureEntity name
> > > is:com.cloud.offering.DiskOffering
> > > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > network id=238
> > > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > > (catalina-exec-15:null) ===END=== -- GET
> > > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > > 39
> > > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > > (catalina-exec-16:null) Allocating in the DB for vm
> > > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating entries for VM:
> > > VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > > (catalina-exec-16:null) Allocating nic for vm
> > > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with requested
> > > profile NicProfile[0-0-null-null-null
> > > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > > network id=238
> > > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > > (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> > > 2013-10-02 00:40:57,930 ERROR
> > > [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> > > Failed to update resource count for account id=2
> > > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > > (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> > > createVirtualMachine; called by
> > > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > > 25
> > > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > > (catalina-exec-16:null) unhandled exception executing api command:
> > > deployVirtualMachine
> > > com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> > > resource count of type primary_storage for account id=2 ====
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
>
RE: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Animesh Chaturvedi <an...@citrix.com>.
Copying Sanjay
Animesh
> -----Original Message-----
> From: Indra Pramana [mailto:indra@sg.or.id]
> Sent: Tuesday, October 01, 2013 11:06 AM
> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> Subject: Re: Unable to create instance after upgrading to CloudStack
> 4.2.0
>
> Dear all,
>
> Further investigation reveals that there might be some issues with the
> schema upgrade. When we check the resource_count table for the account
> ID:
>
> mysql> select * from resource_count where account_id=2;
> +----+------------+-----------+-----------+-------+
> | id | account_id | domain_id | type | count |
> +----+------------+-----------+-----------+-------+
> | 17 | 2 | NULL | user_vm | 30 |
> | 18 | 2 | NULL | public_ip | 4 |
> | 19 | 2 | NULL | volume | 40 |
> | 20 | 2 | NULL | snapshot | 1 |
> | 21 | 2 | NULL | template | 40 |
> | 22 | 2 | NULL | project | 0 |
> | 23 | 2 | NULL | network | 2 |
> | 24 | 2 | NULL | vpc | 0 |
> +----+------------+-----------+-----------+-------+
>
> There's no 'primary_storage' type there. In comparison, Abhinav's
> database contains the details:
>
> mysql> SELECT * FROM cloud.resource_count where account_id=2;
> +----+------------+-----------+-------------------+-------------+
> | id | account_id | domain_id | type | count |
> +----+------------+-----------+-------------------+-------------+
> | 17 | 2 | NULL | user_vm | 4 |
> | 18 | 2 | NULL | public_ip | 1 |
> | 19 | 2 | NULL | volume | 3 |
> | 20 | 2 | NULL | snapshot | 3 |
> | 21 | 2 | NULL | template | 1 |
> | 22 | 2 | NULL | project | 0 |
> | 23 | 2 | NULL | network | 2 |
> | 24 | 2 | NULL | vpc | 1 |
> | 33 | 2 | NULL | cpu | 2 |
> | 34 | 2 | NULL | memory | 1536 |
> | 35 | 2 | NULL | primary_storage | 8589934592 |
> | 36 | 2 | NULL | secondary_storage | 27866955776 |
> +----+------------+-----------+-------------------+-------------+
>
> These types are missing from my resource_count table for each of the
> accounts:
>
> | 33 | 2 | NULL | cpu | 2 |
> | 34 | 2 | NULL | memory | 1536 |
> | 35 | 2 | NULL | primary_storage | 8589934592 |
> | 36 | 2 | NULL | secondary_storage | 27866955776 |
>
> I tried to re-do the schema upgrade manually pertaining to that
> particular table, which is part of this section under:
>
> /usr/share/cloudstack-management/setup/db/schema-410to420.sql
>
> DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> `cloud`.`account_view` AS
>
> But I am still not able to get the four types (cpu, memory,
> primary_storage, secondary_storage) to appear on my resource_count
> table.
>
> Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> don't want to revert back again now.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
>
> > Dear all,
> >
> > I am having problems of unable to create new instances after upgrading
> > to 4.2.0. The error message is:
> >
> > Failed to increment resource count of type primary_storage for account
> > id=2
> >
> > Excerpt from management-server.log:
> >
> > ====
> > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-15:null) ===START=== -- GET
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > 39
> > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEntity name
> > is:com.cloud.offering.ServiceOffering
> > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.template.VirtualMachineTemplate
> > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.network.Network
> > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEntity name
> > is:com.cloud.offering.DiskOffering
> > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > network id=238
> > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-15:null) ===END=== -- GET
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > 39
> > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > (catalina-exec-16:null) Allocating in the DB for vm
> > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating entries for VM:
> > VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > (catalina-exec-16:null) Allocating nic for vm
> > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with requested
> > profile NicProfile[0-0-null-null-null
> > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > network id=238
> > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,930 ERROR
> > [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> > Failed to update resource count for account id=2
> > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> > createVirtualMachine; called by
> > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > 25
> > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > (catalina-exec-16:null) unhandled exception executing api command:
> > deployVirtualMachine
> > com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> > resource count of type primary_storage for account id=2 ====
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
RE: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Animesh Chaturvedi <an...@citrix.com>.
Copying Sanjay
Animesh
> -----Original Message-----
> From: Indra Pramana [mailto:indra@sg.or.id]
> Sent: Tuesday, October 01, 2013 11:06 AM
> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> Subject: Re: Unable to create instance after upgrading to CloudStack
> 4.2.0
>
> Dear all,
>
> Further investigation reveals that there might be some issues with the
> schema upgrade. When we check the resource_count table for the account
> ID:
>
> mysql> select * from resource_count where account_id=2;
> +----+------------+-----------+-----------+-------+
> | id | account_id | domain_id | type | count |
> +----+------------+-----------+-----------+-------+
> | 17 | 2 | NULL | user_vm | 30 |
> | 18 | 2 | NULL | public_ip | 4 |
> | 19 | 2 | NULL | volume | 40 |
> | 20 | 2 | NULL | snapshot | 1 |
> | 21 | 2 | NULL | template | 40 |
> | 22 | 2 | NULL | project | 0 |
> | 23 | 2 | NULL | network | 2 |
> | 24 | 2 | NULL | vpc | 0 |
> +----+------------+-----------+-----------+-------+
>
> There's no 'primary_storage' type there. In comparison, Abhinav's
> database contains the details:
>
> mysql> SELECT * FROM cloud.resource_count where account_id=2;
> +----+------------+-----------+-------------------+-------------+
> | id | account_id | domain_id | type | count |
> +----+------------+-----------+-------------------+-------------+
> | 17 | 2 | NULL | user_vm | 4 |
> | 18 | 2 | NULL | public_ip | 1 |
> | 19 | 2 | NULL | volume | 3 |
> | 20 | 2 | NULL | snapshot | 3 |
> | 21 | 2 | NULL | template | 1 |
> | 22 | 2 | NULL | project | 0 |
> | 23 | 2 | NULL | network | 2 |
> | 24 | 2 | NULL | vpc | 1 |
> | 33 | 2 | NULL | cpu | 2 |
> | 34 | 2 | NULL | memory | 1536 |
> | 35 | 2 | NULL | primary_storage | 8589934592 |
> | 36 | 2 | NULL | secondary_storage | 27866955776 |
> +----+------------+-----------+-------------------+-------------+
>
> These types are missing from my resource_count table for each of the
> accounts:
>
> | 33 | 2 | NULL | cpu | 2 |
> | 34 | 2 | NULL | memory | 1536 |
> | 35 | 2 | NULL | primary_storage | 8589934592 |
> | 36 | 2 | NULL | secondary_storage | 27866955776 |
>
> I tried to re-do the schema upgrade manually pertaining to that
> particular table, which is part of this section under:
>
> /usr/share/cloudstack-management/setup/db/schema-410to420.sql
>
> DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> `cloud`.`account_view` AS
>
> But I am still not able to get the four types (cpu, memory,
> primary_storage, secondary_storage) to appear on my resource_count
> table.
>
> Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> don't want to revert back again now.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
>
> > Dear all,
> >
> > I am having problems of unable to create new instances after upgrading
> > to 4.2.0. The error message is:
> >
> > Failed to increment resource count of type primary_storage for account
> > id=2
> >
> > Excerpt from management-server.log:
> >
> > ====
> > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-15:null) ===START=== -- GET
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > 39
> > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEntity name
> > is:com.cloud.offering.ServiceOffering
> > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.template.VirtualMachineTemplate
> > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.network.Network
> > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEntity name
> > is:com.cloud.offering.DiskOffering
> > 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > network id=238
> > 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-15:null) ===END=== -- GET
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > 39
> > 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> > (catalina-exec-16:null) Allocating in the DB for vm
> > 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating entries for VM:
> > VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> > (catalina-exec-16:null) Allocating nic for vm
> > VM[User|Test-Upgrade-420] in network Ntwk[238|Guest|7] with requested
> > profile NicProfile[0-0-null-null-null
> > 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> > (catalina-exec-16:null) Service SecurityGroup is not supported in the
> > network id=238
> > 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> > 2013-10-02 00:40:57,930 ERROR
> > [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> > Failed to update resource count for account id=2
> > 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> > (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> > createVirtualMachine; called by
> > -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close
> > :665-TransactionContextBuilder.interceptComplete:56-ComponentInstantia
> > tionPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitMan
> > agerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplate
> > dVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantia
> > tionPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrato
> > r.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867
> > -ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:1
> > 25
> > 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> > (catalina-exec-16:null) unhandled exception executing api command:
> > deployVirtualMachine
> > com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> > resource count of type primary_storage for account id=2 ====
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Dear all,
Further investigation reveals that there might be some issues with the
schema upgrade. When we check the resource_count table for the account ID:
mysql> select * from resource_count where account_id=2;
+----+------------+-----------+-----------+-------+
| id | account_id | domain_id | type | count |
+----+------------+-----------+-----------+-------+
| 17 | 2 | NULL | user_vm | 30 |
| 18 | 2 | NULL | public_ip | 4 |
| 19 | 2 | NULL | volume | 40 |
| 20 | 2 | NULL | snapshot | 1 |
| 21 | 2 | NULL | template | 40 |
| 22 | 2 | NULL | project | 0 |
| 23 | 2 | NULL | network | 2 |
| 24 | 2 | NULL | vpc | 0 |
+----+------------+-----------+-----------+-------+
There's no 'primary_storage' type there. In comparison, Abhinav's database
contains the details:
mysql> SELECT * FROM cloud.resource_count where account_id=2;
+----+------------+-----------+-------------------+-------------+
| id | account_id | domain_id | type | count |
+----+------------+-----------+-------------------+-------------+
| 17 | 2 | NULL | user_vm | 4 |
| 18 | 2 | NULL | public_ip | 1 |
| 19 | 2 | NULL | volume | 3 |
| 20 | 2 | NULL | snapshot | 3 |
| 21 | 2 | NULL | template | 1 |
| 22 | 2 | NULL | project | 0 |
| 23 | 2 | NULL | network | 2 |
| 24 | 2 | NULL | vpc | 1 |
| 33 | 2 | NULL | cpu | 2 |
| 34 | 2 | NULL | memory | 1536 |
| 35 | 2 | NULL | primary_storage | 8589934592 |
| 36 | 2 | NULL | secondary_storage | 27866955776 |
+----+------------+-----------+-------------------+-------------+
These types are missing from my resource_count table for each of the
accounts:
| 33 | 2 | NULL | cpu | 2 |
| 34 | 2 | NULL | memory | 1536 |
| 35 | 2 | NULL | primary_storage | 8589934592 |
| 36 | 2 | NULL | secondary_storage | 27866955776 |
I tried to re-do the schema upgrade manually pertaining to that particular
table, which is part of this section under:
/usr/share/cloudstack-management/setup/db/schema-410to420.sql
DROP VIEW IF EXISTS `cloud`.`account_view`;
CREATE VIEW `cloud`.`account_view` AS
But I am still not able to get the four types (cpu, memory,
primary_storage, secondary_storage) to appear on my resource_count table.
Anyone can help? This is my third attempt to upgrade to 4.2.0 and I don't
want to revert back again now.
Looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> Dear all,
>
> I am having problems of unable to create new instances after upgrading to
> 4.2.0. The error message is:
>
> Failed to increment resource count of type primary_storage for account id=2
>
> Excerpt from management-server.log:
>
> ====
> 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> (catalina-exec-15:null) ===START=== -- GET
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
> 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) InfrastructureEntity name
> is:com.cloud.offering.ServiceOffering
> 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) ControlledEntity name
> is:com.cloud.template.VirtualMachineTemplate
> 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) ControlledEntity name is:com.cloud.network.Network
> 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) InfrastructureEntity name
> is:com.cloud.offering.DiskOffering
> 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> (catalina-exec-16:null) Service SecurityGroup is not supported in the
> network id=238
> 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> (catalina-exec-15:null) ===END=== -- GET
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
> 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> (catalina-exec-16:null) Allocating in the DB for vm
> 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating entries for VM: VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> (catalina-exec-16:null) Allocating nic for vm VM[User|Test-Upgrade-420] in
> network Ntwk[238|Guest|7] with requested profile
> NicProfile[0-0-null-null-null
> 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> (catalina-exec-16:null) Service SecurityGroup is not supported in the
> network id=238
> 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,930 ERROR
> [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> Failed to update resource count for account id=2
> 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> createVirtualMachine; called by
> -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptComplete:56-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitManagerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplatedVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrator.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125
> 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> (catalina-exec-16:null) unhandled exception executing api command:
> deployVirtualMachine
> com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> resource count of type primary_storage for account id=2
> ====
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
Re: Unable to create instance after upgrading to CloudStack 4.2.0
Posted by Indra Pramana <in...@sg.or.id>.
Dear all,
Further investigation reveals that there might be some issues with the
schema upgrade. When we check the resource_count table for the account ID:
mysql> select * from resource_count where account_id=2;
+----+------------+-----------+-----------+-------+
| id | account_id | domain_id | type | count |
+----+------------+-----------+-----------+-------+
| 17 | 2 | NULL | user_vm | 30 |
| 18 | 2 | NULL | public_ip | 4 |
| 19 | 2 | NULL | volume | 40 |
| 20 | 2 | NULL | snapshot | 1 |
| 21 | 2 | NULL | template | 40 |
| 22 | 2 | NULL | project | 0 |
| 23 | 2 | NULL | network | 2 |
| 24 | 2 | NULL | vpc | 0 |
+----+------------+-----------+-----------+-------+
There's no 'primary_storage' type there. In comparison, Abhinav's database
contains the details:
mysql> SELECT * FROM cloud.resource_count where account_id=2;
+----+------------+-----------+-------------------+-------------+
| id | account_id | domain_id | type | count |
+----+------------+-----------+-------------------+-------------+
| 17 | 2 | NULL | user_vm | 4 |
| 18 | 2 | NULL | public_ip | 1 |
| 19 | 2 | NULL | volume | 3 |
| 20 | 2 | NULL | snapshot | 3 |
| 21 | 2 | NULL | template | 1 |
| 22 | 2 | NULL | project | 0 |
| 23 | 2 | NULL | network | 2 |
| 24 | 2 | NULL | vpc | 1 |
| 33 | 2 | NULL | cpu | 2 |
| 34 | 2 | NULL | memory | 1536 |
| 35 | 2 | NULL | primary_storage | 8589934592 |
| 36 | 2 | NULL | secondary_storage | 27866955776 |
+----+------------+-----------+-------------------+-------------+
These types are missing from my resource_count table for each of the
accounts:
| 33 | 2 | NULL | cpu | 2 |
| 34 | 2 | NULL | memory | 1536 |
| 35 | 2 | NULL | primary_storage | 8589934592 |
| 36 | 2 | NULL | secondary_storage | 27866955776 |
I tried to re-do the schema upgrade manually pertaining to that particular
table, which is part of this section under:
/usr/share/cloudstack-management/setup/db/schema-410to420.sql
DROP VIEW IF EXISTS `cloud`.`account_view`;
CREATE VIEW `cloud`.`account_view` AS
But I am still not able to get the four types (cpu, memory,
primary_storage, secondary_storage) to appear on my resource_count table.
Anyone can help? This is my third attempt to upgrade to 4.2.0 and I don't
want to revert back again now.
Looking forward to your reply, thank you.
Cheers.
On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> Dear all,
>
> I am having problems of unable to create new instances after upgrading to
> 4.2.0. The error message is:
>
> Failed to increment resource count of type primary_storage for account id=2
>
> Excerpt from management-server.log:
>
> ====
> 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> (catalina-exec-15:null) ===START=== -- GET
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
> 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) InfrastructureEntity name
> is:com.cloud.offering.ServiceOffering
> 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) ControlledEntity name
> is:com.cloud.template.VirtualMachineTemplate
> 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) ControlledEntity name is:com.cloud.network.Network
> 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> (catalina-exec-16:null) InfrastructureEntity name
> is:com.cloud.offering.DiskOffering
> 2013-10-02 00:40:57,813 DEBUG [cloud.network.NetworkModelImpl]
> (catalina-exec-16:null) Service SecurityGroup is not supported in the
> network id=238
> 2013-10-02 00:40:57,828 DEBUG [cloud.api.ApiServlet]
> (catalina-exec-15:null) ===END=== -- GET
> command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674&response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=1380645646739
> 2013-10-02 00:40:57,867 DEBUG [cloud.vm.UserVmManagerImpl]
> (catalina-exec-16:null) Allocating in the DB for vm
> 2013-10-02 00:40:57,887 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating entries for VM: VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,888 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating nics for VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,889 DEBUG [cloud.network.NetworkManagerImpl]
> (catalina-exec-16:null) Allocating nic for vm VM[User|Test-Upgrade-420] in
> network Ntwk[238|Guest|7] with requested profile
> NicProfile[0-0-null-null-null
> 2013-10-02 00:40:57,909 DEBUG [cloud.network.NetworkModelImpl]
> (catalina-exec-16:null) Service SecurityGroup is not supported in the
> network id=238
> 2013-10-02 00:40:57,911 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-16:null) Allocating disks for VM[User|Test-Upgrade-420]
> 2013-10-02 00:40:57,930 ERROR
> [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-16:null)
> Failed to update resource count for account id=2
> 2013-10-02 00:40:57,931 DEBUG [db.Transaction.Transaction]
> (catalina-exec-16:null) Rolling back the transaction: Time = 74 Name =
> createVirtualMachine; called by
> -Transaction.rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptComplete:56-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:131-ResourceLimitManagerImpl.incrementResourceCount:238-VolumeManagerImpl.allocateTemplatedVolume:1477-VirtualMachineManagerImpl.allocate:386-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-CloudOrchestrator.createVirtualMachine:214-UserVmManagerImpl.createVirtualMachine:2867-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125
> 2013-10-02 00:40:57,978 ERROR [cloud.api.ApiServer]
> (catalina-exec-16:null) unhandled exception executing api command:
> deployVirtualMachine
> com.cloud.utils.exception.CloudRuntimeException: Failed to increment
> resource count of type primary_storage for account id=2
> ====
>
> Looking forward to your reply, thank you.
>
> Cheers.
>