xapi-project / xen-api / 35575234315
79%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 36
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 78.996%. Remained the same
35575234315

push

github

web-flow 
CA-430692: RPU: host-evacuate fails for VMs restarted after the coord… (#7261)

…inator upgrade

During a Rolling Pool Upgrade (RPU), the host.evacuate may plan to
migrate a VM to a not-upgraded host. But this may fail because the VM
may have (re)started on the host during the upgrade, hence have
inherited new pool level configurations from the upgraded coordinator
host. One observed configuration is pool.cpu_info which contains the CPU
feature set.

Generally, it is safe to migrate the VMs to only upgraded hosts to avoid
such compatibility issues. For the specific CPU feature set, the whole
story is something like: Xapi proposes a CPU feature set for a VM
according to the pool.cpu_info. Xen actually determines which features
can be used for the VM domain. The problem is currently the CPU feature
set written to the VM.last_boot_CPU_flags by Xenopsd when VM has started
is not the one Xen uses actually. Instead it is still the pool.cpu_info.
The VM.last_boot_CPU_flags will be used for compatibility check before
migration. This should be another fix. But migrating VMs to only
upgraded hosts in host.evacuate is still desired to avoid potential
compatibility issues.

Note the Helpers.rolling_upgrade_in_progress is for both upgrade and
update. And HA is required to be disabled during upgrade and update. So
it's no impact on that work flow.

3667 of 4642 relevant lines covered (79.0%)

0.79 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 35575234315.1 36
79.0
 GitHub Action Run
Source Files on build 35575234315