[Openstack] Unable to access guests in DevStack on OpenStack environment
Robert Collins
robertc at robertcollins.net
Mon Mar 31 02:16:33 UTC 2014
On 27 March 2014 22:49, Juergen Brendel <juergen at brendel.com> wrote:
>
> Hello!
>
> Thank you for your reply.
You're welcome :)
>> - if dhcp isn't working, try using tcp dump on the compute nodes and
>> debug your overlay network (there are many blog posts on this)
>
> I guess that would be next.
>
>
>> That all said - its very odd that the vm got an ip on the *public*
>> network. I would have expected it to get an ip on the private network
>> and be exposed on the public one via a floating ip. the public network
>> probably has dhcp off (see neutron net-show and neutron subnet-show).
>>
>> At a guess - you booted the vm as admin, rather than the user account,
>> and you got the public network as the network for the VM. Try using
>> the demo user account, or make your own user.
>
> Yes, you are right. I changed it now so that I create the VM as the demo
> user. I promptly get an IP address assigned from the private network.
> Well, nova and neutron think the address is assigned, but as we saw from
> the console-log, the guest never received that address...
>
> Maybe the above additional information is useful in determining where to
> look next?
Ok, so the current status is:
- booting as demo user
- nova and neutron assign you an address from the private network
- guest doesn't pick it up via DHCP?
- there's no sign of the DHCP request on the overlay network?
So - I think we're back to 'debug DHCP on the overlay network'.
e.g. something like
http://docs.openstack.org/trunk/openstack-ops/content/network_troubleshooting.html
You should be able to insert tcpdump probes at every point along the
transit path from the hypervisor through to the dhcp agent - I suggest
just firing a few up - network node gre endpoint interface, the DHCP
netns, the tap port for the VM, the outbound interface of the
hypervisor.
You should see encapsulated DHCP requests on some of those - and that
will tell us where it gets to. Seeing it doesn't mean its right of
course - one of the failure modes I've see is bad VLAN tagging in GRE
leading to the receiver dropping the packets.
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
More information about the Openstack
mailing list