易陆发现互联网技术论坛

 找回密码
 开始注册
查看: 752|回复: 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".
" |2 _! @2 S3 z4 K8 \7 Q4 i) ]& [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.# ]. K0 [7 y! U: v. W

; V9 A$ C1 I9 c/ I) s- ]01 V' u6 k! `* U$ @' J; _% e4 I
& v' w2 z' ^. L" q: Z
Refer to http://libvirt.org/html/libvirt- ... virCPUCompareResult
) |2 t( ~3 V8 A& \Traceback (most recent call last):
/ d! C4 X' M0 B, c, ~' w1 m$ |5 a$ I- [( U- k9 q
  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming7 \' Z; ~- T& N& Y8 |: Y
    res = self.dispatcher.dispatch(message)
. p4 l8 Q! m% V5 C
7 ?: Z- b. \* z' q  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 220, in dispatch5 _# ]: R7 S) g; }& {
    return self._do_dispatch(endpoint, method, ctxt, args)$ J0 e. m% g' r0 ]+ ]" }" r

; X; _2 c$ x/ o( a  z  File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 190, in _do_dispatch
" x/ [6 `5 ~2 r1 ~    result = func(ctxt, **new_args)5 t! ~6 \2 O: E: ?! i/ `* A

& O7 M! w' W. l+ R  File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 76, in wrapped7 k5 J, |+ ~9 u+ _, c0 `; T
    function_name, call_dict, binary)+ v+ Q, W) k# |0 a( d- {! [
7 y0 c+ |& a1 a% A# N4 X( Y* i
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
4 a: R9 N% h$ h, T/ v  q    self.force_reraise()$ B7 }% h% L8 O! F! X
# G6 b! s0 T% p  Y+ H
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
$ X9 W1 j6 D! ?    six.reraise(self.type_, self.value, self.tb)  b$ z# a& L( l8 n. g- Z3 P+ D, a
+ B! ?  h9 h: `
  File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 67, in wrapped
8 p" i& F( @1 u, `4 ?. e( L    return f(self, context, *args, **kw)# z4 b. ?7 s6 t4 ~
) N' F% z; [" |, z) c! L3 ]
  File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 1000, in decorated_function
3 t% S0 ]* {) D1 L    return function(self, context, *args, **kwargs)
) F! Z1 c8 W" i) n0 p" z1 ]! _' W. B0 J9 `
  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 215, in decorated_function
: `' Y2 X; h1 `0 }4 j$ ?; ^    kwargs['instance'], e, sys.exc_info())$ \3 H9 G* l$ ~, _7 p6 m

4 n# _1 U* _# A% R  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__8 k# q" Q4 U: `' F) O
    self.force_reraise()9 Q8 w# M; ~1 i7 c- V- [; w0 F$ m( f' n
0 Q' Q8 x+ v9 x; Y
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise4 r* F+ @6 w* N! b, N8 D& u
    six.reraise(self.type_, self.value, self.tb)
