动态分区迁移主要准备过程及典型问题分析
2010-03-17 00:00:00 来源：WEB开发网动态分区迁移主要概念及准备过程概述
动态分区迁移（Live Partition Mobility，以下简称 LPM）是 IBM 基于 POWER6 技术提供的新特性，它特指将运行 AIX 或 Linux 操作系统的逻辑分区从一台物理系统迁移到另外一台完全不同的物理系统的过程。在这个过程中，操作系统和应用程序不受任何破坏，对外提供的服务也不受任何影响。
LPM 的主要用途
LPM 给与管理员更灵活的控制职能，目前它的用途主要体现在以下几个方面：
当逻辑分区所在的系统需要 Firmware 或者硬件的升级，但是这个逻辑分区由于正对外提供服务而不能关闭时，就可以利用 LPM 功能将它先迁移到另一台物理系统上，待升级完毕后，再将逻辑分区迁移回来。
可以用来平衡日益增长的工作量和资源需求，将服务较少的多个逻辑分区迁移到同一台物理系统上，然后将多余的物理系统关闭，从而降低能耗。这个也符合了目前提倡的绿色环保的理念。
随着业务的发展，逻辑分区上的工作量可能会越来越大，这时可以利用 LPM 功能将逻辑分区迁移到资源更多的物理系统上，以提供更优质的服务。
当物理系统的硬件存在潜在问题时，可以利用 LPM 功能将其上正在提供服务的逻辑分区迁移到安全的系统上。
当用户购买了更新型号的硬件时，也可以利用 LPM 功能将以前提供服务的逻辑分区迁移到新机器上。
未来 LPM 功能将会发挥越来越大的作用。试想一下：对外提供服务的逻辑分区都将不被固定在一个硬件系统上，而是随着服务规模和硬件环境的变化，随时被迁移到另外的系统上。
术语
在讲述 LPM 准备过程之前，让我们首先了解一下涉及到的术语：
活动分区（Mobile Partition）：被迁移的逻辑分区。
源系统（Source System）：活动分区原来所在的系统。
目标系统（Target System）：活动分区将要被迁移到的系统。
VIOS（Virtual I/O Server）：即虚拟 I/O 服务器。是一个安装了特殊定制的 AIX 操作系统的逻辑分区。它可以将各种物理资源转化为虚拟资源，从而使得各个逻辑分区通过 VIOS 来共享这些物理资源。
HMC（Hardware Management Console）：即硬件管理平台。用来管理一台或多台系统的平台，它有自己独立的硬件。用户可以通过 HMC 的可视化界面或命令行对逻辑分区和系统等进行一系列的管理工作。
IVM（Integrated Virtualization Manager）：即集成虚拟化管理器。相比 HMC 而言，它没有独立的硬件，而是通过软件来实现对一台系统的管理。是一个轻量级的系统管理器，可以看作是简化了的 HMC。
FSP（Flexible Service Processor）：Power 服务器中用来管理主机硬件的板卡，系统插电后 FSP 即开始工作。该板上有插口用于将系统连接到 HMC 网络。可以通过 ASMI（Advanced System Management Interface）控制 FSP 进而执行电源重启、查看系统信息等操作。
MSP（Mover Service Partition）：即移动服务分区。VIOS 的一个系统设置，由它控制是否允许迁移逻辑分区的状态。
RMC（Resource Monitor and Control）：RMC 是一个分布式的框架和体系结构，它允许 HMC 和被管理的逻辑分区进行通讯。
更多的基本概念和操作过程可以通过查看参考资源。
LPM 及其分类
标准的 LPM 过程是由验证操作和迁移操作两部分组成的。即：
验证操作（Validation）：验证是进行 LPM 之前可选的一步操作，它可以帮助用户检查环境是否已经准备就绪。验证操作提供的错误信息和警告信息可以帮助用户及时修正错误，以保证迁移过程的顺利进行。
迁移操作（Migration）：由 HMC 或 IVM 提供的功能。使用迁移操作，可以完成活动分区从源系统到目标系统的动态分区迁移。
LPM 按照逻辑分区的情况分为下面两种类型的迁移：
冷迁移（Inactive Migration）：被迁移的逻辑分区是断电的。在参考资料中称为非活动迁移，在本文中将使用冷迁移这个翻译。
热迁移（Active Migration）：被迁移的逻辑分区是不断电的，且一直对外提供服务。在迁移过程中逻辑分区能继续提供服务，不会影响用户行为。在参考资源中称为活动迁移，在本文中将使用热迁移这个翻译。
LPM 按照系统的管理方式分为下面两种类型的迁移：
HMC 之间的动态分区迁移：逻辑分区使用 HMC 管理的 LPM。
IVM 之间的动态分区迁移：逻辑分区使用 IVM 管理的 LPM。
LPM 的准备过程
无论我们选择进行冷迁移还是热迁移，首先物理系统的硬件要符合 LPM 功能的特定要求，然后还需对其环境进行特殊的配置以满足 LPM 操作的条件。冷迁移相比于热迁移在系统配置方面要宽松一些，下面仅以热迁移为例进行说明，没有明确说明的条件均适用于冷、热迁移。
主要准备过程包括以下若干方面：
源系统和目标系统的 FSP 的设置。具体包括：
PowerVM 企业版代码已被激活。
逻辑内存块的大小相同。
管理源系统和目标系统的 HMC 或 IVM 满足如下要求：
HMC 的硬件支持 LPM 功能。
HMC 和 IVM 的操作系统版本支持 LPM 功能。
远程的 HMC 和 IVM 之间已建立密钥认证。
源系统和目标系统的设置。具体包括：
源系统和目标系统使用 Power 6 或者更高版本的硬件。
源系统和目标系统的管理方式相同，即都使用 HMC 或都使用 IVM 进行管理。
源系统和目标系统的 Firmware 版本支持 LPM 功能。
目标系统上有足够闲置的内存和处理器用来支持 LPM 功能。
目标系统不可运行在电池系统上。
源 VIOS 和目标 VIOS 满足如下要求：
VIOS 的版本支持 LPM 功能。
启用 MSP 功能（冷迁移无此要求）。
时钟同步（冷迁移无此要求）。
活动分区满足如下要求：
运行的操作系统支持 LPM 功能。
RMC 连接已建立（冷迁移无此要求）。
关闭冗余错误路径报告功能。
虚拟串行适配器（Virtual Serial Adapter）不得多于 2 个，即只能通过 HMC 或 IVM 取得对活动分区的虚拟终端连接。
不属于任何一个逻辑分区负载管理组（Workload Manager Group）。
不能使用线程同步寄存器（Barrier-synchronization Register）（冷迁移无此要求）。
不能使用大页内存（Huge Page）。
不能使用物理或专属的 I/O 设备（冷迁移无此要求）。
运行的应用程序是可安全迁移的。
外部存储满足如下条件：
源系统和目标系统连接相同的 SAN 存储。
将整块的 SAN 存储以虚拟磁盘的形式分配给活动分区。
SAN 逻辑单元的 reserve_policy 属性置为 no_reserve。
目标系统上有足够的虚拟插槽（Virtual Slot）。
网络配置满足 :
源 VIOS 和目标 VIOS 配置共享以太网适配器。
活动分区使用虚拟网卡。
上面的 LPM 准备过程在红皮书《 IBM PowerVM Live Partition Mobility 》中都有所涉及，所以本文只就 LPM 准备环境过程中的最重要、最困难和最繁琐的部分进行着重讲解，并且结合在 LPM 测试过程中发现的问题进行分析。
FSP 的设置
查看是否已激活了 PowerVM 企业版代码
LPM 是 PowerVM 企业版才支持的功能，所以在进行 LPM 操作之前，要首先确认 FSP 上已经激活了 PowerVM 企业版的代码。以 HMC 管理的系统为例，可以通过在 HMC 的 Server Management -> Servers 里选定系统，打开 Properties -> Capability 进行查看。如果 PowerVM 企业版代码已激活，则 Active Partition Mobility Capable 和 Inactive Partition Mobility Capable 的值为 True，如图 1 所示。
图 1. 通过 HMC 查看系统是否已经激活了 PowerVM 企业版代码
LPM 的详细信息可以在 Migration 标签页中查看，如图 2 所示。
图 2. 查看 LPM 的详细信息
查看原图（大图）
LMB 的修改
跟操作系统管理虚拟内存类似，PowerVM Hypervisor 以逻辑内存块（Logical Memory Block，以下简称 LMB）而不是字节为单位管理服务器的物理内存。LPM 要求源系统和目标系统上 LMB 大小的设置必须相同。我们可以通过 ASMI 对其进行修改。具体的修改步骤为，打开 ASMI 页面，在 Performance Setup 部分进行 LMB 的修改，如图 3 所示。
图 3. 修改 LMB 的大小
FSP 的 LMB 设置还需要注意：LMB 的修改结果一定是要重启整台系统后才够生效。
建立密钥认证
LPM 功能仅限于在两种类型的管理方式上使用：即源服务器和目标服务器使用同一台或两台不同的 HMC 管理，或源服务器和目标服务器均使用 IVM 管理。目前还不支持 HMC 和 IVM 之间的 LPM 功能。
当 LPM 操作发生在两台 HMC 之间时，需要为这它们建立密钥认证。分别登陆到两台 HMC 上，执行 mkauthkey 命令。以 hmc-gira 和 hmc-folk 这两台 HMC 为例，后者的 IP 地址是 9.3.117.211，建立密钥认证的过程如清单 1 所示（需要在 hmc-folk 上执行类似的操作），即：先在 .ssh 目录下的 authorized_keys2 文件中查找，如果密钥已经写入该文件，则 hmc-gira 已经建立了与 hmc-folk 的密钥认证，否则执行 mkauthkey 命令。
清单 1. 使用 mkauthkey 命令建立密钥认证实例
hscroot@hmc-gira:~> cat .ssh/authorized_keys2 |grep hmc-folk
hscroot@hmc-gira:~> host hmc-folk
hmc-folk.upt.austin.ibm.com has address 9.3.117.211
hscroot@hmc-gira:~> mkauthkeys -g --ip 9.3.117.211 -u hscroot
Enter the password for user hscroot on the remote host 9.3.117.211:
hscroot@hmc-gira:~>
建立密钥认证后，如有需要，可以查看 authorized_keys2 文件获取具体的密钥。
在没有建立密钥认证的 HMC 之间执行 LPM 的验证操作时，会得到如图 4 所示的错误信息。
图 4. HMC 之间没有建立密钥认证时，执行 LPM 验证操作的错误信息
查看原图（大图）
IVM 之间的迁移同样需要建立密钥认证，否则也会出现类似的错误信息，清单 2 给出的是在 IVM 上使用命令行进行验证操作时得到的错误信息。
清单 2. 在 IVM 上执行 LPM 验证的错误信息
$ migrlpar -o v -m uli13 -t uli14 --ip 9.3.111.64 -p uli13lp1
[VIOSE0104202E-0409] The migration process failed because of an unknown error
on the destination system. Additional information: Permission denied
(publickey,password,keyboard-interactive).
IVM 之间密钥认证的建立方法与 HMC 相同，这里不再累述。
源系统和目标系统的 Firmware 版本的兼容
源系统和目标系统的 Firmware 版本要分别符合 LPM 功能的要求，才能够进行 LPM 的操作。仅仅满足这个条件还不够，还要注意源系统和目标系统的 Firmware 版本是否兼容。在表 1 中，我们可以看到在各种 Firmware 版本的对 LPM 的支持。
表 1. 源系统和目标系统的 Firmware 版本对 LPM 的支持
| 目标系统 Firmware 版本 | ||||||
| 源系统 Firmware 版本 | EM320_031 | EM320_040 | EM320_046 | EM320_061 | EM320_028 | EM320_039 |
| EM320_031 | 支持 | 支持 | 支持 | 禁止 | 禁止 | 禁止 |
| EM320_040 | 支持 | 支持 | 支持 | 禁止 | 禁止 | 禁止 |
| EM320_046 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 |
| EM320_061 | 禁止 | 禁止 | 支持 | 支持 | 支持 | 支持 |
| EM320_028 | 禁止 | 禁止 | 支持 | 支持 | 支持 | 支持 |
| EM320_039 | 禁止 | 禁止 | 支持 | 支持 | 支持 | 支持 |
清单 3 列出的是 Firmware 不兼容时出现的错误信息。
清单 3. Firmware 不兼容时的错误信息
HSCLA359 The destination managed system has failed the compatibility data
checking performed on the migrating partition with the following error:
Partition Firmware Incompatible.
启用源 VIOS 和目标 VIOS 的 MSP 功能
激活 MSP 功能后，VIOS 就具备了分区迁移的功能，它可以通过 VASI 适配器与 hypervisor 进行通讯，进行数据拷贝等操作。因为热迁移涉及到对内存、处理器和其它各种资源状态等动态数据的拷贝，所以需要 MSP 参与进来。对于冷迁移则没有这个要求。
为了满足不同迁移类型的要求，建议打开源系统和目标系统的 MSP 功能，否则会出现如图 5 所示的的错误信息。
图 5. 没有启用 MSP 功能时，执行 LPM 验证操作的错误信息
具体的开启 MSP 功能的步骤是：
打开 HMC，进 System Management -> Servers 选项。
选择要修改的系统。
选择 VIOS 的逻辑分区，在左键菜单中选择 Property。
在 Property 的 General 标签页中进行修改。
具体如图 6 所示：
图 6. 设置 MSP 功能
VIOS 的内存设置
活动分区运行一般的程序时，是不需要对 VIOS 的内存进行特殊设置的。但是当活动分区负载较大时，就要为 VIOS 分配较多的内存（建议至少为 2GB），以满足分区迁移过程中 VIOS 大量拷贝并传送活动分区内存时的资源需求。如果被迁移分区是共享内存（Active Memory Sharing，更多内容请查看参考资源）分区或 VIOS 是页面交换分区时，则 VIOS需要配置更多的内存（建议至少为 3GB）来避免内存的不足。否则 LPM 在迁移期间会停滞在 0% 的进度，但是在验证阶段不会出现任何错误或者警告。
这是因为：
VIOS 的 MSP 代码会因为得不到足够的内存而中止。
entstat 是 AIX 操作系统提供的命令，用于显示以太网设备驱动器和设备统计信息。该命令在内存不足的时也会中止。
活动分区上 RMC 连接的建立
在执行热迁移的活动分区上需要建立 RMC 连接，否则在 LPM 验证阶段会得到如图 7 所示的错误信息：
图 7. 活动分区没有建立 RMC 连接时，执行 LPM 验证操作的错误信息
查看原图（大图）
使用 lsrsrc IBM.ManagementServer 命令来查看 RMC 连接是否建立，当该命令没有输出或者返回的 ManagerType 属性值不为 HMC 时，说明该活动分区上的 RMC 连接没有建立。清单 4 给出了在一个已经建立 RMC 连接的逻辑分区上执行 lsrsrc IBM.ManagementServer 命令的输出。
清单 4. lsrsrc IBM.ManagementServer 命令验证 RMC 连接是否建立
giftlp3:~ # lsrsrc IBM.ManagementServer
Resource Persistent Attributes for IBM.ManagementServer
resource 1:
Name = "9.3.117.84"
Hostname = "9.3.117.84"
ManagerType = "HMC"
LocalHostname = "9.3.111.77"
ClusterTM = "9078-160"
ClusterSNum = ""
ActivePeerDomain = ""
NodeNameList = {"giftlp3"}
giftlp3:~ #
RMC 连接的建立方法可以查看参考资源。
活动分区上物理 I/O 设备的使用
执行热迁移的活动分区不允许分配任何物理或者专属的 I/O 设备，否则在 LPM 验证阶段就会得到如图 8 所示的错误信息。如果活动分区的物理 I/O 设备在当前的概要文件 (Profile) 中被标为 desired，可以使用 DLPAR（Dynamic Logical Partitioning）操作将其移除，如果被标为 required，则只能在关闭该活动分区后，修改概要文件来将其删除。
进行冷迁移的活动分区虽然不受此条件的约束，但是物理或者专属的 I/O 设备是不会被迁移的，只有虚拟设备才会被成功迁移。
图 8. 活动分区使用物理 I/O 设备时，执行 LPM 验证操作的错误信息
SAN 存储的设置
执行 LPM 操作的源系统和目标系统都必须以 SAN 存储作为它们的外部存储。将源系统和目标系统物理上连接到相同的 SAN 存储，然后通过 SAN 交换机（SAN Switch）进行分组（Zone）操作使它们能够访问相同的 SAN 逻辑单元。
判断系统上是否连接了 SAN 存储，可以登陆到 VIOS 上，如清单 5 所示的方法进行查看，要注意观察第二个数据是否为“Available”，如果为 Defined，则系统并不是真的可以访问 SAN 存储。
清单 5. 在 VIOS 上查看系统上的 SAN 硬盘情况
$ lsdev -type disk |grep Available |grep MPIO
hdisk21 Available MPIO Other FC SCSI Disk Drive
hdisk22 Available MPIO Other FC SCSI Disk Drive
hdisk23 Available MPIO Other FC SCSI Disk Drive
hdisk24 Available MPIO Other FC SCSI Disk Drive
hdisk25 Available MPIO Other FC SCSI Disk Drive
hdisk26 Available MPIO Other FC SCSI Disk Drive
hdisk27 Available MPIO Other FC SCSI Disk Drive
hdisk28 Available MPIO Other FC SCSI Disk Drive
hdisk29 Available MPIO Other FC SCSI Disk Drive
hdisk30 Available MPIO Other FC SCSI Disk Drive
hdisk31 Available MPIO Other FC SCSI Disk Drive
hdisk32 Available MPIO Other FC SCSI Disk Drive
$
源系统和目标系统是否连接相同的 SAN 逻辑单元，可以通过 SAN 逻辑单元的唯一标识字符串进行验证。登陆到 VIOS，使用下面的命令分别查看源系统和目标系统的每个 SAN 逻辑单元，比较对应的 SAN 逻辑单元的 lun_id 属性值是否相同，如清单 6 所示。
清单 6. SAN 硬盘的 lun_id 和 reserve_policy 属性
$ lsdev -dev hdisk21 -attr
attribute value description user_settable
PCM PCM/friend/fcpother Path Control Module False
algorithm fail_over Algorithm True
clr_q no Device CLEARS its Queue on error True
dist_err_pcnt 0 Distributed Error Percentage True
dist_tw_width 50 Distributed Error Sample Time True
hcheck_cmd test_unit_rdy Health Check Command True
hcheck_interval 60 Health Check Interval True
hcheck_mode nonactive Health Check Mode True
location Location Label True
lun_id 0x400040fa00000000 Logical Unit Number ID False
lun_reset_spt yes LUN Reset Supported True
max_retry_delay 60 Maximum Quiesce Time True
max_transfer 0x40000 Maximum TRANSFER Size True
node_name 0x5005076304ffce9f FC Node Name False
pvid none Physical volume identifier False
q_err yes Use QERR bit True
q_type simple Queuing TYPE True
queue_depth 16 Queue DEPTH True
reassign_to 120 REASSIGN time out value True
reserve_policy no_reserve Reserve Policy True
rw_timeout 30 READ/WRITE time out value True
scsi_id 0x89800 SCSI ID False
start_timeout 60 START unit time out value True
unique_id 200B75CMRY200FA07210790003IBMfcp Unique device identifier False
ww_name 0x50050763043bce9f FC World Wide Name False
$
在确认了源系统和目标系统能访问相同的 SAN 逻辑单元后，还要注意 SAN 逻辑单元的 reserve_policy 属性值是否已经修改为 no_reserve，如上面的清单 6 所示。
如果 reserve_policy 的属性值不是 no_reserve，则使用下面的命令进行修改。
chdev -dev hdiskX -attr reserve_policy=no_reserve
如果参与迁移的 SAN 逻辑单元的 reserve_policy 属性没有被设置为 no_reserve，则在执行 LPM 验证操作时会得到如图 9 所示的错误信息：
图 9. SAN 硬盘的 reserve_policy 属性值不为 no_reserve 时，执行 LPM 验证操作的错误信息
网络设置
进行 LPM 操作的系统必须使用虚拟网卡。如果使用的是物理网卡，则需要自己创建 SEA（Shared Ethernet Adapter），并且对其进行配置，使系统能够通过它连接到外部网络。
当源系统和目标系统属于同一网段时，他们只要都使用虚拟网卡即可。但是当源系统和目标系统分属于不同的网段时，则需要在路由器上进行特殊配置，使目标系统的网络也位于源系统的网络之内，这样活动分区从源系统迁移到目标系统后，该分区还可以通过网络进行访问。除此之外 HMC 上还要进行额外的 VLAN 添加操作。
举例说明，比如源系统是 dock，它位于 9.3.103 网段，目标系统是 solar，它位于 9.3.111 网段。为了使活动分区能够成功的从 dock 系统迁移到 solar 系统，且迁移后的活动分区仍然可以访问，需要为 solar 系统添加 9.3.103 这个 VLAN。这样 solar 系统也被置于 dock 系统的 VLAN 之内了。同样如果还想将活动分区从 solar 系统迁移回 dock 系统，就需要为 dock 系统添加 9.3.111 这个 VLAN。这样活动分区就可以在 dock 系统和 solar 系统之间来回迁移了。
具体的 VLAN 添加过程是：在 HMC 上选定要进行添加操作的 VIOS，依次选择 Configuration -> Manage Profile -> Virtual Adapter -> Edit Ethernet，输入要添加的 VLAN ID， 然后点击添加，如图 10 所示。当然，在 HMC 上进行 VLAN 的添加操作之前，必须首先在路由器上进行设置，以保证物理上的确可以访问这个 VLAN。
图 10. 分别为源 VIOS 和目标 VIOS 添加额外虚拟网络
查看原图（大图）
HEA 网卡用于 LPM
当源系统或目标系统上的 VIOS 使用 HEA 网卡作为基础网络时，要将 VIOS 所使用的 HEA 网卡的物理端口设置为混杂模式，如图 11 所示。该过程不需要重启整个系统。然后将其创建成 SEA，使用虚拟网络。
图 11. 设置 HEA 网卡的物理端口为混杂模式
概要文件的重命名
LPM 功能允许用户对活动分区迁移后的概要文件（Profile）进行重新命名，如图 12 所示。如果用户不指定新的名字，迁移后在目标系统上将继续使用源系统上的概要文件的名字，如果用户给出的概要文件的名字与源系统上的另一个概要文件的名字相同，则另一个概要文件将被覆盖。
图 12. 给迁移后的 Profile 重命名
查看原图（大图）
在源系统上对活动分区执行的 DLPAR 操作将使它的内存、处理器、虚拟适配器或者其它某一方面发生改变，它的状态就不再与当前概要文件的描述一致。对于这种情况，活动分区在目标系统上应该尽量不要使用原来的概要文件名字，以免引起混淆。这时在迁移过程中就可利用 LPM 的概要文件重命名功能，而且新概要文件的名字要尽量反映出当前活动分区上用户最关注的特征。
下面将用一个反例说明恰当使用概要文件重命名功能的重要性。源系统 A，目标系统 B，活动分区 mlpar，mlpar 在源系统上的当前概要文件为 memory2G。在迁移前使用 DLPAR 操作为 mlpar 添加了 1GB 内存，然后对 mlpar 执行 LPM 操作将其从系统 A 迁移到系统 B，并没有重新命名概要文件。这样 mlpar 在系统 B 的当前概要文件仍为 memory2G。将 mlpar 从系统 B 迁移回系统 A 时，仍然没有对概要文件重新命名。这样虽然概要文件是 memory2G，但 mlpar 的实际内存已经是 3GB 了。此时概要文件的名称并没有真正的描述出逻辑分区的实际情况，会给用户造成错觉。
处理器兼容问题
活动分区上运行的操作系统，有时候因为版本低的原因无法支持某些新型的处理器，这会限制活动分区在处理器型号不同的系统之间进行迁移的灵活性。处理器兼容模式为这种情况提供了解决的方法，而不需要升级活动分区上正在运行的操作系统。
处理器兼容模式是一个由 hypervisor 指定给逻辑分区的值，它指明了该逻辑分区正常工作时所处的处理器环境。处理器兼容模式能让目标系统提供一个目前处理器环境的子环境，使得被迁移的活动分区使用的版本较低的操作系统能够成功地在这个子环境下运行，从而实现不同处理器的系统之间的 LPM。
可以通过 HMC 设置逻辑分区的处理器兼容模式，如图 13 所示：
图 13. 设置逻辑分区的处理器兼容模式
查看原图（大图）
举例说明一下处理器兼容模式在 LPM 中的应用：源系统的处理器型号为 POWER6，目标系统的处理器型号为 POWER6+，活动分区的处理器兼容模式为默认，如图 14 所示，此时这个活动分区获得的处理器环境为 POWER6。将活动分区从源系统迁移到目标系统后，它的处理器兼容模式仍为默认，且它当前获得的处理器环境实际上仍为 POWER6。但当我们在目标系统上重新激活了该活动分区后，它的处理器环境会变为 POWER6+。从这个例子中可以看到处理器兼容模式在这次 LPM 的操作中发挥的作用。但是因为处理器兼容模式的限制，该活动分区不可以迁移回来了，除非将它的处理器兼容模式修改为 POWER6，重新激活该活动分区使设置生效才能够再次进行 LPM 操作。
图 14. 不同的处理器兼容模式：POWER6+、POWER6
查看原图（大图）
目标系统所支持的处理器模式可以在 HMC 上使用 lssyscfg 命令进行查看，如清单 7 所示。
清单 7. 查看系统所支持的处理器兼容模式
hscroot@sqh10lte:~> lssyscfg -r sys -F lpar_proc_compat_modes,name
null,fsp-aurora
unavailable,9.3.111.177
"default,POWER6,POWER6+,POWER6+_enhanced",fsp-solar
"default,POWER6,POWER6+,POWER6+_enhanced",fsp-cloud
unavailable,9.3.117.242
"default,POWER6_enhanced,POWER6",fsp-tap
表 2 给出了热迁移的处理器兼容模式支持矩阵表。该表由两大部分构成，即源系统环境和目标系统环境，系统环境又由系统处理器型号、用户设定处理器兼容模式、实际处理器兼容模式三部分组成。
用户设定处理器兼容模式是指用户在 HMC 中为逻辑分区所指定的处理器兼容模式。逻辑分区实际所获得的处理器兼容模式不一定与用户设定一致。Hypervisor 为逻辑分区指定实际处理器兼容模式时主要考虑以下两方面因素：
逻辑分区上正运行的操作系统所支持的处理器能力。
用户所设定的处理器兼容模式。
当用户激活一个逻辑分区时，hypervisor 会首先查看用户设定的处理器兼容模式，然后判断逻辑分区上正运行的操作系统是否支持该模式。如果支持，则它会被指定为该处理器兼容模式。在这种情况下，逻辑分区的实际处理器兼容模式与用户设定一致。否则，hypervisor 会给逻辑分区指定最满足操作系统所支持的且最贴近于用户设定的处理器兼容模式。
从表 2 可以得出如下规律：
如果能够进行迁移，则在迁移前后，用户设定处理器兼容模式不变。
如果能够进行迁移，则在迁移前后，实际处理器兼容模式不变。
从低版本到高版本系统进行迁移时，如果操作系统支持，则重新激活逻辑分区后，将得到更多的处理器兼容模式。
不支持从高版本到低版本系统的迁移。
表 2. 热迁移的处理器兼容模式支持矩阵表
| 源系统环境 | 目标系统环境 | ||||
| 源系统 | 迁移前设定模式 | 迁移前实际模式 | 目标系统 | 迁移后设定模式 | 迁移后实际模式 |
| POWER6TM | 缺省 | POWER6 或 POWER5TM | POWER6 | 缺省 | POWER6 或 POWER5 |
| POWER6 | POWER6 | POWER6 或 POWER5 | POWER6 | POWER6 | Power6 或 POWER5 |
| POWER6 | POWER6 加强 | POWER6 加强或 POWER5 | POWER6 | POWER6 加强 | Power6 加强或 POWER5 |
| POWER6 | 默认 | POWER6 或 POWER5 | POWER6+TM | 默认 | POWER6+（重新激活逻辑分区后）或 POWER6 或 POWER5 |
| POWER6 | POWER6 | POWER6 或 POWER5 | POWER6+ | POWER6 | POWER6 或 POWER5 |
| POWER6 | POWER6 加强 | Power6 加强或 Power5 | POWER6+ | 不能迁移，因为 POWER6+ 不支持 POWER6 加强 | 不能迁移，因为 Power6+ 不支持 Power6 加强 |
| POWER6+ | 默认 | POWER6+，POWER6，POWER5 | POWER6+ | 默认 | POWER6+ 或 POWER6 或 POWER5 |
| POWER6+ | POWER6+ | POWER6+，POWER6， POWER5 | POWER6+ | POWER6+ | POWER6+ 或 POWER6 或 POWER5 |
| POWER6+ | POWER6+ 加强 | POWER6+ 加强或 POWER5 | POWER6+ | POWER6+ 加强 | POWER6+ 加强或 POWER5 |
| POWER6+ | POWER6 | POWER6 或 POWER5 | POWER6+ | POWRE6 | POWER6 或 POWER5 |
| POWER6+ | 默认 | POWER6+ 或 POWER6 或 POWER5 | POWER6 | 默认 | 如果是 POWER6+ 则不能进行迁移，因为 POWER6 不支持 POWER6+，如果是 POWER6 或 POWER5 则迁移后也为 POWER6 或 POWER5 |
| POWER6+ | POWER6+ | POWER6+ 或 POWER6 或 POWER5 | POWER6 | 不能迁移，因为 POWER6 不支持 POWER+ | 如果是 POWER6+ 则不能进行迁移，因为 POWER6 不支持 POWER6+，如果是 POWER6 或 POWER5 则迁移后也为 POWER6 或 POWER5 |
| POWER6+ | POWER6+ 加强 | POWER6+ 加强或 POWER5 | POWER6 | 不能迁移，因为 POWER6 不支持 POWER6+ 加强 | 如果是 POWER6+ 加强则不能迁移，因为 POWER6 不支持 POWER6+ 加强；如果是 POWER5 则迁移后也为 POWER5 |
| POWER6+ | POWER6 | POWER6 或 POWER5 | POWER6 | POWER6 | POWER6 或 POWER5 |
LPM 的命令行模式
通常情况下，用户更习惯于使用 HMC 和 IVM 提供的可视化界面进行 LPM 操作，但是 LPM 也提供了命令行模式供用户使用。和可视化界面相比，命令行模式省去了和 HMC、IVM 交互带来的滞后操作，所以速度更快。在进行 LPM 的准备过程中，命令行模式会被频繁的使用，甚至可以被编写到脚本中进行环境的自动化检查。
主要的命令行为：
HMC 上的 LPM 操作：
migrlpar -o m -m 源系统 -t 目标系统 -p 活动分区 -w 等待时间
IVM 上的 LPM 操作：
migrlpar – o m – async – t 目标 IVM – id 活动分区 ID – ip 目标 IVM 的 IP -u 目标 IVM 用户名
其他命令：
验证操作：
migrlpar – o v
恢复操作：
migrlpar – o r
停止操作：
migrlpar – o s
小结
本文归纳了 LPM 的准备过程中涉及到的工作，重点介绍了 FSP、 HMC、源系统和目标系统、活动分区、存储和网络的准备过程。并结合在 LPM 测试过程中遇到的种种问题，着重介绍了 LPM 中概要文件重命名和处理器兼容模式的问题。
中查找“动态分区迁移主要准备过程及典型问题分析”更多相关内容
中查找“动态分区迁移主要准备过程及典型问题分析”更多相关内容
赞助商链接
