You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: xapi/design/cpu-levelling-v2.md
+22-28Lines changed: 22 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: CPU feature levelling 2.0
3
3
layout: default
4
4
design_doc: true
5
5
status: proposed
6
-
revision: 5
6
+
revision: 6
7
7
revision_history:
8
8
- revision_number: 1
9
9
description: Initial version
@@ -15,6 +15,8 @@ revision_history:
15
15
description: Rolling Pool Upgrade use cases
16
16
- revision_number: 5
17
17
description: Lots of changes to simplify the design
18
+
- revision_number: 6
19
+
description: Use case refresh based on simplified design
18
20
---
19
21
20
22
Executive Summary
@@ -36,10 +38,8 @@ A VM can only be migrated safely from one host to another if both hosts offer th
36
38
37
39
Most pools start off with homogenous hardware, but over time it may become impossible to source new hosts with the same specifications as the ones already in the pool. The main use of feature levelling is to allow such newer, more capable hosts to be added to an existing pool while preserving the ability to migrate existing VMs to any host in the pool.
38
40
39
-
XXX: If all the hosts in a pool are upgraded to more capable models, the overall feature set offered by the pool could also be updated to be the intersection of the features offered by the upgraded hosts. Upgrading the pool-level feature set will not be implemented in the first release of this feature.
40
-
41
-
Principles
42
-
----------
41
+
Principles for Migration
42
+
------------------------
43
43
44
44
The CPU levelling feature aims to both:
45
45
@@ -55,33 +55,27 @@ _Note:_ Due to the limitations of the old Heterogeneous Pools feature, we are no
55
55
56
56
To make VMs mobile:
57
57
58
-
* A VM that is started in a XenServer pool will be able to see only CPU features that are common to all hosts in the pool.
58
+
* A VM that is started in a XenServer pool will be able to see only CPU features that are common to all hosts in the pool. The set of common CPU features is referred to in this document as the _pool CPU feature level_, or simply the _pool level_.
59
+
60
+
Use Cases for Pools
61
+
-------------------
62
+
63
+
1. A user wants to add a new host to an existing XenServer pool. The new host has all the features of the existing hosts, plus extra features which the existing hosts do not. The new host will be allowed to join the pool, but its extra features will be hidden from VMs that are started on the host or migrated to it. The join does not require any host reboots.
64
+
65
+
2. A user wants to add a new host to an existing XenServer pool. The new host does not have all the features of the existing ones. XenCenter warns the user that adding the host to the pool is possible, but it would lower the pool's CPU feature level. The user accepts this and continues the join. The join does not require any host reboots. VMs that are started anywhere on the pool, from now on, will only see the features of the new host (the lowest common denominator), such that they are migratable to any host in the pool, including the new one. VMs that were running before the pool join will not be migratable to the new host, because these VMs may be using features that the new host does not have. However, after a reboot, such VMs will be fully mobile.
66
+
67
+
3. A user wants to add a new host to an existing XenServer pool. The new host does not have all the features of the existing ones, and at the same time, it has certain features that the pool does not have (the feature sets overlap). This is essentially a combination of the two use cases above, where the pool's CPU feature level will be downgraded to the intersection of the feature sets of the pool and the new host. The join does not require any host reboots.
68
+
69
+
4. A user wants to upgrade or repair the hardware of a host in an existing XenServer pool. After upgrade the host has all the features it used to have, plus extra features which other hosts in the pool do not have. The extra features are masked out and the host resumes its place in the pool when it is booted up again.
70
+
71
+
5. A user wants to upgrade or repair the hardware of a host in an existing XenServer pool. After upgrade the host has fewer features than it used to have. When the host is booted up again, the pool CPU's feature level will be automatically lowered, and the user will be alerted of this fact (through the usual alerting mechanism).
72
+
73
+
6. A user wants to remove a host from an existing XenServer pool. The host will be removed as normal after any VMs on it have been migrated away. The feature set offered by the pool will be automatically re-levelled upwards in case the host which was removed was the least capable in the pool, and additional features common to the remaining hosts will be unmasked.
59
74
60
-
Included use cases
61
-
------------------
62
75
63
-
1. A user wants to add a new host to an existing XenServer pool. The new host has all the features of the existing hosts, plus extra features which the existing hosts do not. The new host will be allowed to join the pool, but its extra features will be hidden from VMs.
64
-
65
-
2. A user wants to add a new host to an existing XenServer pool. The new host does not have all the features of the existing ones. The new host will not be allowed to join the pool.
66
-
67
-
3. A user wants to upgrade or repair the hardware of a host in an existing XenServer pool. After upgrade the host has all the features it used to have, plus extra features which other hosts in the pool do not have. The extra features are masked out and the host resumes its place in the pool when it is booted up again.
68
-
69
-
4. A user wants to upgrade or repair the hardware of a host in an existing XenServer pool. After upgrade the host has fewer features than it used to have. When the host is booted up again, it is disabled in the pool and no VMs can be started on it or migrated to it.
70
-
71
-
5. A user wants to remove a host from an existing XenServer pool. The host will be removed as normal after any VMs on it have been migrated away. The feature set offered by the pool will not change, even if the host which was removed was the least capable in the pool and its removal would allow additional features common to the remaining hosts to be unmasked.
72
-
73
-
6. A user wants to re-add a host to an existing XenServer pool from which the host had previously been removed. The host will be allowed to join the pool, because the pool feature set was not recalculated when it was removed. This use case ensures that a host which was removed for maintenance or to be kept as a cold spare can later be re-added.
74
-
75
-
Excluded use cases
76
-
------------------
77
-
78
-
1. A user wants to create a pool by joining a new host to an existing XenServer host which is not running any VMs. The new host does not have all the features of the existing one. The new host will not be allowed to join the pool. In future, a 're-levelling' command could allow the user to mask features of the existing XenServer host to match those offered by the new host. If the pool had no VMs, this operation would be safe. To work around this problem, hosts should be added to a pool in increasing order of capability.
79
-
80
-
2. A user wants to replace all the hosts in an existing XenServer pool with newer, more capable models and upgrade the pool's feature set to reveal the features offered by the new hosts. The pool feature set will remain the same, even after the last of the older, less capable hosts is removed. In the future, 're-levelling' could allow the pool feature set to be expanded, however this should only be done with the user's consent as doing so would prevent any older hosts from being re-added to the pool.
81
-
82
76
Rolling pool upgrade
83
77
--------------------
84
-
78
+
85
79
* When a heterogeneous pool is upgraded, it might turn out that the master is the most capable host. If the pool level is set to the master's level, then all the other hosts will be disabled after the upgrade. Instead, as each host is upgraded and comes back online, we will compare its feature level with the pool level and down-level the pool if the newly-upgraded host is below the pool's level.
86
80
87
81
* A VM which was running on the pool before the upgrade is expected to continue to run afterwards. However, when the VM is migrated to an upgraded host, some of the CPU features it had been using might disappear, either because they are not offered by the host or because the new feature-levelling mechanism hides them. To allow such a VM to continue running, it will be given a temporary VM-level feature set allowing all CPU features. When the VM is rebooted it will inherit the pool-level feature set.
0 commit comments