Qubes Manager Decomposition for Qubes 4.0

[rootkovska]

For Qubes 4.x we would like to radically simplify the UX of Qubes OS, by hiding as much Qubes internal infrastructure (e.g. net/usb/firewall VMs) as possible, and by making the UX more coherent, and less confusing. One of the culprits of the current UX model is our infamous Qubes Manager. We would like to decompose and simplify it for Qubes 4.0. This ticket describes how I see this being done.

First we should observe that currently Qubes Manager is (confusingly) used for two different types of interactions/tasks: 1) those that involve creating or modifying the persistent configuration of the system (e.g. creation or removal of new AppVMs, setting their properties), and 2) those that involve observing or modifying the ephemeral state of the system (e.g. checking which VMs are running, stopping them, attaching devices to them). This confusing mix of duties is made worse by the fact that the user is expected to launch applications via the "Start Menu", which is not part of the Manager. I saw many users who looked into the Start Menu in order to create a new VM, as well as into the Qubes Manager in order to start an application...

So, we would like the next-gen manager for Qubes 4.0 (which we need to rewrite anyway because of the changes in the core-ng) to be essentially a widget for ephemeral system state observation and management (e.g. stop/restart/kill AppVMs). In other words the Qubes Manager should provide an answer to "What is currently happening with my Qubes system". And also allow some ways to fix/change this current state (e.g. stop VMs, start updates).

Practically-wise I imagine this to be a simple widget for the Xfce4 panel, just like e.g. audio mixer, or clock, and located in the top main taskbar somewhere to the far right, next to all the other icons/widgets for ephemeral state monitoring (network, clock, audio mixer, tray icons, etc). Here's an example screenshot to help your imagination.

This means that when the user clicks on the Q icon for this widget, a drop-down list of the running VMs will appear, potentially also showing other info, such as CPU/MEM resources, and also presenting buttons to shut down each of the VM.

This list should primarily show user AppVMs and optionally (if enabled in config, and in different color, e.g. grayed out, or after a separator - TBD) the system VMs (net/usb, firewall, tor, perhaps templates).

All persistent actions related to VM configuration, such as changing their template, netvm, etc, should be accessible through the appmenu via the Start Menu. In fact we're already exposing this way of modifying VM settings, via the "Add more shortcuts" appmenu for each of the AppVMs. This appmenu should now be called "Settings..." and should open the same window as today, only focused on the Basic Tab, instead of on the Applications tab. Additionally we should add "Delete this AppVM" button to the Setting dialog box.

We need a few more appmenus, for actions which operate on the global system configuration. These are:

1. An entry for changing global system setting,
2. An entry for creation of new AppVMs,
3. An entry for Backup/Restore of the system.
4. In the future: starting of our to-be-implemented Qubes "Appstore" (a GUI app allowing user to select additional templates and "recipes" to install/deploy)

Creation of all the above appmenus is trivial and requires essentially creation of a .desktop file which calls the already-implemented dialog boxe from the current manager (which we might later rewrite or not), and updating the Xfce4 main menu.

The QM widget should also handle device attachments to running VMs. I think the best way to implement this would be by having an additional (additional to the 'Q' icon which pops up the list of running VMs) tray icon appearing whenever there is at least one device to connect (this might be either a block device, or USB device). In that case a dropdown list with available devices and their assignment (similar to a combined output of qvm-block -l and qvm-usb -l) should be popped out.

Two UI-related rules we would like to stick to:

1. All the common operations should not require a right click, only left clicks.
2. Icons/status should only be displayed when it makes some sense -- e.g. no point in displaying an empty list of devices to attach -- in that it's better to just not display the icon for showing the list of devices, etc. More advanced users can always resort to command line, which would be very powerful in Qubes 4.
3. We should hide as much of the Qubes infrastructure as practically possible. As mentioned above this means e.g. not showing system VMs by default, allowing for simple one-click updates of all the templates and Dom0 (which we can now implemented easily with the management stack).

---

Compact list of things to do:

• widget with running VMs
• menu entry for VM settings
• An entry for changing global system setting,
• An entry for creation of new AppVMs,
• An entry for Backup/Restore of the system.
• widget with available devices (block, usb, microphone)
• An entity to launch updates (templates, dom0)

[rootkovska]

