動態(tài)分區(qū)遷移是基于 POWER6 的 IBM System p 服務器的一個新特性，該特性能夠將運行中的邏輯分區(qū)從一臺服務器遷移到另外一臺，并且不影響用戶的使用。集成虛擬化管理器（IVM）是除 HMC 外管理 IBM System p 服務器的另外一種方式，運行在 POWER6 上的 IVM 也支持動態(tài)分區(qū)遷移，不過在使用方式上和 HMC 上的分區(qū)遷移存在較大差別。本文主要介紹了如何在 IVM 上進行動態(tài)分區(qū)遷移，以及 IVM 和 HMC 上動態(tài)分區(qū)遷移的不同之處。

HMC（Hardware Management Console）是大家熟知的硬件管理控制臺，系統(tǒng)管理員可以通過 HMC 進行邏輯分區(qū)創(chuàng)建，編輯，刪除以及分區(qū)狀態(tài)的控制等操作。在 POWER6 出現(xiàn)以后，IBM System p 服務器提供了一個新的虛擬特性— 動態(tài)分區(qū)遷移，利用該特性，用戶能夠將運行中的邏輯分區(qū)從一臺服務器遷移到另外一臺，并且不影響用戶的使用?；?HMC 的動態(tài)分區(qū)遷移在本文的參考資料中有詳細的描述，用戶可以通過這些資料來掌握 HMC 上的動態(tài)分區(qū)遷移操作。

IVM（Integrated Virtualization Manager）—集成虛擬化管理器是 IBM System p 上管理服務器的另一種方式，也支持動態(tài)分區(qū)遷移。因為該方式和 HMC 存在較大差別，因此動態(tài)分區(qū)遷移在這兩種方式下也不盡相同。那么如何在 IVM 上進行動態(tài)分區(qū)遷移，兩個平臺上的分區(qū)遷移操作又有何不同呢？本文將逐一解答這些問題。

為了更好的閱讀本文，要求讀者對 IVM 的基本原理和操作界面有一個初步的認識，同時了解動態(tài)分區(qū)遷移的基本原理并熟悉 HMC 上動態(tài)分區(qū)遷移的配置和操作。讀者可以通過閱讀本文所提供的參考資料了解或熟悉這些方面的相關知識。如果讀者有 IVM 和動態(tài)分區(qū)遷移的配置和使用經驗，則能更進一步理解和掌握本文所描述的內容。

什么是集成虛擬化管理器

說到 IBM System p 的硬件管理控制臺，大家熟知的還是 HMC。通過 HMC，可以管理多臺 System p 服務器，對它們進行分區(qū)管理，動態(tài)資源調節(jié)以及動態(tài)分區(qū)遷移等操作。HMC 盡管簡化了對 System p 服務器的管理，但是還是存在一些缺點。首先，雖然 HMC 為管理從低端到高端各種類型的 System p 服務器提供了一套全面的解決方案，但是在一些簡單的 IT 環(huán)境（比如僅有一臺低端服務器并且只需要簡單的分區(qū)配置）中并不需要這么復雜的功能，一個能最大限度的支持快速部署和簡化管理的方案更加適用于這種環(huán)境。其次，為了對一臺低端服務器進行分區(qū)管理而購買一臺價格并不算太便宜的 HMC 顯得不是太劃算。還有，HMC 不能管理基于 POWER 或 PowerPC 芯片的 IBM 刀片服務器。

IVM 解決了上述問題，它是一個簡化版的 HMC，繼承了大部分 HMC 功能。IVM 是 VIOS（Virutal I/O Server）的一個組成部分，VIOS 從 v1.2 開始支持 IVM，帶有 IVM 功能的 VIOS 是 HMC 和 VIOS 的一個集合體（如圖 1 所示）。一個 IVM 只能管理一臺服務器，基于 Web 的 GUI 操作界面簡化了服務器管理，尤其是虛擬 I/O 資源的管理。由于功能受限，通常 IVM 用于中低端服務器。

要激活 IVM 功能，VIOS 必須安裝在出廠設置（Manufacturing Default Configuration）的服務器上（包括刀片服務器），該服務器不被 HMC 所管理。當 VIOS 作為第一個操作系統(tǒng)被安裝在出廠設置的服務器上后，它接管了該服務器上所有的 I/O 資源，并激活 IVM 功能，系統(tǒng)管理員可以通過瀏覽器連接到 IVM 上進行虛擬 I/O 資源的劃分，分配和刪除，以及邏輯分區(qū)管理等操作。

