Environment Import: no valid state, no bootable device

32 views
Skip to first unread message

Karen Hanson

unread,
Jul 15, 2020, 11:09:38 AM7/15/20
to EaaSI Tech Talk
Hello, 

I have installed EaaSI using the 2020.03 release of the installer and was wondering if anyone could help me with a few issues/questions?

1. I was able to log in and import the eaas/qemu-eaas emulator from Docker Hub (I used the "latest" tag). Next, I attempted to import this environment:
I hit "Import Environment", I tried it with the first Generic QEMU x86 Template and then with Generic Runtime. I noticed that the CONFIG field is empty either way - not sure if something should be in there. When I try to complete the import, the emulator window loads in the browser. It either shows a "no valid state" or it seems to start booting and then ends in "No bootable device". Am I missing a step? I have attached screenshots and a log. 

2. I have now run several failed environment imports - might these be taking space on the hard drive and if so can I manually delete them? I am trying not to run out of space.

3. I have a 15GB qcow2 file that I want to import. Do I have to place it at a URL to import it as an environment or can I file upload it as an object and then use it as an environment? 

Any pointers are very much appreciated - thank you!

Best, 
Karen

ubuntu-10-environment.png
ubuntu-10-no-bootable-device.png
ubuntu-10-no-valid-state.png
import-issues.log

Karen Hanson

unread,
Jul 16, 2020, 11:21:25 AM7/16/20
to EaaSI Tech Talk
Hello, 

I wanted to give a quick update: I imported the v2.12 version of eaas/qemu-eaas, and the environment import now works. I noticed that a value now loads in CONFIG when you select the template, so I think that might be why the latest one didn't work for me. Should I log this somewhere as an issue, or is it already known? Now that this is working, I can probably try a few more things with the 15GB qcow2 file, or otherwise find a place to put it so that it's a URL.

Best,
Karen

Ethan Gates

unread,
Jul 21, 2020, 12:16:26 PM7/21/20
to EaaSI Tech Talk
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

Karen Hanson

unread,
Jul 21, 2020, 4:24:41 PM7/21/20
to EaaSI Tech Talk
Thank you so much Ethan, this is very useful - I will check out that temp folder! I did end up using Wasabi after figuring out Google Drive's virus message on large files prevented download access via a URL.

I have since managed to load the VM in the emulator - the biggest challenge I have now is performance and screen rendering (the VM contains a website with a lot of video). I'm not sure if it's reasonable to expect the video to render nicely, but I'm wondering if I can improve the performance. It seems to eat up whatever CPU I give to it and still runs very slowly. I figured out today that -enable-kvm might not work on an AWS virtual machine because it require CPU access. I'm not much of a hardware person, but this is me trying things without knowing exactly what I'm doing (it's an 8 CORE /16RAM AWS instance):
-m 4096 -smp 6,cores=6,threads=1,sockets=1 -soundhw ac97 -net nic,model=rtl8139 -net user -usb -usbdevice tablet -enable-kvm
"Top" shows 580% CPU and ~2G of memory usage while using the machine. I'm not sure what that means with regards to the relevance of -enable-kvm. I'm wondering if it's worth testing a physical server - whether that might get better performance (through -enable-kvm). I might be able to find one to use for testing if there is a good chance that will improve matters.

I see there is a call tomorrow, so I will join that to see if I can get any performance tips! Thanks again for your help!

Best,
Karen

Karen Hanson

unread,
Jul 22, 2020, 3:11:41 PM7/22/20
to EaaSI Tech Talk
Hello, 

I wanted to answer my own questions in case anyone is looking for the same information. I figured a few things out and also talked to Ethan during the office hours. 

I confirmed that having access to -enable-kvm would speed up performance. AWS machines do not support this unless you are using a "bare metal" server (which are expensive). Otherwise, some cloud server services support "nested kvm" - e.g. Google Cloud, or a physical server would work too since you have direct access to the CPU. I was able to verify that this was an issue on my server (Ubuntu) with the command "sudo kvm-ok" - the response was:
INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used

Otherwise, my configuration is OK, though the extra cores aren't helping much in the absence of KVM. I marginally improved the video by enabling the XPRA option in the environment's UI but it's still a little jumpy. It's difficult to tell how much of that is due to the machine's overall performance. I'm now rebuilding the machine using a lightweight ubuntu ("Lubuntu") and using the Firefox that is packaged with that instead of installing Chrome, which hogs resources. I'm going to see if that improves performance just enough to work with the EaaSI instance I have for now.

Hope these findings are helpful to others. Happy to share more details if anyone is interested in this topic. If anyone sees that I have misunderstood things, I welcome your corrections!

Best, 
Karen 

--
You received this message because you are subscribed to the Google Groups "EaaSI Tech Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eaasi-tech-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eaasi-tech-talk/68a6684b-a625-4b90-b380-6fa8c46f1907o%40googlegroups.com.

Ethan Gates

unread,
Jul 22, 2020, 3:26:43 PM7/22/20
to EaaSI Tech Talk
Thanks for following up to the list, Karen! I'll also pass along a note from Klaus that on Google Cloud, nested KVM is still technically considered beta, so your EaaSI VM/image will have to be "signed" to acknowledge the beta; but as far as I am aware that has not been an issue in our tests with it. Azure should also support nested virtualization.

Also just a quick clarification that Karen has been working in the "legacy" (2019.11) UI due to some encountered bugginess with the new UI, as well as to get access to the experimental XPRA video option, which is not available in the 2020.03 UI release, in case that causes any confusion!

Best,
- Ethan
Reply all
Reply to author
Forward
0 new messages