Is this related to klass AdminVM? Terminology overlap is getting annoying.
It is irrelevant as I see it. Because, @unman already provided here a solution for a goal, and as I understand it is: create AdminVM, give it a network access (at worst?), create qubes with that AdminVM, or set tags for existing as ācreated-by-AdminVMā and set according policies and do whatever you want with them.
You can use them locally too, when in dom0. So, dom0 never touched externally, while the qubes are accessible.
Example of an AdminVM I am pretty regularly deploying is sys-gui-gpu, only locally though.
I apologize if I got the goal wrong.
Also, probably related
No, it isnāt, and there is not overlap.
An admin qube is any qube used for administration. It may also have
other properties. You control what is controlled using standard
policies. You can have one admin qube, dom0, or many. In the default
install dom0 is the only admin qube created. Other admin qubes can be
created from AppVMs or standalones, or could be disposables.
AdminVM is a specific klass, allocated to dom0.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
I donāt think there is an established convention to call a qube that is a client of some Qubes OS admin API methods an āadmin qubeā. E.g. people usually donāt call an āaudio VM/qubeā or a āGUI domain/VM/qubeā an admin qube, even though they make admin API calls.
When the term admin qube is occasionally used in the issue tracker, it tends to be a synonym for AdminVM, with both referring to dom0. dom0 is of course unusual in that itās both an admin API client and an admin API server (including policy evaluation) - it talks to itself when e.g. one of the qvm-something tools is run in dom0. Iād say this server side is what makes it an (or rather the) admin qube.
BTW this is also consistent with the Qubes Air blog post. It distinguishes an admin qube from a GUI qube, and only uses āadmin qubesā in plural for the meta-system spanning multiple āzonesā, with one admin qube per zone and that admin qube being dom0 if the zone is based on Xen.
2 Likes
There is little overlap in this topic, but fepitreās post referred to by corporateblush uses āAdminVMā to refer to admin qube, and that is confusing.
1 Like
And that post links to the admin API introduction, which (predating the VM ā qube terminology change) uses āmanagement VMā. Unfortunately, āmanagement qubeā now seems to be commonly used in relation to Saltā¦
I guess they donāt call naming things one of the hardest problems in computer science for nothing.
2 Likes
How about āadmin client qubeā as an unambiguous term? And āadmin client VMā for traditionalists.
This would match the division between qubes-core-admin (containing the server side of the admin API, for dom0 only) and qubes-core-admin-client (containing the client side of the admin API, for dom0 or any other qube).
1 Like
Too true.
āadminā, āmanagementā, and my personal friend āinterfaceā, are all exquisitely overloaded with hordes of meaning(s), so they seem applicable to a whole host of senses. You can sometimes get away with it in an insiders-only environment. To outsiders it can quickly become exclusionary jargonā¦
1 Like
Jargon-ing while we still donāt know / arenāt sure is the goal reachable through AdminVM as per @fepitreās postā¦
Great idea. If you or anybody else reading this is going to make a pr to glossary, could you please add the note clarifying āAdminVMā term for admin qube?
All other types already have one, and you posted this half way through me making one. I was thinking about replacing āpreviously knownā notes with something like āalso can be referred to asā. Clear distinction of what context the term is used in could be useful too, for example:
āapp qubeā is the preferred term, but depending on the context in can also be referred to as:
AppVMin historic blog and forum posts, or more technical context when referring to qube class (sometimes spelledklassdue to a technicality) used byqvmtools, qrexec policies, configuration management, etc.
another example with more terms:
ādisposableā is the preferred term, but depending on the context in can also be referred to as:
DispVMin historic blog and forum posts, or more technical context when referring to qube class (sometimes spelledklassdue to a technicality) used byqvmtools and qrexec policies, configuration management, etc.@dispvmfor new disposables in certain qrexec policies and admin API.
for admin qube:
admin client qube
A qube used for administering Qubes OS, running admin client software. In the default install, the only admin client qube is dom0, running qubes-core-admin-client software.āadmin client qubeā is the preferred term, but depending on the context in can also be referred to as:
-AdminVMin historic blog and forum posts.warning: Note that
AdminVMwhen referring to admin client qubes is not related to theAdminVMclass (sometimes spelledklassdue to a technicality) used byqvmtools.
Not sure what to do with the old āadmin qubeā term and AdminVM class though. @rustybirdās argument about server side is very compelling but I donāt know whether actual implementation works that way or it just marks domain with id 0 as AdminVM.
1 Like
I am old school when was adopting the terms. But I remember huge discussions about the differences between AdminVM and dom0 at the time and thatās why I mentioned Qubes Air 
This topic should be split, the last half being off-topic, but more important - because itās important, so due to better visibility.
1 Like
AdminCVM so it is consistent with qubes-core-admin-client naming.
The AdminVM class is just hardcoded to ādom0ā.
IMO itās okay to refer to dom0 as the AdminVM or the admin qube, but to be unambiguous I prefer to avoid those terms entirely and call it ādom0ā, as long as Qubes OS only supports Xen anyway.
You wonāt be executing the qvm-foo or qubes-bar command in dom0 though, but it in the admin client qube. Then the command will make (often multiple) admin API calls to dom0.
So as a starting point you could simply try running the command in the qube while watching the dom0 journal. It should log a qrexec call getting rejected because thereās no policy allowing it yet.
Here on the forum, it looks like management qube/vm terms are almost entirely applied for users of admin API. Unman is particularly visible.
Much more recently than the 2020 post by @fepitre, those terms are used in the qubes-ansible documentation, referring to use of the āadmin apiā to strictly delimit the authority of a qube which can perform some admin tasks, but without giving it full dom0 power. A good howto is there.
I believe management VM is useable in exactly the same manner with Salt, but it is confused by the choice to use the āmanagement DVMā term for a disposable qube for salt formula execution outside of dom0 - a different function, normally.
Any change to use āadmin client qubeā would be entirely misplaced. The only person for whom that qube would be a client is dom0 or its equvialent, except when it is dom0 doing the managing directly, when the meaning is completely lost.
I DO NOT want any of my users to even know that dom0 exists.
I DO want them to know that their qubes are managed, and if they are very good and careful then they might get to influence that management.
I think Qubes-OS needs a semiotician, before the terminology churn makes the documentation completely unusable.
Edit: Too many assertive statementsā¦ pls add several *** to indicate where it is IMHO.
1 Like
Again, like the majors are doing, retardizing users. Instead of educating them, toddlering them. But toddlers grow. And when toddlers are, parents canāt wait them to become grown-ups, because by default theyāre messing things up.
Especially grown ups will start to rise up when not feeling free. Look at the Qubes Air and similar topics
So instead of retardizing them, educateām while theyāre in a brain-sponge phase. Better for all.
Good point, perhaps management VM should be in the glossary too.
I donāt fully understand what you mean here. āAdmin client qubeā is a qube running admin client, multiple clients can coexist on the same Qubes OS system. dom0 is running both client(s) and servers. Why would it lose its meaning on dom0?
What do you mean by that? If a user knows that they are using a xen vm or a qube they can safely assume that dom0 exists, no?
This may all be true today, although Iām not even sure about the case where dom0 is managing things.
However, I think you may be considering all users to be people like youā¦ or me.
Whatās running, and where, is an implementation detail - itās likely to be cryptic, confusing to many, and could even need to change in the future. If the terminology is only for devs and tinkerers then thatās fine, but imagine unwrapping the little quote above for a ānormalā person. Clients, servers, and all that stuff - it is going to be noise to them.
What that qube is doing is āmanagingā - itās a qube that manages other qubes. It seems a much better and simpler way to explain it to a neophyte who just needs to get their job done. Maybe one day they might need to know they have multiple ones, or maybe they are just not interested.
(I guess āAdministeringā might have done, but thatās cooked, it seems.)
A person whose job is firefox, libreoffice, and email, has no need to have even heard of xen, or dom0. I literally do not want to have to explain anything beyond
āA qube is like a little computer inside your computer. You can do X, Y, Z from one qube to anotherā
After the programs are in their qubes, and the user can move data from one to another, all the rest is implementation details, all the way down, and those make for bad terminology.
Can you suggest what I should hit them with to force them to learn things that are actually part of my job, and not theirs?
I might need an extra big one though, for when I de-retardize them about gate oxides and which dopants they need in their semiconductorsā¦
Decades ago 1/3 of each of my MS Office course was spent on bringing disposed desktop, teaching them each hardware component basics holding it in their hands, then basics of Windows OS and Windows Explorer. The rest 2/3 was about Office itself and they already were relaxed to now familiar environment entering any Office app.
Till today, when ever we meet by accident or so, they still are calling me āprofessorā (when I actually am not) telling me how grateful they were to me.
I am writing this not to discuss with you, so please ignore it again, but as a potential reference to what should newbies asked for when paying to learn, while reading this topic.
The answerās above. Try it for once, you might be surprised with the effects and reactions, once everything sets down for them after processing time. Respect their intelligence and help them in their absolute but natural ignorance.