全域工作負載管理員版本需知

與外部 CPU 和系統控制的相容性

全域工作負載管理員預期在部署 SRD 時，具備系統上可用 CPU 的完整控制權。但是有時候必須手動調整，例如：

與 HP Integrity 虛擬機器的相容性

全域工作負載管理員 A.03.00.00 版與 HP Integrity VM 早於 A.02.00 版的版本不相容。欲使用 gWLM A.03.00.00 版管理虛擬機器，HP 建議您升級至 HP Integrity VM A.03.00 版或更新版。

若未升級，可能會見到下列訊息：

Unable to deploy SRD 名稱:A VM encountered with no size

或

Unable to deploy SRD '名稱':guestCpuSetEntitlement ():hpvm_nonvm_cpu_set_entitlement (HPVM_NONVM, (100.000000,100.000000),FALSE) failed: (0,90)

與 PRM 和 WLM 的相容性

您無法使用 gWLM 搭配程序資源管理員 (Process Resource Manager，PRM) 或工作負載管理員 (Workload Manager，WLM) 在相同時間管理相同系統。若您試圖這麼做，便會出現一個指出實際管理系統的應用程式出現持有鎖定狀態的訊息。若要在此情況下使用 gWLM，需先關閉持有鎖定的應用程式。

若為 PRM，請輸入下列命令：

# /opt/prm/bin/prmconfig -d
# /opt/prm/bin/prmconfig -r

若為 WLM，請輸入下列命令：

# /opt/wlm/bin/wlmd -k

與全域隨機補充包的相容性

若需搭配使用 gWLM 與全域隨機補充包 (Global Instant Capacity) 之限制的相關資訊，請造訪 http://docs.hp.com/en/vse.html，找出「Using Global Workload Manager 3.0 with Global Instant Capacity」白皮書。

與虛擬分區的罕見不相容性

視工作負載的特性而定，gWLM 可快速轉移 CPU 資源。此快速轉移作業可能 (雖然機會甚微) 會造成競逐 (race) 狀況，使虛擬分區毀損，也可能造成當機，而產生一或多個下列訊息：

No Chosen CPU on the cell-cannot proceed with NB PDC.

或

PDC_PAT_EVENT_SET_MODE(2) call returned error

轉移虛擬機器

若自隸屬 SRD 的 VM 主機轉移虛擬機器，則在新的 VM 主機上將虛擬機器新增至 SRD 前，必須先自該 SRD 移除虛擬機器。

轉移虛擬機器前先自 SRD 移除它。自 SRD 移除虛擬機器前先轉移它可能會導致下列狀況，視您使用的介面不同而異。

gWLM 3.0 的瑕疵修正內容

全域工作負載管理員 A.03.00.00 版包括下列瑕疵修正程式。

昇級以分區為基礎的 SRD 時，需要重新探索

若是使用 gWLM 並擁有下列以分區為基礎類型的 SRD，且將分區中的 gWLM 代理程式從 gWLM A.01.x 升級至 gWLM A.03.00.00，您不能將相同複合系統中的其他分區加入 SRD：

經常使用 TiCAP

全域工作負載管理員可以視需要啟動 TiCAP 以滿足 SRD 規則。為避免不必要的 TiCAP 消耗，您必須有足夠數量具可用永久授權的 CPU。若您的 SRD 大於此數量，便會消耗 TiCAP 以滿足 SRD 的需求。

gWLM 的工作負載未追隨相關聯的 Serviceguard 套件

gWLM 一次只能在一個部署的 SRD 中管理一個工作負載。因此，若工作負載直接與一個 Serviceguard 套件相關聯 (在 Workload Definition 對話中使用選取工具)，則 gWLM 只能在一個它可能在其上執行的主機上管理它。

若虛擬機器與一個 Serviceguard 套件相關聯，則虛擬機器在每個 VM 主機上會由個別的工作負載代表。

不管是哪一種情形，只要工作負載追隨相關聯的 Serviceguard 套件，您目前就無法管理單一的一個工作負載。

「單元-本機」處理器與 iCAP 環境

在使用 iCAP 的 nPartition 中使用虛擬分區以及「單元-本機」處理器會導致 icod_modify 命令失敗。

允許複合系統內的多個 SRD 使用 TiCAP

全域工作負載管理員允許複合系統內的多個 SRD 使用 TiCAP；應避免此情況發生。