% {/ ?5 H* G& a! {1 L( F$ c1 [& `4 H" f/ A
  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 203, in decorated_function
# U" x! {, b. K4 t6 K    return function(self, context, *args, **kwargs)! n6 r. h  s1 o- e/ p- u$ N

8 E' A  U: t2 S  R  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5971, in check_can_live_migrate_destination
8 Y- q# J6 r. D& W! @/ w    disk_over_commit): o5 ^7 D  F. P! f1 C- h
: M6 Q3 l; B. k* G1 ]1 [( A
  File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5982, in _do_check_can_live_migrate_destination# G% d5 e8 k- X# I0 w
    block_migration, disk_over_commit)
" l- t. ^% M) w7 Z0 L% U- u+ C& n2 Z5 }0 j4 V
  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6570, in check_can_live_migrate_destination% o9 Q& f8 @) @  O: ^9 }
    self._compare_cpu(None, source_cpu_info, instance)
4 {1 [6 C9 r" V+ \0 d
! ?: i6 i6 A  `% ^7 {+ U2 P  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6841, in _compare_cpu
0 m" G' Y6 M) ^5 S    raise exception.InvalidCPUInfo(reason=m % {'ret': ret, 'u': u})
# }8 Z/ ?. m, c$ P. ]7 @: e' v) l6 H+ M8 p
InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.8 B  L. r. r/ Q6 l/ P

+ h& d1 c7 p* C2 B0 ~0# }3 s" b0 {4 ?- K

% R) U4 `# U. Z& h  J* `Refer to http://libvirt.org/html/libvirt- ... virCPUCompareResult* A& `) b0 Y+ G
: InvalidCPUInfo_Remote: Unacceptable CPU info: CPU doesn't have compatibility.! H5 ]; T7 T4 u9 s+ }
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
+ R% r5 W) H  P* e  b. | SOLUTION UNVERIFIED - 已更新 2018年四月23日15:25 - English
9 I* g# b) m3 [环境+ S& @' h* C; z( n
Red Hat OpenStack Platform after major upgrade.
& m# ?# l- M+ b5 |Red Hat Enterprise Linux (RHEL) 7 on overcloud nodes.6 \  G, @% n& n/ T
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.
% i+ N& Q) U2 e% _% yNon-rebooted source compute node is running microcode version 59 and rebooted target is running microcode version 58.
: k- f& ~1 n3 d8 X6 {3 @7 [  tThe IBPB CPU model is in use on the source node but not the target node.
1 v+ G% w/ P) ~& }0 V8 V问题: m2 H7 W0 j8 {9 s: v0 _+ z
After 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:
$ M9 H' ~; ?8 {' l2 N$ w" p8 o: l
Raw
# R* O% ?  }3 m5 tUnacceptable CPU info: CPU doesn't have compatibility
8 H4 M( ~, s$ K: e0 p决议
$ \( z' W- p$ `+ o$ x8 ZWe 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 r6 K' J$ [$ y
5 R- c0 F8 A# R6 \, g
After 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.) V- j; }; a: j% }' L0 [

! U: j$ l# w. F9 AFollowing this, complete similar microcode updates on all of the other hosts within the OSP environment.
) ?" A- I& Y) F8 q6 i: o/ d1 L3 d$ @5 o! E" Y* @/ \* o. I! p
根源
  b; f2 C6 V8 _7 v# E; tIf 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.- X# L) }4 g4 p4 w
: W, ^+ D- d/ L1 f- C
The 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:
; p$ e6 v) x/ ]. M3 S* [! R0 `' p
) T7 j* t9 a* p. u( r0 Z' M• What CPU microcode is available via the microcode_ctl package to mitigate CVE-2017-5715 (variant 2)?
$ w6 }) c7 F5 X* p" l" X
9 K! d8 ?: o$ L# rIn 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.
% O9 H( ~' r) X
8 w' i' |! J; o! [+ WAs 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.7 O+ F: g4 y8 X% ^9 _+ |, \

' S# D. W7 K% Y- u5 I1 f+ Y- b诊断步骤& \' f& J3 `# Q; i
To 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:
6 s- u) T, D1 P, G' Q5 U
# y% u, I4 S/ H. m- u6 kRaw
( u0 _# O! ^# p4 K9 ]+ T<microcode version='58'/>
3 n( s* T/ ^" P" i5 kAlternatively, /proc/cpuinfo provides the microcode version in hexadecimal format. For example:& O# M/ d/ x: Q2 u* f8 [- F! Z5 B

+ m% A( F! g4 p7 j" B1 B. M* x! [Raw5 ?5 e+ G, p% V9 R& R% G2 e. N! x
$ grep -is '^microcode' /proc/cpuinfo | head -1
0 y8 {/ V) e* m$ vmicrocode   : 0x3a
( T* R0 |5 Q4 e' n. bWe can see that the above example reports microcode version 58 is running:
( v& @! O3 {0 m/ H" Z3 T
+ ~$ h/ ]9 x4 y1 m! d3 l( dRaw% o0 k0 E7 v" L; I% O1 c
$ echo "ibase=16;3A" | bc
( b( [- O- ~8 ^& ]: L( N58
 楼主| 发表于 2022-6-21 15:09:54 | 显示全部楼层
Live Migration Fails With Error: "Unacceptable CPU Info: CPU Doesn't Have Compatibility.) }0 i1 @' U+ I7 G) S
Problem5 N3 f" P3 v+ c) E
Attempts to perform a live migration of an instance fail with the following error.. S0 W! g! x/ F0 z3 w. I
9 E1 Y, B+ L4 V6 S) I1 F  ^
Unacceptable CPU info: CPU doesn't have compatibility.5 c3 k  n3 ~* W+ W4 n
Copy4 t! _0 W# g& M: q8 _# b; ^
Environment( O  e3 N0 m0 V9 T* c+ R
Platform9 Managed OpenStack - v3.6.0 and Higher2 I/ S5 y/ z2 q! u+ E" W& d/ g* T
Cause5 d. @+ Y4 Y9 ?/ G+ q
This error presents itself when CPU model/architecture differ between the source host and destination host even slightly.
8 _" x# J" L$ D2 l2 K6 Z: O5 O2 W0 G2 F2 A  T
Resolution
  u( t# s1 K1 w& uRun the following command on the host where the VM currently resides to create an XML with the full CPU description.
. D: _/ H2 i) C& Q6 y# virsh capabilities > virsh-caps-[originHostname]-full.xml
- C( P3 N$ b% x" L, a- h7 m% N- }Copy& J4 n& H  Y1 g: H
Edit the XML file you've generated deleting everything above "[cpu]" and everything below "[/cpu]".
. @& Z& n$ c& g  l# 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./ ?/ N; ?* H8 _+ d% E
# virsh cpu-compare virsh-caps-[originHostname]-full.xml
7 n/ s7 A7 [9 o4 s4 {4 Z. E) qCopy
3 l4 X- o# s: k# ]  zTo determine the specific features that must be masked out, run the following command.
* h# O- Z6 n1 o* S0 q6 g6 r) ^5 [# virsh cpu-baseline virsh-caps-[originHostname]-full.xml
3 B4 u  z# h* {Copy
9 k: s. ]. b" f( L$ p4 {; `) RMask out the features that do not appear in the output of the command in Step #4 and attempt to migrate the VM again.
$ A' V( y7 w* L1 d4 l0 W
您需要登录后才可以回帖 登录 | 开始注册

本版积分规则

关闭

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

北京云银创陇科技有限公司以云计算运维,代码开发

QQ|返回首页|Archiver|小黑屋|易陆发现技术论坛 点击这里给我发消息

GMT+8, 2026-4-8 15:29 , Processed in 0.048800 second(s), 24 queries .

Powered by Discuz! X3.4 Licensed

© 2012-2025 Discuz! Team.

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