在使用 HMC 管理服務器時，HMC 通過網絡與 POWER5 或 POWER6 服務器上的 FSP（Flexible Service Processor）進行通信，進而跟 POWER Hypervisor 一起協(xié)作進行服務器管理。而 IVM 則通過一個特殊的虛擬設備 VMC（Virtual Management Channel）與 POWER Hypervisor 進行通信，VMC 和 Hypervisor 之間不需要任何網絡連接。通過 VMC，IVM 能夠進行邏輯分區(qū)配置，控制并顯示分區(qū)狀態(tài)，管理虛擬網絡和存儲資源等操作（如圖 1 所示）。因為 IVM 依賴于 VMC 這種虛擬設備進行分區(qū)管理，因此一個 IVM 只管理一臺服務器。只有 IVM 才有 VMC 這種虛擬設備，HMC 管理下的普通 VIOS 不存在該設備（見清單 1）。

雖然 IVM 只是 VIOS 的一個組成部分，但是通常用戶在使用 IVM 這個名詞時，也指帶有 IVM 功能的 VIOS。讀者可以通過上下文來區(qū)分 IVM 在不同情況下的具體含義。

清單 1：虛擬設備 VMC

在具有 IVM 功能的 VIOS 上：
$ lsdev -virtual | grep vmc
ibmvmc0 Available Virtual Management Channel
$

在 HMC 管理的普通 VIOS 上：
$ lsdev -virtual | grep vmc

實驗環(huán)境

本文將通過圖 2 所示的實驗環(huán)境來說明如何利用 IVM 進行動態(tài)分區(qū)遷移。在 HMC 和 IVM 上進行動態(tài)分區(qū)遷移所需的系統(tǒng)配置大致相同，主要不同在于前者要求兩個服務器連接在同一臺 HMC 上，并通過 HMC 協(xié)調進行分區(qū)遷移，而后者則要求兩臺服務器分別由各自的 IVM 進行管理，分區(qū)遷移由兩個 IVM 協(xié)調進行。

該實驗環(huán)境包含兩個刀片服務器 uli13 和 uli14，網絡和 SAN（Storage Area Network）。每個刀片服務器各安裝一個 VIOS，由 IVM 進行管理。兩個 VIOS 通過 SAN 共享存儲子系統(tǒng)中的 LUN（Logical Unit Number），在 uli13 上通過 IVM 分配給兩個邏輯分區(qū) uli13lp1 和 uli13lp2。兩個刀片服務器連接到同一個以太網中，uli13lp1 和 uli13lp2 通過 IVM 所提供的 VLAN（虛擬局域網）也連接到該網絡。IVM 所在的 VIOS 的 MSP（Mover Service Partition）屬性是默認打開的，沒有任何選項用于打開或者取消 MSP 屬性；這與 HMC 上的動態(tài)分區(qū)遷移不同，后者必須激活 VIOS 的 MSP 屬性才能進行分區(qū)遷移。

在 IVM 上進行動態(tài)分區(qū)遷移

分區(qū)遷移前

圖 3 和圖 4 分別顯示了分區(qū)遷移前源系統(tǒng) uli13 和目標系統(tǒng) uli14 上分區(qū)的狀態(tài)，清單 2 和清單 3 則分別顯示了遷移前兩個系統(tǒng)上虛擬磁盤的映射情況。分區(qū) uli13 是 VIOS，是系統(tǒng) uli13 上 IVM 的宿主分區(qū)；uli13lp1 是其中的一個分區(qū)，處于運行狀態(tài)，占用了 0.1 個處理器單元，1GB 內存和 5 個 SAN 磁盤 hdisk2/5/6/7/8，VIOS 使用虛擬設備 vhost0 和 vtscsi0/1/2/3/4 進行虛擬磁盤映射；uli13lp2 是另一個分區(qū)，處于關閉狀態(tài)，占用了 0.1 個處理器單元，1GB 內存和 5 個 SAN 磁盤 hdisk1/9/10/11/12，VIOS 使用虛擬設備 vhost1 和 vtscsi5/6/7/8/9 進行虛擬磁盤映射。分區(qū) uli14 也是 VIOS，是系統(tǒng) uli14 上 IVM 的宿主分區(qū)；uli14 上沒有其他分區(qū)，剩余的 1.8 個處理器單元和 2.69GB 內存能夠滿足遷移 uli13lp1 和 uli13lp2 所需的資源需求。服務器 uli13 和 uli14 上各有 13 個 SAN 磁盤，同名的磁盤被映射到 SAN 存儲子系統(tǒng)中相同的 LUN。

由于 uli13lp1 處于運行狀態(tài)，因此對它所做的分區(qū)遷移屬于活動遷移；而 uli13lp2 處于關閉狀態(tài)，因此分區(qū)遷移則屬于非活動遷移。與 HMC 上的分區(qū)遷移類似，在 IVM 上活動遷移和非活動遷移的操作過程是一樣的，IVM 根據分區(qū)的狀態(tài)自動選擇相應的遷移方式。本文以 uli13lp1 為例，講解 IVM 上分區(qū)遷移的操作過程。

