Citrix, Inc.
851 West Cypress Creek Road
Fort Lauderdale, FL 33309
United States of America
Disclaimers
This document is furnished "AS IS." Citrix, Inc. disclaims all warranties regarding the contents of this document,
including, but not limited to, implied warranties of merchantability and fitness for any particular purpose. This
document may contain technical or other inaccuracies or typographical errors. Citrix, Inc. reserves the right to
revise the information in this document at any time without notice. This document and the software described
in this document constitute confidential information of Citrix, Inc. and its licensors, and are furnished under a
license from Citrix, Inc.
Citrix Systems, Inc., the Citrix logo, Citrix XenServer and Citrix XenCenter, are trademarks of Citrix Systems, Inc.
and/or one or more of its subsidiaries, and may be registered in the United States Patent and Trademark Office
and in other countries. All other trademarks and registered trademarks are property of their respective owners.
B. Workload Balancing Service Commands ................................................... 186
Service Commands ......................................................................................................... 186
Logging in to the Workload Balancing Virtual Appliance ............................................ 186
service workloadbalancing restart ............................................................................ 186
service workloadbalancing start ............................................................................... 186
service workloadbalancing stop ............................................................................... 186
service workloadbalancing status ............................................................................. 186
xvii
Modifying the Workload Balancing configuration options .......................................... 187
Editing the Workload Balancing configuration file ..................................................... 187
Increasing the Detail in the Workload Balancing Log ................................................. 188
xviii
Document Overview
This document is a system administrator's guide for Citrix XenServer®, the complete server virtualization platform
from Citrix®. It contains procedures to guide you through configuring a XenServer deployment. In particular, it
focuses on setting up storage, networking and resource pools, and how to administer XenServer hosts using the
xe command line interface.
This document covers the following topics:
• Managing users with Active Directory and Role Based Access Controls
• Creating resource pools and setting up High Availability
• Configuring and managing storage repositories
• Configuring virtual machine memory using Dynamic Memory Control
• Setting control domain memory on a XenServer host
• Configuring networking
• Recovering virtual machines using Disaster Recovery and backing up data
• Monitoring and managing XenServer
• Troubleshooting XenServer
• Using the XenServer xe command line interface
Introducing XenServer
Citrix XenServer® is the complete server virtualization platform from Citrix®. The XenServer package contains
all you need to create and manage a deployment of virtual x86 computers running on Xen®, the open-source
paravirtualizing hypervisor with near-native performance. XenServer is optimized for both Windows and Linux
virtual servers.
XenServer runs directly on server hardware without requiring an underlying operating system, which results in
an efficient and scalable system. XenServer works by abstracting elements from the physical machine (such as
hard drives, resources and ports) and allocating them to the virtual machines running on it.
A virtual machine (VM) is a computer composed entirely of software that can run its own operating system and
applications as if it were a physical computer. A VM behaves exactly like a physical computer and contains its own
virtual (software-based) CPU, RAM, hard disk and network interface card (NIC).
XenServer lets you create VMs, take VM disk snapshots and manage VM workloads. For a comprehensive list of
major XenServer features and editions, visit www.citrix.com/xenserver.
• Reducing the number of separate disk images that need to be managed
• Allowing for easy integration with existing networking and storage infrastructures
Using XenServer increases flexibility by:
• Allowing you to schedule zero downtime maintenance by using XenMotion to live migrate VMs between
XenServer hosts
• Increasing availability of VMs by using High Availability to configure policies that restart VMs on another
XenServer host if one fails
1
• Increasing portability of VM images, as one VM image will work on a range of deployment infrastructures
Administering XenServer
There are two methods by which to administer XenServer: XenCenter and the XenServer Command-Line Interface
(CLI).
XenCenter is a graphical, Windows-based user interface. XenCenter allows you to manage XenServer hosts, pools
and shared storage, and to deploy, manage and monitor VMs from your Windows desktop machine.
The XenCenter Help is a great resource for getting started with XenCenter.
The XenServer Command-line Interface (CLI) allows you to administer XenServer using the Linux-based xe
commands.
For a comprehensive list of xe commands and descriptions, see the XenServer Administrator's Guide.
XenServer Editions
The features available in XenServer depend on the edition. The four editions of XenServer are:
• Citrix XenServer (Free): Proven virtualization platform that delivers uncompromised performance, scale, and
flexibility at no cost.
• Citrix XenServer Advanced Edition: Key high availability and advanced management tools that take virtual
infrastructure to the next level.
• Citrix XenServer Enterprise Edition: Essential integration and optimization capabilities for production
deployments of virtual machines.
• Citrix XenServer Platinum Edition: Advanced automation and cloud computing features for enterprise-wide
virtual environments.
For more information about how the XenServer edition affects the features available, visit www.citrix.com/
xenserver.
New Features in XenServer 6.0
XenServer 6.0 includes a number of new features and ongoing improvements, including:
Integrated Site Recovery (Disaster Recovery):
• Automated remote data replication between storage arrays with fast recovery and failback capabilities.
Integrated Site Recovery replaces StorageLink Gateway Site Recovery used in previous versions, removes the
Windows VM requirement, and works with any iSCSI or Hardware HBA storage repository.
Integrated StorageLink:
• Access to use existing storage array-based features such as data replication, de-duplication, snapshot and
cloning. Replaces the StorageLink Gateway technology used in previous editions and removes the requirement
to run a VM with the StorageLink components.
GPU Pass-Through:
• Enables a physical GPU to be assigned to a VM providing high-end graphics. Allows applications to leverage
GPU instructions in XenDesktop VDI deployments with HDX 3D Pro.
Virtual Appliance Support (vApp):
• Ability to create multi-VM and boot sequenced virtual appliances (vApps) that integrate with Integrated Site
Recovery and High Availability. vApps can be easily imported and exported using the Open Virtualization Format
(OVF) standard.
2
Rolling Pool Upgrade Wizard:
• Simplify upgrades (automated or semi-automated) to XenServer 6.0 with a wizard that performs pre-checks
with a step-by-step process that blocks unsupported upgrades.
Microsoft SCVMM and SCOM Support:
• Manage XenServer hosts and VMs with System Center Virtual Machine Manager (SCVMM) 2012. System Center
Operations Manager (SCOM) 2012 will also be able to manage and monitor XenServer hosts and VMs. System
Center integration is available with a special supplemental pack from Citrix. For more information refer to
Microsoft System Center Virtual Machine Manager 2012.
Distributed Virtual Switch Improvements:
• New fail safe mode allows Cross-Server Private Networks, ACLs, QoS, RSPAN and NetFlow settings to continue
to be applied to a running VM in the event of vSwitch Controller failure.
Increased Performance and Scale:
• Supported limits have been increased to 1 TB memory for XenServer hosts, and up to16 virtual processors and
128 GB virtual memory for VMs. Improved XenServer Tools with smaller footprint.
Networking Improvements:
• Open vSwitch is now the default networking stack in XenServer 6.0 and now provides formal support for ActiveBackup NIC bonding.
VM Import and Export Improvements:
• Full support for VM disk and OVF appliance imports directly from XenCenter with the ability to change VM
parameters (virtual processor, virtual memory, virtual interfaces, and target storage repository) with the Import
wizard. Full OVF import support for XenServer, XenConvert and VMware.
SR-IOV Improvements:
• Improved scalability and certification with the SR-IOV Test Kit. Experimental SR-IOV with XenMotion support
with Solarflare SR-IOV adapters.
Simplified Installer:
• Host installations only require a single ISO.
Enhanced Guest OS Support:
• Support for Ubuntu 10.04 (32/64-bit).
• Updated support for Debian Squeeze 6.0 64-bit, Oracle Enterprise Linux 6.0 (32/64-bit), and SLES 10 SP4 (32/64bit).
• Experimental VM templates for CentOS 6.0 (32/64-bit) Ubuntu 10.10 (32/64-bit) and Solaris 10.
Workload Balancing Improvements:
• New, ready-to-use Linux-based virtual appliance with a smaller footprint replaces the Windows-based virtual
appliance and eliminates the Windows licensing dependency.
XenDesktop Enhancements:
• HDX enhancements for optimized user experience with virtual desktops, GPU Pass-Through, and increased VM
and XenServer host limits.
3
VM Protection and Recovery:
• Now available for Advanced, Enterprise and Platinum Edition customers.
NFS Support for High Availability:
• HA Heartbeat disk can now reside on a NFS storage repository.
XenCenter Improvements:
• XenCenter operations now run in parallel, and XenCenter will be available in Japanese and Simplified Chinese
(ETA Q4 2011).
Host Architectural Improvements:
• XenServer 6.0 now runs on the Xen 4.1 hypervisor, provides GPT support and a smaller, more scalable Dom0.
XenServer Documentation
XenServer documentation shipped with this release includes:
• Release Notes cover known issues that affect this release.
• XenServer Quick Start Guide provides an introduction for new users to the XenServer environment and
components. This guide steps through the installation and configuration essentials to get XenServer and the
XenCenter management console up and running quickly. After installation, it demonstrates how to create a
Windows VM, VM template and pool of XenServer hosts. It introduces basic administrative tasks and advanced
features, such as shared storage, VM snapshots and XenMotion live migration.
• XenServer Installation Guide steps through the installation, configuration and initial operation of XenServer
and the XenCenter management console.
• XenServer Virtual Machine Installation Guide describes how to install Windows and Linux VMs within a
XenServer environment. This guide explains how to create new VMs from installation media, from VM
templates included in the XenServer package and from existing physical machines (P2V). It explains how to
import disk images and how to import and export appliances.
• XenServer Administrator's Guide gives an in-depth description of the tasks involved in configuring a XenServer
deployment, including setting up storage, networking and pools. It describes how to administer XenServer
using the xe Command Line Interface.
• vSwitch Controller User Guide is a comprehensive user guide to the vSwitch and Controller for XenServer.
• Supplemental Packs and the DDK introduces the XenServer Driver Development Kit, which can be used to
modify and extend the functionality of XenServer.
• XenServer Software Development Kit Guide presents an overview of the XenServer SDK. It includes code
samples that demonstrate how to write applications that interface with XenServer hosts.
• XenAPI Specification is a reference guide for programmers to the XenServer API.
For additional resources, visit the Citrix Knowledge Center.
4
Managing Users
Defining users, groups, roles and permissions allows you to control who has access to your XenServer hosts and
pools and what actions they can perform.
When you first install XenServer, a user account is added to XenServer automatically. This account is the local
super user (LSU), or root, which is authenticated locally by the XenServer computer.
The local super user (LSU), or root, is a special user account used for system administration and has all rights or
permissions. In XenServer, the local super user is the default account at installation. The LSU is authenticated
by XenServer and not an external authentication service. This means that if the external authentication service
fails, the LSU can still log in and manage the system. The LSU can always access the XenServer physical server
through SSH.
You can create additional users by adding their Active Directory accounts through either the XenCenter's Users
tab or the CLI. All editions of XenServer can add user accounts from Active Directory. However, only XenServer
Enterprise and Platinum editions let you assign these Active Directory accounts different levels of permissions
(through the Role Based Access Control (RBAC) feature). If you do not use Active Directory in your environment,
you are limited to the LSU account.
The permissions assigned to users when you first add their accounts varies according to your version of XenServer:
• In the XenServer and XenServer Advanced edition, when you create (add) new users, XenServer automatically
grants the accounts access to all features available in that version.
• In the XenServer Enterprise and Platinum editions, when you create new users, XenServer does not assign
newly created user accounts roles automatically. As a result, these accounts do not have any access to the
XenServer pool until you assign them a role.
If you do not have one of these editions, you can add users from Active Directory. However, all users will have
the Pool Administrator role.
These permissions are granted through roles, as discussed in the section called “Authenticating Users With Active
Directory (AD)”.
Authenticating Users With Active Directory (AD)
If you want to have multiple user accounts on a server or a pool, you must use Active Directory user accounts for
authentication. This lets XenServer users log in to a pool's XenServers using their Windows domain credentials.
The only way you can configure varying levels of access for specific users is by enabling Active Directory
authentication, adding user accounts, and assign roles to those accounts.
Active Directory users can use the xe CLI (passing appropriate -u and -pw arguments) and also connect to the
host using XenCenter. Authentication is done on a per-resource pool basis.
Access is controlled by the use of subjects. A subject in XenServer maps to an entity on your directory server
(either a user or a group). When external authentication is enabled, the credentials used to create a session are
first checked against the local root credentials (in case your directory server is unavailable) and then against the
subject list. To permit access, you must create a subject entry for the person or group you wish to grant access
to. This can be done using XenCenter or the xe CLI.
If you are familiar with XenCenter, note that the XenServer CLI uses slightly different terminology to refer to Active
Directory and user account features:
XenCenter TermXenServer CLI Term
UsersSubjects
Add usersAdd subjects
5
Understanding Active Directory Authentication in the XenServer Environment
Even though XenServers are Linux-based, XenServer lets you use Active Directory accounts for XenServer user
accounts. To do so, it passes Active Directory credentials to the Active Directory domain controller.
When added to XenServer, Active Directory users and groups become XenServer subjects, generally referred to
as simply users in XenCenter. When a subject is registered with XenServer, users/groups are authenticated with
Active Directory on login and do not need to qualify their user name with a domain name.
Note:
By default, if you did not qualify the user name (for example, enter either mydomain\myuser
or myser@mydomain.com), XenCenter always attempts to log users in to Active Directory
authentication servers using the domain to which it is currently joined. The exception to this
is the LSU account, which XenCenter always authenticates locally (that is, on the XenServer)
first.
The external authentication process works as follows:
1. The credentials supplied when connecting to a server are passed to the Active Directory domain controller
for authentication.
2. The domain controller checks the credentials. If they are invalid, the authentication fails immediately.
3. If the credentials are valid, the Active Directory controller is queried to get the subject identifier and group
membership associated with the credentials.
4. If the subject identifier matches the one stored in the XenServer, the authentication is completed successfully.
When you join a domain, you enable Active Directory authentication for the pool. However, when a pool is joined
to a domain, only users in that domain (or a domain with which it has trust relationships) can connect to the pool.
Note:
Manually updating the DNS configuration of a DHCP-configured network PIF is unsupported
and might cause Active Directory integration, and consequently user authentication, to fail
or stop working.
Upgrading XenServer
When you upgrade from an earlier version of XenServer, any user accounts created in the previous XenServer
version are assigned the role of pool-admin. This is done for backwards compatibility reasons. As a result, if you
are upgrading from a previous version of XenServer, make sure you revisit the role associated with each user
account to make sure it is still appropriate.
Configuring Active Directory Authentication
XenServer supports use of Active Directory servers using Windows 2003 or later.
Active Directory authentication for a XenServer host requires that the same DNS servers are used for both the
Active Directory server (configured to allow for interoperability) and the XenServer host. In some configurations,
the active directory server may provide the DNS itself. This can be achieved either using DHCP to provide the
IP address and a list of DNS servers to the XenServer host, or by setting values in the PIF objects or using the
installer if a manual static configuration is used.
Citrix recommends enabling DHCP to broadcast host names. In particular, the host names localhost or linux
should not be assigned to hosts.
Warning:
XenServer hostnames should be unique throughout the XenServer deployment.
6
Note the following:
• XenServer labels its AD entry on the AD database using its hostname. Therefore, if two XenServer hosts have
the same hostname and are joined to the same AD domain, the second XenServer will overwrite the AD entry
of the first XenServer, regardless of if they are in the same or in different pools, causing the AD authentication
on the first XenServer to stop working.
It is possible to use the same hostname in two XenServer hosts, as long as they join different AD domains.
• The XenServer hosts can be in different time-zones, as it is the UTC time that is compared. To ensure
synchronization is correct, you may choose to use the same NTP servers for your XenServer pool and the Active
Directory server.
• Mixed-authentication pools are not supported (that is, you cannot have a pool where some servers in the pool
are configured to use Active Directory and some are not).
• The XenServer Active Directory integration uses the Kerberos protocol to communicate with the Active
Directory servers. Consequently, XenServer does not support communicating with Active Directory servers that
do not utilize Kerberos.
• For external authentication using Active Directory to be successful, it is important that the clocks on your
XenServer hosts are synchronized with those on your Active Directory server. When XenServer joins the Active
Directory domain, this will be checked and authentication will fail if there is too much skew between the
servers.
Warning:
Host names must consist solely of no more than 63 alphanumeric characters, and must not
be purely numeric.
Once you have Active Directory authentication enabled, if you subsequently add a server to that pool, you are
prompted to configure Active Directory on the server joining the pool. When you are prompted for credentials
on the joining server, enter Active Directory credentials with sufficient privileges to add servers to that domain.
Active Directory integration
Make sure that the following firewall ports are open for outbound traffic in order for XenServer to access the
domain controllers.
PortProtocolUse
53UDP/TCPDNS
88UDP/TCPKerberos 5
123UDPNTP
137UDPNetBIOS Name Service
139TCPNetBIOS Session (SMB)
389UDP/TCPLDAP
445TCPSMB over TCP
464UDP/TCPMachine password changes
3268TCPGlobal Catalog Search
Note:
To view the firewall rules on a Linux computer using iptables, run the following command:
iptables - nL
7
Note:
XenServer uses Likewise (Likewise uses Kerberos) to authenticate the AD user in the AD server,
and to encrypt communications with the AD server.
How does XenServer manage the machine account password for AD integration?
Similarly to Windows client machines, Likewise automatically updates the machine account password, renewing
it once every 30 days, or as specified in the machine account password renewal policy in the AD server. For more
information, refer to http://support.microsoft.com/kb/154501.
Enabling external authentication on a pool
•External authentication using Active Directory can be configured using either XenCenter or the CLI using the
External authentication is a per-host property. However, Citrix advises that you enable and
disable this on a per-pool basis – in this case XenServer will deal with any failures that occur
when enabling authentication on a particular host and perform any roll-back of changes that
may be required, ensuring that a consistent configuration is used across the pool. Use the
host-param-list command to inspect properties of a host and to determine the status of
external authentication by checking the values of the relevant fields.
Disabling external authentication
•Use XenCenter to disable Active Directory authentication, or the following xe command:
xe pool-disable-external-auth
User Authentication
To allow a user access to your XenServer host, you must add a subject for that user or a group that they are in.
(Transitive group memberships are also checked in the normal way, for example: adding a subject for group A,
where group A contains group B and user 1 is a member of group B would permit access to user 1.) If
8
you wish to manage user permissions in Active Directory, you could create a single group that you then add and
remove users to/from; alternatively, you can add and remove individual users from XenServer, or a combination
of users and groups as your would be appropriate for your authentication requirements. The subject list can be
managed from XenCenter or using the CLI as described below.
When authenticating a user, the credentials are first checked against the local root account, allowing you to
recover a system whose AD server has failed. If the credentials (i.e. username then password) do not match/
authenticate, then an authentication request is made to the AD server – if this is successful the user's information
will be retrieved and validated against the local subject list, otherwise access will be denied. Validation against the
subject list will succeed if the user or a group in the transitive group membership of the user is in the subject list.
Note:
When using Active Directory groups to grant access for Pool Administrator users who will
require host ssh access, the number of users in the Active Directory group must not exceed
500.
Allowing a user access to XenServer using the CLI
•To add an AD subject to XenServer:
xe subject-add subject-name=<entity name>
The entity name should be the name of the user or group to which you want to grant access. You may
optionally include the domain of the entity (for example, '<xendt\user1>' as opposed to '<user1>') although
the behavior will be the same unless disambiguation is required.
Removing access for a user using the CLI
1.Identify the subject identifier for the subject t you wish to revoke access. This would be the user or the group
containing the user (removing a group would remove access to all users in that group, providing they are
not also specified in the subject list). You can do this using the subject list command:
xe subject-list
You may wish to apply a filter to the list, for example to get the subject identifier for a user named user1
in the testad domain, you could use the following command:
2.Remove the user using the subject-remove command, passing in the subject identifier you learned in the
previous step:
xe subject-remove subject-uuid=<subject-uuid>
3.You may wish to terminate any current session this user has already authenticated. See Terminating all
authenticated sessions using xe and Terminating individual user sessions using xe for more information about
terminating sessions. If you do not terminate sessions the users whose permissions have been revoked may
be able to continue to access the system until they log out.
Listing subjects with access
•To identify the list of users and groups with permission to access your XenServer host or pool, use the
following command:
xe subject-list
Removing Access for a User
Once a user is authenticated, they will have access to the server until they end their session, or another user
terminates their session. Removing a user from the subject list, or removing them from a group that is in the
subject list, will not automatically revoke any already-authenticated sessions that the user has; this means that
9
they may be able to continue to access the pool using XenCenter or other API sessions that they have already
created. In order to terminate these sessions forcefully, XenCenter and the CLI provide facilities to terminate
individual sessions, or all currently active sessions. See the XenCenter help for more information on procedures
using XenCenter, or below for procedures using the CLI.
Terminating all authenticated sessions using xe
•Execute the following CLI command:
xe session-subject-identifier-logout-all
Terminating individual user sessions using xe
1.Determine the subject identifier whose session you wish to log out. Use either the session-subjectidentifier-list or subject-list xe commands to find this (the first shows users who have sessions, the secondshows all users but can be filtered, for example, using a command like xe subject-list other-config:subjectname=xendt\\user1 – depending on your shell you may need a double-backslash as shown).
2.Use the session-subject-logout command, passing the subject identifier you have determined in the
previous step as a parameter, for example:
When you leave the domain (that is, disable Active Directory authentication and disconnect
a pool or server from its domain), any users who authenticated to the pool or server with
Active Directory credentials are disconnected.
Use XenCenter to leave an AD domain. See the XenCenter help for more information. Alternately run the pool-
disable-external-auth command, specifying the pool uuid if required.
Note:
Leaving the domain will not cause the host objects to be removed from the AD database. See
this knowledge base article for more information about this and how to remove the disabled
host entries.
Role Based Access Control
Note:
The full RBAC feature is only available in Citrix XenServer Enterprise Edition or higher. To
learn more about upgrading XenServer, click here.
XenServer's Role Based Access Control (RBAC) allows you to assign users, roles, and permissions to control who
has access to your XenServer and what actions they can perform. The XenServer RBAC system maps a user
(or a group of users) to defined roles (a named set of permissions), which in turn have associated XenServer
permissions (the ability to perform certain operations).
As users are not assigned permissions directly, but acquire them through their assigned role, management of
individual user permissions becomes a matter of simply assigning the user to the appropriate role; this simplifies
common operations. XenServer maintains a list of authorized users and their roles.
RBAC allows you to easily restrict which operations different groups of users can perform- thus reducing the
probability of an accident by an inexperienced user.
To facilitate compliance and auditing, RBAC also provides an Audit Log feature and its corresponding Workload
Balancing Pool Audit Trail report.
10
RBAC depends on Active Directory for authentication services. Specifically, XenServer keeps a list of authorized
users based on Active Directory user and group accounts. As a result, you must join the pool to the domain and
add Active Directory accounts before you can assign roles.
The local super user (LSU), or root, is a special user account used for system administration and has all rights or
permissions. In XenServer, the local super user is the default account at installation. The LSU is authenticated via
XenServer and not external authentication service, so if the external authentication service fails, the LSU can still
log in and manage the system. The LSU can always access the XenServer physical host via SSH.
RBAC process
This is the standard process for implementing RBAC and assigning a user or group a role:
1. Join the domain. See Enabling external authentication on a pool
2. Add an Active Directory user or group to the pool. This becomes a subject. See the section called “To Add a
Subject to RBAC”.
3. Assign (or modify) the subject's RBAC role. See the section called “To Assign an RBAC Role to a Created subject”.
Roles
XenServer is shipped with the following six, pre-established roles:
• Pool Administrator (Pool Admin) – the same as being the local root. Can perform all operations.
Note:
The local super user (root) will always have the "Pool Admin" role. The Pool Admin role has
the same permissions as the local root.
• Pool Operator (Pool Operator) – can do everything apart from adding/removing users and modifying their
roles. This role is focused mainly on host and pool management (i.e. creating storage, making pools, managing
the hosts etc.)
• Virtual Machine Power Administrator (VM Power Admin) – creates and manages Virtual Machines. This role is
focused on provisioning VMs for use by a VM operator.
• Virtual Machine Administrator (VM Admin) – similar to a VM Power Admin, but cannot migrate VMs or perform
snapshots.
• Virtual Machine Operator (VM Operator) – similar to VM Admin, but cannot create/destroy VMs – but can
perform start/stop lifecycle operations.
• Read-only (Read Only) – can view resource pool and performance data.
11
Note:
You cannot add, remove or modify roles in this version of XenServer.
Warning:
You can not assign the role of pool-admin to an AD group which has more than 500 members,
if you want users of the AD group to have SSH access.
For a summary of the permissions available for each role and more detailed information on the operations
available for each permission, see the section called “Definitions of RBAC Roles and Permissions”.
All XenServer users need to be allocated to an appropriate role. By default, all new users will be allocated to the
Pool Administrator role. It is possible for a user to be assigned to multiple roles; in that scenario, the user will
have the union of all the permissions of all their assigned roles.
A user's role can be changed in two ways:
1. Modify the subject -> role mapping (this requires the assign/modify role permission, only available to a Pool
Administrator.)
2. Modify the user's containing group membership in Active Directory.
Definitions of RBAC Roles and Permissions
The following table summarizes which permissions are available for each role. For details on the operations
available for each permission, see Definitions of permissions.
Table 1. Permissions available for each role
Role
permissions
Assign/
modify roles
Log in to
(physical)
server
consoles
(through SSH
and
XenCenter)
Server
backup/
restore
Import/
export OVF/
OVA
packages and
disk images
Pool AdminPool
Operator
X
X
X
X
VM Power
Admin
VM AdminVM OperatorRead Only
Log out
active user
connections
Create and
dismiss alerts
XX
XX
12
Loading...
+ 177 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.