Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/markitobonito/cloud_repositorio/llms.txt

Use this file to discover all available pages before exploring further.

Cloud Repositorio builds the network plane using Open vSwitch (OVS) on both compute workers and the dedicated network node (10.0.10.3), with one VLAN per VM-to-VM link and optional internet access via NAT on VLAN 400. Every VM interface maps to a TAP device that is attached to the br-int OVS bridge with a VLAN tag, providing L2 isolation between slices while keeping the physical underlay simple. When you create a link between two VM interfaces — for example VM1.eth1 ↔ VM2.eth1 — the orchestrator allocates the next available VLAN from the slice’s pool and records it on both interfaces. The VLAN is not provisioned on the network until deploy_slice is called. At deploy time, VMLauncher runs on the worker that hosts each VM. For every interface that has a VLAN assignment it:
  1. Creates a TAP interface named after the VM and interface.
  2. Brings the TAP up.
  3. Adds it to the br-int OVS bridge with the assigned VLAN tag.
sudo ip tuntap add mode tap name tap_1002_eth1
sudo ip link set dev tap_1002_eth1 up
sudo ovs-vsctl --may-exist add-port br-int tap_1002_eth1 tag=120
The TAP is then handed to QEMU as a netdev tap device, giving the guest OS a direct L2 path to any other VM on the same VLAN — even if the two VMs are on different worker nodes, because OVS VLAN tags are carried over the physical network between workers.

​
VLAN gateways and DHCP

For each link VLAN, the orchestrator provisions a gateway port and a DHCP namespace on the network node (10.0.10.3) during deploy_slice. Gateway port — an internal OVS port is added to br-int and assigned the gateway IP: 
sudo ovs-vsctl --may-exist add-port br-int gw_vlan120 tag=120 \
  -- set interface gw_vlan120 type=internal
sudo ip addr add 192.168.120.1/24 dev gw_vlan120
sudo ip link set dev gw_vlan120 up
DHCP namespace — each VLAN gets a dedicated Linux network namespace named ns-dhcp-vlan{vlan_id} with its own OVS port (dhcp_v{vlan_id}) moved into it and dnsmasq running inside: 
sudo ip netns add ns-dhcp-vlan120

sudo ovs-vsctl --may-exist add-port br-int dhcp_v120 tag=120 \
  -- set interface dhcp_v120 type=internal

sudo ip link set dhcp_v120 netns ns-dhcp-vlan120

sudo ip netns exec ns-dhcp-vlan120 ip addr add 192.168.120.2/24 dev dhcp_v120
sudo ip netns exec ns-dhcp-vlan120 ip link set dev dhcp_v120 up

sudo ip netns exec ns-dhcp-vlan120 dnsmasq \
  --interface=dhcp_v120 \
  --bind-interfaces \
  --dhcp-range=192.168.120.10,192.168.120.250,24h \
  --dhcp-option=3,192.168.120.1 \
  --dhcp-option=6,8.8.8.8 \
  --log-dhcp \
  --log-facility=/tmp/dnsmasq_vlan120.log
The CIDR for each link VLAN is derived from the VLAN ID: 
cidr       = f"192.168.{vlan_id % 256}.0/24"
gateway_ip = f"192.168.{vlan_id % 256}.1"
dnsmasq serves addresses from .10 to .250, announces the gateway via DHCP option 3, and uses 8.8.8.8 as the DNS server (option 6).

​
Internet access (VLAN 400)

Enabling internet access for a VM (internet_enabled=True at VM creation) assigns eth0 to VLAN 400, which uses the subnet 10.60.7.0/24 with gateway 10.60.7.1. This VLAN is configured once per slice deployment if any VM requests it. The network node enables IP forwarding and adds MASQUERADE rules to the ens3 outgoing interface: 
sudo sysctl -w net.ipv4.ip_forward=1

sudo iptables -t nat -A POSTROUTING -s 10.60.7.0/24 -o ens3 -j MASQUERADE
sudo iptables -A FORWARD -i gw_vlan400 -o ens3 -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
VMs on VLAN 400 receive a 10.60.7.x address from dnsmasq and can reach the internet through the network node’s NAT.

​
Interface naming

TAP interfaces follow the pattern tap_{vm_id}_{interface_name}. For example, VM 1002 with interface eth1 produces TAP tap_1002_eth1. Inside the guest:
  • eth0 is always the management interface. When internet access is enabled it lands on VLAN 400; otherwise it is created but left untagged (no VLAN assigned).
  • eth1 and above are data interfaces added at VM creation time via data_interfaces_count. They receive VLAN assignments only after a link is created connecting them to another VM interface.
VLAN pool exhaustion: Each slice has exactly 20 VLANs in its pool. Attempting to create a 21st link returns "VLAN pool exhausted" and the link is not created. To work around this limit, redesign the topology to reuse links where possible, or split the environment across multiple slices.

Build docs developers (and LLMs) love

Get started for freeTalk to us