清單 2：遷移前 uli13 上的虛擬磁盤映射

$ lsdev | grep MPIO
hdisk0 Available MPIO Other FC SCSI Disk Drive
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost0 Available Virtual SCSI Server Adapter
vhost1 Available Virtual SCSI Server Adapter
vtscsi0 Available Virtual Target Device - Disk
vtscsi1 Available Virtual Target Device - Disk
vtscsi2 Available Virtual Target Device - Disk
vtscsi3 Available Virtual Target Device - Disk
vtscsi4 Available Virtual Target Device - Disk
vtscsi5 Available Virtual Target Device - Disk
vtscsi6 Available Virtual Target Device - Disk
vtscsi7 Available Virtual Target Device - Disk
vtscsi8 Available Virtual Target Device - Disk
vtscsi9 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost0 U7998.61X.100390A-V1-C11 0x00000001

VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk2
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400400000000

VTD vtscsi1
Status Available
LUN 0x8200000000000000
Backing device hdisk5
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400700000000

VTD vtscsi2
Status Available
LUN 0x8300000000000000
Backing device hdisk6
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400800000000

VTD vtscsi3
Status Available
LUN 0x8400000000000000
Backing device hdisk7
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400900000000

VTD vtscsi4
Status Available
LUN 0x8500000000000000
Backing device hdisk8
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400A00000000

SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost1 U7998.61X.100390A-V1-C13 0x00000000

VTD vtscsi5
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400300000000

VTD vtscsi6
Status Available
LUN 0x8200000000000000
Backing device hdisk9
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400B00000000

VTD vtscsi7
Status Available
LUN 0x8300000000000000
Backing device hdisk10
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400C00000000

VTD vtscsi8
Status Available
LUN 0x8400000000000000
Backing device hdisk11
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400D00000000

VTD vtscsi9
Status Available
LUN 0x8500000000000000
Backing device hdisk12
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400E00000000

$

清單 3：遷移前 uli14 上的虛擬磁盤映射

$ lsdev | grep MPIO
hdisk0 Available MPIO Other FC SCSI Disk Drive
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
$ lsmap -all
$

遷移的驗證

IVM 在任務列表（如圖 5 所示）里面為分區(qū)遷移新增了“遷移性”這一個類別，包括“遷移”和“狀態(tài)”兩個選項。使用“遷移“選項，可以驗證和發(fā)起分區(qū)遷移。使用“狀態(tài)”選項，可以隨時查看分區(qū)遷移的狀態(tài)，這樣當分區(qū)遷移開始后，系統(tǒng)管理員就可以繼續(xù)其他操作，而不需要等待遷移的完成。

在使用“遷移”選項前，必須先選擇要遷移的分區(qū)，而且每次只能選擇一個分區(qū)。每個分區(qū)都是可選的，包括 VIOS uli13 在內，雖然遷移 VIOS 是不恰當的。如果選擇了 VIOS，那么 IVM 在驗證分區(qū)遷移的時候就會報錯，從而避免了不恰當的遷移請求。因為對于被選擇的分區(qū)，管理員可以從任務列表選擇多種不同的操作，因此 IVM 無法預先知道是否要進行分區(qū)遷移，所以不可能在分區(qū)列表里面禁止選擇 VIOS 的操作，而是在選擇“遷移”功能之后才進行判斷。這里我們選擇遷移的是 uli13lp1（如圖 5 所示），在任務列表里面選擇了“遷移”選項后，用戶看到的是一個驗證和遷移頁面（如圖 6 所示），其中包含幾個字段和按鈕。

字段包括遠程 IVM 的主機名（注意，不是目標系統(tǒng)的名稱）或 IP 地址，以及登陸該遠程系統(tǒng)所需的用戶名和密碼。有趣的是，遠程 IVM 字段還標明了“HMC”字樣，這可能意味著將來即使在 HMC 上進行動態(tài)分區(qū)遷移也不要求兩臺服務器必須由同一臺 HMC 來管理，這樣一來，由不同 HMC 管理的服務器之間，以及由 HMC 和 IVM 所管理的服務器之間也可以進行分區(qū)遷移，從而增加了分區(qū)遷移的靈活性。不過目前的動態(tài)分區(qū)遷移還不支持這一功能。