Additionally should display status/messages from the Health Monitoring Deamon (#2134). E.g. updates available (and offer a button to click), or "unrecoverable program with one of your system VMs, please restart the system".

Additionally the actual icon in the panel (the 'Q') might double as global security status indicator: green - all good, yellow - something's not ok (e.g. proprietary BIOS used), red - insecure configuration (e.g. VT-d not present or enabled, USB controllers or Network devices assigned to Dom0, etc). This is essentially implementing (the UI frontend part of) #6.

[marmarek]

@bnvk do you have any opinion on this?

[tasket]

I have been forming some ideas in this general direction. Perhaps a column of start/stop buttons next to the vm names in QM? Or 'update available' icons that become buttons when appropriate to launch updates.

Also, since vm / application often become synonymous in the Qubes workflow (e.g. "I need this app, so appvm X starts to run the app, but quitting the app does not provide an opportunity to quit the vm") then maybe more can be done to make this convenient. Although monitoring of app processes from dom0 doesn't seem likely, some alternative to the regular 'close' widget may be both easy to learn and implement. My first thought is to use a modifier key along with the close widget to mean "stop the vm along with the app".

What complicates this is that Linux is bad at handling app run cycles to begin with. Although services get red-carpet treatment, user-facing applications are routinely obliterated on system shutdown, for instance. Apps that do a bit of routine maintenance on shutdown may close their windows some time before exiting. So there is a question of how to synchronize behaviors between apps and vm management functions to improve UX.

[marmarek]

On Mon, Jul 04, 2016 at 02:57:24PM -0700, ttasket wrote:

Also, since vm / application often become synonymous in the Qubes workflow (e.g. "I need this app, so appvm X starts to run the app, but quitting the app does not provide an opportunity to quit the vm") then maybe more can be done to make this convenient. Although monitoring of app processes from dom0 doesn't seem likely, some alternative to the regular 'close' widget may be both easy to learn and implement. My first thought is to use a modifier key along with the close widget to mean "stop the vm along with the app".

This is already discussed here:
#832

Generally the idea is to detect if the VM is "inactive" from inside of
the VM (no dom0 involved at all); by checking if there are any visible
windows + some timeout (for both handling long application shutdown, and
also to have quick app startup if someone want to just restart
application).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[kalkin]

After reading @rootkovska post. I did some thinking about the UI & workflows a user has and how to lower the barrier for usage of QubesOS. This is what I come up with, sorry that it's so lengthy, please bear with me.

Introduction

First let me define some vocabulary: Allow me for just this post to introduce the word Space. The words Domain and AppVm/TemplateVM are loaded with too much of technical meaning, which is not interesting to the basic user™.

Space is a bundle of Apps you use (Firefox,OpenOffice,Xterm) to do some Activity (work, banking, image editing, anti NK propaganda), the Data you need for that and the Network Access. There are other Spaces, were you do other Activities, connected to other networks, but Qubes uses all technical abilities to keep them separate. I hope this vocabulary will us help concentrate on what we really want to show to the basic user.

Basic users:

• My mother (an average pc user) want to do stuff with her computer and not to manage VMs. She doesn't need to create an AppVM based on a TemplateVM of a debian-8-ultra-min because of $REASONS. She knows to use the banking blue-one Space to do banking, and for shopping at her favorite shops, she has a dedicated Space where the passwords are saved in the Browser. Her work-mails and all related stuff she does in the work Space purple.
• My rebellious brother Jeff needs a way to communicate with the rebels in $COUNTRY (besides doing the usual stuff). He uses a separate Space for doing research, chatting and receiving mails under an anonymous identity. He connects his Space with via Tor to the Internet. He also uses the integrated GPG support in QubesOS from different Spaces for his different Identities.
• A business user who just has to remember to use Space “Work-Client” green for doing new client signups, while for accessing the inner company database over VPN he uses Space Private Eyes Only red. He doesn't care about the glory details: VpnVM over TorVM over NetVM. He needs to do his day to day work. The whole networking setup was probably done by some one at his company. He also has a Space where he keeps his Bitcoin Wallet which is not network connected for money laundering ☺.

Not basic users:

Any one who says: “…but Fedora-23 sucks because $REASON…”. If you think you are capable to judge a GNU/Linux Distribution, then congratulations you are not a basic user any more. The needs of this users should be taken care off, but we can assume that this users are capable reading the manuals, documentation or in app help. Of course All the options known from R2 & R3 should be there for the power user, but hidden for the basic user.

1. A Preferences App

I actually have no opinion on that, because I don't know how much do we think that the basic user understands the concept of NetVm, ClockVm, TorVm, RAM and so on… May be we can keep it complex, because we assume the basic user will never need to fiddle with it? Can we make sure that the basic user never needs to change the settings?

2 Add Space App

This is as simple dialog screen for creation and customization of the users space. The user has to enter the following values:

• Space Name
• Choose Color
• Choose Icon (too much?)
• Choose Connection: Tor, CompanyVPN or Normal
• Backup: Yes / No
• If the user has the QubesOS GPG feature setup, he could connect a GPG identity here with his Space by choosing one.

I would even go as far and propose that once a Space has a Network Connection assigned, it SHOULD NOT be possible for the user to easily change the Network Connection, because this can leak information in form of i.e. Firefox Cookies.

Advanced Options:

In a tab, or hidden to be shown on request we complement all the other settings provided by the current qvm-create dialog and may be some more options like storage. Here you could manually set the preferred NetVM, even if basic usage doesn't allow it.

2.1 Add Apps to Space

A dialog screen for adding and removing Apps to a space. Just Left Colum ←→ Right Column.

This should be called directly after new Space creation, but can called from the Q-Menu → SpaceName → “Add Apps to Space".

Future Advanced Options

Add package names which will be installed by package Manager. Under the hood a new TemplateVM based on the default fedora-23 is created and the App is installed, and the new TempateVM is assigned as template to the AppVM of the current Space. We can do this because volume snapshots are cheap in R4.

Far Future

• Add App Store integration
• Start Gnome Software App in the TemplateVM so the user can install more Apps

3. A Backup App

For a Backup App the following bits are important for the basic user:

Spaces to backup

A list of Spaces by default all are selected, to back up.

Backups is about saving your work, which is in Spaces. The backup system should be smart enough to figure out when to backup which TemplateVMs and which templates could be easily recreated from other TemplateVMs (see above) and only backup the bare minimum.

Scheduling

User has to choose How often to back up & How long to keep old backups.

Technical Details

The user SHOULD be able to trust the scheduling. We could try to do live backups of running VMs, assuming that we use LVM Thin by default, this should workout fine at least from qubes storage perspective. If we can't do backups of running machines, we should check if i.e.: xscreensaver is running, if so just suspend all the running machines, force them write to disk, backup-up and resume the machines.

Destination

User chooses Backup location & Folder. Available Backup locations:

• Device
• Network Address (WebDAV, ssh, ftp, samba, nfs)
• Amazon S3 (In future)
• Freenet (In future)
• Ubuntu One lol (In future)

Technical Details

This part needs to have a good API so we can plug different Backup Implementations. Behind the scene the backup mechanism creates an AppVM appropriate for the chosen backup method, which mounts the Network or Device and awaits data.

Restore specific Spaces

Chose Space → choose date → Go!

Restore All

Chose date, Check the check box Restore System Configuration → Go

Technical Details

I count as System Configuration the following:

• Network
  • NetVm, TorVm, VpnVm ect..
• Things set in Preferences
• dom0 /home?
• What about my custom dom0 changes in /etc ?

4. App Store

The user chooses an App and installs it. After Installation he can choose to which Spaces he adds the App.

Technical Details

The current QubesOS Storage system allows the creation of a very specific kind of volume. A volume can be snapshot at start of a vm from a source (Think AppVM root snapshots). A volume can also saved when the vm stops (i.e.: a private image of an AppVM or the root of the TemplateVM). An interesting side effect is that you can define a volumeB with a source volumeA, which on start makes a snapshot of the source A, but on the shutdown it saves the changes to disk as volumeB.

So imagine you have fedora-23 TemplateVM. The user install the App “Qubes Development Tools". The app is just an RPM package installed in the AdminVM which contains the script to used in a vm at start containing something like this:

dnf groupinstall “Development Tools” -y

if [ -d /home/user/qubes-builder ]; then 
   git clone $URL /home/user/qubes-builder  && chown -R user:user /home/user/qubes-builder fi

If the user adds “Qubes Development Tools” in the “Add App to Space”-App to a Space behind the scene the following is happening:

1. A dyn-qubes-dev TemplateVM is created. It's root volume is a volume which will be a read-writeable snapshot from the default fedora-23 TemplateVM root.
2. The dyn-qubes-dev TemplateVM is started, at start the above script is executed.
3. The vm shutdowns. On shutdown the root changes are not discarded but stored.
4. The AppVM of the Space where the user added “Qubes Development Tools” is set to have as it's TemplateVM dyn-qubes-dev
5. On update of fedora-23 repeat steps 2 & 3.

Of course it's not a set in stone solution, just my mentioning of what can be achieved with the tech which is already available.

5 Other Important bits

5.1. Storage Management App

• Widget for xfce for fast device-in → dbus → pop-up → choose vm → go!
• An UI analog of qvm-block(1) and qvm-pool(1) for the advanced user. (The basic usage (in R4) should not involve any understanding of storage/volume/pool inner workings)

5.2 Space Manager

The basic user sees here by default all active spaces in a table (grid). Active means they waste resources in some way. He can “close them”. He also can view here all his other (inactive) Spaces.

(Reasoning: Tables are good, people understand Tables. See abuse of Excel)

Advanced User

This is the place to observe the ephemeral state of the system. This is the counterpart of qvm-ls(1) in fancy and dynamic. We should provide an advance grid which shows the Domains, which is filterable and have same fields as qvm-ls(1). At this point I can't stress enough, that this should be easily filterable. Bot the current qubes-manager as the all current implementations of qvm-ls(1) (R3,R4) are suboptimal especially if you deal with a lot of domains. This is why I maintain a script for that.

This should be the replacement for the body part of the current qubes-manager.

Technical Details

Both grids (Space and VM) should be reusable. Use the Space Grid allowing the user to choose the Space in basic mode, show the VM Grid when in Advanced views.

5.3 Audio/Video Managment

Tasks to be accomplished by the user: assign microphone, Webcam and mute a Space While this should be available from the Space Manager, for day-to-day usage the user should use a small widget integrated in the xfce-panel.

Last Words

I hope I have not forgotten anything. This is what i come up with, thinking about this thread and reading the source code of qubes-manager (let us bury it ☺). I welcome all the feedback you've got.

I also don't insist on using the word Space, it's probably patented by some cloud company anyway ☺.

If we the list of Apps makes sense, we should create dedicated issues and discuss the different Apps there.

[kalkin]

Off course all the Qubes Apps, like Backup, Preferences and so on… should be at the appropriate places in the Q-Menu and also be available from the Xfce-Settings App.

[tasket]

Most of the irritation in using Qubes comes from having to interact with task manager and window manager and launcher and VM manager separately. In particular, closing an app often entails the extra step of going to QM to issue a shutdown command. Breaking up QM functions can serve to alleviate this... but we might have to go as far as offering task management functions as well. It might even be less work and more user-accessible to instead extend existing task manager a bit to handle Qubes use cases. We can't keep task and window and vm management separate and expect praise for UX.

Also, keeping in mind that windows are the fulcrum of the Qubes UI--providing security context seamlessly with window management--we may want to add a vm-management function or two to the titlebars. The vm name/identity is right there, so why not? How else do users normally do task management? A: Via the window gadgets. This could be key.

FWIW, I don't think the term 'vm' is much of a problem apart from the far-off day we may see a non-hypervisor implementation of Qubes. Picking an often-used DE term like "space" with no isolation connotations as a replacement could increase confusion. The main problem is that adjectives denoting the vm types are incomplete (and a little misleading). "Netvm" is a misnomer when its used to denote the setting for an upstream interface. Meanwhile "standalone" and "HVM" overlap with most other descriptive lables and we use them imprecisely. There is a certain amount of irreducible complexity here, unfortunately. It could be the subject of a style guide and also forum etiquette.

FOSS distros almost always make their problems worse when they assume interfaces must be either "for grandma" or "leet h4x0rs"; the results are there for all to see. A balance must be struck in the easiest interface modes, lest a project descend to the sort of idiotic experiments circa 2005 where even browsers tried to banish location bars (the term "domain name" is not for innocent eyes). The sad thing is this spilled over into production software and we see it still; For example, browsers removed important visual context in the form of the status bar so that hovering over links now displays the target URL on the page canvas. These aberrations planted seeds of diminished security.

We certainly do need to assume the user can read manuals and howtos... and in the process learn terms and concepts that are meaningful. They need to learn some of the language that describes context, in addition to the usual PC and internet stuff. Good PC interfaces have always been about moderate learning curves and UIs that make features discoverable. That discover-ability causes people to ask questions which can seem inconvenient to us; some projects actively discourage this quality so they are not bothered. Something to keep in mind while going forward...

[tasket]

While we're talking about "burying QM" its worth noting that the ultimate direction things could go might just as well elevate QM to an all-encompassing status, in a ubiquitous mode such as a panel. This seems especially true given QM already has a certain degree of app management built into it. Adding launcher functions would be no stretch at all.

Combined with window widget/hotkey access to shutdown/pause/prefs functions, that leaves two focal points for managing windows, apps and vms together. The only things that wouldn't be integral are functions like backup/restore. I can easily imagine this as a winning combination.

[andrewdavidwong]

@kalkin: Thanks for sharing your thoughts! Just one small comment. ISTM that your term "Space" serves the same function as "qube".

[andrewdavidwong]

@ttasket:

Meanwhile "standalone" and "HVM" overlap with most other descriptive lables and we use them imprecisely. There is a certain amount of irreducible complexity here, unfortunately. It could be the subject of a style guide and also forum etiquette.

Or perhaps a glossary? :)

