Scott, thank you for pursuing this issue. Indeed, the meta-data service keys off of the public IP of the VM, since that is the only source address that is translated when the NCs cannot directly contact the CLC (MANAGED modes). In order for the meta-data service to work, the VM needs to be assigned a public IP, and it looks like this operation is failing (indicated by the fact that the public/private IPs being reported are both from the private IP subnet).
Lets take a look at cc.log for an instance that is failing to get a public IP (look for the RunInstance that corresponds with the instance ID in question, and include a few minutes of log after the RunInstance). We're specifically looking to see if an AssignAddress() operation is ever called for the VM's private IP, or if no AssignAddress() is ever called for that VM. I think this will help us figure out why that VM is not getting a public IP assigned. Thanks again, I think we're close to being able to get to the root cause of this. p.s. I notice that your VNET_NETMASK is set to an invalid value, but the iptables output doesn't reflect this problem; can you confirm that your VNET_NETMASK is actually '255.255.0.0' and not '256.255.0.0' as was reported above? If it is, note that this may have unforeseen consequences. -- metadata service returns empty data with 200 OK https://bugs.launchpad.net/bugs/566792 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