變更大型 SRD 的配置緩慢

變更已部署大型 SRD 的配置可能需要很長的時間 (數分鐘) 方能生效。

gWLM CPU 轉移的事件可能會影響 HP SIM CMS 的效能

HP 產品系統故障管理 (System Fault Management，SFM) 和事件監視服務 (Event Monitoring Service，EMS，特別是硬體監視程式) 會在轉移 CPU 時產生事件或預警。視工作負載的特性而定，gWLM 可快速轉移 CPU。此快速轉移作業會隨著時間推移而造成極大量的事件，因而影響 HP SIM CMS 的效能。

CMS 的回應速度遲緩

CMS 的回應速度遲緩。

在較舊的 CMS 上安裝較新的 gWLM 代理程式，會讓系統無法使用

您可以在使用較舊 gWLM 的 CMS 上安裝較新的 gWLM 代理程式。例如，您可以在具 CMS A.02.00.00.x 版的系統上安裝 A.03.00.00 版代理程式。 此配置無效並會讓系統無法使用。

刪除工作負載耗時很長

一旦提出刪除工作負載的要求，會花費長時間 (數分鐘) 來完成刪除作業。

解決方案

輸入下列命令即可自 gWLM 資料庫移除歷程監視和配置資料：

# gwlm history --truncate --truncate=<CCYY/MM/DD>

若不想調整資料庫，您可以利用 gwlm delete 命令同時刪除多個工作負載：

若需相關資訊，請參閱 gwlm(1M)。

Integrity VM 阻止 pset 和 fss 群組的探索

在已安裝 Integrity VM 的系統上安裝 gWLM 代理程式時，即便 pset 和 fss 群組存在，找尋作業仍只報告 Integrity VM 區間。

僅與受管理同層成員 (Sibling) 的工作負載方能增至具巢狀分區的 SRD

利用 gWLM 命令行介面時，不能將工作負載增至具巢狀分區的 SRD，除非該 SRD 已在管理該工作負載的同層成員。

無法自巢狀分區 SRD 中移除工作負載

試圖自具巢狀分區的 SRD 中移除最後一個 (預設值) fss 群組，您可能會看到包括下列內文的訊息：

Unable to remove workload 工作負載_名稱:Attempting to remove a compartment with an unachievably low Fixed policy size.Increase the Fixed policy resource amount and try again.

使用巢狀分區時 nPartition 過時的大小

監視在 HP-UX 11i v1 系統上 nPartition 內有虛擬分區的 SRD，nPartition 受監視的大小有可能是過時的。

syslog 中出現「dangerous REALTIME job」訊息

若在已有 Integrity VM A.02.00 版的系統上安裝 gWLM A.03.00.00 版時，syslog 中會見到下列形式的訊息：

vm_fssagt[2461]:dangerous REALTIME job 2686 gwlmagent

在 gwlmagent 處可能會見到 parstatus、HPUXChildWrap，或 wbemexec。

關機期間錯誤資訊

您可能會看到類似下列的訊息：

Information Error during shutdown.The unbinding of objects in the registry may have failed, and the workload management lock has not been released.Associated Exception com.hp.gwlm.common.JniPlatformException:prm_ctrl_rel_cfg_lock failed because vm_fssagt:8343 is the lock owner

管理具 pset 限制 fss 群組系統上的 fss 群組

當系統有 pset 時，gWLM 僅使用 fss 群組的 pset 0。gWLM 可以管理僅配置給 pset 0 的 CPU。

解決方案

無解決方案；這就是在有 pset 的系統上施行 fss 群組的情形。您仍可以在 pset 0 內繼續您的 fss 群組 (不管理其他的 pset)、取而代之利用 pset 管理 (忽略 fss 群組)，或是利用下列命令移除所有的 pset (不包括 pset 0)：

# psrset -d all

探索作業不會顯示已停止虛擬機器的最新資訊

全域工作負載管理員探索作業不一定會報告已停止虛擬機器的最新資訊。明確地說，當虛擬機器停止且 vCPU 的數量已變更時，gWLM 探索作業不會顯示變更的 vCPU 數量；而是顯示最近一次啟動虛擬機器時的 vCPU 數量。

多張網路介面卡

