Citrix Systems 5.6 Benutzerhandbuch

Seite von 235
25
1 | 2 | 3
when a pool is overcommited the HA mechanism will attempt to restart protected VMs with the lowest
restart priority first
best-effort
VMs with this priority setting will be restarted only when the system has attempted to restart protected
VMs
ha-always-run=false
VMs with this parameter set will not be restarted
The restart priorities determine the order in which VMs are restarted when a failure occurs. In a given
configuration where a number of server failures greater than zero can be tolerated (as indicated in the HA
panel in the GUI, or by the 
ha-plan-exists-for
 field on the pool object on the CLI), the VMs that have
restart priorities 
1
2
 or 
3
 are guaranteed to be restarted given the stated number of server failures. VMs
with a 
best-effort
 priority setting are not part of the failover plan and are not guaranteed to be kept
running, since capacity is not reserved for them. If the pool experiences server failures and enters a state
where the number of tolerable failures drops to zero, the protected VMs will no longer be guaranteed to be
restarted. If this condition is reached, a system alert will be generated. In this case, should an additional
failure occur, all VMs that have a restart priority set will behave according to the 
best-effort
 behavior.
If  a  protected  VM  cannot  be  restarted  at  the  time  of  a  server  failure  (for  example,  if  the  pool  was
overcommitted when the failure occurred), further attempts to start this VM will be made as the state of
the pool changes. This means that if extra capacity becomes available in a pool (if you shut down a non-
essential VM, or add an additional server, for example), a fresh attempt to restart the protected VMs will
be made, which may now succeed.
Note:
No  running  VM  will  ever  be  stopped  or  migrated  in  order  to  free  resources  for  a  VM  with 
always-
run=true
 to be restarted.
Enabling HA on a XenServer pool
HA can be enabled on a pool using either XenCenter or the command-line interface. In either case, you
will specify a set of priorities that determine which VMs should be given highest restart priority when a pool
is overcommitted.
Warning:
When HA is enabled, some operations that would compromise the plan for restarting VMs may be disabled,
such as removing a server from a pool. To perform these operations, HA can be temporarily disabled, or
alternately, VMs protected by HA made unprotected.
Enabling HA using the CLI
1. Verify  that  you  have  a  compatible  Storage  Repository  (SR)  attached  to  your  pool.  iSCSI  or  Fibre
Channel are compatible SR types. Please refer to the reference guide for details on how to configure
such a storage repository using the CLI.
2. For each VM you wish to protect, set a restart priority. You can do this as follows:
xe vm-param-set uuid=
<vm_uuid>
 ha-restart-priority=
<1>
 ha-always-run=true
3. Enable HA on the pool:
xe pool-ha-enable heartbeat-sr-uuids=
<sr_uuid>