I have recently stumbled across #1419 while trying to make the Android emulator work decently. There you say that you can’t provide KVM due to infrastructural limits in Google Compute Engine.
Today I have stumbled across this ( https://cloudplatform.googleblog.com/2017/09/introducing-nested-virtualization-for.html ) and this ( https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances ). Now, please bear with me - I know nothing about Linux and KVM - but it looks like this feature could help? As far as I understand, you just enable this feature and then KVM will be provided…
If it’s true, please consider this! The non-accelerated ARM emulators are so slow and Google is not even releasing the system images anymore for new Android APIs (already absent for API 26 and 27). So the current workaround (use ARM emulators even if it takes 20 mins) won’t work forever.
Support for x86 Android Emulator (KVM, vmx, svm)
I am sure @BanzaiMan is fully aware of this as I suspect he lives and breathes it :-), but this may be interesting for others. I’d love any input / corrections if my understanding is wrong
My understanding is that with the consolidation of the Linux architecture within Travis (which collapsed the two ‘sudo’ environments that would route to Google Compute Engine or AWS depending on sudo false or true respectively) I think that means everything goes to GCE. I know for sure language: android went to AWS regardless of sudo status prior, but now my android builds are appear to be running on GCE workers.
So since GCE enables the nested virtualization feature, and I think Travis just went all GCE where this is possible, maybe this can be enabled.
Travis would just have to re-configure GCE following this info https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances, and it would work. Even if it was just for ‘language: android’ (or even some limited ‘beta testing’ configuration) it might be worthwhile to lower Travis compute costs as the ARM emulators are stupendously slow while pegging the CPU.
If it is useful at all, I would be willing to test any possible implementation with my dev fork of the AnkiDroid project’s builds and provide feedback - they’re pretty involved Android+Travis emulator users - https://travis-ci.com/mikehardy/Anki-Android
I created a project on github to test android emulators on linux and mac here. For demo purposes it includes attempting to start the x86 emulators (which of course will not run). Could be a useful reference for emulator set-up times.
Was able to get several to start and even use one config reliably here on both linux and mac.
Even wrote article about the experience.
Enabling hardware acceleration on linux (and mac for that matter) would be a huge boost in speed for running android x86 emulators.
Enabling nested virtualization (i.e. KVM support inside the travis worker VM) would also be super useful for non-android projects.
For example for projects that deal with configuration management, provisioning or the system boot process.
As-is, on Travis-CI. because nested virtualization is disabled, such CI code has to execute QEMU without KVM support which results in a massive waste of CPU cycles. In my local experiments, the dracut-sshd test suite runs 50 % slower in a VM without nested virtualization.
okay now after using search, finding nothing and creating a new issue, I found this … please support nested virtualization, the arm-android emulator really is a pain in the automated-tests