DeviceTypes

Device Types

ToMaTo supports different types of devices that can be mixed in a single topology. Some types are realized by multiple possible technologies, which can be selected in the respective element's configuration window.

Container-Based Device

Container-based devices are light-weight virtual machines that translate kernel calls to kernel calls of the host kernel. Container-based virtualization technologies offer complete usermode access to the virtual machines and a limited kernel-mode access. The kernel mode access allows to:

• Manage networking hardware
• Use raw sockets

Limitations

• Only Linux
• No kernel modules
• No kernel changes
• No NFS mounting
• No graphical hardware, and thus no desktop environment possible

Console

The console access is realized as a shell inside the virtual machine. The access is comparable to an ssh session. Multiple concurrent windows will show the same console but when all windows showing the console are closed, the console will be terminated and the next window will show a new clean console. This has several implications:

• The console does not require any login. This does not mean that the system is insecure, the ssh server will prompt for a login as normal.
• The console is text-based, so no graphical programs can be executed.
• The meaning of pressed keys depends on the keyboard layout of the real keyboard of the user.

Images

The root file-system is stored in a folder on the host machine. The file-system can be download and uploaded as a tar archive compressed with gzip (.tgz or .tar.gz). When extracting or creating such an image keep in mind that file ownership can only be set properly if the user has root permissions and all the users and groups in the image exist. When this is not done properly the resulting compressed archive will not be bootable.

Technologies

ToMaTo supports the following technologies for container-based virtualization:

• LXC (preferred) (not available yet)
• OpenVZ

Full Virtualization Device

Full virtualization devices are heavy-weight virtual machines that emulate a whole computer with generic hardware. Most things that are possible on physical computers is also possible on fully virtualized devices. Most operating systems can be run on KVM.

Limitations

• Virtualization solutions might not work. Since the virtual machine itself is virtualized it does not expose the AMD-V/VT-x processor features to the guest operating system.
• The hardware clock runs on GMT time zone. This will be a problem with Microsoft operating systems since they assume the hardware clock to be local time.
• Timer precision will not be as high as on real hardware since the virtual machine's process is scheduled by the host system.

Emulated Hardware

• Processor and RAM depending on the performance profile
• One hard-disk connected to the first IDE as master
• Intel motherboard
• Cirrus Logic GD5446 Video card
• Intel E1000 network cards
• PS/2 mouse and keyboard (german layout)
• Additionally a USB tablet input device (for absolute mouse positioning)

The emulated environment is the same as in KVM run with: kvm -cpu kvm64 -usbdevice tablet -smp sockets=1,cores=1 -nodefaults -vga cirrus -tdf -k de -enable-kvm -net nic,model=e1000 ...

Console

The console access is realized as vnc connection to the graphics output. The console will show exactly the output of the graphics card of the virtual machine. Keyboard or mouse events will be sent to the server via its emulated keyboad and mouse devices. This has several implications:

• The console is not text-based even if a text-based console is displayed.
• Multiple console windows will show the same console.
• The meaning of pressed keys depends on the keyboard layout configured for the emulated virtual keyboard in the virtual machine, not on the real keyboard of the user.
• Closing the console is the same as disconnecting the monitor cable from a computer (emulated keyboard and mouse are not disconnected)

Images

The hard-disk images are stored in the qcow2 format. When they are downloaded they can be run in Qemu. Disk images in the qcow2 format can be uploaded and run. For operating systems that have problems with hardware changes qemu should be configured to emulate the same hardware as in the testbed.

Technologies

ToMaTo supports the following technologies for full virtualization:

• KVM (preferred) (in stable, but not deployed)
• KVMQM

Programmable Device (Repy)

Programmable devices are essentially scripts that can work with networking packages. These scripts can be written in a Python dialect called Repy and can read and write raw Ethernet packets to/from their network interfaces. Programmable devices are very light-weight as they are just small Python scripts.

Repy is a turing-complete subset of Python that allows to run in a sandboxed environment. ToMaTo adds the following functionality to Repy:

• Reading raw packets from networking devices
• Writing raw packets to networking devices
• Listing networking devices and information retrieval
• Encoding and decoding byte structures using the struct library

Emulated Virtual Hardware

The only virtual hardware of Programmable Devices are their networking devices. These devices can handle Ethernet packets up to 1514 Bytes.

Console

For Programmable Devices, the console only displays the output of the script but does not allow any input.

Images

The Repy scripts of the device can be uploaded and downloaded as images. A quick sanity check will be performed before the upload.

Choice of device type

On the first look, full virtualization seems to be the better choice as it allows more operating systems and does not limit operating system functionality. Container-based virtualization though, is a very light-weight solution that gives quick access to Linux machines and is much easier to handle than full virtualization. (E.g. Container-based virtualization allows users to configure that root password or the IP addresses of the interfaces.). Additionally, Full virtualization consumes a lot of resources on the testbed, so it should be avoided if it is not necessary.

This list of criteria can help with the choice:

• Do you need realtime functionality or extremely precise timing? => Use a physical system (not supported by ToMaTo)
• Do you need to run hardware virtualization inside the device? => Use a physical system
• Do you want to test your own low-level protocol? => Use Programmable Devices
• Do you want to apply simple modifications to packets? => Use Programmable Device
• Do you need an operating system other than Linux? => Use full virtualization
• Do you need to access the hardware? => Use full virtualization
• Do you need to modify the kernel or load modules? => Use full virtualization
• Do you need to setup routing tables, ipables or mount filesystems => Use full virtualization
• Otherwise => Use container-based virtualization