On 20/07/2015 18:38, Luciano Castro wrote:
Hi I didn´t stop the agent, I did a 'shutdown -h now' at the Host 'A' in order to simulate a crash.
You don't simulate a crash like this.When you run a "shutdown -h now", you made a clean shutdown (all services are stopped cleany), the cloudstack-agent send a signal to the CS mgr to indicate shutdown himself (the service not the host). The CS mgr don't consider this event to be a crash (until you restart the host / cs-agent service)
On my test environment (CS 4.5.1/Ubuntu14.04/NFS) this lines on the cs mgr logs indicates the "clean" stop after I run the shutdown command:
2015-07-20 20:07:18,894 DEBUG [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-7:null) SeqA 4--1: Processing Seq 4--1: { Cmd , MgmtId: -1, via: 4, Ver: v1, Flags: 111, [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] } 2015-07-20 20:07:18,894 INFO [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-7:null) Host 4 has informed us that it is shutting down with reason sig.kill and detail null 2015-07-20 20:07:18,896 INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-1:ctx-fb37c248) Host 4 is disconnecting with event ShutdownRequested 2015-07-20 20:07:18,898 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-1:ctx-fb37c248) The next status of agent 4is Disconnected, current status is Up 2015-07-20 20:07:18,898 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-1:ctx-fb37c248) Deregistering link for 4 with state Disconnected 2015-07-20 20:07:18,898 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-1:ctx-fb37c248) Remove Agent : 4 2015-07-20 20:07:18,899 DEBUG [c.c.a.m.ConnectedAgentAttache] (AgentTaskPool-1:ctx-fb37c248) Processing Disconnect.
No action for HA process are started by the CS mgr, the HA VMs on the host are still mark "running" in the UI. (until the restart of the host).
My goal is verify if one of my KVM hosts fail, the VMs with HA enabled from thos host 'A' will migrate to another Host (in this case host 'B'. Or , al least, it will be posible do it manually.
If you want test the HA, the better way (for me) is to make a Linux Kernel Crash with this command on the host
(BE CAREFUL) # echo "c" > /proc/sysrq-trigger The host will freeze immediately.Look for the mgr logs, you can view the start of the HA process (example for 1 host with only 1 HA VM inside):
Wait some time (2~3 minutes)2015-07-20 20:21:05,906 INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Investigating why host 4 has disconnected with event PingTimeout 2015-07-20 20:21:05,908 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) checking if agent (4) is alive
[...]2015-07-20 20:21:36,498 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) No need to calibrate cpu capacity, host:1 usedCpu: 6500 reservedCpu: 0 2015-07-20 20:21:36,498 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) No need to calibrate memory capacity, host:1 usedMem: 7247757312 reservedMem: 0 2015-07-20 20:21:36,509 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) Found 1 VMs on host 4 2015-07-20 20:21:36,519 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) Found 2 VM, not running on host 4 2015-07-20 20:21:36,526 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) No need to calibrate cpu capacity, host:4 usedCpu: 1000 reservedCpu: 0 2015-07-20 20:21:36,526 DEBUG [c.c.c.CapacityManagerImpl] (CapacityChecker:ctx-8c096a7a) No need to calibrate memory capacity, host:4 usedMem: 1073741824 reservedMem: 0
[...]2015-07-20 20:22:05,906 INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-f98b00cb) Found the following agents behind on ping: [4] 2015-07-20 20:22:05,909 DEBUG [c.c.h.Status] (AgentMonitor-1:ctx-f98b00cb) Ping timeout for host 4, do invstigation 2015-07-20 20:22:05,911 INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-3:ctx-00c2c8da) Investigating why host 4 has disconnected with event PingTimeout 2015-07-20 20:22:05,912 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-3:ctx-00c2c8da) checking if agent (4) is alive
[...]2015-07-20 20:22:45,915 WARN [c.c.a.m.AgentAttache] (AgentTaskPool-2:ctx-96219030) Seq 4-4609434218613702688: Timed out on Seq 4-4609434218613702688: { Cmd , MgmtId: 203050744474923, via: 4(devcloudnode2), Ver: v1, Flags: 100011, [{"com.cloud.agent.api.CheckHealthCommand":{"wait":50}}] } 2015-07-20 20:22:45,915 DEBUG [c.c.a.m.AgentAttache] (AgentTaskPool-2:ctx-96219030) Seq 4-4609434218613702688: Cancelling. 2015-07-20 20:22:45,915 WARN [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Operation timed out: Commands 4609434218613702688 to Host 4 timed out after 100 2015-07-20 20:22:45,917 DEBUG [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) SimpleInvestigator unable to determine the state of the host. Moving on. 2015-07-20 20:22:45,918 DEBUG [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) XenServerInvestigator unable to determine the state of the host. Moving on.
[...]2015-07-20 20:22:45,967 DEBUG [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) KVMInvestigator was able to determine host 4 is in Down 2015-07-20 20:22:45,967 INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) The state determined is Down 2015-07-20 20:22:45,967 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Host is down: 4-devcloudnode2. Starting HA on the VMs 2015-07-20 20:22:45,968 WARN [o.a.c.alerts] (AgentTaskPool-2:ctx-96219030) alertType:: 7 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: Host disconnected, 4 2015-07-20 20:22:45,974 INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Host 4 is disconnecting with event HostDown 2015-07-20 20:22:45,976 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) The next status of agent 4is Down, current status is Up 2015-07-20 20:22:45,976 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Deregistering link for 4 with state Down 2015-07-20 20:22:45,976 DEBUG [c.c.a.m.AgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Remove Agent : 4 2015-07-20 20:22:45,976 DEBUG [c.c.a.m.ConnectedAgentAttache] (AgentTaskPool-2:ctx-96219030) Processing Disconnect.
[...]2015-07-20 20:22:45,990 DEBUG [c.c.n.NetworkUsageManagerImpl] (AgentTaskPool-2:ctx-96219030) Disconnected called on 4 with status Down
[...]2015-07-20 20:22:45,998 WARN [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) Scheduling restart for VMs on host 4-devcloudnode2
[...]2015-07-20 20:22:46,007 DEBUG [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) Notifying HA Mgr of to restart vm 67-i-2-67-VM 2015-07-20 20:22:46,014 INFO [c.c.h.HighAvailabilityManagerImpl] (AgentTaskPool-2:ctx-96219030) Schedule vm for HA: VM[User|i-2-67-VM] 2015-07-20 20:22:46,016 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentTaskPool-2:ctx-96219030) Notifying other nodes of to disconnect
Etc.... (the start of the VM i-2-67-VM on another host) Milamber
If you need more tests, I can do it. Thanks. On Mon, Jul 20, 2015 at 12:16 PM, Milamber <milam...@apache.org> wrote:On 20/07/2015 15:44, Luciano Castro wrote:Hi ! My test today: I stopped other instance, and changed to HA Offer. I started this instance. After, I shutdown gracefully the KVM host of it.Why a gracefully shutdown of the KVM host ? The HA process is to (re)start the HA VMs on a new host, the current host has been crashed or not available i.e. its cloudstack agent won't respond. If you stopped gently the cloudstack-agent, the CS mgr don't consider this to a crash, so the HA won't start. What's behavior do you expect?and I checked the investigators process: [root@1q2 ~]# grep -i Investigator /var/log/cloudstack/management/management-server.log [root@1q2 ~]# date Mon Jul 20 14:39:43 UTC 2015 [root@1q2 ~]# ls -ltrh /var/log/cloudstack/management/management-server.log -rw-rw-r--. 1 cloud cloud 14M Jul 20 14:39 /var/log/cloudstack/management/management-server.log Nothing. I dont know how internally these process work. but seems that they are not working well, agree? options value ha.investigators.exclude nothing ha.investigators.orde SimpleInvestigator,XenServerInvestigator,KVMInvestigator,HypervInvestigator,VMwareInvestigator,PingInvestigator,ManagementIPSysVMInvestigator investigate.retry.interval 60 There´s a way to check if these process are running ? [root@1q2 ~]# ps waux| grep -i java root 11408 0.0 0.0 103252 880 pts/0 S+ 14:44 0:00 grep -i java cloud 24225 0.7 1.7 16982036 876412 ? Sl Jul16 43:48 /usr/lib/jvm/jre-1.7.0/bin/java -Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers -classpath :::/etc/cloudstack/management:/usr/share/cloudstack-management/setup:/usr/share/cloudstack-management/bin/bootstrap.jar:/usr/share/cloudstack-management/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/cloudstack-management -Dcatalina.home=/usr/share/cloudstack-management -Djava.endorsed.dirs= -Djava.io.tmpdir=/usr/share/cloudstack-management/temp -Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start Thanks On Sat, Jul 18, 2015 at 1:53 PM, Milamber <milam...@apache.org> wrote:On 17/07/2015 22:26, Somesh Naidu wrote: Perhaps, the management server don't reconize the host 3 totally down(ping alive? or some quorum don't ok) The only way to the mgt server to accept totally that the host 3 has a real problem that the host 3 has been reboot (around 12:44)? The host disconnect was triggered at 12:19 on host 3. Mgmt server waspretty sure the host is down (it was a graceful shutdown I believe) which is why it triggered a disconnect and notified other nodes. There was no checkhealth/checkonhost/etc. triggered; just the agent disconnected and all listeners (ping/etc.) notified. At this time mgmt server should have scheduled HA on all VMs running on that host. The HA investigators would then work their way identifying whether the VMs are still running, if they need to be fenced, etc. But this never happened.AFAIK, stopping the cloudstack-agent service don't allow to start the HA process for the VMs hosted by the node. Seems normal to me that the HA process don't start at this moment. If I would start the HA process on a node, I go to the Web UI (or cloudmonkey) to change the state of the Host from Up to Maintenance. (after I can stop the CS-agent service if I need for exemple reboot a node) Regards,Somesh -----Original Message----- From: Milamber [mailto:milam...@apache.org] Sent: Friday, July 17, 2015 6:01 PM To: users@cloudstack.apache.org Subject: Re: HA feature - KVM - CloudStack 4.5.1 On 17/07/2015 21:23, Somesh Naidu wrote: Ok, so here are my findings.1. Host ID 3 was shutdown around 2015-07-16 12:19:09 at which point management server called a disconnect. 2. Based on the logs, it seems VM IDs 32, 18, 39 and 46 were running on the host. 3. No HA tasks for any of these VMs at this time. 5. Management server restarted at around 2015-07-16 12:30:20. 6. Host ID 3 connected back at around 2015-07-16 12:44:08. 7. Management server identified the missing VMs and triggered HA on those. 8. The VMs were eventually started, all 4 of them. I am not 100% sure why HA wasn't triggered until 2015-07-16 12:30 (#3), but I know that management server restart caused it not happen until the host was reconnected. Perhaps, the management server don't reconize the host 3 totally down(ping alive? or some quorum don't ok) The only way to the mgt server to accept totally that the host 3 has a real problem that the host 3 has been reboot (around 12:44)? What is the storage subsystem? CLVMd? Regards,Somesh -----Original Message----- From: Luciano Castro [mailto:luciano.cas...@gmail.com] Sent: Friday, July 17, 2015 12:13 PM To: users@cloudstack.apache.org Subject: Re: HA feature - KVM - CloudStack 4.5.1 No problems Somesh, thanks for your help. Link of log: https://dl.dropboxusercontent.com/u/6774061/management-server.log.2015-07-16.gz Luciano On Fri, Jul 17, 2015 at 12:00 PM, Somesh Naidu < somesh.na...@citrix.com> wrote: How large is the management server logs dated 2015-07-16? I would liketo review the logs. All the information I need from that incident should be in there so I don't need any more testing. Regards, Somesh -----Original Message----- From: Luciano Castro [mailto:luciano.cas...@gmail.com] Sent: Friday, July 17, 2015 7:58 AM To: users@cloudstack.apache.org Subject: Re: HA feature - KVM - CloudStack 4.5.1 Hi Somesh! [root@1q2 ~]# zgrep -i -E 'SimpleIvestigator|KVMInvestigator|PingInvestigator|ManagementIPSysVMInvestigator' /var/log/cloudstack/management/management-server.log.2015-07-16.gz |tail -5000 > /tmp/management.txt [root@1q2 ~]# cat /tmp/management.txt 2015-07-16 12:30:45,452 DEBUG [o.a.c.s.l.r.ExtensionRegistry] (main:null) Registering extension [KVMInvestigator] in [Ha Investigators Registry] 2015-07-16 12:30:45,452 DEBUG [o.a.c.s.l.r.RegistryLifecycle] (main:null) Registered com.cloud.ha.KVMInvestigator@57ceec9a 2015-07-16 12:30:45,927 DEBUG [o.a.c.s.l.r.ExtensionRegistry] (main:null) Registering extension [PingInvestigator] in [Ha Investigators Registry] 2015-07-16 12:30:45,928 DEBUG [o.a.c.s.l.r.ExtensionRegistry] (main:null) Registering extension [ManagementIPSysVMInvestigator] in [Ha Investigators Registry] 2015-07-16 12:30:53,796 INFO [o.a.c.s.l.r.DumpRegistry] (main:null) Registry [Ha Investigators Registry] contains [SimpleInvestigator, XenServerInvestigator, KVMInv I searched this log before, but as I thought that had not nothing special. If you want propose to me another scenario of test, I can do it. Thanks On Thu, Jul 16, 2015 at 7:27 PM, Somesh Naidu < somesh.na...@citrix.com> wrote: What about other investigators, specifically " KVMInvestigator,PingInvestigator"? They report the VMs as alive=false too? Also, it is recommended that you look at the management-sever.log instead of catalina.out (for one, the latter doesn’t have timestamp). Regards, Somesh -----Original Message----- From: Luciano Castro [mailto:luciano.cas...@gmail.com] Sent: Thursday, July 16, 2015 1:14 PM To: users@cloudstack.apache.org Subject: Re: HA feature - KVM - CloudStack 4.5.1 Hi Somesh! thanks for help.. I did again ,and I collected new logs: My vm_instance name is i-2-39-VM. There was some routers in KVM host 'A' (this one that I powered off now): [root@1q2 ~]# grep -i -E 'SimpleInvestigator.*false' /var/log/cloudstack/management/catalina.out INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-2:ctx-e2f91c9c work-3)SimpleInvestigator found VM[DomainRouter|r-4-VM]to be alive? falseINFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-729acf4f work-7)SimpleInvestigator found VM[User|i-23-33-VM]to be alive? falseINFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-4:ctx-a66a4941 work-8)SimpleInvestigator found VM[DomainRouter|r-36-VM]to be alive? falseINFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-5977245e work-10) SimpleInvestigator found VM[User|i-17-26-VM]to be alive? false INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-c7f39be0 work-9)SimpleInvestigator found VM[DomainRouter|r-32-VM]to be alive? falseINFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-3:ctx-ad4f5fda work-10) SimpleInvestigator found VM[DomainRouter|r-46-VM]to be alive? false INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-0:ctx-0257f5af work-11) SimpleInvestigator found VM[User|i-4-52-VM]to be alive? false INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-4:ctx-7ddff382 work-12) SimpleInvestigator found VM[DomainRouter|r-32-VM]to be alive? false INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-9f79917e work-13) SimpleInvestigator found VM[User|i-2-39-VM]to be alive? false KVM host 'B' agent log (where the machine would be migrate): 2015-07-16 16:58:56,537 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Live migration of instance i-2-39-VM initiated 2015-07-16 16:58:57,540 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Waiting for migration of i-2-39-VM to complete, waited 1000ms 2015-07-16 16:58:58,541 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Waiting for migration of i-2-39-VM to complete, waited 2000ms 2015-07-16 16:58:59,542 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Waiting for migration of i-2-39-VM to complete, waited 3000ms 2015-07-16 16:59:00,543 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Waiting for migration of i-2-39-VM to complete, waited 4000ms 2015-07-16 16:59:01,245 INFO [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Migration thread for i-2-39-VM is done It said done for my i-2-39-VM instance, but I can´t ping this host. Luciano --Luciano Castro
