[
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)