比起其他類型的應用程式，屬於主從式應用程式的 gWLM 對於主機的網路配置較為敏感。它只支援單一網路網域內的管理動作。例如，假如您的 CMS 主機具備多張網路介面卡並連線至多個不同網路，gWLM 便會要求完全合格的主機名稱解析為可以取得欲管理 gWLM 代理程式可到達的 IP 位址。

當主機連線到下列兩個項目時，通常會發生這個問題：

全域工作負載管理員會試圖偵測和報告會造成不想要的行為的網路配置問題，不過有時候這類偵測的結果只能記錄在日誌檔中。

不支援主機名稱別名

gWLM 不支援主機名稱別名。僅支援標準的 DNS 主機名稱 (完全合格的網域名稱)。

主機名稱上限為 64 個字元

主機名稱的長度不得超過 64 個字元。

無法建置單一共享資源網域

您可能會在 gWLM 的 HP SIM 介面中看到下列訊息：

Unable to build a single shared resource domain from the set of specified hosts:我的主機A.我的網域.com 我的主機B.我的網域.com

探索區間時出現錯誤

當您使用 Manage New Systems 精靈或是 gwlm discover 命令時，可能會顯示下列訊息：

Error during discovery of compartments.

此外，/var/opt/gwlm/gwlmagent.log.0 檔案包含下列訊息：

com.hp.gwlm.common.PlatformException:/usr/sbin/parstatus -w exited with a non-zero exit status.Captured stderr is:Error: Unable to get the local partition number.

代理程式與 CMS 的配置不同步

有時候，gWLM 代理程式和 gWLM CMS 會對於是否已確實部署某 SRD 有不同的判斷。當您使用 Ctrl-C 中斷 gwlm deploy 或 undeploy 命令時，會發生此情況。此外，若在儲存 gWLM 配置時出現錯誤，也會發生此問題。配置會在部署後儲存到 gWLM 儲存庫中。若部署成功但儲存失敗，gWLM 代理程式會視為已部署 SRD，而 CMS 則否。

解決方案

使用 --force 選項搭配 gwlm deploy 或 gwlm undeploy，同步化代理程式和 CMS。

例如，執行下列命令以強制代理程式和 CMS 視 SRD 為已部署，將您的 SRD 名稱替換為 SRD：

# /opt/gwlm/bin/gwlm deploy --srd=SRD --force

若需 gwlm 命令的相關資訊，請參閱 gwlm(1M)。

The Lock is Already Held By ...訊息

您可能重複看到類似下列的任一訊息：

解決方案

此情況是正常，除非當相同鎖定 (使用者和時間) 持續超過 10 分鐘。在此情況下，停止後再重新啟動 gwlmcmsd 即可清除鎖定，不過您可能必須等待一分鐘方能使用 gWLM：使用下列命令：

	附註： 停止 gwlmcmsd 會停用虛擬化管理員和容量規劃員。

# /opt/gwlm/bin/gwlmcmsd --stop # /opt/gwlm/bin/gwlmcmsd

失去或出現非預期的歷程資料

您可能沒有可供繪圖的歷程資料；不過您確定在這段有問題的時間之內確實有部署 SRD。

還有一個類似的問題，就是在您選取預期系統活動高峰時段後，卻發現記述圖僅顯示有限的活動。同樣的，您也可能預期某時段的活動非常少，但是繪圖卻顯示許多活動。

目前正在載入即時資料

當您試圖檢視即時報告時，可能會看到下列訊息：

Real-time data is currently loading, please wait...You might also verify that the remote node is running and SRDs have been deployed.

資料在即時監視中消失

全域工作負載管理員可能未顯示 SRD 的監控更新資訊，不論是命令行或透過 HP SIM 中的圖形介面皆然。當試圖重組 SRD 時發生逾時會造成此種情況，SRD 仍處於的狀況是必須重新啟動在它每一個受管理節點上的代理程式。原因亦可能是因為受管理節點關閉、未執行它的 gwlmagent，或是在懸滯狀況中。

若受管理的節點關閉或未在執行 gwlmagent，便會看到下列訊息：

The gWLM agent process on the host is not running -- start the agent and retry.

若受管理的節點懸滯，或 SRD 需要重新啟動它所有的代理程式，徵狀包括：

gwlm monitor 運作不正常

gwlm monitor 命令似乎運作不正常

解決方案

