This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
XenCenter 2023.x.x is currently in preview and is not supported for production use. Note that any future references to production support apply only when XenCenter 2023.x.x and XenServer 8 go from preview status to general availability.
You can use XenCenter 2023.x.x to manage your XenServer 8 and Citrix Hypervisor 8.2 CU1 non-production environments. However, to manage your Citrix Hypervisor 8.2 CU1 production environment, use XenCenter 8.2.7. For more information, see the XenCenter 8.2.7 documentation.
You can install XenCenter 8.2.7 and XenCenter 2023.x.x on the same system. Installing XenCenter 2023.x.x does not overwrite your XenCenter 8.2.7 installation.
A resource pool is a homogeneous or heterogeneous aggregate of one or more servers, up to a maximum of 64. Before you create a pool or join a server to an existing pool, ensure the following requirements are satisfied for all servers in the pool.
All servers in XenServer resource pools must have broadly compatible CPUs, that is:
- The CPU vendor (Intel, AMD) must be the same on all CPUs on all servers.
- All CPUs must have virtualization enabled.
In addition to the hardware prerequisites, there are several other prerequisites for a server that joins a pool:
- It must have a consistent IP address (a static IP address on the server or a static DHCP lease). This requirement also applies to the servers providing shared NFS or iSCSI storage.
- Its system clock must be synchronized to the pool coordinator (for example, via NTP).
- It cannot be a member of an existing resource pool.
- It cannot have any running or suspended VMs or any active operations in progress on its VMs. All VMs must be shut down before a server can join a pool.
- It cannot have any shared storage already configured.
- It cannot have a bonded management interface. Reconfigure the joining server’s management interface and move it back on to a physical NIC before joining the pool. After the server has successfully joined the pool, you can reconfigure it. For more information, see Configuring IP Addresses.
- It must be running the same version of XenServer software, at the same patch level, as the servers already in the pool.
- It must be configured with the same supplemental packs as the servers already in the pool. Supplemental packs are used to install add-on software into dom0 (XenServer control domain). To prevent inconsistencies in the user experience across a pool, ensure you install the same supplemental packs at the same revision on all the servers in the pool.
- It must have the same XenServer license as the servers already in the pool. For example, you cannot add a server with XenServer Standard Edition license to an existing resource pool that contains servers with XenServer Premium Edition. You can change the license of any pool members after joining the pool. The server with the lowest license determines the features available to all members in the pool. For more information about licensing, see About XenServer Licensing.
A homogeneous resource pool is an aggregate of servers with identical CPUs. In addition to the requirements in the preceding sections, a server that joins a homogeneous pool must have the same CPUs as those servers already in the pool. CPUs are considered the same if they have the same vendor, model, and features.
XenServer enables expanding deployments over time by allowing disparate host hardware to be joined into a resource pool, known as heterogeneous resource pools. Heterogeneous resource pools are made possible by applying technologies in Intel (FlexMigration) and AMD (Extended Migration) CPUs that provide CPU “masking” or “leveling”. These features allow a CPU to be configured to appear as providing a different make, model, or functionality than it actually does. This capability enables you to create pools of hosts with disparate CPUs but still safely support live migrations. Servers joining heterogeneous pools must meet the following requirements:
- The CPUs of the server that joins the pool must be of the same vendor (AMD, Intel) as the CPUs on servers already in the pool. However, the specific type of CPU (family, model, and stepping numbers) is note required to be the same.
- The CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration.
XenServer simplifies the support for heterogeneous pools. You can add servers to existing resource pools, irrespective of the underlying CPU type, as long as the CPU is from the same vendor family. The pool feature set is dynamically calculated every time:
- a new server joins the pool
- a pool member leaves the pool
- a pool member reconnects following a reboot
Any change in the pool feature set does not affect VMs that are currently running in the pool. A running VM continues to use the feature set which was applied when it was started. This feature set is fixed at boot and persists across migrate, suspend, and resume operations. If the pool level drops when a less-capable server joins the pool, a running VM can migrate to any server in the pool, except the newly added server. When you move or migrate a VM to a different server within or across pools, XenServer compares the VM feature set to that of the destination server. If the feature sets are found to be compatible, the VM is allowed to migrate. This capability enables the VM to move freely within and across pools, regardless of the CPU features the VM is using. If you use Workload Balancing to choose an optimal destination server to migrate your VM, a server with an incompatible feature set is not recommended as the destination server.
To update a running VM to use the pool’s new feature set, power off the VM and start it again. Rebooting the VM, for example, by clicking Reboot in XenCenter, does not cause the VM to update its feature set.
Although not a strict requirement for creating a resource pool, the advantages of pools are only available if the pool has one or more shared storage repositories (SRs). These advantages include running a VM on the most appropriate server and VM migration between servers.
We recommend that you do not attempt to create a pool until shared storage is available. After you add shared storage, you can quickly move any existing VMs whose disks are in local storage into shared storage by copying them.
When a server with a shared SR becomes a pool coordinator, this SR becomes a shared SR for the pool. If the new pool coordinator does not have any shared storage, you have to create a new shared SR for the pool: see Creating a New SR.
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.