RudderVirt

#Multi-VM Networking

Modules with more than one VM are wired together on a shared private network. From inside a VM, the other machines in your module look exactly like other hosts on a small LAN: same subnet, reachable by IP, no NAT in between.

#What this means in practice

  • You can ping, SSH, and curl between VMs. If the briefing gives you addresses for the other machines, those addresses work from inside any VM in the module.
  • The internet is a separate question. Whether your VMs can reach external sites depends on how the module's author configured the network in the manifest. Some modules have outbound internet, some do not. Look at the briefing first; if it does not say, assume the network is closed and ask your instructor.
  • Other students do not share your network. Each student gets their own private clone of the entire module. Your server is a different machine from another student's server, even though they have the same name and might have the same address.

#Addressing

Module authors decide the addressing scheme. The two patterns you will see most often are:

  • Static IPs in a small subnet. The briefing lists each VM's IP. This is the common shape for client/server scenarios.
  • DHCP off a built-in address pool. Each VM picks up a random address. The briefing tells you to discover them with a tool like ip a, ifconfig, or arp -a.

Use whichever the briefing tells you. If the briefing is silent, log into a VM and run ip a (Linux) or ipconfig /all (Windows) to see what address you got and what subnet you are on.

#Switching between machines

You drive one VM at a time. To get to another machine in the module, use the Switch VM menu in the console. See Switching between VMs for the full behavior, including what happens when a sibling VM is stopped or still booting.

#When something is unreachable

First, re-read the briefing. Some modules intentionally block ping or SSH, or ship with the network unconfigured — restoring connectivity is the assignment, not a bug. If the briefing describes the network as something you need to fix, the steps below are the work, not troubleshooting.

Otherwise, if you cannot reach another VM that the briefing says you should be able to reach, work down this list before assuming the module is broken.

  1. Check the other VM is actually running. Switch to it and confirm it booted; the Switch VM menu shows a warning when a sibling is down. Power it on from VM Controls if needed.
  2. Confirm the address. Re-read the briefing and re-check what ip a shows on the source VM.
  3. Check the firewall on the destination VM. Many modules deliberately leave a host firewall in place — blocking ICMP, SSH, or specific ports — and that may be exactly what you are supposed to fix.
  4. Check the service you are trying to reach. A VM responding to ping but refusing a TCP connection usually means the service on that port is not running.