Suitability for an application testing scenario
David Seaward
Previously I've used type II VMs like VirtualBox for application
testing: install application on the base OS, test features (including
GUI features, shell integration and system integration), discard
changes. Additional steps might include: pause/resume the VM, save
different states of the VM.
Are Qubes OS VMs suitable for the same purpose? Specifically, is it
possible to switch from a dom0 view to a VM-only view, rather than VM
windows appearing in dom0?
Regards,
David
P.S. If this is possible, Qubes OS also seems like a more flexible
alternative to dual-booting?
Reg Tiangha
particular distro, you can install it in Qubes as a standalone HVM. Then
the environment would work just like a regular VirtualBox VM without the
Seamless Mode (so you could interact with stuff like its Application Menu).
You can use Qubes Manager to pause the VM, but it doesn't seem to stay
paused after a reboot (when the PC comes back up, the VM is essentially
powered off) so I'm not sure if that's totally useful or not. As far as
I know, Qubes/Xen doesn't have the concept of snapshots so restoring to
different states isn't possible. If I'm wrong, then I'm sure someone
will correct me.
Vít Šesták
On pausing VMs: Actually, even if you just suspend and resume the whole system, all VMs get unpaused.
Xen actually has some restore capability, at least for PVs and maybe also for HVMs. This one is actually used in today's DVM implementation (as of 3.2), but it will AFAIK be handled differently in Qubes 4. The problem is it is hard to make it working properly with template-based VMs without additional restrictions and without counterintuitive impact on performance (like hibernated VMs affecting TemplateVM performance). See https://github.com/QubesOS/qubes-issues/issues/832#issuecomment-289100070 .
So, if you want hibernation, you can use a standalone VM. Such VM can handle everything on its own without involving Qubes (provided that the OS supports hibernation). I am not sure if hibernation will work well with standalone PV, but with standalone HVM, I see no reason why it should not work.
Regards,
Vít Šesták 'v6ak'
Reg Tiangha
first? I don't use suspend or hibernation myself, so I don't know the
answer to that.
Of course, in the current Qubes kernel configuration, Hibernation
support isn't even enabled in the kernel, so I suppose it's currently a
moot point.
Vít Šesták
> Of course, in the current Qubes kernel configuration, Hibernation support isn't even enabled in the kernel
For hibernating standalone HVMs, you will likely use a different kernel than the one provided with Qubes. Note that you need the VM to be running for hibernation.
For hibernating standalone PVs, this might be an issue (likely with an easy solution). With a proper kernel, hibernation might work (provided you have swap on a correct partition – if not, you will not be able to resume ☺), but there might be some other issues. The one potential issue I see: With PVs, restore is a bit complicated due to memory management: The VM AFAIK sees whole memory space without address translation, but it is constrained what it can access. When restoring, it will usually need to remap all the addresses. This must be implemented (and utilized in DVMs), but I am not sure if this is implemented for hibernation or not. But if you cannot make it working easily, don't bother too much: The PV technology is going to be history* since Qubes 4.
For hibernating template-based VMs, we have some worse issues, as noted above.
Regards,
Vít Šesták 'v6ak'
*) Well, even in Qubes 4, it will be used for stubdoms, but I don't think it matters in this case.
Matty South
Great question, David. I would say if testing could be done in Xen, then it could likely be done in Qubes. It's really difficult to mess with dom0 or how it looks, so I doubt you will have luck switching views. What guest OS will you mainly use for testing? One option may be, if you're accustomed to Virtualbox for Windows for example, setting up a Windows VM how you like it for testing and loading a guests in there. I can't comment on the performance of Virtualbox inside of a VM though. Has anyone else done this?
Vít Šesták
Virtualization for x64 generally requires virtualization extensions (VT-x or so), but they aren't available inside a Qubes VM. Maybe some patches can add support for it (look for “nested HVM” or “nested virtualization”), at the cost of additional complexity and thus larger attack surface. It reportedly used to be impossible to implement x64 virtualization without those extensions. It might be possible now, but I haven't seen it being implemented.
Virtualization for x86 (32-bit) guests might work even without virtualization extensions. I haven't tried it, though.
If course, emulation (QEMU, DosBox, …) will work, but it is going to be slow.
Regards,
Vít Šesták 'v6ak'
David Seaward
easiest to achieve with a "Hardware VM domain" (HVM) as outlined here:
https://www.qubes-os.org/doc/hvm/
The screenshots demonstrate that the HVM desktop runs in its own
window. HVMs can be managed via the command line or the Qubes Manager.
Note that the Qubes Manager is scheduled for improvements in Qubes 4.0:
https://github.com/QubesOS/qubes-issues/issues/2132
It would be interesting to know if it is possible (and a good idea) to
install GNOME Boxes on dom0 and access HVMs from there. Or if Qubes
Manager is "good enough" for managing full-desktop-GUI VMs.
Regards,
David
pixel fairy
> Hi,
>
> Previously I've used type II VMs like VirtualBox for application
> testing: install application on the base OS, test features (including
> GUI features, shell integration and system integration), discard
> changes. Additional steps might include: pause/resume the VM, save
> different states of the VM.
>
> Are Qubes OS VMs suitable for the same purpose? Specifically, is it
> possible to switch from a dom0 view to a VM-only view, rather than VM
> windows appearing in dom0?
The tool made for this is vagrant. https://www.vagrantup.com/
most vagrant boxes are command line only. for gui desktops, theres boxcutter/ubuntu1604-desktop and mwrock/Windows2012R2
not that you cant make hvm templates in qubes and go with that, but you wont be able to share or port your development environment as easily.
qubes is awsome in other ways, and once you try it, you wont want to go back. but, nested virtualization is disabled in qubes for security reasons. so you wont get to use vagrant in its default form. theres an lxc plugin for vagrant, linux only, and you could use the libvirt plugin with qemu, which would be in emulation, which is really slow. virtualbox 32bit might also work, but would also be slow (emulation) if it did.
if it matters, another limitation is the lack of graphics acceleration, but its still fast enough for most 2d tasks and watching movies in full screen on most laptops.
if you have a reliable connection to something you can use as a vagrant server, id use qubes as a terminal to that (which we do at work). if not, and if you want to be able to easily share your development environment, id use linux or whatever desktop your comfortable with, vagrant, and virtualbox or kvm if you need nesting in your environments (if your testing hypervisors for example)
if the dev environment is trivial or sharing it doesnt matter so much, then you might as well benefit from qubes.
> P.S. If this is possible, Qubes OS also seems like a more flexible
> alternative to dual-booting?
dual booting would break the security model. if you do want to dual boot, look into AEM to make sure the other os doesnt compromise the boot loader for qubes.