按鈕用于驗證分區(qū)遷移和開始分區(qū)遷移。HMC 也為分區(qū)遷移提供了驗證和遷移兩個功能，系統(tǒng)管理員可以選擇先做驗證，然后再開始分區(qū)遷移，也可以不使用驗證功能，而直接開始分區(qū)遷移。由于分區(qū)遷移向導其中的一個環(huán)節(jié)就是進行自動驗證，因此無論管理員采用什么方式，HMC 總能保證在遷移開始之前進行驗證，盡早發(fā)現(xiàn)并提示管理員修復問題，提高分區(qū)遷移的效率。相比于 HMC，在 IVM 上進行驗證和遷移所需的操作被大大簡化了，用戶只需要點擊“驗證”和“遷移”按鈕就可以進行分區(qū)遷移的驗證和開始分區(qū)遷移。IVM 上的分區(qū)遷移在開始階段也同樣包含了對遷移的驗證，如果驗證失敗了，IVM 停止分區(qū)遷移，并報告錯誤信息。雖然分區(qū)遷移會自動進行驗證，因此用戶可以不用經過驗證而直接開始分區(qū)遷移，但是還是建議用戶在開始遷移之前事先進行驗證。

填寫完上述字段后，按下“驗證”按鈕就開始了分區(qū)遷移的驗證。在驗證過程中，IVM 顯示一個等待對話框（如圖 7 所示），過一小段時間后，驗證完成，IVM 顯示驗證結果。如果驗證沒有發(fā)現(xiàn)問題，那么 IVM 顯示“操作已經成功完成”（如圖 8 所示）；如果發(fā)現(xiàn)錯誤，管理員可以通過 IVM 所顯示的錯誤信息去修復問題，然后再次進行驗證。

開始分區(qū)遷移

驗證成功后，按下“遷移”按鈕就開始進行分區(qū)遷移了（如圖 9 所示）。分區(qū)遷移所需的時間長短視分區(qū)物理內存大小，以及系統(tǒng)所承受的壓力等因素而定。對分區(qū) uli13lp1 進行的遷移是活動遷移，因此所用的時間通常比 uli13lp2 上的非活動遷移來得長。圖 9 所顯示的是 uli13lp1 的遷移狀態(tài)，用戶可以通過該頁面監(jiān)視遷移的進度。該頁面還提供了“停止”和“恢復”兩個按鈕，通過前者，可以取消當前正在進行的分區(qū)遷移，通過后者，可以在遷移出現(xiàn)問題后回退遷移過程，修復問題，使系統(tǒng)恢復到正常狀態(tài)。

在分區(qū)遷移的過程中，系統(tǒng)管理員不必一直監(jiān)視著遷移狀態(tài)，可以在 IVM 上繼續(xù)其他方面的系統(tǒng)維護工作。圖 10 和圖 11 分別顯示的是 uli13 和 uli14 上 IVM“查看 / 修改分區(qū)”頁面的內容，可以看到 IVM 正在遷移 uli13lp1，狀態(tài)欄顯示“遷移－ 正在運行”，遷移過程在 uli14 創(chuàng)建了新的分區(qū) uli13lp1，使用了相同數量的 CPU 和內存資源。這兩幅圖是遷移開始時的截圖，這時候源系統(tǒng) uli13 上 uli13lp1 分區(qū)的運行時狀態(tài)還沒有被完全遷移到目標系統(tǒng) uli14，遷移過程還沒有停止源分區(qū)的運行并激活目標分區(qū)，因此在 uli13 上仍舊可以看到 uli13lp1 正常運行時的參考碼“Linux ppc64”，而在 uli14 上，uli13lp1 則顯示了一個遷移中的中間參考碼。類似的，源分區(qū)顯示了 13.47 天“正常運行時間”和 0.03 個“利用的處理器單元數”，而目標分區(qū)因為還沒有開始運行，因此不顯示這些信息。

分區(qū)遷移后

當分區(qū)遷移成功后，我們可以在 uli13 和 uli14 上分別看到如圖 12 和圖 13 所示的分區(qū)狀態(tài)。在源系統(tǒng) uli13 上，遷移過程停止并刪除了 uli13lp1，因此該分區(qū)不復存在，只剩下 VIOS 和分區(qū) uli13lp2。在目標系統(tǒng) uli14 上，遷移過程創(chuàng)建并激活了 uli13lp1，因此可以看到該分區(qū)正在運行中：首先分區(qū)狀態(tài)由“遷移－ 正在進行”變成了“正在運行”，其次參考碼也從不斷變化的中間值變成“Linux ppc64”，最后正常運行時間和利用的處理器單元數也顯示出來了。這表明 uli13lp1 已經從源系統(tǒng) uli13 成功的遷移到目標系統(tǒng) uli14 上了。

