@@ -7,67 +7,100 @@ layout: vm-operator
77
88* Since 4.0.0*
99
10- ## Prepare the VM
10+ Not all VMs are replacements for carefully maintained individual PCs.
11+ In many workplaces, a standard configuration can be used where
12+ user-specific data is kept in each user's home directory on a shared
13+ file system. In such cases, an alternative to providing individual
14+ PCs is to offer a pool of VMs and allocate them from the pool to users
15+ as needed.
16+
17+ ## Pool definitions
18+
19+ The VM-operator supports this use case with a CRD for pools.
20+
21+ ``` yaml
22+ apiVersion : " vmoperator.jdrupes.org/v1"
23+ kind : VmPool
24+ metadata :
25+ namespace : vmop-dev
26+ name : test-vms
27+ spec :
28+ retention : " PT4h"
29+ loginOnAssignment : true
30+ permissions :
31+ - user : admin
32+ may :
33+ - accessConsole
34+ - start
35+ - role : user
36+ may :
37+ - accessConsole
38+ - start
39+ ` ` `
40+
41+ The ` retention` specifies how long the assignment of a VM from the pool to
42+ a user is retained after the user closes the console. This allows a user
43+ to interrupt his work for this period of time without risking that
44+ another user takes over the VM. The time is specified as
45+ [ISO 8601 duration](https://en.wikipedia.org/wiki/ISO_8601#Durations).
46+
47+ Setting `loginOnAssignment` to `true` triggers automatic login of the
48+ user (as described in [section auto login](auto-login.html)) when
49+ the VM is assigned. The `permissions` property defines what a user can
50+ do with a VM assigned to him.
51+
52+ VMs become members of one (or more) pools by adding the pool name to
53+ property `spec.pools` (an array of strings), e.g. :
54+
55+ ` ` ` yaml
56+ apiVersion: "vmoperator.jdrupes.org/v1"
57+ kind: VirtualMachine
58+
59+ spec:
60+ pools:
61+ - test-vms
62+ ` ` `
63+
64+ # # Accessing a VM from the pool
65+
66+ Users can access a VM from a pool using the widget described in
67+ [user view](user-gui.html). The widget must be configured to
68+ provide access to a pool instead of to a specific VM.
69+
70+ {: width="500"}
71+
72+ Assignment happens when the "start" icon is pushed. If the assigned VM
73+ is not running, it will also be started. The assigned VM's name is
74+ shown in the widget above the action icons.
75+
76+ 
77+
78+ Apart from showing the assigned VM, the widget behaves in the same way
79+ as it does when configured to access a specific VM.
80+
81+ # # Requirements on the guest
82+
83+ Some provisions must be made on the guest to ensure that VMs from
84+ pools work as expected.
1185
1286# ## Shared file system
1387
1488Mount a shared file system as home file system on all VMs in the pool.
15- If you want to use the sample script for logging in a user, the filesystem
16- must support POSIX file access control lists (ACLs).
17-
18- ### Restrict access
19-
20- The VMs should only be accessible via a desktop started by the VM-Operator.
21-
22- * Disable the display manager.
23-
24- ``` console
25- # systemctl disable gdm
26- # systemctl stop gdm
27- ```
28-
29- * Disable `getty` on tty1.
30-
31- ```console
32- # systemctl mask getty@tty1
33- # systemctl stop getty@tty1
34- ```
35-
36- You can, of course, disable `getty` completely. If you do this, make sure
37- that you can still access your master VM through `ssh`, else you have
38- locked yourself out.
39-
40- Strictly speaking, it is not necessary to disable these services, because
41- the sample script includes a `Conflicts=` directive in the systemd service
42- that starts the desktop for the user. However, this is mainly intended for
43- development purposes and not for production.
44-
45- The following should actually be configured for any VM.
46-
47- * Prevent suspend/hibernate, because it will lock the VM.
48-
49- ```console
50- # systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
51- ```
52-
53- ### Install the VM-Operator agent
54-
55- The VM-Operator agent runs as a systemd service. Sample configuration
56- files can be found
57- [here](https://github.com/mnlipp/VM-Operator/tree/main/dev-example/vmop-agent).
58- Copy
59-
60- * `99-vmop-agent.rules` to `/usr/local/lib/udev/rules.d/99-vmop-agent.rules`,
61- * `vmop-agent` to `/usr/local/libexec/vmop-agent` and
62- * `vmop-agent.service` to `/usr/local/lib/systemd/system/vmop-agent.service`.
63-
64- Note that some of the target directories do not exist by default and have to
65- be created first. Don't forget to run `restorecon` on systems with SELinux.
66-
67- Enable everything:
68-
69- ```console
70- # udevadm control --reload-rules
71- # systemctl enable vmop-agent
72- # udevadm trigger
73- ```
89+ When using the
90+ [sample agent](https://github.com/mnlipp/VM-Operator/tree/main/dev-example/vmop-agent),
91+ the filesystem must support POSIX file access control lists (ACLs).
92+
93+ # ## User management
94+
95+ All VMs in the pool must map a given user name to the same user
96+ id. This is typically accomplished by using a central user management,
97+ such as LDAP. The drawback of such a solution is that it is rather
98+ complicated to configure.
99+
100+ As an alternative, the sample auto login agent provides a very simple
101+ approach that uses the shared home directory for managing the user ids.
102+ Simplified, the script searches for a home directory with the given user
103+ name and derives the user id from it. It then checks if the user id is
104+ known by the guest operating system. If not, the user is added.
105+
106+ Details can be found in the comments of the sample script.
0 commit comments