HP BL680c XenServer Administrator's Guide 4.1.0 - Page 9

XenServer Hosts and, resource pools

Get HP BL680c - ProLiant - G5 PDF manuals and user guides
UPC - 884420396314
View all HP BL680c manuals
Add to My Manuals
Save this manual to your list of manuals

Page 9 highlights

Chapter 2. XenServer Hosts and resource pools A resource pool comprises multiple XenServer Host installations, bound together into a single managed entity which can host Virtual Machines. When combined with shared storage, a resource pool enables VMs to be started on any XenServer Host which has sufficient memory and then dynamically moved between XenServer Hosts while running with minimal downtime (XenMotion). If an individual XenServer Host suffers a hardware failure, then the administrator can restart the failed VMs on another XenServer Host in the same resource pool. Up to 16 hosts are supported per resource pool, although this restriction is not enforced. This chapter describes how resource pools can be created through a series of examples using the xe command line interface (CLI). A simple NFS-based shared storage configuration is presented and a number of simple VM management examples are discussed. Procedures for dealing with physical node failures are also described. A pool always has at least one physical node, known as the "master". Other physical nodes join existing pools and are described as "members". Only the master node exposes an administration interface (used by XenCenter and the CLI); the master will forward commands to individual members as necessary. 2.1. Requirements for creating resource pools A resource pool is an aggregate of one or more homogeneous XenServer Hosts, up to a maximum of 16. The definition of homogeneous is: • each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be mixed) • each CPU is the same model (except for stepping) • each CPU has the same feature flags In addition to being homogeneous, an individual XenServer Host can only join a resource pool if: • it has a static IP address (either manually assigned or via DHCP); • it is not a member of an existing resource pool • it has a clock synchronized to the pool master server (for example, via NTP) • it has no shared storage configured • there are no running or suspended VMs on the XenServer Host which is joining • there are no active operations on the VMs in progress, such as one shutting down • the management NIC of the XenServer Host which is joining is not part of a NIC bond • the Linux Pack is either installed on all hosts in the pool, or not installed at all XenServer Hosts in resource pools may contain different numbers of physical network interfaces. Local storage repositories may also exist, of varying size. In practice, it is often difficult to obtain multiple servers with the exact same CPUs, and so minor variations are permitted. If you are sure that it is acceptable in your environment for hosts with varying CPUs to be part of the same resource pool, then the pool joining operation can be forced. 3

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
3
Chapter 2. XenServer Hosts and
resource pools
A
resource pool
comprises multiple XenServer Host installations, bound together into a single managed
entity which can host Virtual Machines. When combined with shared storage, a resource pool enables VMs
to be started on
any
XenServer Host which has sufficient memory and then dynamically moved between
XenServer Hosts while running with minimal downtime (XenMotion). If an individual XenServer Host suffers
a hardware failure, then the administrator can restart the failed VMs on another XenServer Host in the same
resource pool. Up to 16 hosts are supported per resource pool, although this restriction is not enforced.
This chapter describes how resource pools can be created through a series of examples using the xe
command line interface (CLI). A simple NFS-based shared storage configuration is presented and a number
of simple VM management examples are discussed. Procedures for dealing with physical node failures are
also described.
A pool always has at least one physical node, known as the “master”. Other physical nodes join existing
pools and are described as “members”. Only the master node exposes an administration interface (used by
XenCenter and the CLI); the master will forward commands to individual members as necessary.
2.1. Requirements for creating resource pools
A resource pool is an aggregate of one or more homogeneous XenServer Hosts, up to a maximum of 16.
The definition of homogeneous is:
•
each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be mixed)
•
each CPU is the same model (except for stepping)
•
each CPU has the same feature flags
In addition to being homogeneous, an individual XenServer Host can only join a resource pool if:
•
it has a static IP address (either manually assigned or via DHCP);
•
it is not a member of an existing resource pool
•
it has a clock synchronized to the pool master server (for example, via NTP)
•
it has no shared storage configured
•
there are no running or suspended VMs on the XenServer Host which is joining
•
there are no active operations on the VMs in progress, such as one shutting down
•
the management NIC of the XenServer Host which is joining is not part of a NIC bond
•
the Linux Pack is either installed on all hosts in the pool, or not installed at all
XenServer Hosts in resource pools may contain different numbers of physical network interfaces. Local
storage repositories may also exist, of varying size. In practice, it is often difficult to obtain multiple servers
with the exact same CPUs, and so minor variations are permitted. If you are sure that it is acceptable in
your environment for hosts with varying CPUs to be part of the same resource pool, then the pool joining
operation can be forced.