Luciano, What Milamber is suggesting is that HA should get triggered only when there is non-graceful host down situation like agent crash, host crash, network outage, etc. For now, you could try power off (unplug) on the host and see if/how HA behaves. I'd also perform the same test (graceful host shutdown and no mgmt server restart) and leave it for some time, may be an 1hr, to see how VM sync behaves. I am pretty sure state for these VMs won't change essentially meaning these VMs will continue to show as "Running" in Cloudstack while they aren't on the hypervisor.
Milamber, I would think that this is a flawed design and not consistent with the behavior on Xenserver and VMware. I don't see any reason why KVM shouldn't behave the same. HA for VMs should have triggered on host disconnect irrespective of how the host was shutdown as long as the host was previously in "Up" state and had VMs running on it (and were not migrated). In addition, VM sync should sync the states at some point but due to the way it is implemented it won't since there is no agent. Regards, Somesh -----Original Message----- From: Milamber [mailto:milam...@apache.org] Sent: Monday, July 20, 2015 2:30 PM To: users@cloudstack.apache.org Subject: Re: HA feature - KVM - CloudStack 4.5.1 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 was >>>>> pretty 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 >>>>>> like >>>>>> >>>>>>> to >>>>>>> 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? false >>>>>>>> INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-729acf4f >>>>>>>> >>>>>>>> work-7) >>>>>>> SimpleInvestigator found VM[User|i-23-33-VM]to be alive? false >>>>>>>> INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-4:ctx-a66a4941 >>>>>>>> >>>>>>>> work-8) >>>>>>> SimpleInvestigator found VM[DomainRouter|r-36-VM]to be alive? false >>>>>>>> INFO [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? false >>>>>>>> INFO [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 >>>>>>> >>>>>>> >>>>>>> >
