You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Pierre-Luc Dion (JIRA)" <ji...@apache.org> on 2014/09/23 04:07:35 UTC
[jira] [Commented] (CLOUDSTACK-7365) Upgrading without proper
systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144195#comment-14144195 ]
Pierre-Luc Dion commented on CLOUDSTACK-7365:
---------------------------------------------
if I have a cloudstack deployment using XenServer and KVM. I've set Global Setting : system.vm.default.hypervisor to XenServer.
So I did download new systemvm template named: systemvm-xenserver-4.4
then upgrade package and end up with following error message:
{code}
2014-09-22 21:50:44,698 DEBUG [c.c.u.d.Upgrade440to441] (main:null) Updating Hyperv System Vms
2014-09-22 21:50:44,698 WARN [c.c.u.d.Upgrade440to441] (main:null) 4.4.0 Hyperv SystemVm template not found. Hyperv hypervisor is not used, so not failing upgrade
2014-09-22 21:50:44,699 DEBUG [c.c.u.d.Upgrade440to441] (main:null) Updating KVM System Vms
2014-09-22 21:50:44,702 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) Unable to upgrade the database
com.cloud.utils.exception.CloudRuntimeException: 4.4.0 KVM SystemVm template not found. Cannot upgrade system Vms
at com.cloud.upgrade.dao.Upgrade440to441.updateSystemVmTemplates(Upgrade440to441.java:203)
at com.cloud.upgrade.dao.Upgrade440to441.performDataMigration(Upgrade440to441.java:66)
at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:317)
at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:438)
at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<init>(CloudStackSpringContext.java:57)
at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<init>(CloudStackSpringContext.java:61)
at org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4210)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4709)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
2014-09-22 21:50:44,705 DEBUG [c.c.u.d.T.Transaction] (main:null) Rolling back the transaction: Time = 92 Name = Upgrade; called by -TransactionLegacy.rollback:900-TransactionLegacy.removeUpTo:843-TransactionLegacy.close:667-DatabaseUpgradeChecker.upgrade:345-DatabaseUpgradeChecker.check:438-CloudStackExtendedLifeCycle.checkIntegrity:65-CloudStackExtendedLifeCycle.start:55-DefaultLifecycleProcessor.doStart:167-DefaultLifecycleProcessor.access$200:51-DefaultLifecycleProcessor$LifecycleGroup.start:339-DefaultLifecycleProcessor.startBeans:143-DefaultLifecycleProcessor.onRefresh:108
2014-09-22 21:50:52,919 INFO [c.c.u.c.ComponentContext] (main:null) Configuring com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_fb560ae5
2014-09-22 21:50:52,931 INFO [c.c.u.c.ComponentContext] (main:null) Configuring com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_90607a3f
2014-09-22 21:50:52,938 INFO [c.c.u.c.ComponentContext] (main:null) Configuring com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_ad076a37
2014-09-22 21:50:52,938 INFO [c.c.u.c.ComponentContext] (main:null) Configuring com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_946fecf6
{code}
downloading this systemvm template should not be mandatory since it is not use in this setup.
> Upgrading without proper systemvm template corrupt cloudstack management server
> -------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-7365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the default.)
> Components: Management Server
> Affects Versions: 4.3.0, 4.4.0, 4.4.1
> Reporter: Pierre-Luc Dion
> Labels: upgrade
> Attachments: 4.4.0to4.4.1_mgtlogissue.txt
>
>
> Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack management server, it is required to have systemvm template properly named prior to the upgrade. otherwise the management server will fail to restart with after upgrading database schema.
> The possible repair method is to revert packages to previously installed CloudStack and restore the database which have been upgraded.
> This is not a viable upgrade path since management servers packages could be accidentally upgraded after a "yum upgrade" or "apt-get update".
> Upgrading CloudStack management-server without previously uploading systemvm template should not fail to start the management-server. if the systemvm template is not in place, then the management-server cannot start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)