I found the comments in: https://issues.apache.org/jira/browse/CLOUDSTACK-3990 useful but how do I find out the database key so that I can set the pw.
Also in looking at my previous backups for the host_details table it seems like the password entry changes on a regular basis. Is there something the keeps updating the db key and re-ecrypts the host passwords? On Jun 30, 2014, at 1:01 PM, Carlos Reátegui <create...@gmail.com> wrote: > Hi All, > > I am having problems bringing my system back up. I have not checked the > credentials of my hosts but the upgraded management server is unable to > connect to them. Where is the password stored? > > thanks. > Carlos > > > 2014-06-30 12:55:59,277 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host > 1(srvengxen01) > 2014-06-30 12:56:04,394 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] > (LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting > the updates from LB providers and updating service status > 2014-06-30 12:56:04,428 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] > (LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting > the updates from LB providers and updating service status > 2014-06-30 12:56:06,844 DEBUG [c.c.h.x.r.XenServerConnectionPool] > (ClusteredAgentManager Timer:ctx-060c8ace) Unable to create master connection > to host(172.30.45.31) , due to The credentials given by the user are > incorrect, so access has been denied, and you have not been issued a session > handle. > 2014-06-30 12:56:06,848 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-060c8ace) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 1, name = srvengxen01] > 2014-06-30 12:56:06,862 WARN [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-060c8ace) can not load directly connected > host 1(srvengxen01) due to > com.cloud.utils.exception.CloudRuntimeException: Unable to create master > connection to host(172.30.45.31) , due to The credentials given by the user > are incorrect, so access has been denied, and you have not been issued a > session handle. > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:168) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:5722) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.configure(CitrixResourceBase.java:5705) > at > com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:157) > at > com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:672) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:218) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:184) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:98) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:234) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > Caused by: The credentials given by the user are incorrect, so access has > been denied, and you have not been issued a session handle. > at com.xensource.xenapi.Types.checkResponse(Types.java:322) > at com.xensource.xenapi.Connection.dispatch(Connection.java:350) > at com.xensource.xenapi.Session.loginWithPassword(Session.java:537) > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool.loginWithPassword(XenServerConnectionPool.java:321) > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:154) > ... 17 more > 2014-06-30 12:56:06,864 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host > 2(srvengxen02) > 2014-06-30 12:56:09,225 DEBUG [c.c.s.StatsCollector] > (StatsCollector-1:ctx-8458e286) HostStatsCollector is running... > 2014-06-30 12:56:09,226 DEBUG [c.c.s.StatsCollector] > (StatsCollector-2:ctx-aa245eed) VmStatsCollector is running... > 2014-06-30 12:56:09,227 DEBUG [c.c.s.StatsCollector] > (StatsCollector-3:ctx-19894fa1) StorageCollector is running... > 2014-06-30 12:56:09,230 DEBUG [c.c.s.StatsCollector] > (StatsCollector-4:ctx-d66c71fb) AutoScaling Monitor is running... > > > > On Jun 30, 2014, at 9:54 AM, Carlos Reátegui <create...@gmail.com> wrote: > >> Hi Sudha, >> Thanks for checking in. I was out for the weekend and just getting back to >> this now. >> >> My main question at this point is if it is ok for me to kill the system vms >> with the xe vm-shutdown command since the script provided by cloudstack does >> not work with ubuntu. >> >> Also it would be great if someone could have a look at my logs to see if >> they look normal. I am seeing a lot of HA-Worker messages but I do not have >> an HA deployment (unless this is the thread that keeps the system vas >> running). >> >> thanks, >> Carlos >> >> >> >> On Jun 29, 2014, at 11:51 PM, Sudha Ponnaganti <sudha.ponnaga...@citrix.com> >> wrote: >> >>> Hi Carlos, >>> >>> Were you able to resolve the following? Was your upgrade successful? >>> >>> Thanks >>> /sudha >>> >>> -----Original Message----- >>> From: Carlos Reátegui [mailto:create...@gmail.com] >>> Sent: Friday, June 27, 2014 8:55 PM >>> To: CloudStack-Users >>> Cc: dev@cloudstack.apache.org >>> Subject: 4.4 upgrade issues >>> >>> I am trying out the upgrade instructions from >>> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.3/rnotes.html#upgrade-from-4-1-x-to-4-3 >>> but going to 4.4 built from source today. >>> >>> My setup: XenServer 6.0.2 Hosts, Management Server on Ubuntu 12.04, Primary >>> and Secondary on NFS, Basic Network, no security groups >>> >>> ----- >>> Notes on the docs: >>> >>> 8.4 - 8.6: This is only for hosts that use the cloudstack agent. Does not >>> apply to KVM. In general this whole section does not do a good job of >>> explaining what is on the MS vs the Hosts. >>> >>> 13: This fails on ubuntu because: cloudstack-sysvmadm sources >>> /etc/rc.d/init.d/functions which does not exist on ubuntu/debian systems. >>> >>> 14: Copy vhf-util from where? Also the path >>> /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver does not exist >>> on the hosts so I am assuming this is on the MS, however the MS already has >>> it since it is an upgrade and was put there by the original install. Or is >>> this a new version that needs to be grabbed from somewhere? >>> >>> Other: earlier versions like 4.1 worked with JDK 1.6 current releases >>> require 1.7 but the Upgrade doc does not mention that. >>> >>> -- >>> Issues: >>> >>> Saw the following in catalina.out, not sure if it is an issues: >>> Jun 27, 2014 5:28:42 PM org.apache.catalina.loader.WebappClassLoader >>> validateJarFile >>> INFO: >>> validateJarFile(/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/servlet-api-2.5-20081211.jar) >>> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: >>> javax/servlet/Servlet.class Jun 27, 2014 5:28:42 PM >>> org.apache.catalina.loader.WebappClassLoader validateJarFile >>> INFO: >>> validateJarFile(/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/tomcat-embed-core-7.0.30.jar) >>> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: >>> javax/servlet/Servlet.class >>> >>> Since the above script in step 13 did not work is it ok to do "xe >>> vm-shutdown vm=." on each of the system vms? Will CloudStack notice they >>> are ton and start new ones? >>> >>> Here are my log files (please note I stopped the service prior to capturing >>> these logs in case you are wondering): >>> Management server log: >>> https://www.dropbox.com/s/7xhkutt8e724il1/management-server.log >>> Catalina log: >>> https://www.dropbox.com/s/f45ypkbazhkogyj/catalina.2014-06-27.log >>> >>> >>> >>> >> >
