| 1 | [[PageOutline]] |
| 2 | |
| 3 | = INSTOOLS Project Status Report = |
| 4 | |
| 5 | Period: 6/30/10 - 11/15/10 |
| 6 | |
| 7 | == I. Major accomplishments == |
| 8 | |
| 9 | The following highlights our accomplishments during the last reporting period. |
| 10 | |
| 11 | === A. Milestones achieved === |
| 12 | |
| 13 | We continued to make progress toward our milestones. Some of our |
| 14 | accomplishments include: |
| 15 | |
| 16 | * continuing to support operation of the Kentucky ProtoGENI aggregate, enabling basic experimentation through the ProtoGENI clearinghouse. |
| 17 | |
| 18 | * updating the instrumentation software to support virtual nodes and provide a VNC interface to experiment nodes. |
| 19 | |
| 20 | === B. Deliverables made === |
| 21 | |
| 22 | * We contributed the latest version of our code to the ProtoGENI GIT repository. |
| 23 | |
| 24 | == II. Description of work performed during last quarter == |
| 25 | |
| 26 | The following provides a description of our activities and results |
| 27 | during the last reporting period. |
| 28 | |
| 29 | === A. Activities and findings === |
| 30 | |
| 31 | During this period of time we made significant progress on several fronts. |
| 32 | We enhanced our software to support instrumentation of ''virtual nodes'' |
| 33 | and improved the web interface to provide X window access to experimental |
| 34 | nodes through a ''VNC-based interface''. |
| 35 | |
| 36 | As more experiments start to use the ProtoGENI facilities, making efficient |
| 37 | use of the resources has become one of our priorities. To that end, |
| 38 | we worked with the Utah group to add support for ''virtual nodes'' based |
| 39 | on OpenVZ so that each physical PC can be used as multiple experimental |
| 40 | nodes. Adding support for virtual nodes turned out to be fraught with |
| 41 | problems, and so we had to go through several rounds of bug fixes and |
| 42 | upgrades to get the latest development version of the code working. In |
| 43 | addition we had to manually fix the OPENVZ image for the shared nodes because |
| 44 | the change had not been pushed out to the image running at Utah. |
| 45 | |
| 46 | Unlike BSD jails, we found that the OpenVZ image supports the abilty to run |
| 47 | independent SNMP daemons on each OpenVZ node (i.e., one SNMP daemon per VM). |
| 48 | This feature allows us to perform per-sliver monitoring without the need to |
| 49 | write new monitoring software to understand the OpenVZ virtual interfaces. |
| 50 | |
| 51 | To conserve public IP address space, the ProtoGENI implementation of virtual |
| 52 | nodes does not give public IP addresses to virtual nodes. While the IP |
| 53 | addresses assigned to a virtual node can be used within the experimental |
| 54 | network created by the user (i.e., the slice), accessing the node from the |
| 55 | normal Internet is a problem. To address this problem, the ProtoGENI team |
| 56 | added the ability to reach an ssh server via port forwarding to the OpenVZ VM |
| 57 | nodes. This meant we had to modify our code to extract the ``services'' |
| 58 | information from the manifest and then use the login information to access |
| 59 | the virtual nodes. In particular, our INSTOOLS software queries the manifest |
| 60 | for the sshd port and hostname, and uses that information to login |
| 61 | into the VMs. We have to modify all ssh calls being made in both the client |
| 62 | side and server side code to work using port forwarding. |
| 63 | |
| 64 | We also found that the Measurement Controller (MC) could be virtualized. We |
| 65 | applied the same technique that we used on the experimental nodes in order to |
| 66 | gain ssh access to the MC. However, we encountered the same problem of |
| 67 | accessing the web server on the MC, because port forwarding is only setup for |
| 68 | ssh access, not for web access. To address this we currently require that the |
| 69 | user set up their own ssh tunneling, but we are talking with Utah about ways |
| 70 | to automate this in the future. As a result of this limitation, we currently |
| 71 | prefer non-shared nodes for the MC because users can easily access the web |
| 72 | services there without the need to tunnel. |
| 73 | |
| 74 | We gave a hands-on tutorial as part of the ProtoGENI tutorial at GEC9. The |
| 75 | hands-on tutorial allowed experimenters to create ProtoGENI slices and then |
| 76 | instrumentize their slice using the INSTOOLS software. To ensure we had |
| 77 | enough resources available for the slices of all the attendees, we utilized |
| 78 | the virtual node support, allocating virtual nodes for the users' |
| 79 | topologies. The experience pointed out a few areas that we could make |
| 80 | better, but overall most attendees were able to instrumentize their slice and |
| 81 | monitor its behavior. Incidently, after the GEC9 conference we have noticed |
| 82 | that some of the attendees are starting to use our system for their |
| 83 | experiments. |
| 84 | |
| 85 | Another major addition to our software this period was the ability to access |
| 86 | X window software running on the experimental nodes (slivers) via the MC web |
| 87 | interace. Our goal was to leverage existing network monitoring |
| 88 | tools, such as Wireshark and EtherApe, in order to observe the behavior of |
| 89 | experimental nodes. These tools are helpful to collect node statistics and |
| 90 | visualize the link traffic. However, they need X window support. |
| 91 | To support such access, we added the ability to dynamically load X-window |
| 92 | software onto the experimental nodes and then provide indirect access through |
| 93 | the MC Web browser and the VNC protocol. It has been added to the the MC's |
| 94 | Drupal content management system as one of the menu options. The only way |
| 95 | for a user to access the programs running on the experimental nodes is to |
| 96 | first login to the Drupal CMS running on the MC. This way, we can assure the |
| 97 | slice owner that they are the only ones allowed to access/run these |
| 98 | programs. Our Drupal interface currently has two VNC templates that are |
| 99 | preconfigured to run xterm and wireshark respectively on the nodes in the |
| 100 | slice via VNC. The MC runs a JAVA-based VNC client (in the CMS) that mirrors |
| 101 | the VNC connections from the nodes. The VNC communication between the nodes |
| 102 | and the MC are protected by a system generated random password that is |
| 103 | unique for every slice and invisible to the user. |
| 104 | |
| 105 | We gave an overview of the INSTOOLS software at the GEC9 Instrumentation and |
| 106 | Measurement Workshop in Washington D.C. We demonstrated the major |
| 107 | features of the INSTOOLS software, including the ability to access X-based |
| 108 | software like wireshark doing packet-level capture on experimental nodes. |
| 109 | |
| 110 | === B. Project participants === |
| 111 | |
| 112 | The following individuals have helped with the project in one way or another |
| 113 | during the last quarter: |
| 114 | * Jim Griffioen - Project PI |
| 115 | * Zongming Fei - Project Co-PI |
| 116 | * Hussamuddin Nasir - Technician/programmer |
| 117 | * Xiongqi Wu - Research Assistant |
| 118 | * Jeremy Reed - Research Assistant (half time) |
| 119 | * Lowell Pike - Network administrator |
| 120 | * Woody Marvel - Assists in Emulab administration |
| 121 | |
| 122 | |
| 123 | === C. Publications (individual and organizational) === |
| 124 | |
| 125 | === D. Outreach activities === |
| 126 | |
| 127 | * Gave an overview of our INSTOOLS software at the GEC9 Instrumentation and Measurement Workshop. |
| 128 | * Gave a hands-on tutorial as part of the ProtoGENI tutorial at GEC9. |
| 129 | |
| 130 | === E. Collaborations === |
| 131 | |
| 132 | Most of our collaborations continue to be with the Utah ProtoGENI team, and |
| 133 | we continue to be actively involved in the bi-weekly meetings of the ProtoGENI |
| 134 | cluster. |
| 135 | |
| 136 | === F. Other Contributions === |