Differences

This shows you the differences between two versions of the page.

--- ipv6_opnfv_project:arno_laptop [2015/09/05 01:20]
Bin Hu [Internet Unreachable from VM / APEX-2 (Fixed): Default Vagrant Route Exists in Virtual Setups Post Deployment]
+++ ipv6_opnfv_project:arno_laptop [2015/09/05 01:38] (current)
Bin Hu [The Given Horizon URL is Invalid]
@@ Line 90: / Line 90: @@
 The workaround is to ssh to the controller ("vagrant ssh") and run "ifconfig" and find an interface with an IPv4 address beginning with "192.168.1.x".  In my case, it was 192.168.1.202.
+==== Issues in OpenStack Verification ====
+At this point, you can start the "OpenStack Verification" section of the install guide. You should be able to create the volume, image, and launch a few instances before you hit any issues.
+=== No Instance Displays on the Console ===
+One issue may be that When you try to view the console of either instance, nothing ever display.
+The workaround for this is a little gnarly.  In order to login to these instances from the shell, you first have to "vagrant ssh" to the controller, then source the "keystonerc_admin" file to set some auth-oriented environment variables, then do "nova list", just to remind yourself of the IP addresses of the instances (which are 10.0.0.5 and 10.0.0.7 for example), then do "ip netns list", which returns a big uuid value representing the dhcp network namespace.  You'll use that uuid in a couple other commands.
+Still in the controller, you do the following (where $uuid is the uuid value from "ip netns list"):
+  % ip netns exec $uuid ssh cirros@10.0.0.5
+Then create another shell from the main box, ssh to the controller, and do this:
+  % ip netns exec $uuid ssh cirros@10.0.0.7
+You could now do "ping 10.0.0.7" from the first one and "ping 10.0.0.5" from the second one. This represents the end of the "OpenStack Verification" section.
+You may want to go one step further and verify that the VM at 10.0.0.5 was really the one being pinged from the 10.0.0.7 VM. You can normally do this by running "tcpdump -i any icmp" on the VM you are trying to ping, and when you ping from the other VM, you can see debug output that shows it is pinging that VM.
+Alternatively, you could also run tcpdump from the compute node, specifying the tap interface corresponding to each IP. This requires ssh'ing to the compute node and doing "ovs-vsctl show".  This shows the two tap interfaces, but it doesn't show which IP corresponds to each of those tap interfaces. Then you can do an "ifconfig" on the instance and find out the port id.
+Then, still on the compute node, do "tcpdump -i <interfacename> icmp" for the first tap interface.  Create another shell, ssh to the compute node, and do the same for the other tap interface name.  Now, go back to the shell where you're logged into each instance, and do the "ping" to the other instance.  You should now see output from one of the tcpdump calls, showing the pings traveling on that interface.
+As the VMs are now not in /tmp, it should survive a reboot, but you might have to do "vagrant up" in the controller and compute VMs, and then perhaps do something similar in the Horizon GUI for the two instances.  If you bring this up in a different network, you might have trouble with the available IP range. This could be mitigated by first creating a VM for the jumphost and starting the deployment process over.

Wiki

User Tools

Site Tools

Differences

Page Tools