[rootkovska]

While we appreciate that everybody has an opinion on how a UI/UX should looks like, we also recognize that almost everyone see this differently. I'd thus like to ask anybody commenting in this ticket to provide direct response to the original message I posted. Rather than writing essays on how they would like to do that. Or we would not get anywhere.

[rootkovska]

Also, I'd like to ask everybody that we save our grandmas, mothers, wives, sisters, and daughters (as well as all other members of our families, or other groups of people) the doubtfully prestigious roles of models for "non-technical" and/or "absent-minded" users.

Even if one considers their mother or sister to be indeed such a damn good example of a less advanced person in the art of Linux KungFu than themselves, please, please, use the correct term, such as... "non-technical user", or "absent-minded user" instead.

I'm sure every Linux wizard will be given dozens of other opportunities to prove their supremacy on the Command Line over the mere mortals like their mothers or sisters, outside our ticketing system, mailing lists, or Website documentation, or other resources.

Thank you.

[kalkin]

@rootkovska

Also, I'd like to ask everybody that we save our grandmas, mothers, wives, sisters, and daughters (as well as all other members of our families, or other groups of people) the doubtfully prestigious roles of models for "non-technical" and/or "absent-minded" users.

I agree. Thank you for the reminder. I try to live up the CCC Hackerethik, which states: “You should only judge humans but what they do and not their looks, age, gender, species…”, but I'm sorry if I offended you(?) . I will replace mother & Jeff with genderless Alex & Sam, if you are okay with this.

