Global Workload Manager

局限性

• 本地化行为  从 4.0 发行版开始，gWLM 已被本地化为多种语言。但是：

  • 管理 4.0 版之前的 gwlmagent 时，某些错误消息仍以英语显示。

  • 无论浏览器语言环境如何，报告给 HP SIM 的事件均以英语进行报告。

  • 对浏览器语言环境设置的更改将在下列情况下得到反映：

    • 在 VSEMgmt 软件中启动下一个用户界面操作时

    • 下次登录 HP SIM 时

  • 无论语言环境设置如何，gwlmagent 和 gwlmcmsd 的属性文件均以英语文件进行分析。因此，请注意在英语使用句点的地方使用逗号。

  • 某些项始终用英语显示：

    • gwlmagent 和 gwlmcmsd 的启动消息

    • 日志文件

    • 初始配置中的消息

• 无法管理其中包含非活动单元或已解除配置的核心的分区 gWLM 不支持对其中包含非活动单元或已解除配置的核心的分区进行管理（gWLM 可能会错误地尝试分配这些不可用的资源）。

  解决办法 配置核心，以及激活单元。

• 无法构建单个共享资源域  可能会在 HP SIM 的 gWLM 界面中显示以下消息：

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

  解决办法  该消息表明指定的主机之间没有受支持的资源共享机制。在下列情况下，将显示该消息：

  • 已在不同组合系统中指定主机。

  • 已在组合系统的不同 nPartition 中指定主机，但 nPartition 之间没有共享的 iCAP 使用权。

  如果收到该消息，请执行下列操作：

  • 检查指定的受管节点上的 /var/opt/gwlm/gwlmagent.log.0 文件，以查找错误消息。

  • 如果已重命名分区，则重新启动组合系统中的代理可更正该问题。

• 使用嵌套分区时 nPartition 的大小过时（此问题适用于 gWLM 2.x 和 3.x 代理）。  在监视 HP-UX 11i v1 系统上的 nPartition 中具有虚拟分区的 SRD 时，nPartition 的受监视大小可能已过时。

  解决办法  无须执行操作。请忽略为 HP-UX 11i v1 系统上的具有嵌套分区的 SRD 中的 nPartition 所显示的大小值。

• 与 HP Integrity Virtual Machines 的兼容性  Global Workload Manager A.04.00.07 与 HP Integrity VM A.02.00 或更低版本不兼容。如果要使用 gWLM A.04.00.07 管理虚拟机，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)

  解决办法  如有可能，请升级至 HP Integrity VM A.03.00 或更高版本。

  如果无法对 HP Integrity Virtual Machines A.01.20 版进行升级，则必须在 VM Host 上安装 gWLM 代理 A.02.00.00 版。

  如果无法从 HP Integrity Virtual Machines A.02.00 进行升级，请安装 gWLM 代理 A.02.50.00 或使用 gWLM A.04.00.07 来只管理以百分比形式指定动力保障能力的虚拟机（也就是说，不会管理以 CPU 周期形式指定动力保障能力的虚拟机）。

  要获取 gWLM 代理的早期版本以及该配置的相关帮助，请通过电子邮件地址<gwlmfeedback@rsn.hp.com> 与 HP 联系。

• 与 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

• 与 Global Instant Capacity 的兼容性  有关 Global Instant Capacity 和 gWLM 一起使用时的限制的信息，请访问 http://docs.hp.com/en/vse.html，并查阅白皮书《Using Global Workload Manager with Global Instant Capacity》。

• 少数情况下与虚拟分区不兼容  根据工作负荷的特性，gWLM 可快速地迁移 CPU 资源。在极少数情况下，此频繁迁移可潜在地产生一种争用状态，从而导致虚拟分区崩溃。同时，还可能使系统出现混乱，并生成下列一个或多个消息：

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

  或

  PDC_PAT_EVENT_SET_MODE(2) call returned error

  解决办法  升级至 vPar A.03.04 可解决此问题。

  对于 vPar 的早期版本，可按照下列方法解决此问题：通过路径分配为每个单元至少分配一个 CPU，作为至少一个虚拟分区的绑定 CPUzzz（可以是任何虚拟分区）。这样，可确保在 CPU 迁移时不进行重新指定。例如，如果有四个单元（0、1、2 和 3），每个单元有四个 CPU（10、11、12 和 13）和四个虚拟分区（vpar1、vpar2、vpar3 和 vpar4），则应将 0/1x、1/1x、2/1x 和 3/1x 分别分配给 vpar1、vpar2、vpar3 和 vpar4，其中 x 为 0、1、2、3。

