- 最新
- 投票最多
- 评论最多
Hello,
Please check this blog out- https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-status-check-failure/
Try Stop-Starting your instance to see if that changes anything. Check what happens when you Stop/Start your instance- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html#instance_stop
This should be able to recover and help move to a new Hardware.
I read the blog post but seems its for linux and I am migrating a windows server. I tried stopping and restarting a few times but I get the same instance status check failed each time. Is there anywhere I can view detailed log info?
As the OP points out, this seems to be a problem afflicting some Windows servers migrated through AWS Application Migration Service. I am encountering this issue as well. Here are a few more details: I was able to migrate another Windows instance (a domain controller) using Application Migration Service without incident and accessibility is fine- I am connected to it via RDP as I write this. However, when migrating a member server (a Windows remote desktop session host), for a very short time after it initially boots the server is accessible via RDP and can even contact the domain controller as I can log in with domain credentials, however very shortly thereafter (within about two minutes) the server is automatically rebooted (it would seem to install additional AWS-specific services that are part of the migration) and becomes inaccessible. Rebooting or starting/stopping the server does not change the failure of the instance reachability check. I know from the successful migration of the DC that there are at least two automatic reboots after the migration completes (the second of which includes installation of the process that displays AWS EC2 instance details on the windows desktop), so these reboots are clearly part of the migration process, suggesting that either an AWS scripted configuration change, AWS driver, or AWS service is breaking instance accessibility after the initial boot. Post-reboot CPU usage also goes to nearly 100%.
相关内容
AWS 官方已更新 1 年前
I don't know whether this will apply in your case, so I didn't post it as an answer, but hopefully it'll prove to be of some help. In my case, the instance was reachable via RDP for about two minutes after it was initially booted (up until the first automatic reboot post-migration). I found that connecting to the instance as soon as the RDP service could accept a connection, then disabling the Windows Firewall (a properly-configured security group was protecting things) and stopping and disabling the following services as quickly as possible once connected stopped the automatic reboot from happening and allowed the system to remain accessible via RDP after being rebooted/shutdown thereafter: AwsReplicationDriverLogger, AwsReplicationLogger, AwsReplicationPostConvertService, AwsReplicationService, AwsReplicationVolumeUpdaterService. At that point I was able to reboot/reconfigure the system at my leisure.