I select hostnames drawn from the ordinal numerals of whatever language I happen to be trying to learn. Recently, it was Japanese so the first host was named “ichiro”, the second as “jiro”, the third as “saburo”.

Those are the romanized spellings of the original kanji characters: 一郎, 二郎, and 三郎. These aren’t the ordinal numbers per-se (eg first, second, third) but are an old way of assigning given names to male children. They literally mean “first son”, “second son”, “third son”.

Previously, I did French ordinal numbers, and the benefit of naming this way is that I can enumerate a countably infinite number of hosts lol

All it did was a lookup into a fairly sparse array. All the kerfuffle about it was unduly placed.

I want to make sure I’ve understood your initial configuration correctly, as well as what you’ve tried.

In the original setup, you have eth0 as the interface to the rest of your network, and eth0 obtains a DHCP-assigned address from the DHCP server. Against eth0, you created a bridge interface br0, and your host also obtains a DHCP-assigned address in br0. Then in Incus, you created a Macvlan network against br0, such that each containers against this network will be assigned a random MAC, and all the container Ethernet frames will be bridged to br0, which in-turn bridges to eth0. In this way, all containers can each receive a DHCP-assigned address. Also, each container can send traffic to the br0 IP address, to access services running on the host. Do I have that right?

For your Docker attempt, it looks like you created a Docker network using the Macvlan driver, but it wasn’t clear to me if the parent interface here was eth0 or br0, if you still have br0. When you say “I have MACVLAN working”, can you describe which aspect is working? Unique MAC assignment? Bridged traffic to/from the containers or the network?

I’m not very familiar with Incus, but I’m entirely in the dark about this shoddy plugin you mentioned for DHCP and Macvlan to work. So far as I’m aware, modern Docker Engine uses the CNI plugins when creating networks, so the “-d macvlan” parameter specifies which CNI plugin will load. Since this would all be at Layer 2, I don’t see why a plugin is needed to support DHCP – v4 or v6? – traffic.

And the host cannot contact the container due to the MACVLAN method

Correct, but this is remedied by what’s to follow…

Can I make another bridge device off of br0 and bind to that one host-like?

Yes, this post seems to do exactly that: https://kcore.org/2020/08/18/macvlan-host-access/

I can always put a Docker/podman inside of an Incus container, but I’d like to avoid onioning if possible.

I think you’re right to avoid multiple container management tools, if simply because it’s generally unnecessary. Although it kinda looks like Incus is more akin to Proxmox, in that it supports managing VMs and containers, whereas Podman and Docker only manage containers, which is further still distinct from the container runtime (eg CRI-O, containerd, Docker Engine (which uses containerd under the hood)).

I once had the mispleasure to face a Bash script that was 35 lines tall but over 800 columns wide. The bulk of it was a two-dimensional array – or rather, a behemoth that behaved like an array of arrays – with way, way too many fields.

If that wasn’t bad enough, my code review to essentially rotate the table 90 degrees was rejected because – and I kid you not – the change was unreviewable in any of our tools and thus deemed too risky to change. /facepalm

The gall of some people.