再看看虛擬磁盤的映射情況。在 uli13 上，uli13lp2 的虛擬磁盤映射仍然存在，而 uli13lp1 的虛擬磁盤映射則被解除掉了，甚至它所占用的虛擬設備 vhost0 和 vtscsi0/1/2/3/4 也被刪除掉了（見清單 4）。在 uli14 上則增加了 uli13lp1 的虛擬磁盤映射，5 個 SAN 磁盤 hdisk2/5/6/7/8 被映射給了該分區(qū)，顯然這與原來的磁盤映射關系是相同的，同時虛擬設備 vhost0 和 vtscsi0/1/2/3/4 也被創(chuàng)建并用于虛擬磁盤映射（見清單 5）。通過對比清單 5 和清單 2，我們可以發(fā)現(xiàn)兩個系統(tǒng)上映射給 uli13lp1 的 SAN 磁盤都是一樣的，甚至虛擬設備的名稱也都是一樣的。不過虛擬設備的名稱并不要求必須是一樣的，這要看遷移前目標系統(tǒng)上虛擬設備資源的使用情況，如果源系統(tǒng)上所使用的虛擬設備名稱在目標系統(tǒng)上已經被占用了，那么分區(qū)遷移時只能使用其他的設備名稱，只要保證磁盤映射關系相同就可以了。在本文所舉的例子中，由于 uli14 在遷移前除了 VIOS 外沒有其他分區(qū)，uli13lp1 在 uli13 上所占用的虛擬設備名稱在 uli14 上并沒有被使用，因此遷移過程在目標系統(tǒng)上創(chuàng)建的虛擬設備也使用了相同的名稱。

清單 4：遷移后 uli13 上的虛擬磁盤映射

$ lsdev | grep MPIO
hdisk0 Available MPIO Other FC SCSI Disk Drive
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost1 Available Virtual SCSI Server Adapter
vtscsi5 Available Virtual Target Device - Disk
vtscsi6 Available Virtual Target Device - Disk
vtscsi7 Available Virtual Target Device - Disk
vtscsi8 Available Virtual Target Device - Disk
vtscsi9 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost1 U7998.61X.100390A-V1-C13 0x00000000

VTD vtscsi5
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400300000000

VTD vtscsi6
Status Available
LUN 0x8200000000000000
Backing device hdisk9
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400B00000000

VTD vtscsi7
Status Available
LUN 0x8300000000000000
Backing device hdisk10
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400C00000000

VTD vtscsi8
Status Available
LUN 0x8400000000000000
Backing device hdisk11
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400D00000000

VTD vtscsi9
Status Available
LUN 0x8500000000000000
Backing device hdisk12
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400E00000000

$

清單 5：遷移后 uli14 上的虛擬磁盤映射

$ lsdev | grep MPIO
hdisk0 Available MPIO Other FC SCSI Disk Drive
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost0 Available Virtual SCSI Server Adapter
vtscsi0 Available Virtual Target Device - Disk
vtscsi1 Available Virtual Target Device - Disk
vtscsi2 Available Virtual Target Device - Disk
vtscsi3 Available Virtual Target Device - Disk
vtscsi4 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost0 U7998.60X.100E7DA-V1-C11 0x00000001

VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk2
Physloc U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400400000000

VTD vtscsi1
Status Available
LUN 0x8200000000000000
Backing device hdisk5
Physloc U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400700000000

VTD vtscsi2
Status Available
LUN 0x8300000000000000
Backing device hdisk6
Physloc U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400800000000

VTD vtscsi3
Status Available
LUN 0x8400000000000000
Backing device hdisk7
Physloc U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400900000000

VTD vtscsi4
Status Available
LUN 0x8500000000000000
Backing device hdisk8
Physloc U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400A00000000

$

查看遷移狀態(tài)

上面說到系統(tǒng)管理員可以在分區(qū)遷移開始后在 IVM 上繼續(xù)其他方面的系統(tǒng)管理工作，而不需要一直監(jiān)視著分區(qū)遷移的狀態(tài)。那么通過什么途徑能夠再次查看分區(qū)遷移的狀態(tài)呢？

第一種方法是使用任務列表中“狀態(tài)”選項（如圖 14 所示）。在源系統(tǒng)的 IVM 上選擇了該功能后，用戶就可以再次看到分區(qū)遷移的狀態(tài)頁面了（如圖 15 所示），通過該頁面用戶可以監(jiān)視，停止或者恢復分區(qū)遷移。

