100 | | A simple vizualization of the experiment is in {{{containers/visualization.png}}}. This is annotated with node and network names as well as interface IP addresses. The topology depiction [attachment:visualization-small.png above] is an example. A larger version is also attached. |
| 100 | A simple vizualization of the experiment is in {{{containers/visualization.png}}}. This is annotated with node and network names as well as interface IP addresses. The topology depiction [attachment:visualization-small.png above] is an example. A [attachment:visualization.png larger version] is also attached. |
| 101 | |
| 102 | The {{{containers/hosts}}} file is a copy of the IP to hostname mapping found on each virtual machine in the topology. It can be useful in converting IP addresses back to names. It is installed in {{{/ext/hosts}}} or the equivalent on each machine. |
| 103 | |
| 104 | At this point, as with any DETER experiment, the topology does not have any resources attached. To get the resources, swap the experiment in from the web interface or using the {{{swapexp}}} command. |
| 105 | |
| 106 | === Using the Experiment === |
| 107 | |
| 108 | Swapin is just the start for a containerized experiment. Once the DETER web interface reports that the experiment has finished its swap-in, the programs that convert the physical topology into the virtual topology have just started to run. At the moment, the containers system does not have a good mechanism for notifying the world that the virtual topology has been successfully created. We are working on resolving this shortcoming, and in the long run we expect [http://montage.deterlab.net MAGI agents] to provide this functionality. Until then, you can ping or try to ssh to individual nodes in the experiment, or use the [UsersGuide#StartCommands workaround we sugeest below]. |
| 109 | |
| 110 | Once the containerized elements have all started, the nodes are available as if they were physical nodes. For example, we can access node {{{n-0}}} of the experiment we swapped in by: |
| 111 | |
| 112 | {{{ |
| 113 | $ ssh n-0.example1.detertest |
| 114 | }}} |
| 115 | |
| 116 | Be sure that you replace {{{example1}}} with the experiment name you passed to {{{containerize.py}}} and {{{DeterTest}}} with the project you created the experiment under. This is a DNS name, so it is case-insensitive. |
| 117 | |
| 118 | When the ssh succeeds you will have access to an Ubuntu 10.04 32-bit node with the same directories mounted as in a physical deter experiment. Your home directory will be mounted, so your ssh keys will work for accessing the machine. |
| 119 | |
| 120 | To confirm that the containerized experiment is working as we expect, we can ping other nodes, using the [https://trac.deterlab.net/wiki/Tutorial/UsingNodes#Hostnamesforyournodes same node naming conventions] as physical DETER experiments. Containerized nodes access the control net as well, so access them using the [https://trac.deterlab.net/wiki/Tutorial/UsingNodes#Hostnamesforyournodes same node naming conventions]. |
| 121 | |
| 122 | Here is a ping from {{{n-0}}} to {{{center}}} and {{{n-1}}}. |
| 123 | |
| 124 | {{{ |
| 125 | n-0:~$ ping -c 3 center |
| 126 | PING center-tblink-l21 (10.0.0.2) 56(84) bytes of data. |
| 127 | 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=1 ttl=64 time=20.4 ms |
| 128 | 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=2 ttl=64 time=20.0 ms |
| 129 | 64 bytes from center-tblink-l21 (10.0.0.2): icmp_seq=3 ttl=64 time=20.0 ms |
| 130 | |
| 131 | --- center-tblink-l21 ping statistics --- |
| 132 | 3 packets transmitted, 3 received, 0% packet loss, time 2002ms |
| 133 | rtt min/avg/max/mdev = 20.052/20.184/20.445/0.184 ms |
| 134 | n-0:~$ ping -c 3 n-1 |
| 135 | PING n-1-tblink-l5 (10.0.6.1) 56(84) bytes of data. |
| 136 | 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=1 ttl=64 time=40.7 ms |
| 137 | 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=2 ttl=64 time=40.0 ms |
| 138 | 64 bytes from n-1-tblink-l5 (10.0.6.1): icmp_seq=3 ttl=64 time=40.0 ms |
| 139 | |
| 140 | --- n-1-tblink-l5 ping statistics --- |
| 141 | 3 packets transmitted, 3 received, 0% packet loss, time 2003ms |
| 142 | rtt min/avg/max/mdev = 40.094/40.318/40.764/0.355 ms |
| 143 | }}} |
| 144 | |
| 145 | The nodes have the expected round trip times. |
| 146 | |
| 147 | At this point you can load and run software and generally experiment normally. |
| 148 | |
| 149 | === Start Commands === |
| 150 | |
| 151 | DETER provides a facility to run a command when the experiment starts, called [https://trac.deterlab.net/wiki/Tutorial/CreatingExperiments#Startingyourapplicationautomatically start commands]. A containerized experiment offers a similar facility with a few differences: |
| 152 | |
| 153 | * The start commands are not coordinated across nodes. In DETER the start commands all execute when the last node has reported to the testbed that it has completed booting. In a containerized experiment, the startcommands run when the containerized node has come up. |
| 154 | * Start commands have to be shorter than in DETER because the container system is also using the facility. |
| 155 | * The event system cannot be used to prplay the start command. |
| 156 | |
| 157 | While start commands that make use of shell syntax for multiple commands and file redirection will generally work, syntax errors will cause them to fail silently. Because of this, and because containerized experiments cannot have as long a start command string, we recommend that if you are doing anything more complex than calling a single program, you script this and run the script from the per-expriment directory or your home directory. |
| 158 | |
| 159 | Start commands give offer a simple workaround for detecting that all nodes in an experiment have started. A script like this: |
| 160 | |
| 161 | {{{ |
| 162 | #!/bin/sh |