Mai 2010
- Table of Contents
- 1. Constituants
- 2. Switch Params
- 3. Connexions
- 4. Vlan
- 5. Topology Files
- 5. Demo Configuration
Constituants
Virtual Machine This machine is based on 2 possible technologies: UML and KVM, both in the linux mainline. UML machines need 2 files, one usually called linux is the binary to be run in the user world and a root file system which is just a big file that has to be mounted to be read. KVM machines need only root the file-system, the binary that launches it is called qemu-kvm. These Virtual Machines have ethernet interfaces plugged to sockets (sun sockets for UML and inet sockets for KVM), those sockets go straight to the uml_cloonix_switch daemon. While running, Virtual Machines do not write on their reference root file-system. When they have to save stuff, they write it in a file called COW for Copy On Write. All virtual machines are in the bulk directory of the cloonix-x.y tree.|------------------------| | Virtual Machine | | | | eth0 eth1 eth2 | |--| |----| |----| |--| vvvv vvvv vvvvVirtual Switch implemented by daemon uml_cloonix_switch in the bin_clownix directory of the cloonix-x.y tree. This daemon is the heart of the cloonix-net tool, it does several things: Machine Management: - Creates an iso9660 config file pass as a CDROM to the machine it wants to start, this config contains the small config differences such as the name and demo-associated user files. - Creates the adapted command-line to launch the machine with the requested parameters such as ethernet interfaces and others. - Launches the machine, gets its pid to be able to kill it. Machine eth Management: - Creates server sockets, either unix or tcp that will bring data from/to the virtual machines ethernet interfaces. These data flows are considered to be inside the cloonix network. Tux Management: - Creates server sockets, either unix or tcp that will bring data from/to outside of the cloonix network. All data flows coming from or going to the outside goes through a tux server socket. Switch Management: - All sockets of all interfaces of all machines and of all tux must be switched upon user request, the packets are transmitted as fast as possible from socket to socket. Obeys to xml commands: - Receives The daemon uml_cloonix_switch receives XML messages for real time live configuration.|------------------------| |------------------------| | Virtual Machine | | Virtual Machine | | | | | | eth0 eth1 eth2 | | eth0 eth1 | |--| |----| |----| |--| |------| |----| |------| xxxx xxxx xxxx xxxx xxxx | | | | | | | | | | | |--| |----| |----| |-------------| |----| |------| | | xml control<======> U M L _ C L O O N I X _ S W I T C H | | | |-----| |---------| |-------------| |----| |------| | | | | | | | | xxxx<--tux xxxx<----tux---->xxxx xxxx<--tux | | | | | | |---| |---| |--| |--| |---| |----| | tap2tux | | t2t | | slirp2tux | |----------| |--------| |-----------| || || // || \\ || || // || \\ /dev/tun socket to // || \\ to tap of tux of other ssh internet puseaudio host cloonixSlirp IP stack implemented by daemon slirp2tux This daemon is launched (relaunched if killed) by uml_clownix_switch at the start of the network, it is equiped with a hand-made ip stack to do dhcp and interface ssh, the outside internet and pulseaudio. Cloonix 2 Cloonix connection implemented by daemon tux2tux, also called t2t. This daemon is launched upon command by uml_clownix_switch. Cloonix 2 Host connection implemented by daemon tap2tux. This daemon is launched upon command by uml_clownix_switch. This daemon must be owned by root and have the sticky bit on because we must be admin to create a tap interface. Switch's Clients These are to connect and give configuration orders to the uml_cloonix_switch. The clients are wrapped by scripts, the names are: ctrl, fconf, event, graph. ctrl Command Line Interface, connects, sends a command and closes. fconf Reads a topology file and sends it or receive a running configuration and writes a file. event Monitors things. graph Graphical interface based on GTK.
Switch daemon
./uml_cloonix_switch <config_file> In start_cloonix_net the following file is used: <cloonix_config> <network_name> Cloonix-Net-Lab </network_name> <server_name> /tmp/cloonix_switch/cloonix_unix_sock </server_name> <server_port> 54321 </server_port> <work_dir> /tmp/cloonix_switch </work_dir> <bulk_dir> $HOME/cloonix_labs/bulk </bulk_dir> <bin_dir> $HOME/cloonix_labs/bin_cloonix </bin_dir> <rsa_public_key> $HOME/.ssh/id_rsa.pub </rsa_public_key> </cloonix_config>
Lan
To understand the configuration of the clownix daemon switching action, we must first describe what is called a lan in the software.
A lan is a name. And the switching rule is simply: all interfaces in the same lan see each-other.
Any number of lans are attached to a single interface of a machine. This makes the following config possible: __________________________________________________________________ | | | ------------- ------------- ------------- | | | | | | | | | | | V M A | | V M B | | V M C | | | | | | | | | | | | eth1| | eth1 | |eth1 | | | ----------|-- ------|------ ---|--------- | | | | | | | | | | | | |----- lan_one ----|---- lan_two -----| | |________________________________________________________________| A and B see each other, B and C also but A and C do not see each other. The lan configuration can be modified at any time during run and the action is instantaneous.
Topology Files
The topology file is a simple way to describe your network structure and connections, the best way to learn how to write one is through examples. Here is a sample of a topology file: <TOPOLOGY> <config_path> . </config_path> <VM> <name> ROUTER1 </name> <type> KVM </type> <mem> 128 </mem> <rootfs> openwrt_kvm </rootfs> <eth> <vlan > lan_two </vlan> </eth> <eth> <vlan > lan_three </vlan> </eth> <eth> <vlan > lan_one </vlan> </eth> </VM> ... </TOPOLOGY>
Demo Configuration
The file containing the topology, if it is in a directory with other files and directories with particular names, those other files and directories are read and used in the config of the target VM. The particular file name is: files_to_delete_from_all_targets The particular directories are: files_to_add_in_all_targets files_to_add_in_<VM_NAME_FOUND_IN_TOPOLOGY>> In the file files_to_delete_from_all_targets, you must put script commands, such as: "rm -f /etc/rc.d/S60quagga" These commands will be executed before VM boot. All directories, files and links in files_to_add_in_all_targets will be copied in all the VM targets of the demo before boot. All directories, files and links in files_to_add_in_My_VM will be copied in the VM called My_VM before VM boot. Here is a sample of the ospf demo shipped with cloonix-x.y: The chosen names are not very meaningfull, but in ROUTERS, /etc/rc.d/S80_ospf_interface_conf will configure interfaces and start quagga in HOSTS, /etc/rc.d/S80_ospf_interface_conf will configure interfaces ./topology ./files_to_delete_from_all_targets ./files_to_add_in_all_targets ./files_to_add_in_all_targets/etc ./files_to_add_in_all_targets/etc/quagga ./files_to_add_in_all_targets/etc/quagga/zebra.conf ./files_to_add_in_all_targets/etc/init.d ./files_to_add_in_all_targets/etc/init.d/commun_startup ./files_to_add_in_all_targets/etc/rc.d ./files_to_add_in_all_targets/etc/rc.d/S87_update_host_file ./files_to_add_in_ROUTER1 ./files_to_add_in_ROUTER1/etc ./files_to_add_in_ROUTER1/etc/quagga ./files_to_add_in_ROUTER1/etc/quagga/ospfd.conf ./files_to_add_in_ROUTER1/etc/init.d ./files_to_add_in_ROUTER1/etc/init.d/ospf_interface_conf ./files_to_add_in_ROUTER1/etc/rc.d ./files_to_add_in_ROUTER1/etc/rc.d/S80_ospf_interface_conf . . . ./files_to_add_in_HOST1 ./files_to_add_in_HOST1/etc ./files_to_add_in_HOST1/etc/init.d ./files_to_add_in_HOST1/etc/init.d/ospf_interface_conf ./files_to_add_in_HOST1/etc/rc.d ./files_to_add_in_HOST1/etc/rc.d/S80_ospf_interface_conf . . .