Add support for Mikrotik CHR arm64 images

[mpfz0r]

• Adjust vrnetlab to support aarch64.
• Bump routeros docker image to debian trixie for newer more performant qemu version
• Install python 3.12 with uv. To keep backwards compatibility
• add cross platform build support to makefile.include (via DOCKER_PLATFORM variable)

[mischadiehm]

works great and so much faster on my macbp!

md@debian-clab:/Users/md/git/narrowin-labs/ot-lab$ docker ps | grep mikrotik
86009b90de33   vrnetlab/mikrotik_routeros:7.20.6-arm64    "uv run /[launch.py](http://launch.py/) -…"   2 minutes ago        Up 2 minutes (healthy)          22/tcp, 830/tcp, 5000/tcp, 5678/tcp, 8291/tcp, 10000-10099/tcp, 161/udp   clab-ot-sec-flat-sw-acc2
9877277669f4   vrnetlab/mikrotik_routeros:7.20.6-arm64    "uv run /[launch.py](http://launch.py/) -…"   2 minutes ago        Up 2 minutes (healthy)          22/tcp, 830/tcp, 5000/tcp, 5678/tcp, 8291/tcp, 10000-10099/tcp, 161/udp   clab-ot-sec-flat-gw-firewall
81b584e51030   vrnetlab/mikrotik_routeros:7.20.6-arm64    "uv run /[launch.py](http://launch.py/) -…"   2 minutes ago        Up 2 minutes (healthy)          22/tcp, 830/tcp, 5000/tcp, 5678/tcp, 8291/tcp, 10000-10099/tcp, 161/udp   clab-ot-sec-flat-sw-acc1
831b4beed6fa   vrnetlab/mikrotik_routeros:7.20.6-arm64    "uv run /[launch.py](http://launch.py/) -…"   2 minutes ago        Up 2 minutes (healthy)          22/tcp, 830/tcp, 5000/tcp, 5678/tcp, 8291/tcp, 10000-10099/tcp, 161/udp   clab-ot-sec-flat-sw-dist

[mpfz0r]

also tested on amd64 now. I consider this done

[mischadiehm]

@mpfz0r not sure if using -arm64 is best choice when trying to make this as easy to use as possible you might wanna get rid of the dash?

export ARCH=arm64

# then in the clab config you would do sth like:
    #image: vrnetlab/mikrotik_routeros:7.20.6
    #image: vrnetlab/mikrotik_routeros:7.20.6-arm64 the dash here breaks this simple env switch
    image: vrnetlab/mikrotik_routeros:7.20.6{ARCH}
    restart-policy: "no"

which fails when you want simple env switches unless one does:

export ARCH="-arm64"

which is also kind of awkward? So if you create the image without the - we loose a bit readability but do gain quite some simple flexibility

[mpfz0r]

I would've like to keep this a semantic version. I'm either gonna tag the amd64 image with an additional tag -amd64 for consistency, or maybe I can try and make this a multi-arch image.
hang in there..

[mpfz0r]

I've added this and also cross platform build support, so you dont need to resort to two machines when building this.
This is the new format:

vrnetlab/mikrotik_routeros:7.20.4                                     43e6c174249e        479MB          479MB
vrnetlab/mikrotik_routeros:7.20.4-amd64                               43e6c174249e        479MB          479MB
vrnetlab/mikrotik_routeros:7.20.4-arm64                               e210346fe2d3       2.27GB          442MB

I've started looking into multi-arch images, but since this needs a running registry, I think this doesn't necessarily need to be implemented in vrnetlab.

[mischadiehm]

@hellt any chance this can get merged or is there anything missing?

[hellt]

I was waiting on @mpfz0r to conclude the testing. Is everything complete?

[mpfz0r]

@hellt yes, it is. there was a bit of a back and forth on how we tag the images. But I consider this ready now.

we might want to think on whether we can update the base image for all platforms to benefit from a newer qemu.
But I don't have the capacity to test this yet.

[hellt]

I don't think we can take this in for the common library. It seems quite specific to CHR and not universally applied to all platforms.

Instead, I would propose adding the necessary variables that the CHR would provide to the class constructor when the certain arch is detected

[hellt]

@mpfz0r @mischadiehm I would suggest you to check how to minimize the custom touches done to the common/vrnetlab.py

some added things there are CHR specific, and should be in the CHR code, not in the common

[mpfz0r]

I don't think we can take this in for the common library. It seems quite specific to CHR and not universally applied to all platforms.

hmm, my thinking was that if we get non-x86 images from other vendors, at least picking the right qemu-system-${self.arch} would have a place in common.
The other ones are debatable I guess.

The tcg flags are for optimization and should help other platforms as well.

I'm not entirely sure other future arm64 platforms would need the same UEFI firmware, so I'd make this one into CHR specific.