This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible via network (floating IP).
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process is still present and running.
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot- instances {instanceID}", once the instaces comes back up, it is no longer accessible via network (floating IP).
If only "sudo reboot" from within the instance or "euca-reboot- instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node `euca-run- instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'` _.key ubuntu@ `euca-describe- instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot' instance command instances $instanceid
sudo -s
source creds/novarc
# start instance
instanceid=
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-
euca-reboot-
Now euca-describe- instances will show the instance as running, but it is is unreachable via ssh. The kvm process is still present and running.