将设为首页浏览此站
开启辅助访问 天气与日历 收藏本站联系我们切换到窄版

易陆发现论坛

 找回密码
 开始注册
查看: 71|回复: 3
收起左侧

错误:实例热迁移到主机"compute06"失败 Failed to compute_task_migrate_server: Unacce

[复制链接]
发表于 2022-6-21 15:01:36 | 显示全部楼层 |阅读模式
购买主题 本主题需向作者支付 10 金钱 才能浏览
 楼主| 发表于 2022-6-21 15:01:54 | 显示全部楼层
2022-06-21 14:47:33.988 25 WARNING oslo_config.cfg [req-b990f037-8329-4f82-aba0-2ad6df0942d8 ef9faa1589a945ec9764b05c1c433b57 6f0124196ea74eb79fbcf370add3ca7e - default default] Option "os_region_name" from group "placement" is deprecated. Use option "region-name" from group "placement".0 G2 S0 I) S( ^# x
2022-06-21 14:47:36.470 25 WARNING nova.scheduler.utils [req-b990f037-8329-4f82-aba0-2ad6df0942d8 ef9faa1589a945ec9764b05c1c433b57 6f0124196ea74eb79fbcf370add3ca7e - default default] Failed to compute_task_migrate_server: Unacceptable CPU info: CPU doesn't have compatibility.$ K5 r, S+ `5 L. h
: A5 h( {/ r/ S; b: ?
01 x7 E6 m* X5 o2 @
3 w$ Y% V. ?! r
Refer to http://libvirt.org/html/libvirt- ... virCPUCompareResult$ ^, v$ g  c  T. G7 ^, {8 V# a5 p
Traceback (most recent call last):
; R2 W7 J5 A: y, m9 m- q
0 F8 M( x2 u( z8 i  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming
8 \# d+ p6 W7 |" W    res = self.dispatcher.dispatch(message)" [- |/ {, V0 z7 L  T! h, I- k) Q* N$ p3 c

! G" I  L+ X: f# }5 F  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 220, in dispatch
! V0 S1 ^# f$ v3 p; n" n$ M6 Y+ U    return self._do_dispatch(endpoint, method, ctxt, args); r: Z( k& t7 K8 _: b" z

1 J! [0 T! \7 K3 o  Q: V5 }  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 190, in _do_dispatch
9 e  k2 G- G# A" c    result = func(ctxt, **new_args)
& {! I& V8 m$ U# a1 |) }; n
5 c# C2 b) K3 }6 N; O  File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 76, in wrapped' }1 q2 }# \! v! R3 C
    function_name, call_dict, binary)
: Z/ e, p  p. Z( V9 \% q( k8 n* v- G$ a- [: P6 C
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
. Z0 h. [3 X! A  K$ q' I    self.force_reraise()
& p) s1 U5 G5 k8 J1 g
7 x9 g; k9 i0 o' G3 }9 T/ U  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise; I6 q! F/ J- ]
    six.reraise(self.type_, self.value, self.tb)9 Y/ O1 F( w) p! |/ D$ H9 _
8 p9 U: c7 u3 n+ F- z: T5 e! F
  File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 67, in wrapped
* K  R- r: V5 Y    return f(self, context, *args, **kw)' U" r% }' |* H# P7 }

; b# U8 Q1 N7 t. G3 y3 [5 o  File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 1000, in decorated_function
6 s- j$ p8 S4 O+ A: K. i    return function(self, context, *args, **kwargs)
7 p. i7 a! }) w2 @' Z/ e
- h7 m' r8 [5 T1 }, U  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 215, in decorated_function
* X$ f2 K+ a- R7 i1 k. @    kwargs['instance'], e, sys.exc_info())
! C2 F" R9 v3 Q. g- Q6 o# y
( v# I# U: @5 y& r1 g; g  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__6 A/ O( o. u4 M6 d
    self.force_reraise()* D8 t* z) M) z, f3 G
- W% [) W: P+ J% U! l( @' t# R
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise2 I. I: ~8 n+ Z- g  f/ A
    six.reraise(self.type_, self.value, self.tb)
6 h+ Z! b9 N' I  e0 u* M/ S
2 a5 y7 X+ }- a& X1 F1 C  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 203, in decorated_function; u) x7 j! V! X5 }- T
    return function(self, context, *args, **kwargs)- p7 V  M8 }7 P9 u. V7 h  [
6 k# E" U( ?* u' F8 X
  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5971, in check_can_live_migrate_destination& f2 }3 @' q7 }" a1 G. Z
    disk_over_commit)
+ g; R7 y: n/ M, {: M7 P9 c
3 P0 k) m9 |6 }$ T" u4 D) P$ |  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5982, in _do_check_can_live_migrate_destination
0 ?6 g; H/ a7 C    block_migration, disk_over_commit)
$ T5 V3 f% W3 V  V4 i6 y$ S  n
0 y7 q7 z" X4 u1 f9 R4 P/ \  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6570, in check_can_live_migrate_destination4 c( ~3 @. W" |" G  Q9 g" |8 \
    self._compare_cpu(None, source_cpu_info, instance)$ L- C) u" V- R! t