The objective of the narrative was to make the more technical minded people understand, that there are humans who just want to get their stuff done and who are not interested in understanding all the VM magic behind the scene. IMHO good examples of average people to which you can relate can open eyes to the some other minded people. Which IMHO is important when talking about human interfaces, on an openly accessible ML/Ticketsystem where every one can respond and has an opinion.

[Jeeppler]

I like this idea for advanced users:
We should provide an advance grid which shows the Domains, which is filterable and have same fields as qvm-ls

it would be nice to have something like:

qm --fields=all --where label=green and template=like("fed") --order-by desc --format=table

or

qm --fields=all --where vm-type=pvh --order-by asc --format=json

or

qm --where label=green and type=template --action=qvm-start

I think it is important to have a powerful solution for advanced users. I know it seams a little bit off topic, but issue is also about UI/UX simplification. I think all users are important and should have a tool to get their work done.

[Jeeppler]

The current Qubes Manager has some issues with dark themes. I would be happy if the new solution would look good with dark and bright themes.

[rootkovska]

Advanced users are envisioned to use qvm-* commandline tools. Much more powerful these are gonna be in Qubes 4, especially qvm-ls.

[zander]

Related #3417

[Shane-Optima]

I guess this has been in the pipeline for a while, but t's hard to convey how big of a disappointment this news has been to so many of us enthusiastic Qubes users (and evangelists.) Not just of the loss of the Qubes Manager (yes, I know it's been brought back in a more limited form "by popular demand"), but the news that this is apparently the long term UX goal that will be aimed for.

