Closed ghost closed 2 years ago
Right, we should allow a list. I will implement this.
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.
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.
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.
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?