另外一種方法是使用“服務管理”中的“監(jiān)視任務”功能（如圖 16 左部所示）。在源系統(tǒng)上選擇了該功能后，IVM 會在窗口的右部顯示所有任務的一個列表，其中包括分區(qū)遷移任務（如圖 16 右部所示）。每個分區(qū)遷移任務只對應列表中的一項，遷移狀態(tài)被持續(xù)的更新到該項中，因此每次看到的都是最新的狀態(tài)。選擇其中某個分區(qū)遷移任務，點擊“屬性”按鈕，就可以看到當前分區(qū)遷移的狀態(tài)（如圖 16 右下角窗口所示）。圖 16 所示的是 uli13lp1 遷移成功后的狀態(tài)，如果在遷移過程中查看該項，則可以看到遷移的進度。

命令行界面

除了上述 GUI 界面可用于分區(qū)遷移外，IVM 還提供了命令行界面（CLI）。GUI 界面使得系統(tǒng)管理員能夠更加直觀方便的進行分區(qū)遷移操作，而命令行界面則對于有計劃的分區(qū)遷移和自動測試特別有用。

與 HMC 一樣，IVM 也提供了 migrlpar 和 lslparmigr 兩個新命令用于分區(qū)遷移。命令 migrlpar 用于檢查，開始，停止分區(qū)遷移并從錯誤中恢復；命令 lslparmigr 用于查看分區(qū)遷移的狀態(tài)。不過與 HMC 相比，IVM 提供的命令在語法上稍有不同。從清單 6 和清單 7 可以看出，IVM 命令行主要增加了 --ip <target HMC/IVM IP address>，-u <target HMC/IVM username> 和 --async 三個選項。

