3.2 RC - which VM settings?

[JPL]

A clean install of 3.2 failed at the configuration stage so I am creating and configuring the sys-net, sys-firewall sys-whonix and all appVMs manually.

Can someone tell me what difference the following settings will make:

- Initial memory min / max. I'm going for 500/3000 fo0r all as I have 8GB memory. Reasonable?

- VCPUs - defaults to 2 but I can pick a maximum of 8. Which should I choose (processor is Intel i7)?

- Tickbox for include in memory balancing. What difference does this make? Should I tick it for all VMs?

Thanks

[Alex]

On 08/03/2016 11:39 AM, JPL wrote:
> [...]

> Can someone tell me what difference the following settings will
> make:
>
> - Initial memory min / max. I'm going for 500/3000 fo0r all as I have
> 8GB memory. Reasonable?

Don't overprovision for system-related VMs. A netVM will rarely need
more than 1GB, same for firewallVM.

You appVMs may vary: in my work vm, where I use 2 IDEs (Android Studio
and MonoDevelop) + android emulator + firefox + thunderbird, I capped at
10GB and it works ok. My workstation has 32GB ram.

> - VCPUs - defaults to 2 but I can pick a maximum of 8. Which should I
> choose (processor is Intel i7)?

Don't overprovision vCPUs: the hypervisor will have to find *that many*
cores free at the same time to run your VM, and that's why VMWare
recommends 1vCPU for every VM on their ESX/ESXi infrastructure that you
can upgrade to 2 if needed.

I am against giving more than 2 vCPUs per VM in Qubes, and I recommend
careful experiments when tweaking this value (increment by 1 and test
with your actual workload, if there are performance gains or losses).

> - Tickbox for include in memory balancing. What difference does this
> make? Should I tick it for all VMs?

You cannot have memory balancing enabled for VMs with devices attached;
apart from that, there's no actual reason to allocate fixed amounts of
RAM for you VMs. Say, you dedicated 10GB out of 16 to one important VM,
but now you're just upgrading your templates with all the appVMs turned
off, and you'd like the templates to benefit of all available memory
without having to manually correct allocations. Or you just closed your
personal Firefox instance to gain a little room for a big compilation in
the work AppVM.

TL;DR: I think the defaults provided in Qubes are reasonably ok, and
while they may be changed if needed, changes should be tested carefully
- knobs are inter-dependent, and giving "more" of any one may actually
reduce performance overall, or for specific tasks.

--
Alex

[JPL]

Thanks for the detailed answer Alex. Makes sense now. Cheers

[Torsten Grote]

Hi Alex,

On 08/03/2016 06:56 AM, Alex wrote:
> You appVMs may vary: in my work vm, where I use 2 IDEs (Android Studio
> and MonoDevelop) + android emulator + firefox + thunderbird, I capped at
> 10GB and it works ok.

Do you mind explaining how you got the Android Emulator working in an
AppVM? If I try to start one within an AppVM it tells me:

Your CPU does not support required features (VT-x or SVM).

This worked fine though when running on bare metal. I guess these CPU
features are not exposed to AppVMs, so I am very interested to learn how
you solved that problem.

Thanks and Kind Regards,
Torsten

[Alex]

On 08/03/2016 03:35 PM, Torsten Grote wrote:
> Hi Alex,
>
> On 08/03/2016 06:56 AM, Alex wrote:
>> You appVMs may vary: in my work vm, where I use 2 IDEs (Android
>> Studio and MonoDevelop) + android emulator + firefox + thunderbird,
>> I capped at 10GB and it works ok.
>
> Do you mind explaining how you got the Android Emulator working in
> an AppVM? If I try to start one within an AppVM it tells me:
>
> Your CPU does not support required features (VT-x or SVM).
>

It says that to me too, but using an ARM image does work (this message
is just a warning) - albeit slower than any low-end actual smartphone.
x86 images would like to use the virtualization capabilities, so that
message becomes an error rather than a warning, and the emulator does
not even start.

But it's quick and nice for debug; with an usbVM I was able to connect a
real smartphone, for further debug; as Marek said in another thread, not
all devices work - a low-end Alcatel I bought for debug does work this
way, but my Asus Zenfone does not: once disconnected from usbVM and
attached to the work AppVM, it senses the usb reset and does not attach
again until the cable is unplugged and connected again.

TL;DR: use an ARM image, that message is a warning. Or use an actual
smartphone, but YMMV.

--
Alex

[Torsten Grote]

