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. in the United States and other countries. All other products or services mentioned in this document are
trademarks or registered trademarks of their respective companies.
Index .......................................................................................................... 214
xx
Document Overview
This document is a system administrator's guide to XenServer™, the platform virtualization solution from
Citrix®. It describes the tasks involved in configuring a XenServer deployment-- in particular, how to set up
storage, networking and resource pools, and how to administer XenServer hosts using the xe command
line interface (CLI).
This section summarizes the rest of the guide so that you can find the information you need. The following
topics are covered:
• XenServer hosts and resource pools
• XenServer storage configuration
• XenServer network configuration
• XenServer workload balancing
• XenServer backup and recovery
• Monitoring and managing XenServer
• XenServer command line interface
• XenServer troubleshooting
• XenServer resource allocation guidelines
How this Guide relates to other documentation
This document is primarily aimed at system administrators, who need to configure and administer XenServer
deployments. Other documentation shipped with this release includes:
• XenServer Installation Guide provides a high level overview of XenServer, along with step-by-step
instructions on installing XenServer hosts and the XenCenter management console.
• XenServer Virtual Machine Installation Guide describes how to install Linux and Windows VMs on top of
a XenServer deployment. As well as installing new VMs from install media (or using the VM templates
provided with the XenServer release), this guide also explains how to create VMs from existing physical
machines, using a process called P2V.
• XenServer Software Development Kit Guide presents an overview of the XenServer SDK- a selection of
code samples that demonstrate how to write applications that interface with XenServer hosts.
• XenAPI Specification provides a programmer's reference guide to the XenServer API.
• XenServer User Security considers the issues involved in keeping your XenServer installation secure.
• Release Notes provides a list of known issues that affect this release.
1
Managing users
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 using
Active Directory (AD)”.
Authenticating users using 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:
2
XenCenter TermXenServer CLI Term
UsersSubjects
Add usersAdd subjects
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 from XenServer 5.5
When you upgrade from XenServer 5.5 to the current release, any user accounts created in XenServer 5.5
are assigned the role of pool-admin. This is done for backwards compatibility reasons: in XenServer 5.5, all
users had full permissions to perform any task on the pool.
As a result, if you are upgrading from XenServer 5.5, 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
3
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.
Note the following:
• XenServer hostnames should be unique throughout the XenServer deployment. 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 servers 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.
Enabling external authentication on a pool
•External authentication using Active Directory can be configured using either XenCenter or the CLI
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 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 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:
5
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:
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 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-subject-
identifier-list or subject-list xe commands to find this (the first shows users who have sessions, thesecond shows all users but can be filtered, for example, using a command like xe subject-list otherconfig:subject-name=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
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.
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.
7
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.
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.
8
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
Log out
active user
connections
Create and
dismiss
alerts
Pool AdminPool
Operator
X
X
X
XX
XX
VM Power
Admin
VM AdminVM
Operator
Read Only
Cancel task
of any user
Pool
management
VM
advanced
operations
VM create/
destroy
operations
XX
XX
XXX
XXXX
9
Role
permissions
Pool AdminPool
Operator
VM Power
Admin
VM AdminVM
Operator
Read Only
VM change
CD media
View VM
consoles
XenCenter
view mgmt
ops
Cancel own
tasks
Read audit
logs
Configure,
Initialize,
Enable,
Disable
WLB
Apply WLB
Optimization
Recommendations
XXXXX
XXXXX
XXXXX
XXXXXX
XXXXXX
XX
XX
Modify WLB
Report
Subscriptions
Accept WLB
Placement
Recommendations
Display
WLB
Configuration
Generate
WLB
Reports
Connect to
pool and
read all pool
metadata
XX
XXX
XXXXXX
XXXXX
XXXXXX
Definitions of permissions
The following table provides additional details about permissions:
10
Loading...
+ 205 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.