使用 gwlm monitor 時，利用 --srd=srd 明確指定 SRD：

# gwlm monitor --srd=srd

樣本在啟動或結束 gwlmreport 輸出時不見了

gwlmreport 送出報表的報告時段，是從報表開始的當天午夜零時開始，到報表結束當天的午夜十二點結束。報表排除任何與報表開始或結束午夜時段重疊的樣本。

將規則權重設為零造成不當配置

此問題僅會影響 gWLM A.02.00.00.x 版代理程式。

規則權重可以在資源過多時，協助 gWLM 決定資源配置。當用於 SRD 的所有規則均設為相同的權重值時，資源應該會平均配置到相關的工作負載。然而，將 SRD 內所有規則的權重設為零，會造成單一工作負載配置到所有過多資源。

具固定規則的工作負載較要求的取得更多的資源

在具巢狀分區的 SRD 內，指派固定規則 (固定值的總數小於父區間的下限) 導致工作負載取得較在固定規則內指定還多的資源。

彙聚率和擁有借用/使用量規則

此問題影響 gWLM A.01.01.x 代理程式和 gWLM A.02.00.00.x 代理程式。

當您在定義規則時選擇性指定的彙聚率值 (convergence rate)，只會影響自訂規則。擁有借用 (OwnBorrow) 和使用量規則不會受影響。

自訂量測標準在重新部署時消失

自訂規則會使用您透過 gwlmsend 命令所提供的規則值。若您重新部署具有自訂規則的 SRD，該規則標準的最新值就會消失。在此情況下，gWLM 會根據工作負載規則指定的最小要求進行其配置。工作負載還會接收符合所有規則後，依然存在的任何 CPU 資源。

gwlm 命令核心傾印

試圖在 /var 已滿時執行 gwlm 命令導致核心傾印。

無法建立新的本地執行緒

可能會顯示包含下列內文的訊息：

...unable to create new native thread

出現多個以虛擬分區為基礎的 SRD

gWLM 通常不允許您在同一時間，於單一 nPartition 或系統上建立多個以虛擬分區為基礎的 SRD。然而，當多位 gWLM 使用者幾乎在同時部署 SRD 時，gWLM 可能能會不小心允許多個 SRD 存在。

只允許部署單一 SRD

您可能會看到類似下列的訊息：

Error trying to deploy SRD, mysystem.vpar.000 to mysystem2.mydomain.com. SRD, mysystem2.fss.000 is already deployed.Only one SRD is allowed to be deployed.

fss 群組中的應用程式懸滯

在 HP-UX 11i v2 (B.11.23) 中，當 fss 群組內的應用程式在單一處理器虛擬分區、nPartition 或系統中執行時，可能會懸滯。

不同 conditionItem 元素的相同接受的順序值

當您利用 compositePolicyDefinition 元素在 XML 配置檔中定義條件規則時，利用 conditionItem 元素指定條件。針對每一個 conditionItem 元素，指定一個 gWLM 用來決定評估順序的順序值。 gWLM 目前接受相同 compositePolicyDefinition 元素中不同 conditionItem 元素的相同順序值，但無法評估它們且不會告知使用者。此時 gWLM 應要會產生錯誤。

命令集未置於正確工作負載中

當區間以 pset 或 fss 群組為基礎時，gWLM 允許您將命令集放在使用具有替代名稱之應用程式記錄的區間中。只有在所使用的 shell 或編譯器列於 /etc/shells 檔案中時，才能這樣做。perl 通常不在此檔案中。因此，perl 命令集 (以及其他任何以 shell 或編譯器為基礎，且未列在 /etc/shells 中的命令集) 的放置位置不正確。

執行檔不受此問題影響。

解決方案

將 /opt/perl/bin/perl，以及任何其他需要的 shell 或編譯器增至 /etc/shells。全域工作負載管理員會在 30 秒內辨識新增的 shell 或編譯器。

	附註： 由於命令集不需要完整的路徑名稱，使用者可以使用新命令集或封裝的命令集名稱存取以 pset 或 fss 群組為基礎的區間 (若不用此法便無法存取)。

處理程序移動到預設的 pset 或預設的 fss 群組

會失去所有以 gwlmplace 命令在受管理節點上的處理程序放置處，若：