• 升级基于分区的 SRD 需要重新发现  如果正使用 gWLM 且拥有下列两种基于分区的 SRD 中的一种，并且已将分区中的 gWLM 代理从 gWLM A.01.x 升级到 gWLM A.04.00.07，则不能将同一组合系统中的其他分区添加到该 SRD：

  • nPartition 内部的基于 vPar 的 SRD

  • 使用 iCAP 的基于 nPartition 的 SRD

  解决办法  在 CMS 上使用以下步骤重新建立 SRD：

  1. 对于已部署的 SRD，请重新发现该 SRD。对于基于 vPar 的 SRD，请输入以下命令：

     # gwlm discover --type=vpar \ --file=/tmp/myfile.xml 主机

     对于基于 nPartition 的 SRD，请输入以下命令：

     # gwlm discover --type=npar \ --file=/tmp/myfile.xml 主机

     在这些命令中，用 SRD 中的分区的列表（以空格分隔）替换主机。

  2. 对 /tmp/myfile.xml 文件进行下列调整，如 gwlmxml(4) 中所述：

     • 请确保将 sharedResourceDomain 元素中的 mode 属性设置为所需的值（Managed 或 Advisory）：

       mode="Managed"

     • 确保将 sharedResourceDomain 元素的 interval 属性设置为所需的值：

       interval="x"

     • 如果想要 gWLM 根据需要分配 TiCAP，请确保将 sharedResourceDomain 元素的 ticapMode 属性设置为 all：

       ticapMode="all"

     • 请确保隔离专区定义中的 workloadReference 条目正确，并且其自身会调整工作负荷定义中的名称。例如，该条目可能是主机.OTHER.2，而不是主机.OTHER。

  3. 导入文件以重新创建 SRD：

     # gwlm import --file=/tmp/myfile.xml --clobber

     因为已经部署了 SRD，所以在导入时会部署新的 SRD 定义，以取代原先的 SRD。

• gWLM 中的工作负荷不与 Serviceguard 程序包关联 除虚拟机以外，gWLM 一次只能在一个已部署的 SRD 中管理工作负荷。因此，如果工作负荷与 Serviceguard 程序包直接关联（通过 Workload Definition 对话框中的选择器来设置），gWLM 只能在可能运行该工作负荷的一个主机上来管理该工作负荷。但管理此类工作负荷可能会破坏 Virutalization Manager 和 Capacity Advisor 对群集成员之间的工作负荷利用率的跟踪。因此，建议不要直接管理与 Serviceguard 程序包关联的工作负荷。

  解决办法 对于与 Serviceguard 程序包关联的工作负荷可能故障切换到的所有主机，必须将策略应用于封闭的操作系统实例（虚拟分区或 nPartition）。根据提供的程序包，可使用 gWLM 条件策略来更改资源分配。这样，便可以控制封闭操作系统实例的资源分配，并仍可以通过 Virtualization Manager 监视工作负荷。

• 不支持主机名别名  gWLM 不支持主机名别名，仅支持规范的 DNS 主机名（完全限定的域名）。

  解决办法  当通过 HP SIM 或在 gwlm 命令中使用的 XML 文件来配置 gWLM 时，仅使用规范的 DNS 名称。

主要问题

• 在更早版本的 CMS 上安装较新的 gWLM 代理导致系统不受支持  可以在使用更早版本 gWLM 的 CMS 上安装较新的 gWLM 代理。例如，可以在使用 CMS A.02.00.00.x 的系统上安装 A.04.00.07 代理。此配置无效并将使 VSE 管理 CMS 软件不可用。从 gWLM A.04.00.07 开始，CMS 软件会验证代理软件版本是否在过去的两个主要发行版中，以及该版本是否超过当前发行版。

  解决办法  更新 CMS 版本。此更新还将安装相应的代理（由于 gWLM 要求 SRD 中的所有受管节点均具有相同的代理版本，因此必须在包含 CMS 的 SRD 中的所有其他受管节点上更新代理）。有关执行此更新的信息，请参阅《VSE 管理软件安装与更新指南》。

• gWLM 无法在使用某些时区设置时启动 在使用某些时区设置时，gwlmcmsd 和 gwlmagent 可能无法启动。尝试调用其中任一个守护程序时，gwlmagent.log.0 文件或 gwlmcmsd.log.0 文件中将显示以下消息：

  Unable to call method, 'main', with signature, '([Ljava/lang/String;)V', in class, 'com/hp/gwlm/node/Node'. Exception in thread "main"

  解决办法  使用 Java 1.5.0.12 或更高版本。

• gWLM 命令核心转储  当 /var 已满时尝试运行 gwlm 命令导致核心转储。

  解决办法  在 /var 中保留可用空间。

• 无法创建新的本机线程  此时可能会显示包含以下文本的消息：

  ...unable to create new native thread

  解决办法  出现此问题的原因是将下列内核参数设置得过低：

  • max_thread_proc

    将 max_thread_proc 至少设置为 256。

  • nkthread

    将 nkthread 设置为适当的值，以便支持 max_thread_proc 值以及系统中所有其他进程所需的线程数。