清單 6：IVM 上分區(qū)遷移命令的語法

 migrlpar [-o s | m | r | v -m <managed system> [-t <managed system>] [-
 -ip <target HMC/IVM IP address> [-u <target HMC/IVM username>]] -p
 <partition name> |--id <partition ID>[-n <profile name>][-f <input
 data file> | -i "input data>"] [-w <wait time>] [-d <detail level>] [-
 -async] [-v] [--force] [--stderr] [--help]

 lslparmigr -r manager | lpar | msp | procpool | sys | virtualio [-m
 <managed system] [-t <managed system>] [--ip <target HMC/IVM IP
 address> [-u <target HMC/IVM username>]] [--filter "<filter data>"] [-F
 [<attribute names>]] [--header] [--stderr] [--help]

清單 7：HMC 上分區(qū)遷移命令的語法

 migrlpar -o {m | r | s | v}
 -m managed-system [-t target-managed-system]
 {-p partition-name | --id partition-ID} [-n profile-name]
 [{-f input-data-file | -i "input-data"}]
 [-w wait-time] [-d detail-level] [-v] [--force]
 [--help]

 lslparmigr -r {lpar | msp | procpool | sys | virtualio}
 -m managed-system [-t target-managed-system]
 [--filter "filter-data"]
 [-F [attribute-names] [--header]] [--help]

選項 --ip 用于指明目標 HMC/IVM 的主機名或者 IP 地址，該選項與 -t <managed system> 選項比較容易引起混淆，因為系統(tǒng)管理員很可能將 IVM 的主機名與整個系統(tǒng)的名稱設置成一樣，用戶需要注意不要把兩者混為一談。在本文的例子中，目標 IVM（或者說目標 IVM 的宿主 VIOS）的主機名是 uli14，可以通過 hostname 來查看（見清單 8）；而刀片服務器 uli14 的系統(tǒng)名稱是 Server-7998-60X-SN100E7DA，可以通過 lssyscfg（見清單 8）或者 IVM GUI 界面“查看 / 修改系統(tǒng)屬性”的“系統(tǒng)名稱”字段（如圖 17 所示）來查看。

清單 8：uli14 的主機名和系統(tǒng)名稱

$ hostname
uli14
$ lssyscfg -r sys -F name
Server-7998-60X-SN100E7DA
$

選項 -u 用于指明登陸目標 HMC/IVM 所需的用戶名。如果分區(qū)遷移命令需要用戶名但是用戶沒有提供 -u 選項，那么遷移過程會自動使用執(zhí)行該命令的用戶名。

如果使用了 --async 選項，那么命令 migrlpar 在遷移過程中完成遷移的驗證后就馬上返回，遷移過程繼續(xù)進行，這樣系統(tǒng)管理員就不需要等待整個遷移過程的完成，可以進行其他操作。如果系統(tǒng)管理員在做完其他操作后想查看分區(qū)遷移的狀態(tài)，可以使用 lslparmigr 命令（見表單 9）。當遷移過程還在繼續(xù)進行，那么 lslparmigr 顯示“Migration Starting”狀態(tài)；如果遷移已經完成，那么 lslparmigr 顯示“Not Migrating”狀態(tài)。

清單 9：用命令行進行分區(qū)遷移

用 migrlpar 進行分區(qū)遷移，使用 --async 選項
$ hostname
uli13
$ lssyscfg -r sys -F name
Server-7998-61X-SN100390A 
$ migrlpar -o m -m Server-7998-61X-SN100390A -t Server-7998-60X-SN100E7DA --ip uli14 
 -u padmin -p uli13lp1 --async
$

使用 --async 選項的 migrlpar 返回后遷移繼續(xù)進行，可以使用 lslparmigr 查看遷移狀態(tài)
$ lslparmigr -r lpar -m Server-7998-61X-SN100390A --filter "lpar_names=uli13lp1"
name=uli13lp1,lpar_id=2,migration_state=Migration 
Starting,migration_type=active,dest_sys_name=Server-7998-60X-SN100E7DA,dest_lpar_id=2,
source_msp_name=uli13,source_msp_id=1,dest_msp_name=uli14,dest_msp_id=1,
bytes_transmitted=2366013,bytes_remaining=1090875392,remote_manager=uli14,
remote_user=padmin
$

等待一段時間，分區(qū)遷移完成，再使用 lslparmigr 查看遷移狀態(tài)
$ lslparmigr -r lpar -m Server-7998-61X-SN100390A --filter "lpar_names=uli13lp1"
name=uli13lp1,lpar_id=2,migration_state=Not Migrating
$

用 migrlpar 進行分區(qū)遷移，不使用 --async 選項，命令返回后馬上用 lslparmigr 查看遷移狀態(tài)
$ migrlpar -o m -m Server-7998-61X-SN100390A -t Server-7998-60X-SN100E7DA --ip uli14 
-u padmin -p uli13lp1 -w 5
$ lslparmigr -r lpar -m Server-7998-61X-SN100390A --filter "lpar_names=uli13lp1"
name=uli13lp1,lpar_id=2,migration_state=Not Migrating
$

IVM 和 HMC 上分區(qū)遷移的比較

從上述討論中我們可以看到，相對于 HMC，IVM 上的動態(tài)分區(qū)遷移相對簡化，這與 IVM 的設計原則是一致的。IVM 和 HMC 上的分區(qū)遷移所需的配置基本相同，比如對 System p 平臺，F(xiàn)irmware 和 VIOS 版本，網絡和外部存儲的配置，RMC（Resource Monitoring and Control）daemon，以及被遷移分區(qū)所運行的操作系統(tǒng)版本的要求是相同的，而且被遷移分區(qū)都不能屬于任何一個“Partition workload groups”；而由于 IVM 和 HMC 在管理界面的截然不同，因此操作過程相差較大。下面列舉的是兩種管理方式下動態(tài)分區(qū)遷移不同點的一些對比：

• 服務器的管理：由 HMC 管理時，源和目標服務器必須由同一臺 HMC 來管理，分區(qū)遷移由該 HMC 來協(xié)調；由 IVM 管理時，每臺服務器由各自的 IVM 進行管理，分區(qū)遷移由兩個 IVM 協(xié)調進行。

• MSP 屬性：在 HMC 上，需要激活 VIOS 上的 MSP 屬性才能進行分區(qū)遷移；而在 IVM 上，MSP 是默認打開的，不需要激活。

• MSP 的個數：在 HMC 上，一個系統(tǒng)上可以存在多個 MSP，每個 MSP 都可以用于分區(qū)遷移；而在 IVM 上，VIOS 就是 MSP，有且僅有一個 MSP。

• GUI 界面：GUI 操作界面的截然不同是顯而易見的，不過兩者之間還是有不少相似之處，比如都提供驗證和遷移功能等。

• CLI 界面：相對于 HMC 而言，IVM 的用于分區(qū)遷移的命令主要增加了 --ip <target HMC/IVM IP address>，-u <target HMC/IVM username> 和 --async 三個選項。

• -m 和 -t 選項的可選性：在 HMC 上使用命令 migrlpar 進行動態(tài)分區(qū)遷移時，-m <managed system> 和 -t <managed system> 都是必須的，這是因為 HMC 管理著多臺服務器，如果不提供這些消息，HMC 無法知道哪個是源系統(tǒng)，哪個是目標系統(tǒng)。而在 IVM 上，-m <managed system> 則是可選的（見清單 10），這是因為一個 IVM 只管理著一臺服務器，因此源系統(tǒng)就是發(fā)起分區(qū)遷移的 IVM 所在的系統(tǒng)；依此類推，-t <managed system> 本來也可以是可選的，因為源系統(tǒng)上的 IVM 可以通過 -ip 和 -u 選項和與目標系統(tǒng)上的 IVM 進行通信，自動獲取目標系統(tǒng)的名稱，但是事實上該選項在進行分區(qū)遷移時是必須的（見清單 10）。

清單 10：-m 和 -t 選項的可選性

$ migrlpar -o m --ip uli14 -u padmin -p uli13lp1
[VIOSE01040120-0006] Required parameter -t or its value is missing or not valid.

$ migrlpar -o m -t Server-7998-60X-SN100E7DA --ip uli14 -u padmin -p uli13lp1
$	

• 用戶名和密碼：由于同一臺 HMC 管理著參與動態(tài)分區(qū)遷移的兩臺服務器，因此遷移的時候不需要指定登陸到目標 HMC 的用戶名和密碼；而當兩臺服務器分別由兩個不同的 IVM 來管理時，就需要指定登陸到目標 IVM 的用戶名和密碼。

• Profile：在 HMC 上進行分區(qū)遷移時，用戶可以指定一個 profile 名稱用于記錄遷移后分區(qū)當前的配置，保留現(xiàn)有的 profile。而在 IVM 上，因為每個邏輯分區(qū)有且僅有一個 profile，因此不需要指定新的 profile 名稱，分區(qū)遷移過程總是把遷移后的分區(qū)配置記錄在該 profile 里面；所以，IVM 的 GUI 界面并不提供輸入新的 profile 的域，并且命令 migrlpar 所提供的“-n profile-name”選項并不起作用。

• 等待時間（wait time）：該參數是指等待由 HMC 或 IVM 向被遷移分區(qū)所發(fā)出的命令執(zhí)行完成所花的最長時間（以分鐘為單位）。在 HMC 上，分區(qū)遷移的 GUI 向導提供了該域，允許用戶設定新的等待時間；而在 IVM 上，GUI 界面并不提供該域，因此只能使用默認的等待時間。當在 HMC 或者 IVM 上使用命令行進行分區(qū)遷移時，可以通過“-w <wait time>”來設定等待時間。

• 其他特性：在 HMC 上進行分區(qū)遷移要避免使用“Barrier Synchronization Register”和“Huge pages”等特性，否則遷移驗證會失敗；而因為簡化設計的緣故，IVM 并沒有提供這些特性，因此也就不需要檢查分區(qū)是否使用這些特性了。

這里還需要澄清 VASI（Virtual Asynchronous Services Interface）和物理 I/O 設備這兩點。

• VASI 是 MSP 和 Hypervisor 之間進行通信的一個虛擬設備。在源系統(tǒng)上，MSP 通過 VASI 從 Hypervisor 獲取分區(qū)的運行時狀態(tài)，然后通過網絡傳送給目標系統(tǒng)的 MSP；在目標系統(tǒng)上，MSP 通過 VASI 把分區(qū)的運行時狀態(tài)傳送給 Hypervisor。在 IVM 和 HMC 兩種情況下，VASI 都是必須的。在早期支持動態(tài)分區(qū)遷移的 VIOS 版本（比如 VIOS 1.5.0.0）中，VASI 是需要用戶自己去創(chuàng)建的；而在較新版本的 VIOS（比如 VIOS 1.5.2.0）中，VASI 是系統(tǒng)自動創(chuàng)建的。

• 動態(tài)分區(qū)遷移對物理 I/O 設備的遷移做了限制：活動遷移不能使用物理設備，在遷移開始之前必須手動把所有物理設備刪除掉；非活動遷移可以使用物理設備，但是遷移過程會自動把物理設備刪除掉，因此如果要在目標分區(qū)使用物理設備，那么需要在遷移完成之后手動把物理設備加入目標分區(qū)的配置文件。在 HMC 上，邏輯分區(qū)擁有物理 I/O 設備是很正常的事情，用戶在進行分區(qū)遷移之前要按照上述要求去處理物理設備的使用。版本較低的 VIOS，比如 VIOS 1.5.0.0 上的 IVM 只支持虛擬設備，除 VIOS 外，其他分區(qū)所使用的網卡和磁盤都是虛擬的；而從 VIOS 版本 1.5.1.1 開始，IVM 可以將物理設備直接分配給分區(qū)來使用，這時用戶也同樣需要注意上述要求。

小結

本文介紹了如何在 IBM 集成虛擬化管理器— IVM 上進行動態(tài)分區(qū)遷移，包括遷移所需的配置，遷移的驗證，發(fā)起和狀態(tài)的查看，以及用于遷移的命令。本文還對比了在 IVM 和 HMC 上的分區(qū)遷移，雖然兩者的差別不是非常大，但是管理界面上的截然不同使得兩者的操作方式差別較大。與 HMC 相比，IVM 上的動態(tài)分區(qū)遷移操作過程較為簡化，這與 IVM 的設計原則是一致的。