`qemu_sink` example has been renamed `qemus` and modified as follows:
- `boot_and_log.sh` starts 2 VMs
- The script is instantiated in the deployment file and
- at start-up each VMs will start:
  - an UDP server listening on 192.168.0.53:1234 (resp. 192.168.0.54:1235)
  - an UDP client connecting to 192.168.0.53:1235 (resp.
  192.168.0.53:1234)
- We use netcat in the VMs (using cloud-init) to achieve the above, and
it's usable through a tmux inside each VM (root account)

This example validates the initial implementation of Tansiv using Slirp
and UDP traffic between two VMs.

Lessons learnt:

- How VM are identified by the coordinator ?
Until now, we use a logical name (sets in the deployment.xml) which must
be built by the information in the VSG packet. We use the IPs of the
source and destination as logical name. Unfortunately here the traffic
originating from both VMs uses 127.0.0.1 as ip source. Out of the box
this causes some troubles in the coordinator. I could have used the
ip+port for this logical name but I've followed another path: I gave the
knowledge of the logical identifier to each qemu process and slirp is
using it to set the source of the VSG packet accordingly. This way we
ensure that this logical name is unique in the coordinator and refers to
the right VM.