Caveats and Limitations

As mentioned in Mapping Configuration, the tool adds semantics to simple text tags which is a somewhat “hidden feature” and implicit.

It’s also not obvious from within the UI and without looking at the PATty log whether there’s any conflict or, in particular, why a configured mapping does not work.

It is up to the user(s) to use unique ports and to ensure external connectivity of nodes which are expected to have ports exposed via PAT.

In a multi user environment, users should be assigned port ranges which they must use. For example, user1 uses 2000-2999, user2 uses 3000-3999 and so on. But nothing will prevent user2 to use a port from user1’s range.

Port clashes / errors can only be seen in the PATty log.

The tool must run as root as it modifies the firewall of the host.

This approach might or might not work for a particular environment. But for personal use, this is most likely not a problem. Neither is security a big concern if the CML controller VM is running on the user’s laptop anyway (e.g., nothing is externally exposed and the personal user is the only user using CML).

Troubleshooting

Troubleshooting requires admin access on the controller, either via CLI / SSH or via System Administration Cockpit:

• Ensure all running nodes of all labs use unique tags / mappings.

• For PAT, ensure that the to-be-exposed host has an IP address acquired. It must be from the NAT bridge, e.g., by default from 192.168.255.0/24.

• Check the PATty log either via Cockpit -> Services -> patty, look for ERR messages (this is easier when the log level is set to Warn and not Info)

• Use the command line and search the log via sudo journalctl -u virl2-patty | grep --color -Ee 'ERR|WRN'.