次要问题

• 使用 pset 隔离专区开始管理受监视的工作负荷 如果尝试通过应用某个策略并使用 pset 隔离专区管理一组受监视的工作负荷，则可能会出现以下错误：

  The value '0' specified for 'Total Size' must be a positive integer value.

  此错误会在尝试完成 Manage Systems & Workloads Wizard 的 Workload & Policies 设置时出现。

  如果尝试管理的一组 pset 隔离专区所需的核心数超出受管节点上的可用核心数，则将显示此消息。pset 的最小大小是一个核心，因此所需的核心数至少为要管理的工作负荷数。如果系统上没有足够的资源来管理 pset 隔离专区中的受监视工作负荷集，则无法计算 Total Size 字段。

  解决办法  可以使用基于 fss 组（具有较小的最小大小）的隔离专区管理工作负荷，或向分区或 SRD 中添加资源以便满足 pset 的最小大小要求。

• 定量使用 TiCAP  为了满足 SRD 策略，Global Workload Manager 可根据需要激活 TiCAP。要避免不必要的 TiCAP 损耗，必须拥有足够数量的带有永久许可证的 CPU。如果 SRD 大于此数量，则需要消耗 TiCAP 来满足 SRD 的需要。

  解决办法  请在创建 SRD 之前停用 TiCAP 资源。此时处于活动状态的任何 TiCAP 资源均包含在 SRD 中，因此每当部署该 SRD 时均会消耗这些资源。

• 单元本地处理器和 iCAP 环境  在使用 iCAP 的 nPartition 中使用带有虚拟分区的单元本地处理器，会导致 icod_modify 命令失败。

  解决办法  不要使用单元规格来分配 CPU。请考虑使用硬件路径来向虚拟分区分配 CPU。

  或者，要使用单元本地处理器，请在 HP-UX 11i v2 (B.11.23) 上更新至 vPar A.04.04 或在 HP-UX 11i v3 (B.11.31) 上更新至 vPar A.05.01。

• 允许组合系统中的多个 SRD 使用 TiCAP  Global Workload Manager 可允许组合系统中的多个 SRD 使用 TiCAP；它应防止这种情况的发生。

  解决办法 不要以这种方式配置 SRD。

• 对大型 SRD 执行配置更改的速度太慢  对已部署的大型 SRD 的配置进行的更改，可能需要较长的时间（几分钟）才能生效。

  解决办法  尚无解决办法。完成更改所需要的时间取决于与该 SRD 中的所有隔离专区通信所用的时间。

• gWLM CPU 迁移事件可能会影响 HP SIM CMS 的性能  当迁移 CPU 时，HP 产品 System Fault Management (SFM) 和事件监视服务（尤其是 EMS 硬件监视程序）将生成某些事件或指示。根据工作负荷的特性，gWLM 可快速地迁移 CPU。随着时间的推移，此频繁迁移可产生大量事件，从而对 HP SIM CMS 的性能产生负面影响。

  解决办法  可以使用下列选项作为解决办法：

  选项 1

  对于由 gWLM 管理的运行 HP-UX 11i v3 的系统，请安装修补软件 PHCO_36126 和 PHSS_36078（这些修补软件包含在 2007 年 9 月操作环境更新发行版中）。EMS 硬件监视程序的修复程序也可从 2007 年 9 月操作环境更新发行版中获取。即便应用了这些修补软件和修复程序，仍然会在每次更改 CPU 数目时生成一个事件。

  对于由 gWLM 管理的运行 HP-UX 11i v2 的系统，请升级至 2007 年 6 月操作环境更新发行版。

  选项 2

  在 CMS 上升级至 HP SIM C.05.01.00.01.xx。缺省情况下，此版本的 HP SIM 不会订阅这些事件，并且不会降低性能。

  选项 3

  如果要订阅事件，请在 HP SIM 中设置自动清除事件功能。

  有关以上任何一种解决办法的详细信息，请参阅 HP SIM 文档资料（可从 http://www.hp.com/go/hpsim 获得）。

• CMS 响应太慢  CMS 响应太慢。

  解决办法  在 CMS 上为 gwlm list 命令计时。如果花费的时间超过 10 秒，请执行下列步骤：

  1. 在文件 /etc/opt/gwlm/conf/gwlmcms.properties (HP-UX) 或 安装路径\VirtualServerEnvironment\conf\gwlmcms.properties (Windows) 中，通过将 com.hp.gwlm.cms.cachesize 属性的值增大 25% 来增大 CMS 数据库的缓存大小（该大小越接近 2 的乘方，缓存的内存效率越高。如果目标缓存大小接近 2 的乘方，请将其四舍五入到下一乘方值。例如，如果目标缓存大小为 60000，请将其四舍五入到 66000）。

  2. 使用以下命令停止并重新启动 gwlmcmsd。

     	注释： 停止 gwlmcmsd 将禁用 Virtualization Manager 和 Capacity Advisor。

     # gwlmcmsd --stop # gwlmcmsd

