201 | | |
202 | | |
203 | | }}} |
204 | | |
205 | | The good news is that the container system is using qemu containers to build our experiment. Unfortunately qemu containers only support 7 experimental interfaces, an internal limit on the number of interfaces the virtual hardware supports. A |
| 201 | }}} |
| 202 | |
| 203 | The good news is that the container system is using qemu containers to build our experiment. Unfortunately qemu containers only support 7 experimental interfaces, an internal limit on the number of interfaces the virtual hardware supports. A [attachment:example2.tcl version of the topology with fewer satellites] will containerize without error. |
| 204 | |
| 205 | {{{ |
| 206 | $ /share/containers/containerize.py --default-container qemu DeterTest example2 ~/example2.tcl |
| 207 | Containerized experiment DeterTest/example2 successfully created! |
| 208 | Access it via http://www.isi.deterlab.net//showexp.php3?pid=DeterTest&eid=example2 |
| 209 | }}} |
| 210 | |
| 211 | The qemu experiment looks much like the openvz experiment above, at this small scale. Qemu nodes more completely emulate hardware and the kernels are independent, unlike openvz containers. For example, a program can load kernel modules in a qemu VM, which it cannot do in an openvz container. The qemu containers load the Ubuntu 12.04 (32 bit) distribution by default. |
| 212 | |
| 213 | We can also swap in the experiment using ViewOS processes, but processes cannot be manipulated from outside. They are too lightweight to allow an ssh login, though they will run a start command. |
| 214 | |
| 215 | === Mixing Containers === |
| 216 | |
| 217 | Mixing containers requires the experimenter to assign container types in their topology assignment. This is done by attaching an attribute to nodes. The attribute is named {{{containers:node_type}}}. If the experiment definition is in [http://fedd.isi.deterlab.net/wiki/TopDl topdl] the attribute can be attached using the [http://fedd.deterlab.net/wiki/TopdlLibrary#SharedFunctions standard topdl routines]. Attaching the attribute in ns2 is done using the DETER {{{tb-add-node-attribute}}} command. |
| 218 | |
| 219 | {{{ |
| 220 | tb-add-node-attribute $node containers:node_type openvz |
| 221 | }}} |
| 222 | |
| 223 | That command in an ns2 topology description will set {{{node}}} to be placed in an openvz container. Using this feature, we can modify our [attachment:example1.tcl first topology] to consist of qemu nodes and a single process container in the center. Process nodes can have unlimited interfaces, but we cannot log into them. The new topology file looks like this: |
| 224 | |
| 225 | {{{ |
| 226 | source tb_compat.tcl |
| 227 | set ns [new Simulator] |
| 228 | |
| 229 | # Create the center node (named by its variable name) |
| 230 | set center [$ns node] |
| 231 | # The center node is a process |
| 232 | tb-add-node-attribute $center containers:node_type process |
| 233 | |
| 234 | # Connect 10 satellites |
| 235 | for { set i 0} { $i < 10 } { incr i} { |
| 236 | # Create node n-1 (tcl n($i) becomes n-$i in the experiment) |
| 237 | set n($i) [$ns node] |
| 238 | # Satellites are qemu nodes |
| 239 | tb-add-node-attribute $n($i) containers:node_type qemu |
| 240 | # Connect center to $n($i) |
| 241 | ns duplex-link $center $n($i) 100Mb 10ms DropTail |
| 242 | } |
| 243 | |
| 244 | # Creation boilerplate |
| 245 | $ns rtptoto Static |
| 246 | $ns run |
| 247 | }}} |
| 248 | |