52 | | FIXME |
| 52 | Although the Omni {{{createsliver}}} client request has finished, the |
| 53 | aggregate manager may still be busy in the background booting the |
| 54 | requested nodes and bringing up network connections. It is possible |
| 55 | to use Omni manually to follow the AM's progress (with the |
| 56 | "{{{omni sliverstatus}}}" command, which in turn uses the {{{SliverStatus}}} |
| 57 | AM call), but instead we will demonstrate a higher-level tool which |
| 58 | illustrates how custom scripts can make use of Omni to simplify |
| 59 | common sequences of tasks into a single convenient command. |
| 60 | |
| 61 | The {{{readyToLogin.py}}} script will contact an AM, determine whether |
| 62 | all requested resources at that AM are ready, and if so, display a summary |
| 63 | of the hosts including their addresses and the proper SSH keys to use to |
| 64 | access them. |
| 65 | |
| 66 | To run this script, please use the command: |
| 85 | |
| 86 | You can copy and paste the {{{ssh}}} command lines directly into your terminal |
| 87 | to log in to either of your hosts. While you're welcome to inspect either |
| 88 | one, for the purpose of this experiment, the {{{client}}} host is the one |
| 89 | running the {{{iperf}}} tests and collecting all the logs, so please use |
| 90 | the {{{client}}} ssh command now. |
| 91 | |
| 92 | You may get a warning from {{{ssh}}} complaining that the authenticity of the |
| 93 | host cannot be established. This is just because your {{{ssh}}} client has |
| 94 | never accessed this VM before, and so does not yet recognise its key. Say |
| 95 | "yes", you do want to continue connecting, and you should see a shell prompt |
| 96 | from the remote end: |
| 97 | {{{ |
| 98 | [example@client ~]$ |
| 99 | }}} |
| 100 | |
| 101 | The {{{install}}} and {{{execute}}} services requested in our rspec have |
| 102 | already started, and measurements are now being collected. (You can |
| 103 | verify that things are working by inspecting the {{{/local}}} directory |
| 104 | on each host, and looking for the approriate processes with a command like |
| 105 | {{{ps ax}}}. If you do not see the proper files and processes, please |
| 106 | double-check the {{{rspec}}} you used in the previous step.) |
| 107 | |
| 108 | The client machine is saving all the test results in the {{{/tmp/iperf-logs}}} |
| 109 | directory. Files with timestamps in the names will gradually appear |
| 110 | there (there are 100 tests overall, and it may take 20 minutes for all |
| 111 | of them to complete if you want to wait for them). |
| 112 | |
| 113 | Each log file corresponds to one test with some number of simultaneous |
| 114 | TCP connections over the VLAN link you requested between the two hosts. |
| 115 | Later tests gradually include more concurrent connections, so the |
| 116 | throughput of each individual connection will decrease, but the |
| 117 | aggregate throughput (the {{{[SUM]}}} line at the end of each file) |
| 118 | should remain approximately consistent. |
| 119 | |
| 120 | For a real experiment, of course, this step would be the most imporant |
| 121 | and collection, analysis and archival of the results would be critical, |
| 122 | but for now, play around as necessary to satisfy your curiosity and |
| 123 | then continue. |
| 124 | |
| 125 | = [wiki:GENIExperimenter/Tutorials/PortalOmniExample/TeardownExperiment Next: Finish] = |