Right now, the underserved segment of tech users are the power users. These are the people who understand what VMs do and roughly how they work, but do not know enough of the details, or have enough proficiency on the command line, to quickly see everything that needs seeing and do everything that needs doing.

It is possible to cater to these users--who are a massive part of the Qubes fanbase and are getting the word out there (for whatever that's worth)--without "confusing" people. To a power user, it is not at all confusing to have a list of all VMs with their configuration, their current state, and ways to alter or connect them easily at their fingertips. What is confusing is being told that we have to go hunt down a different part of the UI to do what needs doing. Why? If we know that a VM exists, we want to be able to look at a list of VMs, find it, click on it and do that thing, somehow. We're not fussy on how it gets done. Left click instead of right click, sure. And perhaps in the name of UNIX-y modularity, another GUI program could be launched as a result. But a requirement that I be aware of, track down and use a totally separate GUI to interact with the VM I'm staring a...?

Do you know what the UX feature that power users have appreciated the most in the past 10 years, the thing that gets the most mileage? It's that little box in the start menu (or equivalent) that searches for and suggests the program you're going to launch or the setting you want to alter. And that's because it does EVERYTHING. "I know exactly what I want to do... just tell me where I can relay that command to the OS!"

I've a tremendous amount of respect for the philosophies and the finished products that have come out of Rutkowska and the rest of the Qubes team (years before hearing about Qubes, I'd actually hacked together something superficially very similar using Virtualbox's "transparent desktop" feature, with different colored windows in each VM) but I believe that information hiding can be done without alienating the power users. It would be more work, probably. Every new demographic you cater too is more work. That is an inescapable fact of life, and obviously your time and money is limited. So if it is a tradeoff, I can only say, maybe just ask yourself... how important is the NON-power user demographic to you right now?

I've been pushing Qubes as the greatest thing since sliced bread over on Slashdot. Emphasizing how easy and intuitive it is; how it occupies that magical middle power-usery ground where you don't need to be so concerned with the specifics of how things are done, just knowing the 50,000 foot view is enough to get a lot out of it. They don't make distros like Qubes any more. I don't just mean there aren't other secure hypervisors out there; they don't offer UXes that occupy that wondrous middle around that so many of us part-time geeks are trapped in. Instead, everywhere we look the UXes have become extremely polarized: everything is either dumbed down into oblivion or requiring a CLI pipe proficiency that I never had the time to develop.

Do you understand how frustrating it is to be informed enough to know EXACTLY what you want to see or so but not be able to easily configure it? To not have enough hours in the day to become the highly proficient masters we'd all prefer to be?

I understand and even agree with many of the specific issues with the Qubes Manager, but the big picture verdict and philosophy sounds very disheartening. It is not "confusing" to us to have a centralized way of viewing and interacting with all of the VMs any more than the little search box in the start menu was confusing.

You guys do what you have to do, and I really can't applaud you enough for everything you've already done... but on behalf of all power users everywhere, I just felt like I need to make that detail perfectly clear.

[comods]

allowing for simple one-click updates of all the templates and Dom0 (which we can now implemented easily with the management stack).

1. With a fresh install of Qubes R4.0, updating from fedora-26 to fedora-28 was needlessly tedious. Having to use the Terminal to download 28, then being required to close VMs before I could change their template, instead of being able to have the change go into effect on the next reboot. This one-click update would be very useful.

2. During installation, I was asked if I wanted the list of default qubes setup. There should be a one-click resetup of any default qubes that have been deleted.

[andrewdavidwong]

@evadogstar:

2th Such a command is present (salt, the same command executed on setup). But unfortunately I don't remember it. @andrewdavidwong please, place it to update docs.

Sorry, I don't understand what you're asking for. Could you try rephrasing?

[andrewdavidwong]

Look at @RefinedSoftwareLLC question #2. As I remember, Qubes already have some beautiful way to re-setup all of default VMs (sys-net, sys-firewal, etc.) Can you add this command to the documentation?

I'm not aware of such a command, but I'd be happy to add it to the documentation if someone who knows it can provide it.

[marmarek]

See readme here for the list of states. You can apply a single state with qubesctl state.sls STATE_NAME. For example qubesctl state.sls qvm.personal will create personal VM (if not already there), with all its dependencies (template, sys-firewall, sys-net). The same for others.

[andrewdavidwong]

Should that README be moved into qubes-doc and replaced with a link pointing to the appropriate URL on our website?

[comods]

@andrewdavidwong Can you include @marmarek 's how to use explanation along with the list of states. With the addition of running from dom0 and using sudo. "From dom0, you can apply a single state with sudo qubesctl state.sls STATE_NAME. For example sudo qubesctl state.sls qvm.personal will create personal VM (if not already there), with all its dependencies (template, sys-firewall, sys-net). The same for others."

[marmarek]

Should that README be moved into qubes-doc and replaced with a link pointing to the appropriate URL on our website?

Yes, good idea.