pveum.adoc

   1 [[chapter_user_management]]
   2 ifdef::manvolnum[]
   3 pveum(1)
   4 ========
   5 :pve-toplevel:
   6
   7 NAME
   8 ----
   9
  10 pveum - Proxmox VE User Manager
  11
  12
  13 SYNOPSIS
  14 --------
  15
  16 include::pveum.1-synopsis.adoc[]
  17
  18
  19 DESCRIPTION
  20 -----------
  21 endif::manvolnum[]
  22 ifndef::manvolnum[]
  23 User Management
  24 ===============
  25 :pve-toplevel:
  26 endif::manvolnum[]
  27
  28 // Copied from pve wiki: Revision as of 16:10, 27 October 2015
  29
  30 Proxmox VE supports multiple authentication sources, e.g. Linux PAM,
  31 an integrated Proxmox VE authentication server, LDAP, Microsoft Active
  32 Directory.
  33
  34 By using the role based user- and permission management for all
  35 objects (VMs, storages, nodes, etc.) granular access can be defined.
  36
  37
  38 [[pveum_users]]
  39 Users
  40 -----
  41
  42 {pve} stores user attributes in `/etc/pve/user.cfg`.
  43 Passwords are not stored here, users are instead associated with
  44 <<pveum_authentication_realms,authentication realms>> described below.
  45 Therefore a user is internally often identified by its name and
  46 realm in the form `<userid>@<realm>`.
  47
  48 Each user entry in this file contains the following information:
  49
  50 * First name
  51 * Last name
  52 * E-mail address
  53 * Group memberships
  54 * An optional Expiration date
  55 * A comment or note about this user
  56 * Whether this user is enabled or disabled
  57 * Optional two-factor authentication keys
  58
  59
  60 System administrator
  61 ~~~~~~~~~~~~~~~~~~~~
  62
  63 The system's root user can always log in via the Linux PAM realm and is an
  64 unconfined administrator. This user cannot be deleted, but attributes can
  65 still be changed and system mails will be sent to the email address
  66 assigned to this user.
  67
  68
  69 [[pveum_groups]]
  70 Groups
  71 ~~~~~~
  72
  73 Each user can be member of several groups. Groups are the preferred
  74 way to organize access permissions. You should always grant permission
  75 to groups instead of using individual users. That way you will get a
  76 much shorter access control list which is easier to handle.
  77
  78
  79 [[pveum_authentication_realms]]
  80 Authentication Realms
  81 ---------------------
  82
  83 As {pve} users are just counterparts for users existing on some external
  84 realm, the realms have to be configured in `/etc/pve/domains.cfg`.
  85 The following realms (authentication methods) are available:
  86
  87 Linux PAM standard authentication::
  88 In this case a system user has to exist (e.g. created via the `adduser`
  89 command) on all nodes the user is allowed to login, and the user
  90 authenticates with their usual system password.
  91 +
  92 [source,bash]
  93 ----
  94 useradd heinz
  95 passwd heinz
  96 groupadd watchman
  97 usermod -a -G watchman heinz
  98 ----
  99
 100 Proxmox VE authentication server::
 101 This is a unix like password store (`/etc/pve/priv/shadow.cfg`).
 102 Password are encrypted using the SHA-256 hash method.
 103 This is the most convenient method for small (or even medium)
 104 installations where users do not need access to anything outside of
 105 {pve}. In this case users are fully managed by {pve} and are able to
 106 change their own passwords via the GUI.
 107
 108 LDAP::
 109 It is possible to authenticate users via an LDAP server (e.g.
 110 openldap). The server and an optional fallback server can be
 111 configured and the connection can be encrypted via SSL.
 112 +
 113 Users are searched under a 'Base Domain Name' (`base_dn`), with the
 114 user name found in the attribute specified in the 'User Attribute Name'
 115 (`user_attr`) field.
 116 +
 117 For instance, if a user is represented via the
 118 following ldif dataset:
 119 +
 120 ----
 121 # user1 of People at ldap-test.com
 122 dn: uid=user1,ou=People,dc=ldap-test,dc=com
 123 objectClass: top
 124 objectClass: person
 125 objectClass: organizationalPerson
 126 objectClass: inetOrgPerson
 127 uid: user1
 128 cn: Test User 1
 129 sn: Testers
 130 description: This is the first test user.
 131 ----
 132 +
 133 The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
 134 attribute would be `uid`.
 135 +
 136 If {pve} needs to authenticate (bind) to the ldap server before being
 137 able to query and authenticate users, a bind domain name can be
 138 configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
 139 password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
 140 (e.g. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a
 141 single line containing the raw password.
 142
 143 Microsoft Active Directory::
 144
 145 A server and authentication domain need to be specified. Like with
 146 ldap an optional fallback server, optional port, and SSL
 147 encryption can be configured.
 148
 149
 150 [[pveum_tfa_auth]]
 151 Two-factor authentication
 152 -------------------------
 153
 154 There are two ways to use two-factor authentication:
 155
 156 It can be required by the authentication realm, either via 'TOTP'
 157 (Time-based One-Time Password) or 'YubiKey OTP'. In this case a newly
 158 created user needs their keys added immediately as there is no way to
 159 log in without the second factor. In the case of 'TOTP', users can
 160 also change the 'TOTP' later on, provided they can log in first.
 161
 162 Alternatively, users can choose to opt in to two-factor authentication
 163 via 'TOTP' later on, even if the realm does not enforce it. As another
 164 option, if the server has an 'AppId' configured, a user can opt into
 165 'U2F' authentication, provided the realm does not enforce any other
 166 second factor.
 167
 168 Realm enforced two-factor authentication
 169 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 170
 171 This can be done by selecting one of the available methods via the
 172 'TFA' dropdown box when adding or editing an Authentication Realm.
 173 When a realm has TFA enabled it becomes a requirement and only users
 174 with configured TFA will be able to login.
 175
 176 Currently there are two methods available:
 177
 178 Time-based OATH (TOTP):: This uses the standard HMAC-SHA1 algorithm
 179 where the current time is hashed with the user's configured key. The
 180 time step and password length parameters are configured.
 181 +
 182 A user can have multiple keys configured (separated by spaces), and the keys
 183 can be specified in Base32 (RFC3548) or hexadecimal notation.
 184 +
 185 {pve} provides a key generation tool (`oathkeygen`) which prints out a random
 186 key in Base32 notation which can be used directly with various OTP tools, such
 187 as the `oathtool` command line tool, or on Android Google Authenticator,
 188 FreeOTP, andOTP or similar applications.
 189
 190 YubiKey OTP::
 191 For authenticating via a YubiKey a Yubico API ID, API KEY and validation
 192 server URL must be configured, and users must have a YubiKey available. In
 193 order to get the key ID from a YubiKey, you can trigger the YubiKey once
 194 after connecting it to USB and copy the first 12 characters of the typed
 195 password into the user's 'Key IDs' field.
 196
 197 +
 198 Please refer to the https://developers.yubico.com/OTP/[YubiKey OTP]
 199 documentation for how to use the
 200 https://www.yubico.com/products/services-software/yubicloud/[YubiCloud] or
 201 https://developers.yubico.com/Software_Projects/YubiKey_OTP/YubiCloud_Validation_Servers/[host
 202 your own verification server].
 203
 204 [[pveum_user_configured_totp]]
 205 User configured TOTP authentication
 206 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 207
 208 Users can choose to enable 'TOTP' as a second factor on login via the 'TFA'
 209 button in the user list (unless the realm enforces 'YubiKey OTP').
 210
 211 [thumbnail="screenshot/gui-datacenter-users-tfa.png"]
 212
 213 After opening the 'TFA' window, the user is presented with a dialog to setup
 214 'TOTP' authentication. The 'Secret' field contains the key, which can simply be
 215 generated randomly via the 'Randomize' button. An optional 'Issuer Name' can be
 216 added to provide information to the 'TOTP' app what the key belongs to.
 217 Most 'TOTP' apps will show the issuer name together with the corresponding
 218 'OTP' values. The user name is also included in the QR code for the 'TOTP' app.
 219
 220 After generating a key, a QR code will be displayed which can be used with most
 221 OTP apps such as FreeOTP. Now the user needs to verify both the current user
 222 password (unless logged in as 'root'), as well as the ability to correctly use
 223 the 'TOTP' key by typing the current 'OTP' value into the 'Verification Code'
 224 field before pressing the 'Apply' button.
 225
 226 [[pveum_configure_u2f]]
 227 Server side U2F configuration
 228 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 229
 230 To allow users to use 'U2F' authentication, the server needs to have a valid
 231 domain with a valid https certificate. Initially an 'AppId'
 232 footnote:[AppId https://developers.yubico.com/U2F/App_ID.html]
 233 needs to be configured.
 234
 235 NOTE: Changing the 'AppId' will render all existing 'U2F' registrations
 236 unusable!
 237
 238 This is done via `/etc/pve/datacenter.cfg`, for instance:
 239
 240 ----
 241 u2f: appid=https://mypve.example.com:8006
 242 ----
 243
 244 For a single node, the 'AppId' can simply be the web UI address exactly as it
 245 is used in the browser, including the 'https://' and the port as shown above.
 246 Please note that some browsers may be more strict than others when matching
 247 'AppIds'.
 248
 249 When using multiple nodes, it is best to have a separate `https` server
 250 providing an `appid.json`
 251 footnote:[Multi-facet apps: https://developers.yubico.com/U2F/App_ID.html]
 252 file, as it seems to be compatible with most
 253 browsers. If all nodes use subdomains of the same top level domain, it may be
 254 enough to use the TLD as 'AppId', but note that some browsers may not accept
 255 this.
 256
 257 NOTE: A bad 'AppId' will usually produce an error, but we have encountered
 258 situation where this does not happen, particularly when using a top level domain
 259 'AppId' for a node accessed via a subdomain in Chromium. For this reason it is
 260 recommended to test the configuration with multiple browsers, as changing the
 261 'AppId' later will render existing 'U2F' registrations unusable.
 262
 263 [[pveum_user_configured_u2f]]
 264 Activating U2F as a user
 265 ~~~~~~~~~~~~~~~~~~~~~~~~
 266
 267 To enable 'U2F' authentication, open the 'TFA' window's 'U2F' tab, type in the
 268 current password (unless logged in as root), and press the 'Register' button.
 269 If the server is setup correctly and the browser accepted the server's provided
 270 'AppId', a message will appear prompting the user to press the button on the
 271 'U2F' device (if it is a 'YubiKey' the button light should be toggling off and
 272 on steadily around twice per second).
 273
 274 Firefox users may need to enable 'security.webauth.u2f' via 'about:config'
 275 before they can use a 'U2F' token.
 276
 277 [[pveum_permission_management]]
 278 Permission Management
 279 ---------------------
 280
 281 In order for a user to perform an action (such as listing, modifying or
 282 deleting a parts of a VM configuration), the user needs to have the
 283 appropriate permissions.
 284
 285 {pve} uses a role and path based permission management system. An entry in
 286 the permissions table allows a user or group to take on a specific role
 287 when accessing an 'object' or 'path'. This means an such an access rule can
 288 be represented as a triple of '(path, user, role)' or '(path, group,
 289 role)', with the role containing a set of allowed actions, and the path
 290 representing the target of these actions.
 291
 292
 293 [[pveum_roles]]
 294 Roles
 295 ~~~~~
 296
 297 A role is simply a list of privileges. Proxmox VE comes with a number
 298 of predefined roles which satisfies most needs.
 299
 300 * `Administrator`: has all privileges
 301 * `NoAccess`: has no privileges (used to forbid access)
 302 * `PVEAdmin`: can do most things, but miss rights to modify system settings (`Sys.PowerMgmt`, `Sys.Modify`, `Realm.Allocate`).
 303 * `PVEAuditor`: read only access
 304 * `PVEDatastoreAdmin`: create and allocate backup space and templates
 305 * `PVEDatastoreUser`: allocate backup space and view storage
 306 * `PVEPoolAdmin`: allocate pools
 307 * `PVESysAdmin`: User ACLs, audit, system console and system logs
 308 * `PVETemplateUser`: view and clone templates
 309 * `PVEUserAdmin`: user administration
 310 * `PVEVMAdmin`: fully administer VMs
 311 * `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
 312
 313 You can see the whole set of predefined roles on the GUI.
 314
 315 Adding new roles can be done via both GUI and the command line.
 316
 317 [thumbnail="screenshot/gui-datacenter-role-add.png"]
 318 For the GUI just navigate to 'Permissions -> User' Tab from 'Datacenter' and
 319 click on the 'Create' button, there you can set a name and select all desired
 320 roles from the 'Privileges' dropdown box.
 321
 322 To add a role through the command line you can use the 'pveum' CLI tool, like
 323 this:
 324 [source,bash]
 325 ----
 326 pveum roleadd PVE_Power-only -privs "VM.PowerMgmt VM.Console"
 327 pveum roleadd Sys_Power-only -privs "Sys.PowerMgmt Sys.Console"
 328 ----
 329
 330
 331 Privileges
 332 ~~~~~~~~~~
 333
 334 A privilege is the right to perform a specific action. To simplify
 335 management, lists of privileges are grouped into roles, which can then
 336 be used in the permission table. Note that privileges cannot directly be
 337 assigned to users and paths without being part of a role.
 338
 339 We currently use the following privileges:
 340
 341 Node / System related privileges::
 342
 343 * `Permissions.Modify`: modify access permissions
 344 * `Sys.PowerMgmt`: Node power management (start, stop, reset, shutdown, ...)
 345 * `Sys.Console`: console access to Node
 346 * `Sys.Syslog`: view Syslog
 347 * `Sys.Audit`: view node status/config, Corosync cluster config and HA config
 348 * `Sys.Modify`: create/remove/modify node network parameters
 349 * `Group.Allocate`: create/remove/modify groups
 350 * `Pool.Allocate`: create/remove/modify a pool
 351 * `Realm.Allocate`: create/remove/modify authentication realms
 352 * `Realm.AllocateUser`: assign user to a realm
 353 * `User.Modify`: create/remove/modify user access and details.
 354
 355 Virtual machine related privileges::
 356
 357 * `VM.Allocate`: create/remove new VM to server inventory
 358 * `VM.Migrate`: migrate VM to alternate server on cluster
 359 * `VM.PowerMgmt`: power management (start, stop, reset, shutdown, ...)
 360 * `VM.Console`: console access to VM
 361 * `VM.Monitor`: access to VM monitor (kvm)
 362 * `VM.Backup`: backup/restore VMs
 363 * `VM.Audit`: view VM config
 364 * `VM.Clone`: clone/copy a VM
 365 * `VM.Config.Disk`: add/modify/delete Disks
 366 * `VM.Config.CDROM`: eject/change CDROM
 367 * `VM.Config.CPU`: modify CPU settings
 368 * `VM.Config.Memory`: modify Memory settings
 369 * `VM.Config.Network`: add/modify/delete Network devices
 370 * `VM.Config.HWType`: modify emulated HW type
 371 * `VM.Config.Options`: modify any other VM configuration
 372 * `VM.Snapshot`: create/remove VM snapshots
 373
 374 Storage related privileges::
 375
 376 * `Datastore.Allocate`: create/remove/modify a data store, delete volumes
 377 * `Datastore.AllocateSpace`: allocate space on a datastore
 378 * `Datastore.AllocateTemplate`: allocate/upload templates and iso images
 379 * `Datastore.Audit`: view/browse a datastore
 380
 381
 382 Objects and Paths
 383 ~~~~~~~~~~~~~~~~~
 384
 385 Access permissions are assigned to objects, such as a virtual machines,
 386 storages or pools of resources.
 387 We use file system like paths to address these objects. These paths form a
 388 natural tree, and permissions of higher levels (shorter path) can
 389 optionally be propagated down within this hierarchy.
 390
 391 [[pveum_templated_paths]]
 392 Paths can be templated. When an API call requires permissions on a
 393 templated path, the path may contain references to parameters of the API
 394 call. These references are specified in curly braces. Some parameters are
 395 implicitly taken from the API call's URI. For instance the permission path
 396 `/nodes/{node}` when calling '/nodes/mynode/status' requires permissions on
 397 `/nodes/mynode`, while the path `{path}` in a PUT request to `/access/acl`
 398 refers to the method's `path` parameter.
 399
 400 Some examples are:
 401
 402 * `/nodes/{node}`: Access to {pve} server machines
 403 * `/vms`: Covers all VMs
 404 * `/vms/{vmid}`: Access to specific VMs
 405 * `/storage/{storeid}`: Access to a storages
 406 * `/pool/{poolname}`: Access to VMs part of a <<pveum_pools,pool>>
 407 * `/access/groups`: Group administration
 408 * `/access/realms/{realmid}`: Administrative access to realms
 409
 410
 411 Inheritance
 412 ^^^^^^^^^^^
 413
 414 As mentioned earlier, object paths form a file system like tree, and
 415 permissions can be inherited down that tree (the propagate flag is set
 416 by default). We use the following inheritance rules:
 417
 418 * Permissions for individual users always replace group permissions.
 419 * Permissions for groups apply when the user is member of that group.
 420 * Permissions replace the ones inherited from an upper level.
 421
 422
 423 [[pveum_pools]]
 424 Pools
 425 ~~~~~
 426
 427 Pools can be used to group a set of virtual machines and data
 428 stores. You can then simply set permissions on pools (`/pool/{poolid}`),
 429 which are inherited to all pool members. This is a great way simplify
 430 access control.
 431
 432
 433 What permission do I need?
 434 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 435
 436 The required API permissions are documented for each individual
 437 method, and can be found at http://pve.proxmox.com/pve-docs/api-viewer/
 438
 439 The permissions are specified as a list which can be interpreted as a
 440 tree of logic and access-check functions:
 441
 442 `["and", <subtests>...]` and `["or", <subtests>...]`::
 443 Each(`and`) or any(`or`) further element in the current list has to be true.
 444
 445 `["perm", <path>, [ <privileges>... ], <options>...]`::
 446 The `path` is a templated parameter (see
 447 <<pveum_templated_paths,Objects and Paths>>). All (or, if the `any`
 448 option is used, any) of the listed
 449 privileges must be allowed on the specified path. If a `require-param`
 450 option is specified, then its specified parameter is required even if the
 451 API call's schema otherwise lists it as being optional.
 452
 453 `["userid-group", [ <privileges>... ], <options>...]`::
 454 The caller must have any of the listed privileges on `/access/groups`. In
 455 addition there are two possible checks depending on whether the
 456 `groups_param` option is set:
 457 +
 458 * `groups_param` is set: The API call has a non-optional `groups` parameter
 459 and the caller must have any of the listed privileges on all of the listed
 460 groups.
 461 * `groups_param` is not set: The user passed via the `userid` parameter
 462 must exist and be part of a group on which the caller has any of the listed
 463 privileges (via the `/access/groups/<group>` path).
 464
 465 `["userid-param", "self"]`::
 466 The value provided for the API call's `userid` parameter must refer to the
 467 user performing the action. (Usually in conjunction with `or`, to allow
 468 users to perform an action on themselves even if they don't have elevated
 469 privileges.)
 470
 471 `["userid-param", "Realm.AllocateUser"]`::
 472 The user needs `Realm.AllocateUser` access to `/access/realm/<realm>`, with
 473 `<realm>` referring to the realm of the user passed via the `userid`
 474 parameter. Note that the user does not need to exist in order to be
 475 associated with a realm, since user IDs are passed in the form of
 476 `<username>@<realm>`.
 477
 478 `["perm-modify", <path>]`::
 479 The `path` is a templated parameter (see
 480 <<pveum_templated_paths,Objects and Paths>>). The user needs either the
 481 `Permissions.Modify` privilege, or,
 482 depending on the path, the following privileges as a possible substitute:
 483 +
 484 * `/storage/...`: additionally requires 'Datastore.Allocate`
 485 * `/vms/...`: additionally requires 'VM.Allocate`
 486 * `/pool/...`: additionally requires 'Pool.Allocate`
 487 +
 488 If the path is empty, `Permission.Modify` on `/access` is required.
 489
 490 Command Line Tool
 491 -----------------
 492
 493 Most users will simply use the GUI to manage users. But there is also
 494 a fully featured command line tool called `pveum` (short for ``**P**roxmox
 495 **VE** **U**ser **M**anager''). Please note that all Proxmox VE command
 496 line tools are wrappers around the API, so you can also access those
 497 functions through the REST API.
 498
 499 Here are some simple usage examples. To show help type:
 500
 501 [source,bash]
 502  pveum
 503
 504 or (to show detailed help about a specific command)
 505
 506 [source,bash]
 507  pveum help useradd
 508
 509 Create a new user:
 510
 511 [source,bash]
 512  pveum useradd testuser@pve -comment "Just a test"
 513
 514 Set or Change the password (not all realms support that):
 515
 516 [source,bash]
 517  pveum passwd testuser@pve
 518
 519 Disable a user:
 520
 521 [source,bash]
 522  pveum usermod testuser@pve -enable 0
 523
 524 Create a new group:
 525
 526 [source,bash]
 527  pveum groupadd testgroup
 528
 529 Create a new role:
 530
 531 [source,bash]
 532  pveum roleadd PVE_Power-only -privs "VM.PowerMgmt VM.Console"
 533
 534
 535 Real World Examples
 536 -------------------
 537
 538
 539 Administrator Group
 540 ~~~~~~~~~~~~~~~~~~~
 541
 542 One of the most wanted features was the ability to define a group of
 543 users with full administrator rights (without using the root account).
 544
 545 Define the group:
 546
 547 [source,bash]
 548  pveum groupadd admin -comment "System Administrators"
 549
 550 Then add the permission:
 551
 552 [source,bash]
 553  pveum aclmod / -group admin -role Administrator
 554
 555 You can finally add users to the new 'admin' group:
 556
 557 [source,bash]
 558  pveum usermod testuser@pve -group admin
 559
 560
 561 Auditors
 562 ~~~~~~~~
 563
 564 You can give read only access to users by assigning the `PVEAuditor`
 565 role to users or groups.
 566
 567 Example1: Allow user `joe@pve` to see everything
 568
 569 [source,bash]
 570  pveum aclmod / -user joe@pve -role PVEAuditor
 571
 572 Example1: Allow user `joe@pve` to see all virtual machines
 573
 574 [source,bash]
 575  pveum aclmod /vms -user joe@pve -role PVEAuditor
 576
 577
 578 Delegate User Management
 579 ~~~~~~~~~~~~~~~~~~~~~~~~
 580
 581 If you want to delegate user management to user `joe@pve` you can do
 582 that with:
 583
 584 [source,bash]
 585  pveum aclmod /access -user joe@pve -role PVEUserAdmin
 586
 587 User `joe@pve` can now add and remove users, change passwords and
 588 other user attributes. This is a very powerful role, and you most
 589 likely want to limit that to selected realms and groups. The following
 590 example allows `joe@pve` to modify users within realm `pve` if they
 591 are members of group `customers`:
 592
 593 [source,bash]
 594  pveum aclmod /access/realm/pve -user joe@pve -role PVEUserAdmin
 595  pveum aclmod /access/groups/customers -user joe@pve -role PVEUserAdmin
 596
 597 NOTE: The user is able to add other users, but only if they are
 598 members of group `customers` and within realm `pve`.
 599
 600
 601 Pools
 602 ~~~~~
 603
 604 An enterprise is usually structured into several smaller departments,
 605 and it is common that you want to assign resources to them and
 606 delegate management tasks. A pool is simply a set of virtual machines
 607 and data stores. You can create pools on the GUI. After that you can
 608 add resources to the pool (VMs, Storage).
 609
 610 You can also assign permissions to the pool. Those permissions are
 611 inherited to all pool members.
 612
 613 Lets assume you have a software development department, so we first
 614 create a group
 615
 616 [source,bash]
 617  pveum groupadd developers -comment "Our software developers"
 618
 619 Now we create a new user which is a member of that group
 620
 621 [source,bash]
 622  pveum useradd developer1@pve -group developers -password
 623
 624 NOTE: The -password parameter will prompt you for a password
 625
 626 I assume we already created a pool called ``dev-pool'' on the GUI. So we can now assign permission to that pool:
 627
 628 [source,bash]
 629  pveum aclmod /pool/dev-pool/ -group developers -role PVEAdmin
 630
 631 Our software developers can now administrate the resources assigned to
 632 that pool.
 633
 634
 635 ifdef::manvolnum[]
 636 include::pve-copyright.adoc[]
 637 endif::manvolnum[]
 638