Hi Karen,
Apologies for not putting out a quicker response! I was "out of the office" last week and catching up on things now. But, I am glad you got the import working and that you found exactly the work-around we would recommend for others/everyone else on this list. To respond more thoroughly to your questions:
1) All the behavior that you described with the "Generic QEMU x86" and "Generic Runtime" templates is indeed expected. The issue we have right now is that the emulator versions marked with the default/"latest" tag in OpenSLX's Docker repositories are designed to function with their improved EaaS workflow for creating and importing environments - a workflow that has not yet been incorporated into the EaaSI interface. So the "latest" images and their associated templates are not functional with EaaSI v2020.03. The work-around is exactly as you described: specifying an older emulator tag/version rather than accepting the blank/default/"latest" option when importing emulators.
"Generic x86 QEMU Template", "Generic BasiliskII Template", "Generic SheepShaver Template", "Generic PPC Template" and "Generic Runtime" are all associated with the "latest" images and will not boot environments in EaaSI v2020.03.
Template options like "Generic 90s PC", "Generic 2000s PC", and all others (which, indeed, should populate the "Config" field with some text) come from earlier emulator images and should work; so, I recommend importing e.g. QEMU emulators with the tag "v2-12" or "v3-0" to get working templates.
2) Images that are imported but not saved wind up in a temp/cache folder in your EaaSI install (should be "image-archive/images/tmp" from the top-level eaas directory). They will indeed remain there taking up space on the server unless either that directory is manually cleared, or it should clear automatically whenever the EaaS service is restarted/rebooted. This can not be done through the browser interface, so let us know if you or a sysadmin need more information here!
3) The qcow file must be imported as an Environment, there is currently no way to mark a Content or Software object as the base image for an Environment; so yes, it must be imported via URL. Environment images tend to be much larger than Content/Software objects (like your 15GB file) and browser/web-UI based import methods frequently fail on files that large (if Tyler and Wendy see this thread, they can attest we've had issues even getting a ~2.7 GB ISO disk image uploaded as Software over our home connections...) The URL/end-point based import method has proven much more stable for importing environments and large files. Please let me know if you need any assistance with getting your image to a working URL, we've tried a few different cloud storage providers (Wasabi has probably been the most stable/easiest option).
Best,
- Ethan