On 08/03/2016 11:37 AM, Alex wrote:
> It says that to me too, but using an ARM image does work (this message
> is just a warning)

Oh thanks! I didn't try using an ARM image. If you ever find out how to
run an x86 image with Qubes, please let me know.

> once disconnected from usbVM and attached to the work AppVM,
> it senses the usb reset and does not attach
> again until the cable is unplugged and connected again.

You might be able to use ADB via TCP. I explained how here:


https://github.com/QubesOS/qubes-issues/issues/2202#issuecomment-235937670

Kind Regards,
Torsten

[Torsten Grote]

On 08/03/2016 12:10 PM, Torsten Grote wrote:
> Oh thanks! I didn't try using an ARM image. If you ever find out how to
> run an x86 image with Qubes, please let me know.

I tried it now and it works, but is barely usable, because it is
very(!!!) slow. On top of running ARM emulation in an AppVM, I needed to
turn on software graphic rendering, because hardware rendering didn't work.

It would be nice if Android guests would be officially supported by
Qubes OS, but until that's the case, maybe there's a way of running
Android guests in the meantime.

An Android image comes with these files:

kernel-qemu
ramdisk.img
system.img
userdata.img

Shouldn't it be possible somehow to create a XEN guest VM with these
files mounted, so Android can actually boot?

Kind Regards,
Torsten

[Alex]

On 08/04/2016 07:51 PM, Torsten Grote wrote:
> I tried it now and it works, but is barely usable, because it is
> very(!!!) slow. On top of running ARM emulation in an AppVM, I needed
> to turn on software graphic rendering, because hardware rendering
> didn't work.

Yeah, it's quite slow, but depending on your app it may suffice - my
apps are "companions" for business applications, so there are no speed
requirements nor fancy graphics to display.

> It would be nice if Android guests would be officially supported by
> Qubes OS, but until that's the case, maybe there's a way of running
> Android guests in the meantime.
>
> An Android image comes with these files:
>
> kernel-qemu ramdisk.img system.img userdata.img
>
> Shouldn't it be possible somehow to create a XEN guest VM with these
> files mounted, so Android can actually boot?

While an Android x86 HVM guest may boot, would it work as an emulator
suitable for debugging? There may be some work to do to route tcp port
5554 from the debuggee (server) to the debugger.

I don't think a PV situation could easily work, because Qubes would like
to have its tools installed in the VM to be able to compose windows
coming from all the VMs in the system, while Android does not easily
allow for such a modification. But an HVM may boot, with its own
windowed fullscreen.

--
Alex

[raah...@gmail.com]

ya gpus are very vulnerable.

[yon...@gmail.com]

On Friday, August 5, 2016 at 1:52:12 AM UTC+8, Torsten Grote wrote:
> I tried it now and it works, but is barely usable, because it is
> very(!!!) slow. On top of running ARM emulation in an AppVM, I needed to
> turn on software graphic rendering, because hardware rendering didn't work.

Did any one found a better way to get the Emulator to work ?
I tried using the ARM emulation but it just hangs on the boot screen.

[johny...@sigaint.org]

Apologies if this is out of context, I don't see the original posting to
which this one is replying:

Have you tried Android x86? Without that ARM emulation, the performance
should be a lot better.

http://www.android-x86.org/

I've gotten it running on KVM under Tails. The setup wizard crashed, I
think because I haven't gotten the networking working yet, and I haven't
spent any more time on it. But it did seem to run, and was fast enough.

I think you're a lot more restricted on which store apps have been
compiled for x86, as well.

I failed to get it to work under Virtualbox on Windows, it just hung at
the Android logo.

Apparently people have success with differing versions of it, so if one
doesn't work, try another. :)

I haven't tried it under a Qubes HVM yet, but will give that a try today.

JJ

[yon...@gmail.com]

Hi JJ thanks for your reply.

You can find the full discussion here -
https://groups.google.com/forum/#!msg/qubes-users/l2bcrfJpF4s/R1aaOT_IBgAJ
and there a few more topics about android studio in the group.

I couldn't get KVM running inside qubes appVM I haven't tried to do it on a HVM but from what I managed to understand it might not be too easy (But I think all the information I found discussed qubes 3 RC2 and nothing more recent)

For now I managed to connect to an actual device using adb, which might be a better solution than an emulator any way. I'm just now starting to look into android development so for the foreseeable future it will probably be good enough for what I need.

If you manage to get KVM the x86 emulator to work that would be really useful