GNS3 / gns3-registry

GNS3 devices registry
GNU General Public License v3.0
327 stars 392 forks source link

QEMU appliance for multiple processor architectures #685

Closed ghost closed 2 years ago

ghost commented 2 years ago

Currently for QEMU appliances the processor architecture is a global setting (qemu/arch) in the appliance file. So when I want to create an appliance for both the Intel and ARM processor architecture I currently have to create two .gns3a file, one with "arch": "x86_64" containing the Intel images and another one with "arch": "aarch64" containing the ARM images.

Are there any plans to allow multiple processor architectures within a single appliance?

grossmj commented 2 years ago

Right, we should allow a list. I will implement this.

ghost commented 2 years ago

I think a simple list won't work. GNS3 uses the arch property to select the qemu binary. Using a list of allowed architectures would result in a list of qemu binaries, from which the user has to select the right one. But the user can't know, which is the right one. So there is a good chance the wrong one is choosen.

Another way would be to add an arch property to the image. But the image definition should be independent from the emulator. So adding a qemu specific option to an image would break this.

Another problem is, that the arch setting may not be the only parameter, that needs to be adjusted. Maybe an ARM image needs different adapter or disk types than an Intel image. Or the ARM image needs some different kernel or qemu option settings. So most qemu parameter must be changeable in the images sector.

Currently I think, that having two appliance files is still the best option. And it needs no changes.

grossmj commented 2 years ago

Correct, a simple list is well... too simplistic ;) After you listed all the problems, I have the same conclusion as you: two appliance files is the best option.

ghost commented 2 years ago

Well, turns out, that having multiple processor architectures in one appliance file is not that simple as I originally thought.

As we have a good workaround (using an appliance file for each architecture), I'm closing this issue.