cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamas Monos <tam...@veber.co.uk>
Subject RE: Upgrade 3.0.2->4.0.0
Date Fri, 09 Nov 2012 12:12:40 GMT
Hi,

Thank you!
That workaround worked just fine!
Awesome :)

The last thing I'd need some help with is the usage after the upgrade:

2012-11-09 11:44:51,924 INFO  [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) Parsing usage
records between Wed Nov 07 15:00:00 GMT 2012 and Fri Nov 09 10:59:59 GMT 2012
2012-11-09 11:44:51,955 DEBUG [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) deleting network
offering: 7 from Vm: 36
2012-11-09 11:44:51,957 DEBUG [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) Creating networking
offering: 7 for Vm: 34 for account: 3
2012-11-09 11:44:51,957 ERROR [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) Exception
in usage manager
com.cloud.utils.exception.CloudRuntimeException: DB Exception on: org.apache.commons.dbcp.DelegatingPreparedStatement@8a030d6
        at com.cloud.utils.db.GenericDaoBase.findById(GenericDaoBase.java:955)
        at com.cloud.user.dao.AccountDaoImpl$$EnhancerByCGLIB$$792a6be2.CGLIB$findById$33(<generated>)
        at com.cloud.user.dao.AccountDaoImpl$$EnhancerByCGLIB$$792a6be2$$FastClassByCGLIB$$310d9132.invoke(<generated>)
        at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
        at com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
        at com.cloud.user.dao.AccountDaoImpl$$EnhancerByCGLIB$$792a6be2.findById(<generated>)
        at com.cloud.utils.db.GenericDaoBase.findByIdIncludingRemoved(GenericDaoBase.java:915)
        at com.cloud.usage.UsageManagerImpl.createNetworkOfferingEvent(UsageManagerImpl.java:1315)
        at com.cloud.usage.UsageManagerImpl.createHelperRecord(UsageManagerImpl.java:785)
        at com.cloud.usage.UsageManagerImpl.parse(UsageManagerImpl.java:518)
        at com.cloud.usage.UsageManagerImpl.run(UsageManagerImpl.java:332)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:679)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'account.default_zone_id'
in 'field list'
        at sun.reflect.GeneratedConstructorAccessor30.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.Util.getInstance(Util.java:386)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2283)
        at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:97)
        at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:97)
        at com.cloud.utils.db.GenericDaoBase.findById(GenericDaoBase.java:952)
        ... 18 more

Is there a usage DB upgrade script that did not run somewhere?

Regards

Tamas Monos                                               DDI         +44(0)2034687012
Chief Technical                                             Office    +44(0)2034687000
Veber: The Hosting Specialists               Fax         +44(0)871 522 7057
http://www.veber.co.uk

Follow us on Twitter: www.twitter.com/veberhost
Follow us on Facebook: www.facebook.com/veberhost

-----Original Message-----
From: Kishan Kavala [mailto:Kishan.Kavala@citrix.com] 
Sent: 08 November 2012 18:24
To: cloudstack-dev@incubator.apache.org
Subject: RE: Upgrade 3.0.2->4.0.0

Tamas,
  Looks like vmware systemVm template upgrade is missing in 4.0 upgrade. 

You can try the below work around:

1.  Add new vmware template to CS with name systemvm-vmware-4.0 2.  Wait till the template
is downloaded and installed successfully 3.  Look up id of this template in DB (Name should
match the input provided in step # 1)
   mysql> select id from `cloud`.`vm_template` where name = 'systemvm-vmware-4.0' and removed
is null; 4. Update template type to SYSTEM
   mysql> update `cloud`.`vm_template` set type='SYSTEM' where id = <id-from-step3>;
5. Update template Id for all system Vms
   mysql> update `cloud`.`vm_instance` set vm_template_id = <id-from-step3> where
type <> 'User' and hypervisor_type = 'VMware'; 6. Restart all system Vms

~kishan
________________________________________
From: Tamas Monos [tamasm@veber.co.uk]
Sent: Thursday, November 08, 2012 7:39 PM
To: cloudstack-dev@incubator.apache.org
Subject: Upgrade 3.0.2->4.0.0

Hi,

Sorry putting this on dev-list but got no luck on the user one.

I have upgraded from 3.0.2 to 4.0.0 and the management server started and updated the database
just fine, however the rest of the upgrade procedure just does not work.
I'm running the script: "nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r >
sysvm.log 2>&1 &" accordingly to my environment and see in its log it is trying
to stop/start a router.
It stops it, then recreates the same secondary datastore (vmware) and then starts the same
router rather than deploying the new imported systemVM template and creating a new one.
It neither touches the sec-storage VM nor the console-proxy VM so new management system, old
systemVMs.

No errors during running the script no errors in the log:
Stopping and starting 1 running routing vm(s)...
Done restarting router(s).

Is there a way to bypass this and convince CS 4.0 manually to use the new imported systemvm-vmware-3.0.5
template for systemvms?
This way I could just destroy the systemvms and CS would re-create them with the new template.

Thanks in advance.

Regards

Tamas Monos                                               DDI         +44(0)2034687012
Chief Technical                                             Office    +44(0)2034687000
Veber: The Hosting Specialists               Fax         +44(0)871 522 7057
http://www.veber.co.uk<http://www.veber.co.uk/>

Follow us on Twitter: www.twitter.com/veberhost<http://www.twitter.com/veberhost>
Follow us on Facebook: www.facebook.com/veberhost<http://www.facebook.com/veberhost>



Mime
View raw message