• 删除工作负荷需要较长的时间  发出删除工作负荷的请求后，可能需要较长的时间（几分钟）才能完成删除操作。

  解决办法  通过输入以下命令，从 gWLM 数据库中删除旧的历史监视和配置数据：

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

  如果不想删除数据库的数据，可使用 gwlm delete 命令同时删除多个工作负荷。

  有关详细信息，请参阅 gwlm(1M)。

• Integrity VM 阻止发现 pset 和 fss 组  在安装了 Integrity VM 的系统上安装 gWLM 代理时，发现操作将仅报告 Integrity VM 隔离专区，即使存在 pset 和 fss 组也是如此。

  解决办法  要发现系统上的 pset 或 fss 组，必须删除 Integrity VM。

• 只可以将具有同级受管工作负荷的工作负荷添加到具有嵌套分区的 SRD  在使用 gWLM 命令行界面时，除非工作负荷在 SRD 中已经有一个同级受管工作负荷，否则不能将此工作负荷添加到此具有嵌套分区的 SRD 中。

  解决办法  当使用 HP SIM 中的 gWLM 界面时，不会出现此问题。只需按照 Manage Systems and Workloads 向导（可通过选择 CreateShared Resource Domain 来访问）第 1 步的说明，并选择要包含在一个 SRD 中的一组主机。

• 无法从嵌套分区 SRD 删除工作负荷  在尝试从具有嵌套分区的 SRD 中删除最后一个（缺省）fss 组时，可能出现一条包含以下文本的消息：

  Unable to remove workload workload_name:Attempting to remove a compartment with an unachievably low Fixed policy size.Increase the Fixed policy resource amount and try again.

  解决办法  取消部署 SRD 并将其删除。然后创建一个不包含要删除的 fss 组的新 SRD。

• 组合 pset 和虚拟分区  在虚拟分区上使用 pset 时，按路径或单元规格向虚拟分区分配 CPU 可能会导致进程在删除 CPU 后丢失其附属处理器集。

  解决办法 有两种解决办法：

  • 不要按路径或单元规格向虚拟分区分配 CPU。

  • 将 pset 0（缺省/其他工作负荷）的 gWLM 策略最小值设置为大于或等于特定于路径的 CPU 与特定于单元的 CPU 之和。

• 版本低于 4.0 的 vPar 拒绝在虚拟分区中嵌套 Pset 的配置  如果 vPar 版本低于 vPar A.04.00，则 gWLM 不支持在虚拟分区中嵌套 pset。但 gWLM 并不始终拒绝此类配置，而 gWLM 4.0 确实会拒绝这些配置。因此，在开始使用 gWLM 4.0 代理时，可能会拒绝对 gWLM 2.x 或 gWLM 3.x 使用的配置。在给定此类配置的情况下，如果在升级代理之前取消部署 SRD，则重新部署 SRD 将失败，并显示错误消息。如果在升级代理后 SRD 处于已部署状态，则代理将无法恢复 SRD 操作。此外，将生成 SIM 事件以报告验证失败。

  解决办法 有两个解决办法：

  • 更新到 vPar A.04.00 或更高版本。

  • 更新配置，使得不会在虚拟分区中嵌套 pset。

• 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。

  解决办法  可以安全地忽略此消息。这些进程不是实时进程（如果愿意，可升级至 Integrity VM A.03.00，它可以正确标识这些进程，并且不会生成该消息）。

• 关闭时发生信息错误  系统将显示类似以下内容的消息：

  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 只将 pset 0 用于 fss 组。gWLM 只能管理分配给 pset 0 的 CPU。

  解决办法  尚无解决办法；在具有 pset 的系统上就是这样实现 fss 组的。可以继续使 fss 组保留在 pset 0 之内（而不管理其他 pset）、使用 pset 进行管理（忽略 fss 组）或者使用以下命令删除所有 pset（除 pset 0 之外）：

  # psrset -d all

• 发现操作不显示已停止的虚拟机的当前信息  Global Workload Manager 发现操作不总是报告已停止的虚拟机的当前信息。具体而言，当停止了虚拟机并更改了 vCPU 的数量后，gWLM 发现操作并不显示更改后的 vCPU 数量。而是显示虚拟机最近一次启动后的 vCPU 的数量。

  解决办法  在执行发现操作之前启动虚拟机。