1 p/ K% w/ W; ?- n- {* L2 p% P" [2 s  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6841, in _compare_cpu
# r; `7 M3 M) P; A, X3 M: m5 O" Q- v% s    raise exception.InvalidCPUInfo(reason=m % {'ret': ret, 'u': u})
0 A7 ]$ F4 _9 B! J" u) ?; c5 K2 h+ [. K. j8 S" g- G
InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.' D3 ~6 e: o# R) x
& M( w- q1 f2 a8 V5 Q0 u, j
0/ c, E$ D" T: {+ Z8 y
( |% |6 S( `+ G+ X/ w
Refer to http://libvirt.org/html/libvirt- ... virCPUCompareResult7 v+ ]# I5 z% j$ R
: InvalidCPUInfo_Remote: Unacceptable CPU info: CPU doesn't have compatibility.9 f. B. K' U/ `( [6 Q
2022-06-21 14:47:36.472 25 WARNING nova.scheduler.utils [req-b990f037-8329-4f82-aba0-2ad6df0942d8 ef9faa1589a945ec9764b05c1c433b57 6f0124196ea74eb79fbcf370add3ca7e - default default] [instance: 4e781528-c494-45fe-8c67-15763fd5650c] Setting instance to ACTIVE state.: InvalidCPUInfo_Remote: Unacceptable CPU info: CPU doesn't have compatibility.
 楼主| 发表于 2022-6-21 15:08:44 | 显示全部楼层
Live migration fails with 'Unacceptable CPU info: CPU doesn't have compatibility' between non-rebooted and rebooted compute nodes after in-place OpenStack Platform major upgrade: [4 V# }' u- I& z( S% x
SOLUTION UNVERIFIED - 已更新 2018年四月23日15:25 - English $ ?" y  Q* I: ^0 @8 ?5 _
环境
+ v9 S, m& j0 ?! m- N/ wRed Hat OpenStack Platform after major upgrade.
2 n& X/ v2 M, i5 }$ A8 [2 YRed Hat Enterprise Linux (RHEL) 7 on overcloud nodes.& e& O, [% K5 F% N' m
microcode_ctl-2.1-22.5.el7_4.x86_64 and linux-firmware-20170606-58.gitc990aae.el7_4.noarch installed as part of the upgrade.
* P0 \: ?( ]4 B- q+ _Non-rebooted source compute node is running microcode version 59 and rebooted target is running microcode version 58.4 r! A7 A3 r# Y1 a( k
The IBPB CPU model is in use on the source node but not the target node.
4 x; y' F2 E/ p! K7 I2 G5 q+ ~7 V问题
1 [- t& X. n( f4 z0 G- [- lAfter an in-place OpenStack Platform major upgrade, live migration fails with the following error when the source node has not been rebooted and the target node has:
. P% j5 K/ [$ @1 S$ ^8 w; F) o
Raw
4 s+ f0 a5 {4 ^/ h: }" [6 ]Unacceptable CPU info: CPU doesn't have compatibility+ b+ Y  K; A9 K0 B# K' A" G" B/ w
决议5 r6 Q# ^3 k1 p5 m. X6 Y
We recommend working with your respective silicon/hardware vendors in order to upgrade target nodes to version 59 of the CPU microcode or later (whichever is recommended by your silicon/hardware vendors).1 k9 V# T. H7 N3 u$ o6 [

/ m# l6 K  I. u! e2 F1 @9 G) I( CAfter updating, confirm whether virsh capabilities reports that microcode version 59 or later is installed on target node and that the IBPB CPU model is in use. If this is the case, then test live migration on a non-production guest first.8 p: }1 d- Y  s4 @- H" T
8 `3 s9 z6 C& `0 \4 N2 J* U
Following this, complete similar microcode updates on all of the other hosts within the OSP environment.
" S' G; ]; W6 [4 F7 A9 Y4 |9 _; |- t6 R2 |/ |  C5 m
根源7 i1 d2 S3 T8 H( w: o
If Red Hat distributed microcode_ctl and linux-firmware packages are downgraded to microcode version 58 during a major upgrade, the microcode downgrade will only take effect on each node after a reboot.' K( c% f+ h+ b' E4 M

# c3 I$ e) P3 r/ {, BThe latest microcode_ctl and linux-firmware packages from Red Hat do not include resolutions to CVE-2017-5715 (Spectre variant 2) exploit. Red Hat is no longer providing microcode to address Spectre variant 2, due to instabilities introduced that are causing customer systems to not boot. The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on January 3rd 2018. The following article provides more detail in relation to this:
$ L+ {; h" v5 {" A
/ D5 c# C. b* z* E• What CPU microcode is available via the microcode_ctl package to mitigate CVE-2017-5715 (variant 2)?0 V* z4 {+ z) B, N' J# E* o: q; w

/ f7 y# i+ _# A# ~In certain scenarios (for example if compute nodes are not rebooted during the major upgrade procedure and then target nodes are later rebooted post upgrade but source nodes are not), source nodes could be running microcode version 59 or later whereas rebooted target nodes could be running microcode version 58.3 {0 H. k$ v  i: f. E- x& L) c
+ z* b! d  H9 D$ z8 E- I7 L8 M
As such, live migrations would then fail with the Unacceptable CPU info: CPU doesn't have compatibility error, because the target node would lack support for required CPU features.& e6 ?. x) S* c
# R# ?' ]5 S0 t! ?$ h( |& U! [) m
诊断步骤
; ]# ]& w! u* e1 v$ N# Z2 vTo check which microcode version is actually running on each node, one option would be to run virsh capabilities and review the microcode version= parameter within the output. For example:
8 V4 e5 ?$ Y9 k' Y) B2 [) E3 m; j/ K; K: ^. ^/ A2 o" k" }
Raw
; A, ]8 W6 J# M4 Z; L3 w  y<microcode version='58'/>( l, O2 U+ C2 \9 _6 K: G
Alternatively, /proc/cpuinfo provides the microcode version in hexadecimal format. For example:
8 Y- u5 \) e7 K# f
$ }! C/ k& _8 L! L% K, U% P: [Raw
7 {8 \/ L. o, U' k9 I9 H$ grep -is '^microcode' /proc/cpuinfo | head -1
, g4 R3 X# _) `8 Kmicrocode   : 0x3a8 B, H, t7 j0 n7 N6 _$ b
We can see that the above example reports microcode version 58 is running:" L6 R. _+ ?; G$ ?7 H! n
; Y; C: J& [. f) Y
Raw
4 C1 b, l2 Z4 @9 E9 M. L; k$ echo "ibase=16;3A" | bc
& e- b2 ?( g9 k- s) O58
 楼主| 发表于 2022-6-21 15:09:54 | 显示全部楼层
Live Migration Fails With Error: "Unacceptable CPU Info: CPU Doesn't Have Compatibility.
7 I3 p5 x+ G. S' y1 e- eProblem! F5 C. z% w4 L0 e, T
Attempts to perform a live migration of an instance fail with the following error.! p: M$ l& T+ c* j

& B$ T+ [2 n) q# \3 ]Unacceptable CPU info: CPU doesn't have compatibility.  B8 v& M. `$ U% }& {+ n
Copy
1 U. O: ?8 U  w" |$ ^Environment
9 `% n, q8 A( R/ TPlatform9 Managed OpenStack - v3.6.0 and Higher! h9 B" Y- _# [4 K  Q
Cause2 b$ x/ J* a& |9 n5 ?
This error presents itself when CPU model/architecture differ between the source host and destination host even slightly." Q3 N/ W5 e; C9 r

+ l3 ?$ V: T8 B8 M' s5 qResolution4 T5 W6 o, |( y
Run the following command on the host where the VM currently resides to create an XML with the full CPU description.
/ w  I4 j! @" V! z# virsh capabilities > virsh-caps-[originHostname]-full.xml
. O' ~' U6 P5 V1 X4 Z2 [8 aCopy
7 a5 g$ \6 N# _Edit the XML file you've generated deleting everything above "[cpu]" and everything below "[/cpu]".
! T8 O7 V& u2 c- m* s# sMove the file to the destination host and run the following command which will tell you if there is a legitimate mismatch and on which side it lies.
3 t. x' N2 f& p. ]4 R# virsh cpu-compare virsh-caps-[originHostname]-full.xml
8 t. m. N8 {+ w: L0 gCopy
# I) ~( z0 O% D# G' x3 pTo determine the specific features that must be masked out, run the following command.
8 h% z% C. ?; s0 [1 j( ^/ W# virsh cpu-baseline virsh-caps-[originHostname]-full.xml
: q6 S$ E5 J1 L% b5 c% r  kCopy
' }( a/ X$ [& u3 v- Q. WMask out the features that do not appear in the output of the command in Step #4 and attempt to migrate the VM again.
3 l5 J# `1 b, R
您需要登录后才可以回帖 登录 | 开始注册

本版积分规则

关闭

站长推荐上一条 /4 下一条

如有购买积分卡请联系497906712

QQ|返回首页|Archiver|手机版|小黑屋|易陆发现 点击这里给我发消息

GMT+8, 2022-7-4 10:37 , Processed in 0.050597 second(s), 24 queries .

Powered by LR.LINUX.cloud bbs168x X3.2 Licensed

© 2012-2022 Comsenz Inc.

快速回复 返回顶部 返回列表