在這些情況下，處理程序的位置會根據任何適用的應用程式記錄或使用者記錄。若無紀錄存在，會將非 root 處理程序置於預設的 pset 或預設的 fss 群組；root 處理程序則留在原處。

使用 psrset 的處理程序放置處被忽略

當 gWLM 管理系統上的 pset 時，系統上的每個處理程序均必須進入工作負載。gWLM 會根據您在建立或編輯工作負載定義時所指定的應用程式記錄或使用者記錄，進行處理程序的放置。若無記錄，處理程序則會遵循線上輔助說明主題「pset /fss group tips」中「Precedence of placement techniques」一節的放置規則。

若您使用 psrset 命令將處理程序放入 pset，gWLM 可能會將處理程序放到預設的 pset 中。

無法移除已棄置的 fss 群組

gWLM 建立的 fss 群組被棄置，且無法輕易移除。有多種原因造成此種情況。例如，當您管理以 fss 群組為基礎的 SRD 時，使用了第二個 CMS；原因可能是因為原本的 CMS 已經關閉。這樣可以讓 SRD 留下您無法移除的 fss 群組。

解決方案

您可使用 HP SIM 介面建立自動整合現有 fss 群組的新 SRD。

或者可移除 fss 群組，此時有幾種選項。若已安裝 PRM，請輸入下列命令：

# /opt/prm/bin/prmconfig -r

若未安裝 PRM，請使用下列程序：

1. 執行探索：

   # /opt/gwlm/bin/gwlm discover 主機 --file=myfile.xml \ --type=fss

   其中的主機是具有 fss 群組的主機。

2. 將 myfile.xml 匯入配置儲存庫：

   # /opt/gwlm/bin/gwlm import --file=myfile.xml

3. 執行下列命令並檢查輸出中包含主機的名稱，以便判斷 SRD 名稱：

   # /opt/gwlm/bin/gwlm list

   例如，名稱為主機.fss.xyz (其中 xyz 是 0-9 的數字)。

4. 部署 SRD：

   # /opt/gwlm/bin/gwlm deploy --srd=主機.fss.xyz

5. 解除部署 SRD：

   # /opt/gwlm/bin/gwlm undeploy --srd=主機.fss.xyz

此時，fss 群組應該已從系統中移除。不過，這些群組的工作負載定義仍保留在 gWLM 配置庫中。您可以使用 HP SIM 中的 gWLM 介面移除那些定義和 SRD 定義。選擇 ToolsVSE Management 後，再按一下 Shared Resource Domain 頁籤。選擇具 fss 群組的 SRD 後，再選擇 DeleteShared Resource Domain。

大小/配置少於虛擬機器的規則下限

在已部署 SRD 中虛擬機器的大小或配置可能會較它們的規則下限還少。

NONVM 目前大小是負的

當您在主機上部署 SRD 時，若 VM 主機上的 CPU 超額預定 (oversubscribed)，gWLM 顯示 NONVM 目前的大小為負值。

取消管理已開啟的虛擬機器會讓 SRD 解除部署

取消管理已啟動的虛擬機器時，會讓 SRD 解除部署，雖然會顯示下列的訊息：

The virtual machine VM_名稱 on host 主機名稱 is on but does not have an associated gWLM policy.Please turn the virtual machine off, or apply a gWLM policy to provide the necessary resources.

日誌檔副檔名不是 .log.0、.log.1 和 .log.2

全域工作負載管理員設計為使用 .log.0、.log.1，和 .log.2 作為日誌檔的副檔名，使用 Java 鎖定檔案，確保在任何特定時間內，只能有一個 gWLM 處理程序更新日誌。從 Java 1.4.2.06 版開始的檔案鎖定功能允許以 .log.0.n 的副檔名格式建立檔案，其中 n 是某整數。

解決方案

使用 Java 1.4.2.06 版或更新版時，欲檢查日誌有無錯誤，請使用下列命令查看哪些檔案具有最新的錯誤訊息：

# /bin/ls -ltr /var/opt/gwlm/*log*

接著，您可以使用 /usr/bin/tail 檢視最近更新日誌檔的訊息。

若要傳送日誌檔給 HP 支援中心，請利用下列命令建立 tar 檔案：

# cd / # tar cvf /tmp/gwlmlogs4support.tar var/opt/gwlm/*log*

然後，將 /tmp/gwlmlogs4support.tar 檔案傳送到 HP 支援中心。