• 多个网络接口卡  作为一种客户端/服务器应用程序，gWLM 比其他类型的应用程序对主机的网络配置更为敏感。gWLM 仅支持在单个网络域内进行管理。例如，如果您的 CMS 主机具有连接到多个独立网络的多个网络接口卡，gWLM 要求将完全限定的主机名解析为可由要管理的 gWLM 代理访问的 IP 地址。

  当主机同时连接到下列两项时尤其需要考虑此问题：

  • 通过一个网络接口卡和 IP 地址连接的企业 LAN/WAN

  • 用于与另外一组特定主机（例如群集成员）进行通信的另一个专用内部网络和专用 IP 地址

  Global Workload Manager 会尝试检测和报告那些可能会产生意外行为的网络配置问题，但在某些情况下，进行这种检测的环境只能将问题记录到日志文件中。

  解决办法  如果遇到某些异常行为（例如 gWLM 代理无法更新或报告其工作负荷状态），请检查主机上的 /var/opt/gwlm/glwmagent.log.0 文件来查找错误。

• 配置了错误的主机名或 IP 地址 可能会在日志文件（gwlmagent.log.0 或 gwlmcmsd.log.0）中看到以下消息：

  Unable to determine the network address and/or hostname of the current host. This indicates a mis-configured network and/or a host name resolution issue for this host. For troubleshooting information, see the VSE Management Software Release Notes and search for this message.

  此错误最常见的原因是 /etc/hosts（或 Windows 中的等效位置）中的主机名配置文件存在问题，或 /etc/nsswitch.conf 文件（只限于 HP-UX）的设置不正确。

  背景信息 gWLM 不是一个简单的客户端/服务器应用程序。它涉及：

  • 多个受管节点“服务器”（SRD 中的 gWLM 代理集都是共同管理 SRD 的对等服务器）

  • 处理配置和监视的 CMS 管理服务器

  在正常操作情况下，所有这些组件都需要完全的连接性。gWLM 至少要求每个主机都有一个可以从每个其他交互 gWLM 组件（CMS 以及单个 SRD 中的所有 gWLM 代理）访问的主 IP 地址/主机名（多个 SRD 中的 gWLM 代理不需要在未部署的 SRD 中具有连接性）。

  缺省情况下，gWLM 使用给定主机的主 IP 地址/主机名。但是，可以根据HP Global Workload Manager 用户指南中所述步骤设置一个管理 LAN，以使用其他 IP 地址/主机名。

  解决办法 更正主机配置，使得：

  • 可以正确解析主要的完全限定域名（通过 DNS 或配置文件）

  • IP 地址和主要完全限定域名对于主机一致，并且不会解析为本地主机地址（例如 127.0.0.1）

  可使用下面的步骤检查主机配置。

  1. 运行 vseassist 工具来执行初始网络配置检查。

  2. 要验证 HP-UX 上的配置是否正确，请尝试执行下列步骤：

     1. 使用 hostname 命令获取当前的主机名：

        [mysystem#1] > hostname mysystem

     2. 使用 nslookup 获取为主机配置的 IP 地址：

        [mysystem#2] > nslookup mysystem Trying DNS Name: mysystem.mydomain.com Address: 15.11.100.17

     3. 验证 /etc/hosts 是否为地址配置了相同名称。请注意，第一个名称应是完全限定域名，其后将列出所有别名。

        [mysystem#3] > grep 15.11.100.17 /etc/hosts 15.11.100.17 mysystem.mydomain.com mysystem

     4. 验证对 IP 地址的反向查找是否返回在 /etc/hosts 中配置的同一个完全限定域名。

        [mysystem#4] > nslookup 15.11.100.17 Trying DNS Name: mysystem.mydomain.com Address: 15.11.100.17

  通过编辑 /etc/hosts 修复任何问题，或者参阅下列内容以获取其他信息：

  • 《HP-UX IP Address and Client Management Administrator's Guide》，可从 http://docs.hp.com 联机获得。

  • 《BIND 9 Administrator Reference Manual》，可从 Internet Systems Consortium at http://www.isc.org/sw/bind/arm93 获得。

  • Windows 文档资料。

• 在发现隔离专区期间出现错误  在使用 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.

  解决办法  此问题极有可能是由于 nPartition Provider 软件的版本太旧造成的。Global Workload Manager 使用 nPartition Provider（通常每个版本的 HP-UX 均包含此软件）提供的命令来确定系统的功能。

  还可使用 /opt/vse/bin/vseassist 命令来诊断问题。

  即使不使用 nPartition，也应安装最新的 nPartition 软件。

  对于 HP-UX 11i v1，请使用 B.11.11.01.03.01.01 或更高版本。

  对于适用于 HP 9000 服务器的 HP-UX 11i v2，请使用 B.11.23.01.03.01.01 或更高版本。

  对于适用于 HP Integrity 服务器的 HP-UX 11i v2，请使用 B.11.23.01.04 或更高版本。

  可从下列位置找到此 nPartition Provider：

  • 2005 年 5 月开始按季度发行的 AR CD

  • 软件仓库网站 http://software.hp.com

• 在 gWLM 运行时修改 Java gWLM 不支持删除、覆盖或者修改 gWLM 正在已部署 SRD 的受管节点或 CMS 中使用的 Java 版本的任何操作（包括使用 update-ux）。

  解决办法 在执行任何会影响 gWLM 正在 SRD 中的系统上使用的 Java 版本的操作之前，取消部署 SRD。如果使用 update-ux，则应确保：

  • 在 CMS 上重新启动 CMS 守护程序

    使用命令行界面：/opt/gwlm/bin/gwlmcmsd

    使用 HP SIM 界面：选择菜单配置 Configure VSE Agents Start gWLM CMS Daemon

  • 在受管节点上重新启动代理

    使用命令行界面：/opt/gwlm/bin/gwlmagent

    使用 HP SIM 界面：选择菜单配置 Configure VSE Agents Start gWLM Agent

• 未同步配置代理和 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 名称）：

  # gwlm deploy --srd=SRD --force

  有关 gwlm 命令的详细信息，请参阅 gwlm(1M)。

• 丢失或意外的历史数据（系统时钟存在差异）  即使可以确定在特定时间段已经部署了 SRD，仍然可能没有可用于图形化的历史数据。

  当选择了预期要发生大量系统活动的时间段，而图形仅显示有限的活动时，会出现相关问题。与此类似，您可能预期在某个时间段发生很少的活动，而图形却显示大量活动。

  解决办法  检查 CMS 上的系统时钟与 SRD 中所有系统上的系统时钟是否已同步。如果这些时钟存在很大差异，gWLM 可能无法使来自受管节点的数据与要图形化的时间段相匹配。

• 缺少历史数据（已重新启动 gWLM CMS 守护程序/服务） 在显示工作负荷的历史数据时，工作负荷的历史报告可能为空，或可能显示以下错误消息：

  There is no gWLM historical data for the workload MyWorkload.wkld. The workload has never been managed by gWLM, or the historical data has been removed.

  由于 gWLM 历史数据缓存在 HP SIM 中，因此如果在最初查看历史数据之后重新启动 gWLM CMS 守护程序/服务，则界面会错误地报告没有可用于查看的数据或无法加载数据部分。

  解决办法 

  1. 注销 HP SIM

  2. 再次登录到 HP SIM

  3. 重新生成历史报告

• 当前正在加载实时数据  当尝试查看实时报告时，可能会显示以下消息：

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

  解决办法  通常，这种情况只是暂时出现。如果持续出现此情况，应检查 gwlmagent 守护程序是否正在远程节点上运行。如果正在运行，则停止并重新启动该守护程序。如果此情况仍然存在，则取消部署该 SRD，然后再重新部署。

• 在实时监视中丢失数据  Global Workload Manager 在命令行上或在 HP SIM 的图形界面中可能不会显示 SRD 的监视更新内容。造成这种情况的原因可能是尝试重组 SRD 时超时，这时必须重新启动该 SRD 的每个受管节点上的代理。另外的原因可能是受管节点关闭、挂起或没有运行 gwlmagent。

  如果受管节点关闭或 gwlmagent 未运行，将显示以下消息：

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

  如果受管节点挂起，或者 SRD 需要重新启动其所有代理，其现象可能包括：

  • gwlm monitor 命令的输出结果省略一些 SRD 的数据

  • HP SIM 中的“共享资源域”视图显示多个 SRD 存在严重错误“SRD data is currently stale”。

  解决办法  如果 SRD 不能在一段持续时间内提供实时监视，请重新启动 SRD 中每个受管节点上的 gWLM 代理。

  在 SRD 成员挂起的情况下，当对该 SRD 的实时监视被阻止时，其他 SRD 将继续管理资源。但由于挂起的 SRD 成员，对其他 SRD 的实时监视将可能被阻止。要恢复对其他 SRD 的监视，请执行下列操作：

  1. 取消部署包含挂起成员的 SRD。这可能需要对 gwlm undeploy 命令使用 --force 选项。

  2. 在 CMS 上使用下列命令，重新启动 gwlmcmsd 来清除被阻止的监视：

     # gwlmcmsd --stop # gwlmcmsd

  3. 创建一个新 SRD 来代替被取消部署的那个 SRD，忽略挂起的 SRD 成员。

  4. 一旦挂起的 SRD 成员恢复正常运行后，即可取消部署代替 SRD 并重新部署原来的 SRD，使其恢复到原始状态。

• 创建高级报告时显示“Input date format error:null” 在 gWLM 的 HP SIM 界面中尝试创建高级报告时，可能会显示以下消息：

  Input date format error:null

  当日期的文本字段为空时将生成此消息，即使屏幕上不显示此字段也是如此。

  解决办法 选择其他报告类型，直到显示空日期字段。在该字段中输入一个有效日期，然后重新选择原来的报告类型。

• gwlmreport 输出的开始或结尾处缺失采样数据  来自 gwlmreport 的报告基于某个报告时段，该报告时段从报告开始之日的午夜开始，到报告结束之日的午夜结束。如果报告时段开始或结束时间跨越午夜，则相应交错时段内的采样数据不会包括在该报告中。

  解决办法  尚无解决办法，但应注意此行为。

• 使用 Secure gWLM Communications 工具时出错 在 gWLM 的 HP SIM 界面中使用 Secure gWLM Communications 工具时，可能会显示下列错误消息：

  ERROR: gwlmimportkey failed to import key for 主机名证书文件 on 主机名:keytool error: java.lang.Exception: Input not an X.509 certificate unable to correctly import the server key ERROR: Task 'Secure gWLM Communications' terminating.

  当通信证书文件主机名证书文件已被破坏或无效时，将显示此消息。

  解决办法 

  1. 从 CMS 上的以下位置删除在错误消息中指定的主机名证书文件：

     • HP-UX：

       /etc/opt/gwlm/certs/主机名证书文件

     • Windows：

       C:\Program Files\HP\Virtual Server Environment\conf\certs\主机名证书文件（尽管安装时可能选择了其他路径）

  2. 重新运行 Secure gWLM Communications 工具。

• 将策略权重设置为零导致分配不准确  此问题仅影响 gWLM A.02.00.00.x 代理。

  策略权重有助于 gWLM 在存在剩余资源时确定资源分配。如果将在 SRD 中使用的所有策略的权重设置为同一个值，应使资源平均分配给相关联的工作负荷。但是，如果将 SRD 中的所有策略的权重设置为零，将导致全部剩余资源都分配给单个工作负荷。

  解决办法  将权重值从零更改为一。

• 具有 Fixed 策略的工作负荷获得多于请求的资源  在具有嵌套分区的 SRD 中，在固定值的总和小于父级隔离专区最小值时分配 Fixed 策略，可使工作负荷获得多于在 Fixed 策略中指定的资源。

  解决办法  设置 Fixed 策略，使请求的 CPU 数大于或等于父级隔离专区所需的最小 CPU 数。

• 聚合率和 OwnBorrow/利用率策略  此问题影响 gWLM A.02.00.00.x 代理。

  定义策略时（可选）指定的聚合率值仅影响 custom 策略。OwnBorrow 和利用率策略不受其影响。

  解决办法  尚无解决办法。不过从 gWLM A.02.00.01.x 代理开始，该问题已得到解决。

• 重新部署时丢失定制度量标准  Custom 策略使用通过 gwlmsend 命令提供的度量标准值。如果重新部署具有 custom 策略的 SRD，则会丢失该策略度量标准的最新值。在此情况下，gWLM 的分配将基于工作负荷策略中指定的最低要求。工作负荷还可以接收在满足全部策略后余下的任何 CPU 资源。

  解决办法  在重新部署后立即更新所有 custom 策略的度量标准值。

• 可能出现多个基于虚拟分区的 SRD  gWLM 通常不允许在单个 nPartition 或系统上同时创建多个基于虚拟分区的 SRD。但是，如果多个 gWLM 用户几乎在同一时间部署 SRD，则 gWLM 可能会无意中允许创建这样的多个 SRD。

  解决办法  删除其中一个 SRD，然后通过将被删除的 SRD 中的工作负荷置于其余 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.

  解决办法  将 --force 选项与 gwlm undeploy 命令一起使用来取消部署 SRD，然后在受管节点上重新启动 gwlmagent。

• SRD 部署超时并显示空白屏幕 如果尝试部署 SRD，但：

  • gWLM 超时并显示一个空白屏幕

  • 每个受管节点中存在与以下事件类似的事件：

    gWLM Agent MySystem.MyDomain.com Information Unable to manage the following hosts: Associated Exception Unable to manage the following hosts: MySystem.MyDomain.com: The gWLM agent process on the host is not running -- start the agent and retry.

  需要配置 gWLM 以便使其与多个 LAN 上的主机配合使用。

  解决办法 阅读HP Global Workload Manager 用户指南中的“将 gWLM 与多个 LAN 上的主机配合使用”一节。

• fss 组中的应用程序挂起  在 HP-UX 11i v2 (B.11.23) 上，fss 组内的应用程序在单处理器虚拟分区、nPartition 或系统上运行时可能会挂起。

  解决办法 安装修补软件 PHKL_33052。

• 脚本未放置在正确的工作负荷中  如果隔离专区基于 pset 或 fss 组，则可以通过 gWLM 使用具有备用名称的应用程序记录将脚本放置在该隔离专区中。只有当文件 /etc/shells 中列出了正在使用的 shell 或解释程序时，才可执行此操作。通常，perl 不位于此文件中。因此，未正确放置 perl 脚本（以及其他任何基于未列在 /etc/shells 中的 shell 或解释程序的脚本）。

  可执行文件不受此问题影响。

  解决办法  将 /opt/perl/bin/perl 以及任何其他需要的 shell 或解释程序添加至文件 /etc/shells。Global Workload Manager 将在 30 秒内识别这些添加的 shell 或解释程序。

  	注释： 因为此脚本不需要完整的路径名，所以未授权用户可对新脚本或包装程序使用此脚本名访问基于 pset 或 fss 组的隔离专区（否则将无法访问）。

• 移动到缺省 pset 或缺省 fss 组的进程  在下列条件下，使用 gwlmplace 命令在受管节点上放置的所有进程都将丢失：

  • 重新引导受管节点。

  • 重新启动本地 gwlmagent 守护程序。

  • 取消部署当前的 SRD。

  在这些情况下，将根据适用的任何应用程序记录或用户记录放置进程。如果不存在任何记录，则将非超级用户进程放置到缺省 pset 或缺省 fss 组，将超级用户进程保留在其当时所在的位置。

  解决办法  要在两次重新部署期间保持进程放置不变，请在创建或编辑 gWLM 中的工作负荷定义时，使用 gWLM 的应用程序记录或用户记录。

• 忽略使用 psrset 放置的进程  当 gWLM 正在系统上管理 pset 时，该系统上的每个进程都必须在一个工作负荷下运行。gWLM 将根据您在创建或编辑工作负荷定义时指定的应用程序记录或用户记录来放置进程。如果不存在任何记录，则进程将受放置规则的制约，这些放置规则在联机帮助主题“pset / fss group tips”的“Precedence of placement techniques”部分进行了说明。

  如果使用 psrset 命令在 pset 中放置进程，gWLM 可能将这些进程移动到缺省 pset 中。

  解决办法  要保持进程的放置，请在创建或编辑 gWLM 中的工作负荷定义时，使用 gWLM 的应用程序记录或用户记录。如果使用记录不可行，则使用 gwlmplace 命令。但是，在每次重新部署 SRD 后，必须使用 gwlmplace 命令，将进程放回所需的工作负荷中。

• 无法删除放弃的 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 组即会从系统中消失，但是，fss 组的工作负荷定义仍位于 gWLM 配置储备库中。可以通过使用 HP SIM 中的 gWLM 界面来删除这些定义和 SRD 定义。选择工具VSE Management，然后单击“Shared Resource Domain”标签。选择带有 fss 组的 SRD，然后选择 DeleteShared Resource Domain。

• 大小/分配小于虚拟机的策略最小值  已部署 SRD 中的虚拟机的大小或分配可能显示为小于其策略最小值。

  解决办法  等待几分钟，因为 gWLM 可能需要几分钟的时间才能识别虚拟机在停止和启动状态之间的转换。

• NONVM 的当前大小为负值  在 VM Host 上部署 SRD 时，如果超额订购了 CPU，gWLM 会将 NONVM 的当前大小显示为负值。

  解决办法  有两种解决办法：

  • 调整那些正在运行的虚拟机的动力保障能力，使 CPU 不被超额订购。

  • 停止一个或多个虚拟机，直至那些仍在运行的虚拟机不超额订购 CPU 为止。

• 取消管理已启动的虚拟机导致取消部署 SRD  当尝试取消管理已启动的虚拟机时，即使此时显示以下消息，也会取消部署 SRD：

  The virtual machine VM_name on host hostname 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.

  解决办法  关闭虚拟机并重新部署包含该虚拟机的 SRD。

• 除 .log.0、.log.1 和 .log.2 以外的日志文件扩展名  Global Workload Manager 的日志文件使用文件扩展名 .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*

  然后向 HP 技术支持发送 /tmp/gwlmlogs4support.tar 文件。

• 高级报告无法处理名称开头/结尾包含空格的工作负荷  从 gWLM A.03.00.00 开始，工作负荷名称可以包含空格。但是，用于生成高级报告的 gwlmreport 实用程序无法处理以空格开头或结尾的工作负荷名称。

  解决办法 重命名工作负荷，使其不以空格开头或结尾。

• gwlmreport ovpafeed --dataversion 问题 运行下列命令之一：

  • gwlmreport ovpafeed

  • gwlmreport ovpafeed --dataversion=4.0

  将导致出现错误。

  解决办法 使用下列命令设置供给信息并提取数据

  • gwlmreport ovpafeed --setup --dataversion=3.0

  • gwlmreport ovpafeed --dataversion=3.0

• 确保安全通信时出现错误 尝试确保 gWLM 通信安全时可能会看到类似如下所示的消息：

  keytool error:java.lang.Exception:Key password must be at least 6 characters unable to create keystore /etc/opt/gwlm/certstor/gwlm.keystore unable to create the gwlm keystore at /opt/gwlm/bin/gwlmsslconfig line 184.

  解决办法  重新尝试确保通信安全。