Qubes in Qubes OS: Should we be calling VMs 'qubes'?

[aronowski]

@Zrubi

And I would say if one choose to use Qubes OS for a reason, then it also must learn some relevant terms like: virtual machine, Xen, dom0, domU, virtualization, PCI PassTrough, basic networking. Otherwise they will surely fail.

I’d put it into other words: “it’s better for one to learn about this than not learn at all, otherwise someday the lack of knowledge might be problematic, usually when in need of some manual troubleshooting full of technical terms”.

Some parts of the existing tooling are so nice, like the Qube Manager with it mentioning when to use different virtualization modes: they don’t necessarily hide the technical details, but instead inform the user, what is what, and where and when to use an option, rather than saying nothing with the mentality of “if a user really, really, really wants to know, they will go out of their way to learn it on their own, e.g. in the documentation”.
Instead, a user can learn the technical parts when just using the system for their reasons, whether that’s working, banking, and whatnot.
Gotta disagree with the “must learn” part, though - I myself don’t need to know how is PCI Passthrough implemented to have some hardware attached to a certain domain. Or that I don’t need to configure networking myself, as my role is just about specifying, what domain should be a network provider for another one - very nice for setting up a company VPN once, and then using a VPN domain as a provider for job-related domains with different systems.
I’d also consider how a dedicated Qubes OS installation could be used by a company’s Service Desk and set up for a specific user. One who doesn’t need to know the underlying technology, but can focus on the software used for their work, with preconfigured applications and policies by a company’s Service Desk. I could imagine, for instance, a split implementation of an offline domain with trade-secret Excel sheets, which can get some online data with Power Query only by requesting an online domain to pass it via a qrexec service. Here the Service Desk is in charge of working with the technical part, the user is not.

@Zrubi

But I would go more far about this:

• if a Qubes user don’t know what the difference between Xen, KVM, Hyper-v, VMware, or docker… then they still not understand how Qubes is standing out from anything else out there.

Yep! Possible reason could be this:

@Zrubi

So you think they just accept what they get? and happily trust the vendor because they said so? - like an average iPhone user?

Meaning, for example, a non-technical user who accepts a solution without knowing its underlying technology, basing on the history and expertise of the people, who develop it.

---

Back on the topic of the naming convention, I’d appreciate the future, where a qube can in practice be a remotely-accessed smartphone with a banking app, having its display painted on my laptop screen, where I do my banking, rather than being only a VM and nothing else.
This example is on purpose, since using an Android Xen guest with banking apps didn’t end well when I last tried it. Having the same workflow, but with a real phone, which doesn’t get blocked “for my security”, would be nice.

[Churros]

This is something that has bothered me for a long time, and I find that when writing on the forum I use domU, qube, VM, appvm or template based on my internal prng, without any consistency. Remarkable to me, because I hate being imprecise and usually avoid it

Personally, I would prefer “qvm” over “qube” or “vm”, but I understand that may not be ideal because of the tools that start with “qvm-“

… or maybe that makes it ideal?

My nominal $.02

[phceac]

To delete -premature post

[johnhwoods]

Exactly. To me, a VM is a machine that runs in a type 2 hypervisor like Virtualbox. Some of my Qubes have VMs in them.

[Zrubi]

@johnhwoods

To me, a VM is a machine that runs in a type 2 hypervisor like Virtualbox.

wow
Well, you can create your own terminology for sure… but that’s not so useful in practice.
You should ask the AI, and/or google what is a virtual machine, to see what others mean when they say VM.

@johnhwoods

Some of my Qubes have VMs in them.

That’s what we call ‘nested virtualisation’, and that’s a very special scenario, with it’s own cons and pros. And I can hardly imagine if it has any meaningful use case in case of Qubes OS.

[johnhwoods]

This seems unnecessarily rude for a general discussion. But anyway

A Qube is a very specific kind of VM. It’s literally only useful in Qubes OS. And all the VMs in Qubes-OS, with the exception of the nested ones I mentioned, are exactly this kind of VM. Why look for a more generic name when it’s bound to be more imprecise?

[Zrubi]

I don’t meant to be rude, and I’m sorry if you feel so.

However, your statement is still far from reality. VMs in Qubes OS are not ‘specific type’. In fact you can choose what type of VMs you want/need:

• HVM
• PV
• PHV

Beside the virtualisation type, can chose the role of your VMs:

• AppVM
• TemplateVM
• DispVM

And AppVMs can have another kind of role like:

• ProxyVM (provides network)
• NetVM

And all of those are provided by Xen, the (current) hypervisor of Qubes OS. The Qubes specific parts are ‘just’ how easily you can create and how seamlessly can use them… but not ‘what kind of VM’ we talking about.
(very similar kind of VMs can be created and used on any other Xen based system like xpc-ng, or XenServer)

So yeah you can call all of them ‘qube’ - just like you can call all the different vehicle types as ‘car’. You are not wrong, just using a very broad term, while ignoring the important details ‘under the hood’