ネットワーク ノード マネージャ 7.51
既知の問題と対策

一般情報

最新のアップデートあるいは対策は、リリースノートの付録をご覧ください。

Java Plug-in の入手またはパッチを調べるときは、サポートする環境の ドキュメントを参照してください。

以下には、トラブルシューティングのセクションもあります。

既知の問題

  • NNM アクティブ問題アナライザ (ovet_poll)
  • NNM ET による検出の制限要因
  • Linux 上の NNM ツール
  • オンラインヘルプとマンページ
  • ダイナミックトランスレーションモードの HP-UX 11i v2 での大規模検出
  • 一般的なトラブルシューティング
  • インストール

    OpenView Operations for Windows

    Windows 2000 および XP で、OVO-W (バージョン 7.2 以前) が既にインストールされているシステムへ NNM をインストールしようとすると、10% のところでハングします。

    この問題への対策は、NNM をインストールする前に、OVO-W のすべてのデーモン (特に、OVTrace.exe) を停止することです。

    「既知の問題」へ戻る

    日本語版 Microsoft Windows プラットフォームでの NNM のインストール

    マルチプロセッサベースまたはハイパースレッディング(HT)システムの日本語版 Microsoft Windows 2003 SP1 または Microsoft Windows 2003 Server R2 上に NNM 7.5 をインストールすると、次のエラーが発生します。

    Application Pop-up: ovcwd.exe
    Application Error: The instruction at "0x ........" reference d memory at "0x ........" . The memory could not be read. Click on OK to terminate the program. 
    Application Pop-up: request_create.exe
    Application Error: The instruction at "0x ........" reference d memory at "0x ........" . The memory could not be read. Click on OK to terminate the program.

    この問題を解決するには、NNM 7.51 メディアキットに含まれている更新された NNM 7.5 Windows CD、または http://www.openview.hp.com/uploads/ovrd/ovr_l_nnm_0001.html にある NNM 7.5 Windows インストールデポを使用してください。

    「既知の問題」へ戻る

    HPOvAvayaIcon のインストール、アンインストールがエラー 1720 で失敗する

    NNM 7.51 アップグレードパックを使ったデバイスエージェントのインストール中に、Avaya Icon のインストールがエラー 1720 で失敗する場合があります。

    この問題を修正するには、Windows Script バージョン 5.6 以降をインストールします。

    暗号化ファイルシステム (Encrypted File System) へのインストール

    Windows 2000 でフォルダーのどれかが暗号化されている場合、インストールは失敗します。 主な現象としては、ovnnmInstallLic.exe が失敗します。 (setup.log ファイルを見てください)

    この状況から復旧するには、以下の手順に従ってください:

    1. Network Node Manager をアンインストールします
    2. フォルダーの暗号化を解除します
    3. Network Node Manager をインストールします
    4. 再びフォルダーを暗号化します

    「既知の問題」へ戻る

    NFS マウントした CD ドライブを使ってインストールする

    NNM のインストール用にリモートの CD ドライブをエクスポートするとき、ドライブアクセスに 'root' 権限を与える必要があります。 CD ドライブがインストールされているマシンで以下のような行を追加します。

    「既知の問題」へ戻る

    ディスク空き容量の解析

    この製品を、Windows 2000 または Windows XP を実行しているシステムにインストールするとき、"コンポーネントの選択" ダイアログ・ボックスの "現在の空き容量:" は実際の空き容量と異なる値を表示することがあります。 選択したドライブに充分な容量があれば、表示情報にかかわらず、インストールを正常に継続できます。

    「既知の問題」へ戻る

    システムのファイアウォール設定

    ファイアウォールをシステムにインストールしている場合は、ファイアウォールがループバック (127.0.0.1) へのアクセスを許可していることを確認してください。

    「既知の問題」へ戻る

    Windows で NNM を標準以外の場所へインストールする場合

    NNM は、レジストリに NNM のインストール場所の情報を登録します。標準のインストール先ではない場所 ( %SystemDrive%¥Program Files¥HP OpenView 以外) に NNM をインストールする場合は、 NNM をインストールする前にサブディレクトリを作成しておく必要があります。 これにより、後から他の OpenView アプリケーションをインストールすることが可能となり、データの保存に (%SystemDrive%¥Program Files¥HP OpenView¥data ではなく) 標準以外の場所を使用できます。

    インストール先を決め、次のディレクトリを作成してください。
    "<install location>¥data"

    「既知の問題」へ戻る

    ターミナルサービスでのインストールで再起動が必要な場合がある

    Network Node Manager 7.51 をターミナルサービスでインストールする場合、 コマンドプロンプトウィンドウで %SystemRoot% を解決できないという問題が起こることがあります。この問題が発生した場合、再起動が必要です。

    「既知の問題」へ戻る

    Problem Diagnosis に設定が必要な場合がある

    Network Node Manager 7.51 を "C:\Program Files\HP OpenView" 以外のディレクトリへインストールするときは、次のコマンドを実行して Problem Diagnosis を設定する必要があります。

    "<installation directory>\pdAE\bin\pdpinstall.vbs <installation directory>"

    これにより、特定の Problem Diagnosis コンポーネントが自分のインストールディレクトリを認識できるようになります。

    「既知の問題」へ戻る

    Microsoft SQL Server が設定されているとインストールエラーが発生する

    システムに以前のバージョンの NNM がインストールされていて、デフォルトデータベースとして Microsoft SQL Server を使用するように設定されている場合、7.51 への移行時にエラーが報告されます。これは、インストールプログラムが不要であるはずの Extended Topology データベースコンポーネントの設定を試みるためです。 Microsoft SQL Server データベースで Extended Topology を実行することはサポートされていません。

    setup.log に ovet_switchTopoDBView.ovpl または tables_topoService.schema の設定についてのエラーが報告されている場合は、無視してかまいません。

    「既知の問題」へ戻る

     

     

    ライセンス関連

    移行の問題

    60日間の一時ライセンスに関する情報は、「ライセンス」セクションを参照してください。

    ライセンスを取得済みの場合のインストール方法

    サポート契約締結ユーザーには、ライセンスが提供されています。 このライセンスを、以下の手順で、移行前にインストールしておく必要があります。

    1. ライセンスを任意のファイルに保存する。
    2. Unix の場合は、スーパーユーザーになる。
    3. コマンド ovnnmInstallLic [license file] を実行する。
    4. $OV_CONF/.license にライセンスが格納されたことを確認する。

    ライセンスをお持ちでない場合の取得およびインストール方法

    NNM 6.4 より前のユーザーの場合:

    1. ovnnmPassword を実行し、NNM 7.51 のライセンスを要求する。
    2. ライセンスを任意のファイルに保存する。
    3. Unix の場合は、スーパーユーザーになる。
    4. コマンド ovnnmInstallLic [license file] を実行する。
    5. $OV_CONF/.license にライセンスが格納されたことを確認する。

    NNM 6.4 のユーザーの場合:

    1. Unix の場合は、スーパーユーザーになる。
    2. ovnnmPassword を実行し、NNM 7.51 のライセンスを要求する。
    3. $OV_CONF/.license に新しいライセンスが格納されたことを確認する。

    NNM 6.4 ユーザーで、HA 環境を使っている場合は、HA ユーザーは電子メールのみによるライセンス要求ができないため、MC ServiceGuard のホワイトペーパーで説明されている HA ライセンスの要求方法に従い、上述の「NNM 6.4 より前のユーザーの場合」の手順を実行してください。

    警告: ovnnmPassword で表示されるテキストボックスにライセンスを入力しないでください。ovnnmPassword は、未知のライセンスを識別するロジックにより、それを受け付けません。 NNM 6.4 より前のユーザーの場合は、ライセンスをファイルに保存し、ovnnmInstallLic を実行する必要があります。

    ovnnmPassword のクラッシュ

    WRQ の Reflection X を実行している PC にディスプレイをリダイレクトしている Solaris システムで、ovnnmPassword (または、その他の Java アプリケーション)を実行すると、JRE (Java Runtime Environment) がクラッシュする場合があります。これは Java に関する既知の問題で、詳細は http://developer.java.sun.com/developer/bugParade/bugs/4068604.html に記述されています。 Reflection X は Sun の JDK 1.1.1 との間で問題があります。 これは、X サーバの持っていないフォントを検索するためです。 これは RX Settings | Fonts | Options で Allow Font Substitution と Allow Font Scaling を有効にすることで解決します。もちろん、Sun 上でフォント・サーバを使えるのなら、それを設定し、RX Settings | Fonts でフォント・パスにフォント・サーバを追加し、RX がそれを使うよう設定するのがベストです。 フォント・サーバの使い方については Font Category で Help をクリックして参照できます。

    「既知の問題」へ戻る

    Linux 上での印刷

    Linux 上での印刷を容易にするには、xpr rpm パッケージをインストールする必要があります。 ダイナミックビューの印刷オプションおよび他のすべてのアプリケーション用にサーバーを設定する必要があります。

    「既知の問題」へ戻る

    ECS Designer の評価用ライセンスを要求する

    "HP OpenView ECS Designer for the NNM" 製品のパスワード要求をするには $OV_CONF/OVLicense/forms/nnm/$LANG ディレクトリのフォームを使用してください。 $OV_CONF/ecs/forms/C ディレクトリのフォームは、スタンドアロンの ECS Designer 製品専用ですので使わないでください。

    「既知の問題」へ戻る

    ECS Designer の評価用ライセンスを要求する

    "HP OpenView ECS Designer for the NNM" 製品のパスワード要求をするには $OV_CONF/OVLicense/forms/nnm/$LANG ディレクトリのフォームを使用してください。 $OV_CONF/ecs/forms/C ディレクトリのフォームは、スタンドアロンの ECS Designer 製品専用ですので使わないでください。

    「既知の問題」へ戻る

    Linux 上のインストール中の rpm エラー

    NNM のインストール中に次のエラーが発生することがあります -

    rpmdb: region error detected; run recovery.
    error: db4 error(-30981) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery
    error: cannot open Packages index using db3 - (-30981)
    このエラーを回避するには、次のコマンドを実行します。
    $ rpm --rebuilddb
    インストールを最初からやり直してください。 ただ、一度インストールに失敗したことで、エラーが発生することがあります。 その場合は、NNM を削除してから再インストールしてください。

    「既知の問題」へ戻る

    Linux 上のインストールエラーからの復旧

    ディスク容量不足、以前の NNM の削除失敗などの理由により NNM のインストールに失敗すると、NNM 固有の RPM がシステムにインストールされたままになることがあります。 その場合は、"$OV_BIN"/remove.nnm スクリプトを実行して NNM 固有の RPM を削除してください。 削除スクリプトのログ(/tmp/nnm_remove.log)が削除の失敗を示していることがあります。 これは通常、以前のインストールが未完了のため NNM 固有の RPM の一部が見つからないことが原因です。 この場合でも、削除スクリプトはインストールされたすべての NNM 固有の RPM を削除しています。
    しかし、/opt/OV、/var/opt/OV、/etc/opt/OV などのディレクトリや、これらのディレクトリ内のサブディレクトリ、ファイルが手動で削除されてしまうと、削除スクリプトは NNM 固有の RPM の削除に失敗します。 したがって、これらのディレクトリやそのサブディレクトリは、決して手動で削除しないでください。

    「既知の問題」へ戻る

    NNM の移行より先に「RNS OVPI and NNM Integration Module」をインストールするとインストールエラーが発生する

    この問題は、Windows プラットフォーム上で RNS 5.0 OVPI and NNM Integration Module を NNM 7.0x と共に実行している場合にのみ発生します。 Windows プラットフォームでは、RNS 5.0 OVPI and NNM Integration Module は "ICO_RNS" サービスをインストールしますが、このサービスは NNM が提供する Java Runtime Environment を使用します。 NNM の移行中に NNM 7.0x の上に NNM 7.5 がインストールされる間にも、このサービスは実行を続けます。 このため、NNM 7.5 のインストールプログラムが新しい Java Runtimr Environment をインストールしようとした時に中断します。 この問題を回避するには、NNM 7.5 をインストールする前に、Windows の ICO_RNS サービスを停止します。 このインストールエラーがすでに発生してしまった場合は、ICO_RNS サービスを停止してから NNM 7.5 のインストールスクリプトを再実行します。 NNM 7.5 のインストールが完了した後、このサービスを再起動する必要があります。

    「既知の問題」へ戻る

    Solaris 10 でのインストール時の警告

    Network Node Manager 7.51 を Solaris 10 にインストールする際、/var/adm/sw/swagent.log に次の警告が残る場合があります。

    "WARNING: The Analysis Phase had warnings. See the above output for details."

    これらの警告が発生しても、Network Node Manager 7.51 のインストールは正常に続行されます。

    「既知の問題」へ戻る

    Solaris 10 でのシンボリックリンク障害

    Solaris 10 プラットフォーム上での HPOvSNMP のインストールにより、シンボリックリンクが失敗します。.

    HPOvSNMP パッケージをインストールする前に、次のように環境変数をエクスポートすることにより、この問題を解決することができます。
    PKG_NONABI_SYMLINKS=true
    export PKG_NONABI_SYMLINKS

    Windows 上の Oracle 10g でのインストールの問題

    Oracle 10g がインストールされた Windows システムに Network Node Manager 7.51 をインストールすると、一部の NNM Perl スクリプトの実行が失敗することがあります。

    この問題を回避するには、Oracle 10g をインストールする前に Network Node Manager 7.51 をインストールするか、 NNM 7.51 メディアキットに含まれている更新された NNM 7.5 Windows CD、または http://www.openview.hp.com/uploads/ovrd/ovr_l_nnm_0001.html にある NNM 7.5 Windows インストールデポを使用して NNM をインストールします。

    「既知の問題」へ戻る

    他社製のカスタムアイコンが表示されない/他社製のメニューが有効にならない

    NNM 7.0 を利用するためのアップデートが完全にはなされなかった他社製統合製品があると、その他社製のアイコンはおそらく表示されません。また、ovw からその他社製デバイスを選ぶと、メニューが淡色表示のままになっているかもしれません。

    これは、$OV_CONF/oid_to_sym ファイルと $OV_CONF/oid_to_sym_reg/ ディレクトリのファイルとの OID マッピングの矛盾が原因です。 これを解決するには、 矛盾しているエントリを編集して矛盾を解消します。 矛盾の解決手順は、 oid_to_sym(4) のリファレンスページの "MIGRATION ISSUES" セクションに記載されています。

    Windows でのネームサービスのパフォーマンス

    Windows 2000 や XP で、ネームサービスのパフォーマンスに関連する問題が発生することがあります。 これらの問題には、netmon, ovet_poll, ovrepld の遅延が含まれます。 さらに、ネームサービスのパフォーマンスに対する警告イベントが発生することもあります。ネームサービス (NetBios も含め) は調整可能です。Microsoft 社の TCP/IP のチューニング を参照してください。『ネットワーク管理ガイド』にも説明があります。

    Windows XP Service Pack 2 が原因でオブジェクトが危険域ステータスになる

    Windows XP の Service Pack 2 がインストールされたシステムで、すべてのオブジェクトが誤ったステータスになるという問題が発生することがあります。 この問題は、インターネットファイアウォールを有効にしている場合に発生します。デフォルトでは、Windows XP Service Pack 2 をインストールすると、ファイアウォールが有効になります。

    NNM では、ファイアウォールを無効にする必要があります。さもないと、ping がファイアウォールにブロックされてしまいます。NNM が Windows 2000 でも実行されているとすると、これが唯一の代替手段です。

    「既知の問題」へ戻る

    ネイティブアラームブラウザでの OAD 名によるアラームフィルタ機能の制限

    OAD を設定している場合、ネイティブアラームブラウザの "重複アドレスドメインとの一致" フィルタの機能は、Web アラームブラウザの "OAD 名による" フィルタ機能との一貫性がありません。

    「既知の問題」へ戻る

    ポーリングコリレータおよびボード停止中コリレータで Cisco Stack MIB が動作しない場合がある

    ポーリングコリレータおよびボード停止中コリレータで Cisco Stack MIB が動作しない場合がある

    「ボード停止中」コリレータと、「ボード停止中」トラップに基づいてポーリングを行うイベントは、古いバージョンの Cisco Stack MIB では動作しません。 動作しない Stack MIB のバージョンは、「モジュール停止中」トラップの varbind 1 が moduleIndex ではなく moduleType のものです。

    「既知の問題」へ戻る

    RAMS と syslog メッセージ

    NNM 7.5 のインストール時に RAMS と syslog の機能が共に有効にされた場合、OSPF の syslog メッセージと RAMS の syslog メッセージが共にアラームブラウザに表示されます。 RAMS の方がより高度な根本原因分析を行うので、OSPF の syslog メッセージは不要です。 OV_Syslog_OSPF_Neighbor_Down イベントを「ログのみ」に変更することを推奨します。 RAMS を使用しない場合は、何も変更する必要はありません。

    「既知の問題」へ戻る

    NNM AE と HSRP デバイス

    NNM AE は、HSRP の検出/管理を有効にしていない場合でも、HSRP デバイスの HSRP 仮想 IP アドレスを検出、管理します。 NNM AE がネットワークに HSRP デバイスを検出した場合は、NNM AE によるこれらのデバイスの管理を有効にしなければなりません。 有効にするには、setupExtTopo.ovpl スクリプトを使用します。 詳細は setupExtTopo.ovpl のリファレンスページ(または UNIX の man ページ)を参照してください。

    「既知の問題」へ戻る

    Web ブラウザに関する既知の問題

    最新のブラウザを使用していることを確認してください。Java Plug-in もインストールする必要があります。どのブラウザがサポートされているか、および JPI のインストール方法については、 サポートする環境を参照してください。

    「既知の問題」へ戻る

    JPI の問題

    Windows 上での JPI 1.4.1 問題

    Windows 上の JPI 1.4.1 ではウィンドウが正しく表示されないことがあります。 この不具合は、ネットワークプレゼンタ、Web アラームブラウザ、その他の NNM Web GUI に次のような現象が現われます。

    ウィンドウを移動するか、サイズを変更するか、影響を受けている領域にカーソルを持っていくかすると、ダイアログボックスのデータが正しく表示されるかもしれません。 これらのアクションによりウィンドウは正しく更新されます。

    「既知の問題」へ戻る

    JPI 1.4.1_03 とエンティティ拡張

    Windows の JPI 1.4.1_03 には、XML ドキュメントのエンティティ拡張の数を制限するシステムプロパティがあります。しかし、システムプロパティはデフォルトでは読むことができません。したがって、このプロパティへアクセスしようとしても失敗し、そのため拡張しようとしても失敗します。

    このセキュリティの問題によって、ホームベースを起動しようとすると、例外が発生します。

    この問題を解決するには、最新の Java Plug-in (「ネットワーク ノード マネージャ 7.51 でサポートする環境」を参照) を入手し、インストールします。

    この JPI を使う必要がある場合には、この問題への対策は、ファイル JRE_PATH/lib/security/java.policy で「grant」とマークされているセクションに、次の 2 行を追加することです。JRE_PATH は 1.4.1_03 JRE へのパスで、通常、Windows の場合は C:\Program Files\Java で、Unix システムの場合は /opt/java です。

    permission java.util.PropertyPermission "entityExpansionLimit", "read";
    permission java.util.PropertyPermission "disallowDoctypeDecl", "read";

    すべてのブラウザを閉じ、java キャッシュをクリアする必要があります。

    同じ内容を、$HOME/.java.policy に置いてもかまいません。

    「既知の問題」へ戻る

    JRE の自動インストール

    JRE 1.4.2 を自動インストールしてホームベースを起動すると、次のようなエラーが表示されることがあります。

    "The Java Runtime Environment could not be loaded from <some path>."

    これは以前の JPI へのパスがキャッシュに残っていることが原因です。

    この問題を解決するには、[スタート->設定->コントロール パネル] と操作して、[Java Plug-In] アイコンをクリックし、[キャッシュ] タブで [キャッシュをクリア] を選択します。

    ユーザーのホームディレクトリの .java ディレクトリの削除が必要な場合もあります。

    「既知の問題」へ戻る

    JPI とリモートデスクトップの接続

    ホームベース (または、別の Java アプリケーション) を実行している PC に接続するのに Microsoft のリモートデスクトップを使うと、Java コンソールに例外が通知されます。

    
    

    java.lang.NullPointerException
    at sun.awt.windows.WWindowPeer.displayChanged(Unknown Source)
    at sun.awt.SunDisplayChanger.notifyListeners(Unknown Source)
    at sun.awt.Win32GraphicsDevice.displayChanged(Unknown Source)
    at sun.awt.Win32GraphicsEnvironment.displayChanged(Unknown Source)
    at sun.awt.windows.WToolkit$4.run(Unknown Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

    この例外は、他の Java アプレットでも通知されるものです。 この例外が通知されても、ホームベースは正常に動作します。

    「既知の問題」へ戻る

    Windows 2003 上での JPI ダウンロード中のエラー 1606

    NNM 7.5 インストール後に最初にダイナミックビューを起動するとき、JVM がオンデマンドでダウンロード、インストールされます。 しかし、Windows 2003 Server (Standard Edition および Enterprise Edition) で JVM をダウンロード、インストールすると次のエラーダイアログが現れます。

    Error 1606. Could not access network location http: //java.sun.com/webapps/download/GetFile/1.4.2-b28/windows-i586/ja142000.cab

    これは、Sun の Java の既知の不具合です。 この問題を解決するには、http://java.com/en/download/help/download_error_codes.jsp

    のページの SOLUTION セクションにある

    Please click here to download the offline package manually」のリンクをクリックして、

    JPI を手動でダウンロード、インストールしてください。 JPI のインストール後にダイナミックビューが利用可能になります。

    「既知の問題」へ戻る

    Ovw

    ovw でアプリケーションの実行が失敗する

    OVIS-NNM コンポーネントのインストール後に Solaris 上で Ovw を実行すると、ovwMapCmd ovis-nnm アプリケーションの実行が失敗します。

    この問題を解決するには、(Ovw を実行する)システムから次のコマンドを実行する必要があります。

    export LD_LIBRARY_PATH=/opt/OV/iodbc/lib 

    Solaris で ovw が 128色を割り当てることができない

    Solaris 10 では、ovw が次の警告を発することがあります。"ovw: 128 色を割り当てることができませんでした。 モノクロ・イメージを使用します。"

    これを回避するには、Solaris 10 の fbconfig コマンドを使って深度を 24 に変更します。 マシンを再起動してから ovw を実行してください。

    詳細は、Solaris 10 の fbconfig のマニュアルページを参照してください。

    「既知の問題」へ戻る

    ダイナミックビュー

    NNM 7.51 のインストール後に、カスタマイズされた変更が失われる

    NNM 7.51 のインストールが原因で、web.xml ファイル($OV_AS/webapps/topology/WEB-INF ディレクトリに存在)が、新しいバージョンのファイルに置換されます。その結果、web.xml ファイルに施されたすべてのカスタマイズされた変更が失われます。カスタマイズされた変更の消失を防ぐために、 NNM 7.51 のインストーラは、NNM 7.51 をインストールする前に、カスタマイズされた web.xml ファイルのコピーを /opt/OV/patches/siiBackup/PHSS_34687/opt/OV/tomcat/jakarta-tomcat-4.0.4/webapps/topology/WEB-INF ディレクトリに保存します。

    web.xml ファイルの次のセクションに施された、カスタマイズされた変更は、このファイルが新しいバージョンで置換されると失われます。

    カスタマイズされた変更を新しいバージョンの web.xml ファイルに残すには、NNM 7.51 のインストール後に次の手順を実行する必要があります。

    1. web.xml ファイル(NNM 7.51 インストーラがインストール前に保存したもの)の次のセクションを、下の表に示す対応する XML ファイルへコピーします。
      セクション XML ファイル
      ユーザ認証情報 userAuthentication.xml
      maxNeighbors および defaultNumOfHops 1NeighborServlet.xml
      maxNodes および enableETFilters 1NodeServlet.xml
      includeDisabled 1IfaceServlet.xml
    2. 次のコマンドを実行して web.xml ファイルを生成します。
    3. 次のコマンドで ovas を再起動します。 これにより、カスタマイズされた変更を、新しいバージョンの web.xml ファイルに保持するプロセスが完了します。

    [編集:管理対象にする/管理対象外にする/追加/削除] メニューはパスワードが必要

    NNM/Starter Edition または NNM/Advanced Edition を実行していて、setupExtTopo.ovpl は実行していない場合は、 ダイナミックビューのメニュー項目 ( [編集:削除...], [編集:ノードの追加...], [編集:管理対象にする], [編集:管理対象外にする]) 用のパスワードが設定されていません。

    上記メニュー項目を表示するには、"$OV_BIN"/dvUsersManager.ovpl を実行してパスワードを設定します。

    詳細は dynamicViewsUsers.xml(4) リファレンスページを参照してください。

    「既知の問題」へ戻る

    ラベル

    ovw のラベルを変更してもダイナミックビュー上のラベルには影響しません。これは、ダイナミックビューのラベルはトポロジデータベースから出力されるのに対し、ovw は、ラベルをローカルに保存するからです。

    「既知の問題」へ戻る

    マウスの右ボタンのクリック

    右クリックで表示されるメニュー項目がブラウザの下部を消してしまうことがあります。 特に、スクロールバーのあるページの下部でクリックした場合に起こります。 回避するには、スクロールバーでノードをブラウザの中央に置いてから右クリックします。

    「既知の問題」へ戻る

    ネームサービス

    ブラウザを実行しているシステムが、管理ステーションの名前 ($OV_DB/openview/ovwdb/ovserver で自動定義されています) を解決して管理ステーションの IP アドレスを得られない場合、ダイナミックビューのアプレットはロードされません。また、インデックスページ (http://<MACHINENAME>:7510/topology/) にイメージが表示されない場合も、この設定ミスが原因です。

    「既知の問題」へ戻る

    アクティブテーブルのヘルプ

    アクティブテーブルから起動されるダイアログには、[ヘルプ] ボタンがありますが、機能しません。 アクティブテーブルの一般的なヘルプは、次の URL にあります。
    http://<machine>:3443/OvCgi/OvWebHelp.exe?Context=cxttsk&Content=cnttsk&Scope=scptsk&Topic=UsingTables
    「:3443」は Unix サーバーの場合にだけ必要で、Windows サーバーの場合は不要です。このヘルプは、ダイアログの説明というよりは、アクティブテーブルの機能が説明されています。

    「既知の問題」へ戻る

    認証・認可

    特定のビューをセキュアアクセスに設定していて、 その認証画面でユーザー名とパスワードの入力を間違えた場合、再入力の画面が表示されるようにはなっていません。アクセスするには、ブラウザを再起動する必要があります。

    「既知の問題」へ戻る

    アクティブテーブルの列の位置変更

    アクティブテーブルで列の位置を変えると、行を選択して他のビューを起動することができなくなります。

    「既知の問題」へ戻る

    ホームベースと IIS

    Windows 2000 Professional を実行しているシステムを指定してホームベースを起動すると、次のようなエラーになることがあります。

    java.lang.NoClassDefFoundError: com/hp/ov/ui/chart/pie/PieChart

    これは、Windows 2000 Professional では IIS に機能制限があり、同時接続数は最大 10 個までとなっているためです。

    対策:  ブラウザで [更新] をクリックしてください。

    「既知の問題」へ戻る

    重複アドレスドメインビューでの複数回の更新

    重複アドレスドメインビューで、ビューの描画が完全に終わる前に [更新] ボタンをクリックすると、 "PortAttachedToAnotherNode" に関する例外が 2、3 個表示され、ビュー上にノードが重複して表示されます。

    対策:  表示を更新したい場合は、ステータスバーに "ダイナミックビューの準備完了" と表示されてから、[更新] ボタンを 1 回だけクリックしてください。

    「既知の問題」へ戻る

    ノード詳細

    ノード詳細の表示方法は 2 通りあります。 @ノード (またはアクティブテーブルのエントリー) をダブルクリックします。 Aノードを選択して、右クリックメニューから選択するか、[表示: 詳細] メニューを選択します。

    重複アドレスドメインのノードの場合は、ダブルクリックによる方法しか使えません。 他の方法ではエラーとなります。

    逆に、Extended Topology による検出でフィルター処理されたノードの場合は、メニューによる方法しか使えず、ダブルクリックするとエラーとなります。

    対策:  [表示: 詳細] メニューでエラーとなった場合は、ダブルクリックしてください。 ダブルクリックしてエラーとなった場合は、[表示: 詳細] メニューを使用してください。

    「既知の問題」へ戻る

    ダイナミックテーブルのソート

    ダイナミックテーブルのテーブルヘッダーの列をクリックしてソート後、ソート順序を逆にするために再度クリックしても逆順になりません。

    対策:  列のヘッダーで右クリックし、[昇順] または [降順] を選択してソートしてください。

    「既知の問題」へ戻る

    近隣接続ビューと Extended Topology: IllegalStateException

    Extended Topology による検出中に SNMP の可用性が一貫していない場合、接続の表示が乱れることがあります。近隣接続ビューの例外エラーとして次のように表示されます。

    Exception: java.lang.IllegalStateException: getNmosIfObjectsForConnection():
    didn't get two interfaces from getInterfacesByObjIDList()
    notFoundList.size():1
    conn:...

    対策:  次のコマンドを実行します。
    $OV_MAIN_PATH/support/NM/ovet_fixTopology.ovpl -fixDanglingConn

    「既知の問題」へ戻る

    ダイナミックビューと Extended Topology: NmosTopoAPIException

    再検出後に、ダイナミックビューのキャッシュに古いトポロジの参照が残ることがあります。例外エラーとしてダイナミックビューに次のように表示されます。

    Exception: com.hp.ov.nmtopology.NmosTopoAPIException: The given Topology Object is invalid
    NmosTopoAPIException: ... is not a vaild Address ID

    対策:  次のコマンドを実行します。

    「既知の問題」へ戻る

    ダイナミックビューとメモリ

    大規模環境では、ovas がメモリを使い果たす可能性があります。ovas が使用する JVM ヒープのサイズは変更可能で、デフォルトでは 128 MB に設定されています。

    ovas がメモリを使い果たした場合、ポップアップダイアログボックスやログメッセージの形で何らかの兆候が現れます。たとえば、ovas.log の次のようなエラーメッセージです。

    Exception trace for java.lang.OutOfMemoryError:
    java.lang.OutOfMemoryError

    ポップアップダイアログでは、次のようなメッセージです。

    Dynamic View servlet exception
    Exception:  java.lang.OutOfMemoryError.

    ovas へのコマンドパラメータを変更して、ヒープサイズを増やすことができます。 2つの重要なパラメータは、-Xmx<size>-Xms<size>> です。 ヒープサイズおよびガーベージコレクションのチューニングの詳細は、Tuning Garbage Collection を参照してください。JVM ヒープに割り当てるメモリが多すぎると、JVM がガーベージコレクションの実行中に一時停止してしまうことがあるので注意してください。

    対策:

    1. JVM に割り当てるメモリの量を決定します。この例では、サイズを 256 MB とします。
    2. $OV_LRF/ovas.lrf を編集します。
    3. 次の行を:
      OVs_YES_START:ovtopmd,ovdbcheck,httpd::OVs_WELL_BEHAVED:15:NOPAUSE:
      次のように変更します:
      OVs_YES_START:ovtopmd,ovdbcheck,httpd:-Xmx256m -Xms256m:OVs_WELL_BEHAVED:15:NOPAUSE:
    4. ovaddobj ovas.lrf" を実行します。
    5. 次のようにアプリケーションサーバーを再起動します: 
      1. ovstop ovas
      2. ovstart ovas

    「既知の問題」へ戻る

    トポロジが非常に多い場合に最初のノードビューが遅い

    ovas 再起動後に最初に表示されるノードビューは、トポロジが非常に多い場合は数分かかることがあります。最初に表示された後は、オブジェクトがキャッシュされ、ノードビューのパフォーマンスが大幅に向上します。

    対策: ありません

    「既知の問題」へ戻る

    スイッチングルーターがスイッチとして表示される

    スイッチングルーターは、isSwitch フラグと isRouter フラグの両方がセットされたデバイスです。 APA は、このデバイスをルーターとして扱います。 しかし、ダイナミックビューでは、このデバイスはスイッチとして8角形のアイコンで表示されます。APA とは異なる扱いなので、混乱を招くおそれがあります。

    対策: ありません

    「既知の問題」へ戻る

     

    Web インタフェース - HP OpenView ランチャー

    Java ベースの Web ランチャー (ovlaunch.exe URL) が立ち上がらない

    ランチャーのウィンドウは閉じないでください。

    ランチャーからアプリケーションを起動しているとき、ランチャーのウィンドウは閉じないでください。 アプリケーションによっては、web スクリプトを実行するのに、ランチャーのフレームを使用します。 ランチャーのウィンドウを閉じるとランチャーのウィンドウから起動されたアプリケーションも終了します。 ネットワークプレゼンタは、この例にあたります。 ランチャーのウィンドウが画面上で邪魔な場合はアイコン化しておくことができます。

    「既知の問題」へ戻る

    Web インタフェース - ネットワークプレゼンタ

    Windows 上の Web ブラウザで JPI 1.4.1 を使用して、ネットワークプレゼンタを表示すると、パナー・ウィンドウが正しく再描画されません。

    「既知の問題」へ戻る

    Web インタフェース - SNMP MIB ブラウザ

    Windows XP では、NNM を初めてインストールした後システムをリブートしなければ、 Web SNMP MIB ブラウザが動作しません。 このリブートによって、IIS がパーミッションを正しく再設定します。 次のようなテキストが表示されるかもしれません: "The specified CGI application misbehaved by not returning a complete set of HTTP headers..."

    「既知の問題」へ戻る

    Web インタフェース - 経路トレース

    Windows XP では、Web版の経路トレース(ダイナミックビューおよびネットワークプレゼンタからアクセス可能) は、 %SystemRoot%\system32\tracert.exeにインターネットユーザー(IUSR)のアクセスパーミッションがあることを前提にしています。デフォルトでは、このパーミッションは拒否されます。Web版の経路トレースを使用するには、インターネットユーザーに tracert.exe へのアクセスを許可するか、このファイルを %OV_BIN% にコピーしてください。

    「既知の問題」へ戻る

    Web インタフェース - レポート設定/レポートプレゼンタ

    レポート設定の変更/表示ウィンドウ内の日本語文字が文字化けします。回避するには Windows 上で Internet Explorer を使用してください。

    PingResponseTime レポートと PingRetries レポートは、レポートを設定してもレポートは作成されますが、データが収集されません。 データ収集は、次の 2 つの手順のいずれかを行うまで開始されません。
    xnmpolling - event を実行するか、次を実行します。

        ovstop netmon
        ovstart netmon
    「既知の問題」へ戻る

    Web インタフェース - レポート変更

    Red Hat Advanced Server 2.1 で Netscape/Mozilla を使用して、すでに作成済みのレポートを変更する場合、レポート変更の UI が表示されません。 レポートの変更には、他のプラットフォーム上でサポート対象の任意のブラウザを使用してください。

    「既知の問題」へ戻る

    Web インタフェース - レポート機能と重複アドレスドメイン

    OAD 内のノードの動作状況レポート、可用性レポート、例外レポート、およびインベントリ レポートを設定することはできません。 しかし、以下の手順により、OAD 内のノードに対する SNMP 収集を有効にすることはできます。

    1. 次のファイルをエディタで開きます。
      %OV_LRF%¥snmpCollect.lrf (Windows の場合)
      $OV_LRF/snmpCollect.lrf (UNIX の場合)
    2. 2 つのコロン (::) の間に、以下の例のように "-z" オプションを挿入し、ファイルを保存します。
      OVs_YES_START:pmd,ovwdb,ovtopmd:-z:OVs_WELL_BEHAVED:20:PAUSE
    3. root または Administrator 権限で、次のコマンドを実行します。
      ovaddobj %OV_LRF%\snmpCollect.lrf (Windows の場合)
      ovaddobj $OV_LRF/snmpCollect.lrf (UNIX の場合)
    4. root または Administrator 権限で、ovstop -c snmpCollect を実行します。
    5. root または Administrator 権限で、ovstart -c snmpCollect を実行します。

    「既知の問題」へ戻る

    Web インタフェース - SNMP データプレゼンタ

    プロキシ・サーバを使用していて、プロキシ・サーバ上で動作している DNS サーバが NNM のデータ・プレゼンタのホスト名を名前解決できない場合、ツリー構造の線が表示されず、不明グラフィックのアイコンが表示されます。 この現象が現れたときには、プロキシ・サーバの使用を無効にし、ブラウザのキャッシュをクリアし、ページを更新してください。 この方法で解決できない場合は、次のようにして、http サーバの http 設定ファイルに http サーバの完全修飾名を設定してください。

    http サーバが UNIX システムで動作している場合:

    設定ファイル /opt/OV/httpd/conf/httpd.confServerName エントリを変更します。 新しい設定を保存後に http サーバを再起動する必要があります。 再起動するには、ovstop を実行し、次に ovstart を実行します。

    「既知の問題」へ戻る

    Web インタフェース - アラームブラウザ

    Web アラーム・ブラウザが Windows 2000/XP/2003 で動作している NNM 管理ステーションに接続中は、Windows ベースの管理ステーションに接続している 1 台のローカル・プリンタへしか印刷されません。 印刷したい場合は、プリンタがプリンタ・ポートの LPT1(PRN), LPT2, または LPT3 のいずれか一つに設定されている必要があります。

    Web ベースのイベント・ブラウザでは、イベント・テーブルがたいていツールバーへオーバーラップします。 対策としてはウィンドウのサイズを (ほんの少しだけでも) 変更すればウィンドウが正しく再描画されます。 これは Windows プラットフォーム上の JPI 1.4 で動かすと起こります。

    「既知の問題」へ戻る

    Web インタフェース - Correlation Composer GUI

    Windows XP/2000 の Correlation Composer からJava Help を印刷しようとすると、 ブラウザがハングすることがあります。これは、Java 1.4 の既知のバグです。詳細は、http://developer.java.sun.com/developer/bugParade/bugs/4768427.html を参照してください。

    複数のユーザーが Composer GUI を立ち上げたり、一人のユーザーが複数の Composer GUI を ECS CMG Composer の [Modify] ボタンから起動した場合は、 コリレータに加えた変更は、最後の「保存」のみが有効となり、 その他の変更は失われます。

    「既知の問題」へ戻る

    Web インタフェース - ovsyslogcfg

    Reflection X バージョン 8.0.5 を実行している PC へリダイレクトした Solaris から ovsyslogcfg を実行すると、次のエラーになります。
    "Xlib: unexpected async reply (sequence 0x77)!"

    対策:  ovsyslogcfg プログラムはコンソールから実行してください。

    「既知の問題」へ戻る

    Web インタフェース - ovweb

    ovweb は、お好みのウェブブラウザで指定したURLを立ち上げるためのユーティリティプログラムです。NNM 6.31 においては、HP-UX および Solaris では、URL中のアンパーサンド文字(&)は「エスケープ」 する必要がありました。

    たとえば(\ に注目してください):

    ovweb "http://somewhere.com?foo=1\&bar=2"

    NNM 7.51 では、ovweb をコマンドラインから実行する場合でシェルが 要求する場合に限り、これらの文字をエスケープする必要があります。 それ以外の場合に エスケープする必要はありません。 たとえば次のように指定します。

    ovweb "http://somewhere.com?foo=1&bar=2"

    または

    ovweb http://somewhere.com?foo=1\&bar=2

    「既知の問題」へ戻る

    データウェアハウス

    組み込みデータベース以外のデータベースをご使用になる場合は、データウェアハウスを使用する前に、ovdwconfig.ovpl を使用してデータウェアハウス スキーマを手動で作成しておく必要があります。

    Oracle を使用する場合:

    すべてのエクスポートツールは ODBC に使用可能です。Oracle を使用するには sql*net をインストールし、設定する必要があります。 デフォルトのデータソースが /etc/opt/OV/share/conf/analysis/system_odbc.ini ファイルに OVoracle と設定されています。 切り替えるには、設定ファイルの "ServerName" パラメータを tnsnames.ora に定義したサーバに変更します。 次に、以下のコマンドを実行します。

    NNM データウェアハウスのツールでの使用のために $ORACLE_HOME を設定するには、ovdwconfig.ovpl に "env" パラメータを指定して、ovdwenvs.conf ファイル内の ORACLE_HOME の値を設定します。 たとえば次のように指定します。

    「既知の問題」へ戻る

    Oracle SID が HP-UX、Solaris、Linux システムで誤設定されることがある

    HP-UX と Solaris システムで、Oracle SID が "openview" ではないにもかかわらず、ファイル listener.ora に Oracle SID が "openview" と設定されてしまうことがあります。 Oracle SID が "openview" ではない場合は、ovdbsetupo3.sh の再実行によりエラーとして報告されます。 修正するには、listener.ora を編集し、$ORACLE_SID の値を設定します。

    ファイルは以下にあります:

    HP-UX 11.X: /etc/listener.ora
    SOLARIS 2.X: /var/opt/oracle/listener.ora
    KUNUX 2.X: $ORACLE_HOME/network/admin/listener.ora

    「既知の問題」へ戻る

    ovbackup と NNM データウェアハウスを使用する場合

    ovbackup.ovpl を使用し、NNM データウェアハウスを使用している場合、 ovbackup.ovpl コマンドが実行されると、組み込みデータベース・サーバに対してもオンライン・バックアップの開始が指示されます。 ロールフォワード復元だけを行うために、デフォルトの定期バックアップを停止しておく必要があります。 定期バックアップの停止方法は次のとおりです。

    1. $OV_DB/analysis/default/solid.ini ファイルを $OV_DB/analysis/default/solid.ini.old ファイルにコピーします。
    2. $OV_DB/analysis/default/solid.ini ファイルを編集します。
    3. "At=<time> backup" エントリをコメント・アウトします。 コメントアウトするには、行の先頭に ";" を挿入します。 たとえば次のようにします。
      ;At=01:00 backup
    4. $OV_DB/analysis/default/solid.ini ファイルを保存します。

    これで組み込みデータベースが ovbackup.ovpl コマンドの実行時にのみバックアップされるようになりました。 ovbackup.ovpl の使用を後日停止する場合は、デフォルトの定期バックアップを元に戻すべきです。 戻すには、$OV_DB/analysis/default/solid.ini.old$OV_DB/analysis/default/solid.ini にコピーします。

    「既知の問題」へ戻る

    データウェアハウスの起動とイベント

    NNM 6.2 では、イベント "OV_DBUp" は、重要度が"重要警戒域"の "エラー"アラームとして定義されていましたが、 このイベントは NNM 6.2 では使用されていませんでした。 NNM 7.51 では、"OV_DBUp" イベントがデータウェアハウスの起動時に常に生成されるようになりました。 trapd.conf ファイルには、このイベントは (NNM 7.51 では)、重要度が"正常域"の "ログのみ"アラームとして定義されています。 このイベントに関し、新規に NNM 7.51 をインストールした場合は問題ありませんが、NNM6.2 から NNM 7.51 へのアップグレードの場合には問題があります。 既存のイベント (OV_DBUp も含まれます) は、アップグレード中に更新されないからです。 したがって、NNM 6.2 からアップグレードした NNM 7.51 では "重要警戒域" アラーム (OV_DBUp) が ovstart が実行されるたびに生成されます。 この問題を解決したい場合は、NNM イベント設定ユーティリティをご使用になり、このイベントを "正常域" 重要度、"ログのみ"アラームに変更してください。 このユーティリティは、ovw の [オプション] メニューにあります。

    「既知の問題」へ戻る

    Windows 2000/XP/2003 のリブート後にデータウェアハウスを再起動する場合

    SQL Server を使用している場合は、リブート前に ovstop コマンドを使用して OpenView を停止しておくことが重要です。 そうしないと OpenView の再起動時に ovdbcheck がエラーになる可能性があります。 ovdbcheck が再接続を試みるとき、SQL Server がまだリブートから回復している途中だからです。 これを回避するには、単に SQL Server が回復処理を終了するのを待ち、終わってから、ovstart を実行します。

    「既知の問題」へ戻る

    Service Pack の再インストール

    Windows service pack は Microsoft のコンポーネント (たとえば Microsoft Peer Web Services) を追加した場合や、次のエラー (または SNMP エラー) を受取った場合に再インストールする必要があります。

    ODBC バージョンの不一致を警告するダイアログ:

    次のような、ODBC ユーティリティ間のバージョンの不一致を知らせる "ODBC Driver Manager" ポップアップ・ウィンドウが表示されることがあります。

       The ODBC resource DLL
    ?? (C:\WINNT40\System32\odbcint.dll)
       is a different version than the ODBC driver manager
    ?? (C:\WINNNT40\System32\ODBC32.dll).
    

    正しいデータ処理結果を確保したい場合は、ODBC コンポーネントを再インストールする必要があります。 これは、必ずしも NNM ではなく、ODBC コンポーネントをインストールするアプリケーションのいずれかをインストールしたときにたまたま起こってしまったものです。解決方法は最新の Service Pack を再インストールするしかありません。 NNM には、Windows ODBC コンポーネントは含まれていません。 この不一致 DLL 問題は Windows の既知の問題です。詳細は Microsoft 社の Article PSS ID Number: Q170769 を参照してください。

    「既知の問題」へ戻る

    リモートコンソール

    HP-UX または Solaris NNM管理ステーションに接続する日本語 Windows 2000/XP/2003 上のNNMリモート・コンソールの場合、他社の NFS client 製品が registration, symbols, conf の各サブディレクトリ下のシンボリックリンク Japanese_Japan.932 をたどるよう設定する必要があります。 日本語 Windows 上のNNMリモート・コンソールを動作させたとき、ovw ウィンドウ中のメニューが英語で表示される場合、シンボリックリンク Japanese_Japan.932 が機能していないことが考えられます。 NFS client 製品のひとつである Disk Access の場合は、「Administrator Utility」からではなく、「コントロールパネル」中の「DiskAccess」アプレットを起動してシンボリックリンクをたどるよう設定してください。   Disk Access のデフォルト設定ではシンボリックリンクをたどりません。

    リモートコンソールは、Red Hat Linux Advanced Server 2.1 版の samba サーバーとはテストされていません。

    「既知の問題」へ戻る

    SNMP エージェントの問題

    Windows 2000/XP/2003 上で NNM 管理ステーションを動かす場合 (Microsoft の SNMP サービスとの相互作用)

    NNM のインストール時に、SNMP リクエストの受信待機 (listen) をポート 161 ではなく、未使用の標準ではないポートにするので、Microsoft SNMP エージェントは事実上無効となります。 インストール時に、NNM は %SystemRoot%\system32\etc\services ファイルを変更します。 これで、Microsoft の snmp.exe は継続して動き、Microsoft エージェントに依存する他のアプリケーションのインストールは正常に行えますが、SNMP リクエストは Microsoft の SNMP サービスには届かなくなります。

    SNMP Research Emanate SNMP エージェント (snmpdm.exe) とアダプタ (wpaagt.exe) は SNMP リクエストを処理しようとします。 Microsoft SNMP サービスのインストールは、Microsoft 拡張エージェントがインストールされるために必要です (すべての SNMP エージェント拡張 DLL が使用されます。 Microsoft メイン・エージェントだけが不要です)。

    注記: [Microsoft SNMP プロパティ] ダイアログに入力されている情報はすべて無視されます。 すべての設定情報は \<install_dir>\conf\SNMPAgent\snmpd.conf ファイルに指定しておく必要があります。 この情報には SNMP トラップ・デスティネーションやコミュニティ名を含みます。

    「既知の問題」へ戻る

    国際化(I18NとL10N)の問題

    ここでは、製品内のいずれの個所であるかを問わず、英語環境以外の環境で発生する問題をすべて挙げてあります。

    簡体字中国語と Microsoft Windows

    ovw > Edit > Add Object オプションを使って Add Object Pallette GUI を起動した後、フォント表示に関連する次の問題が発生します。

    簡体字中国語の NNM レポートプレゼンタ

    NNM レポートプレゼンタ ウェブ UI の簡体字中国語の日付形式が正しくありません。

    簡体字中国語の NNM ホームベース

    NNM ホームベースで、簡体字中国語の一部のフォントが、その他のフォントに比べて小さいです。

    サポート対象外: CGI ベースのビューでは、クライアントとサーバで異なる言語は使えません。

    ある言語で動作している NNM アプリケーションを、別の言語で動作しているサーバと組み合わせて使うことはできません。 以下に示す NNM ビューは使えないか、またはサーバ側の言語で表示されます。

    「既知の問題」へ戻る

    Red Hat Advanced Server 2.1 での繁体字中国語および韓国語用のロケール名

    Red Hat Advanced Server 2.1 では、繁体字中国語および韓国語ロケール用の $LANG の値として、次のロケール名を使用します。

    「既知の問題」へ戻る

    Red Hat Linux Advanced Server 2.1 上の繁体字中国語または韓国語ブラウザ(Netscape または Mozilla)での Web UI へのアクセス

    繁体字中国語または韓国語ブラウザから Web インタフェースへアクセスすると、日付/時刻や、繁体字中国語、韓国語の文字が四角い記号として表示される場合があります。

    回避方法

    この問題を回避するには、以下の手順に従います。

    1. ブラウザのすべてのインスタンスを閉じます。
    2. cd <Java Plugin install directory/lib>
    3. 例: cd /usr/java/j2re1.4.2_01/lib

    4. 次のファイルを見つけます:
    5. 繁体字中国語の場合: font.properties.zh_TW.Redhat8.0
      韓国語の場合: font.properties.ko.Redhat8.0

    6. 次のようにして上記のファイルをコピーし、新しいファイルを作成します:
    7. 繁体字中国語の場合: cp font.properties.zh_TW.Redhat8.0 font.properties.zh_TW.Redhat
      韓国語の場合: cp font.properties.ko.Redhat8.0 font.properties.ko.Redhat

    8. font.properties<.Language>.Redhat ファイルを編集します。
    9. このファイルに、次の形式のフォント仕様のエントリを追加します:
      "-b&h-luxi serif-bold-i-normal--*-%d-*-*-p-*-iso8859-1"
      これらのフォントがお使いのシステムに存在することを確認します。



    10. ブラウザを起動します。

    以上の手順により、Web インタフェースに言語固有のフォントを正しく表示できるようになります。 しかし、次の問題が残る場合があります:
    ネットワークプレゼンタを起動し、繁体字中国語/韓国語の名前をもつシンボルを選択して右クリックすると、ポップアップウィンドウに誤ったシンボル名が表示されます。

    「既知の問題」へ戻る

    Linux 上の繁体字中国語/韓国語ロケールでの OVW の実行

    繁体字中国語または韓国語ロケールで実行中の ovw でシンボルを選択して右クリックすると、画面がちらつくことがあります。 右クリックで画面がちらついた場合、サブマップ中の任意のシンボルにドラッグ操作を行い、ちらつきを止める必要があります。 ただ、この現象は X サーバーの再起動後に一度だけしか起こりません。

    「既知の問題」へ戻る

    簡体字中国語と Linux

    Linux 版 NNM は簡体字中国語にローカライズされています。 以下は NNM を Linux で実行中に見られる問題です。

    「既知の問題」へ戻る

    Linux 上の管理ステーションで実行中のブラウザからのダイナミックビュー - すべてのロケールに影響

    管理ステーションで実行中のブラウザ(Netscape または Mozilla)からダイナミックビューを起動すると、次の問題が起こる場合があります。 ダイナミックビューのメニューまたはサブメニューからオプションを選択すると、警告メッセージが表示されます。
    例: パフォーマンス -> ネットワーク動作 -> インタフェースエラー -> インタフェースエラー
    起動したウィンドウは、英語以外のロケールの文字を正しく表示しない場合があります。
    この問題を解決するには、以下の手順に従います。

    1. 次のコマンドを実行して、ロケール固有のリソースファイルが存在するディレクトリへ移動します。

    2. cd /usr/lib/X11/<locale>/app-defaults
      例: cd /usr/lib/X11/ja_JP.eucjp/app-defaults
    3. 次のコマンドを、XNm、XNmtrap、XNmappmon、XNmgraphExecute それぞれに対して実行します。

    4. xrdb -merge <filename>

    「既知の問題」へ戻る

    Linux 上の日本語および簡体字中国語での Ovnnmpassword の実行

    ovnnmPassword ウィンドウの「ヘルプ」ボタンをクリックすると起動されるヘルプウィンドウでは、日本語または簡体字中国語の文字が正しく表示されない場合があります。 この問題を解決するには、以下の手順に従います。

    1. 次のコマンドを実行して、ロケール固有のリソースファイルが存在するディレクトリへ移動します。

    2. cd /usr/lib/X11/<locale>/app-defaults
      例: cd /usr/lib/X11/ja_JP.eucjp/app-defaults
    3. 次のコマンドを実行します。

    4. xrdb -merge OVHelp

    「既知の問題」へ戻る

    Linux 上の OVW の日本語 GUI

    「既知の問題」へ戻る

    Linux 上のオンラインヘルプウィンドウ - すべてのロケールに影響

    オンラインヘルプウィンドウのメニューは、起動されたロケールに関係なく英語で表示されます。

    「既知の問題」へ戻る

    Traditional Chinese と HP-UX

    Traditional Chinese の TrueType フォントを使用するには、HP-UX に次のパッチをインストールする必要があります:

    HP-UX 11.0
    PHSS_24937
    HP-UX 11i
    PHSS_26977
     
    「既知の問題」へ戻る

    日本語 Solaris 2.x で LANG=ja で使う場合

    NNM は EUC コードセットのロケール(LANG 環境変数) として ja と japanese をサポートしています。 LANG=ja の場合、NNM ツールの一部は英語で表示されます。 日本語で表示させるための対策としては、次のコマンドを root ユーザーで実行してください。

    1. cd /opt/OV/lib/nls/ja
    2. rm japanese
    3. mv * ../japanese/.
    4. cd /opt/OV/lib/nls
    5. rmdir ja
    6. ln -s /opt/OV/lib/nls/japanese /opt/OV/lib/nls/ja
    7. ovw を終了し、NNM プロセスを再起動する。

    「既知の問題」へ戻る

    サポート対象外: Solaris 10 でのローカリゼーション

    Network Node Manager 7.51 は日本語、簡体字中国語、および韓国語の Solaris 10 システムにインストールして使用することができますが、製品が完全にローカライズされているわけではありません。 以下は英語で表示されるものの一例です。

    1. ovstart -c コマンドを実行すると、ほとんどのプロセスからの出力は英語で表示されます。
    2. ネイティブアラームブラウザのメニューとサブメニュー
    3. MIB アプリケーションビルダのメニューとサブメニュー
    4. Web UI の一部

    注記: メッセージは特定の言語か英語で表示されるほか、文字化けする場合もあります。

    「既知の問題」へ戻る

    データウェアハウス

    データウェアハウスには、ローカライズされたデータを含む多くのフィールドがあります。

    nnm_event_cat テーブルのデータがローカライズされている結果として、「カテゴリ別アラーム」レポートの「アラーム・カテゴリ」カラムのデータもローカライズされます。 さらに、「重要度別アラーム」詳細レポートの「カテゴリ」カラムのデータもローカライズされます。 nnm_event_sev テーブルのデータがローカライズされている結果として、「重要度別アラーム」レポートの「アラーム重要度」カラムのデータもローカライズされます。 さらに、「カテゴリ別アラーム」詳細レポートの「重要度」カラムのデータもローカライズされます。 nnm_event_detail テーブルのデータがローカライズされている結果として、「重要度別アラーム」と「カテゴリ別アラーム」の両方のメッセージ・フィールドの特定のテキストもローカライズされます。

    nnm_event_thresh テーブルの "high_time" と "low_time" フィールドは、NNM で提供されるレポートのいずれにも使われません。 これらのフィールドは、ローカライズされたバージョンの trapd.conf ファイルから ovdwevent によって生成しているので、ローカライズされています。 データ・ソースとして使われている trapd.conf のバージョン(文字コード)は、ovdwevent が実行されたときのロケール(言語/文字コード・セット)によって決まります。

    「既知の問題」へ戻る

    Web ベースのアラームブラウザのプリント

    web ベースのアラーム・ブラウザは、ovalarmsrv 経由でプリントします。ovalarmsrv を実行しているマシンに接続されているプリンタは、日本語出力をプリントするためのマルチバイト文字をサポートしていなければなりません。プリンタへ引数を渡す方法がないので、lp コマンドへの '-ojapanese' オプションに類似の機能を、プリンタがデフォルトで有効にできる必要があります。

    「既知の問題」へ戻る

    ovw を使った Unix 上のサブマップのプリント

    横長 (landscape) や日本語 (Japanese) でプリントするために、ご使用のプリンタへオプションを渡す必要がある場合は、環境変数 OVwLpOpts を設定してから、ovw を実行します。 そうすると、プリント出力の下部にある時刻の文字列が、正確にプリントされます。たとえば、次のように設定します。

        export OVwLpOpts="-olandscape -ojapanese"
    「既知の問題」へ戻る

    トポロジ / マップのデータベースでは複数ロケール混在不可

    NNM を初めてインストールした時点では、トポロジ / マップのデータベースはその時点のロケールでラベルが作られています。サブマップ名は、このロケールで作成されますので、アクセスは同じロケールで行う必要があります。

    NNM で使用する言語を決める必要があります。 いったんロケールを決めると、変更するのはかなり難しくなります。 それは、NNM ではトポロジとマップのデータベースに複数ロケールの文字列を使用できないからです。 言語を決めたら、以下のステップを実行してください。

    1. $LANG を希望のロケールに設定します (例えば、LANG=ja_JP.SJIS; export LANG)。
    2. エクスポートされた LANG 環境で NNM をインストールします。
    3. OV プロセスを停止します (ovstop)。
    4. 希望の LANG 環境で OV プロセスを再起動します (ovstart)。
    5. Bootup スクリプトを設定します。 それには、/sbin/init.d/ov500 を次のように変更します (例は HP-UX で SJIS を使用)。
          'start')
              if .........
              case `uname` in
               ...........
          'start')
              if .........
              case `uname` in
               ...........
              HP-UX)
                  ECHO_CMD=$ECHO_CMD_HP
                  OVHOME=/opt/OV
                  PATH=/bin:/usr/bin:/etc:$PATH
                  export PATH LANG=ja_JP.SJIS # Add following 2 lines
                  export LANG                 # if want to set LANG=SJIS
                  ;; 
    6. デフォルトのロケールを変更したい場合は、次のようにしてデフォルトの WEB ロケールを設定します。
      # ovchange_locale_mapping [-sjis | -euc]
      (デフォルトのロケール)
      HP-UX: ja_JP.SJIS
      Solaris: ja
    7. Linux: ja_JP.eucJP

    「既知の問題」へ戻る

    syslog 設定 GUI

    syslog 設定 GUI では、パターンマッチング条件の名前としてマルチバイト文字のロケールをサポートしていません。 これは、syslog メッセージ自体がローカライズされておらず、名前が特定の syslog メッセージに直接対応するからです。 これらのフィールドにマルチバイト文字を入力することもできません。

    「既知の問題」へ戻る

    Linux 上の NNM ツール

    このセクションでは、NNM に含まれるツールのすべての既知の問題について説明します。

    snmpget および snmpset が HP-UX/Solaris/Windows とは異なる動作をする

    NNM には snmpget, snmpset, snmpwalk, snmptrap コマンドがあります。 しかし、これらのコマンドは、Red Hat Linux Advanced Server 2.1 の ucd-snmp パッケージにも含まれています。 デフォルトでは、ucd-snmp のコマンドユーティリティは /usr/bin に置かれ、NNM が供給するコマンドは /opt/OV/bin にインストールされます。 したがって、ユーザーが snmpget を実行すると、ucd-snmp が供給する snmpget コマンドが実行され、NNM が供給するコマンドとは同じ動作をしません。

    この問題を解決するには、$PATH の /usr/bin よりも前に /opt/OV/bin を追加します。

    例:
    ksh の場合:
    $ export PATH=/opt/OV/bin:$PATH
    csh の場合:
    $ setenv PATH /opt/OV/bin:$PATH

    「既知の問題」へ戻る

    Linux では hpuxagt が利用できない

    NNM に含まれる Emanate SNMP エージェントに hpuxagt がなく、これは Linux へは移植されていません。

    「既知の問題」へ戻る

    障害 -> ネットワーク接続性 -> Locate via:SNMP が Linux ノードに対して動作しない

    障害 -> ネットワーク接続性 -> Locate via:SNMP には、HP-UX エージェントでサポートされる機能(snmp エージェントの Emanate Suite の一部)が必要です。 しかし、hpuxagt は Linux に移植されていません。 この機能は Linux ノードに対しては動作しませんが、HP Emanate Agent Suite の一部として供給される hpuxagt が実行されている Linux 以外のノードに対しては動作します。

    「既知の問題」へ戻る

    ovperms.ovpl

    ovperms.ovpl スクリプトは Linux では利用できません。

    「既知の問題」へ戻る

    SNMP エージェント起動スクリプト名は ovsnmpd

    SNMP エージェントおよびサブエージェントを起動するスクリプトは、ovsnmpd に名前が変更され、/usr/sbin へインストールされます。

    「既知の問題」へ戻る

    snmpdm のログファイル

    他のプラットフォームでは、Snmpd.log は /var/adm に作成されますが、Linux では /etc/SnmpAgent.d に作成されます。

    「既知の問題」へ戻る

    ovstop が ovas のすべてのインスタンスを停止しない

    ovstop を実行しても、ovas のすべてのインスタンスが停止しない場合があります。 このため、ovstop 実行後 ovstart を実行すると、ovas が正しく起動しないことがあります。

    この問題を回避するには、ovstart を実行する前にすべての ovas のインスタンスを kill してください。

    「既知の問題」へ戻る

    snmp コマンドのマンページの競合Commands

    NNM には snmpget, snmpset, snmpwalk, snmptrap コマンドのマンページがあります。 しかし、これらは、Red Hat Linux Advanced Server 2.1 の ucd-snmp man パッケージにも含まれています。 デフォルトでは、 ucd-snmp のマンページは /usr/share/man/man1 にインストールされ、NNM が供給するマンページは /opt/OV/man にインストールされます。 したがって、ユーザーが 'man snmpget' を実行すると、ucd-snmp が供給するマンページのパスが NNM のパスより先に現れるため、ユーザーは NNM が供給するマンページを見ることができません。

    この問題を回避するには、$MANPATH の /opt/OV/bin よりも前に /opt/OV/man を追加します。

    例:
    ksh の場合:
    $ export MANPATH=/opt/OV/bin:$MANPATH
    csh の場合:
    $ setenv MANPATH /opt/OV/bin:$MANPATH

    「既知の問題」へ戻る

    xnmloadmib

    xnmloadmib GUI の色が、OVW の他の GUI の色と異なる場合があります。 これは無視しても問題ありません。

    「既知の問題」へ戻る

    オンラインヘルプとマンページ

    このセクションには、NNM に含まれるオンラインヘルプシステムのすべての既知の問題が書かれています。

    特定のデーモンやコマンド用のマンページが見つからない

    デーモンやコマンドのマンページは、NNM 用は /opt/OV/man/man1m、ECS ツール用は /opt/OV/man/man1m.Z に置かれます。 これらのコマンドのマンページを表示するには、コマンド行でセクションを指定してください (たとえば、man 1m netmon, man 1m.Z ecsmgr)。

    代わりに、1m および 1m.Z/etc/man.config ファイルの MANSECT 変数に追加する方法もあります (たとえば、MANSECT 1:8:2:3:4:5:6:7:9:tcl:n:l:p:o:1m:1m.Z)。 これにより、コマンド行パラメータを指定しなくても、man が追加のディレクトリ man1m および man1m.Z を検索するようになります。

    「既知の問題」へ戻る

    オンラインヘルプウィンドウのサイズ

    デスクトップに GNOME を使用する場合、NNM のオンラインヘルプウィンドウのサイズが一定ではありません。 右端のスクロールバーが見えないときは、矢印キーか PageUp/PageDown キーを使ってスクロールしてください。

    「既知の問題」へ戻る

    オンラインヘルプの内容

    ovw の「ヘルプ」メニューの "ヘルプの使用" をクリックすると "OpenView Windows Help" というタイトルのウィンドウが現れます。 このウィンドウは、オンラインヘルプ自体の使用方法についての情報を含んでいます。 表示される内容には、CDE (Common Desktop Environment) に固有な情報が含まれる場合があります。 それらの情報は、デスクトップ環境に CDE を使用する場合にのみ当てはまり、 GNOME や KDE には当てはまりません。

    「既知の問題」へ戻る

    コンソール上の警告メッセージ

    オンラインヘルプウィンドウを起動中に、コンソールに次のようなエラーが表示されることがあります。

    "Warning: Representation size 2 must match superclass's to override columns"

    この警告は無視してかまいません。

    「既知の問題」へ戻る

    オンラインヘルプの印刷オプション

    オンラインヘルプウィンドウから印刷オプションを使用すると( File->Print)、コンソールに次のような警告メッセージが表示されることがあります。

    Warning:
    Name: copiesField
    Class: XmTextField
    Character '\61' not supported in font. Discarded.

    この警告は無視してかまいません。

    「既知の問題」へ戻る

    イベント相関処理サブシステム (ECS)

    HP-UX 11.X システムで日本語ロケールを使うと、過渡状態コリレータのパラメータセクションの形式がおかしくなります。表示を正しくするには、ウィンドウのサイズを変更してください。

    「既知の問題」へ戻る

    Reporting and Network Solutions 4.0  (RNS 4.0)

    Reporting and Network Solutions 4.0 のコンポーネントはローカライズされていません。これらの製品はネットワーク ノード マネージャ 7.51 でサポートされている すべての言語で動作しますが、テキストメッセージは常に英語で表示されます。

    「既知の問題」へ戻る

     

    Aries ダイナミックトランスレーションモードの HP-UX 11i v2 での大規模検出

    5000ノードを超える大規模の ET 検出を実行するときは、/.ariesrc ファイルに次の行を追加して Aries のヒープサイズを増やすことを推奨します。
        / -pa_os_cpu -heap_ssz 49152 -ap_heap_ssz 24576

    「既知の問題」へ戻る


    ovet_auth と rvd

    DNS の設定に誤りがあると次のようなエラーを受け取る可能性があります。

    2002-05-15 17:07:48 rvd: unrecoverable IP configuration error:
        gethostname() returns '<hostname>',
        gethostbyname() for that returns IP address '15.2.113.5',
        but that address does not match any listed interface.
    2002-05-15 17:08:07 rvd: startup aborted: Initialization failed.
    Fatal warning : A critical bus error occurred. in ../CRivRvNet.cc at line 367

    <hostname> には管理システムのホスト名が出力されます。 これらのエラーはおそらくファイル $OV_LOG/ovet_auth.log にも記録されています。 この状況では ovet_auth はコアダンプし、終了します。 この問題に遭遇した場合は、DNS の設定をチェックする必要があります。

    「既知の問題」へ戻る

    Problem Diagnosis プローブのアンインストール

    プローブをアンインストールしても、GUI に表示が残ります。

    原因: プローブはアンインストールしても、サーバーへの登録は解除されていません。

    対策: $OV_MAIN_PATH/pdAE/config/pdconfig.xml ファイルを手動で編集し、アンインストールしたプローブに関する <PROBE> から </PROBE> までのすべてのエントリーを削除します。

    「既知の問題」へ戻る

    Error executing SQL Statement - SQL(INSERT INTO address_update ( ObjId,
    addressid, addresstype, issubnet, SubnetObjId, PrefixLength, V4Address,
    RouteDistinguisher,IPLevel,PubV4Address,NodeObjId,V4AddrByte1,V4AddrByte
    2,V4AddrByte3,V4AddrByte4,PV4AddrByte
      ODBC Return Code (-1),
      SQL State (43Ex),
                 ^^^^
    Native RDBMS Error (1), Message ([DataDirect][ODBC 20101 driver][Oracle]ORA-00001: unique
    constraint (OVDB.SYS_C001045) violated)

    SQL State" のコードは、43Ex か 435x のいずれかになります。

  • $OV_BIN/etrestart.ovpl" を実行します。
  • Extended Topology 設定 GUI で、[今すぐ全検出を開始] を" 選択します。
  • 「既知の問題」へ戻る

    移行後に ovet_daIPv6 が起動しない

    以前のバージョンの Extended Topology の ovet_daIPv6 エージェントは、$OV_CONF/ovsuf と $OV_LRF/ovet_daIPv6.lrf ファイルで定義されているように、ovet_dhdns デーモンに依存していました。7.51 へ移行しても、設定スクリプト setupExtTopo.ovpl はこれを修正せず、その結果 ovstart が ovet_daIPv6 デーモンの依存関係が解決できないと報告します。

    対策: If there are any entries in the $OV_CONF/ovsuf ファイルに ovet_dhdns に依存する ovet_daIPv6 用のエントリがあれば、次のコマンドを実行してこのエントリを置き換えることを推奨します。

    UNIX の場合:

        $OV_BIN/ovdelobj $OV_LRF/ovet_daIPv6.lrf

        $OV_BIN/ovaddobj $OV_LRF/ovet_daIPv6.lrf

    Windows の場合:

        ovdelobj "%OV_LRF%\ovet_daIPv6.lrf"

        ovaddobj "%OV_LRF%\ovet_daIPv6.lrf"

    「既知の問題」へ戻る

    Windows で重複アドレスドメインのゾーン ID が更新されない

    Windows で NNM 7.0 から 7.51 への移行時に、OAD ゾーン ID が新しいフォーマットに更新されません。

    対策: Windows で次のコマンドを実行します:

        "%OV_BIN%\migrate70to701ZoneNumber.ovpl"

    「既知の問題」へ戻る

    Windows で setupExtTopo.ovpl がデフォルトゲートウェイが無いと報告する

    Windows で setupExtTopo.ovpl を使って NNM Advanced Edition を設定する際、次のメッセージが返される場合があります。

    警告: デフォルト経路が見つかりません。

    これは、ローカルシステムの SNMP の設定が有効でなくなった場合に発生することがあります。コンピュータの IP アドレスを変更した場合や、無効なコミュニティ文字列が指定された場合などです。

    対策:

        "%OV_BIN%\xnmsnmpconf.exe"

    を実行して、コンピュータのすべての IP アドレスとホスト名が入力されていること、それらのエントリのコミュニティ文字列が有効であることを確認します。設定後、次のコマンドを使って、タイムアウトを示すエラー文がないことを確認します。

        "%OV_BIN%\rnetstat -r -n"

    「既知の問題」へ戻る

    setupExtTopo.ovpl がプロセスが起動できないと報告する

    setupExtTopo.ovpl を実行中に次のエラーが報告され、

    エラー: 1つ以上のプロセスを開始できませんでした。 詳細については ovstatus を実行するか /var/opt/OV/log/setupExtTopo.log を参照してください

    "ovstatus -c" が次の結果を返す場合、

    ovet_poll -  NOT_RUNNING    (ovet_poll-77) main 関数が 予期しない XPL コンポーネント例外を受信しました。 詳細は OV システムログを参照してください。(ovet_poll-87) トポロジデータベースの状態チェック中の予期しない障害: SQL ステートメントをバインド中のエラー 終了します(255)

    NNM AE データベースが正しく作成されていません。この状態は HP-UX 上でよく発生します。
    対策: redoSolid.ovpl スクリプトを実行してから、setupExtTopo.ovpl を再実行します。

    /opt/OV/support/redoSolid.ovpl
    /opt/OV/bin/setupExtTopo.ovpl

    「既知の問題」へ戻る

    SNMPv3 デバイスで VLAN 情報が利用できない場合がある

    デバイスへ SNMPv3 クエリのみを(BRASS エージェントへの ET のフックを経由して)行うと、ほとんどの場合、それらのデバイスの VLAN テーブルにクエリを行うことができません。 これは、設定済みのコミュニティ文字列に ET が内部で付加する特殊文字(@)が、BRASS エージェントで使うために必要な特殊なコミュニティ文字列の設定エントリには効果がないという事実によるものです。

    「既知の問題」へ戻る

    syslogTrap とバッファデータ

    syslogTrap は /var/opt/OV/tmp/OpC/msgagtdf ファイルに書き込みます。このファイルには、定義されたデフォルト上限サイズがないので、無限に大きくなる可能性があります。

    対策: このファイルのサイズを制限するには、/opt/OV/bin/OpC/install/opcinfo ファイルに以下のパラメータを追加します。

    OPC_BUFLIMIT_ENABLE TRUE

    OPC_BUFLIMIT_SIZE 10000

    OPC_BUFLIMIT_SEVERITY critical

    「既知の問題」へ戻る

    ProCurve スイッチとのレベル2接続性が無い

    非IP の Procurve スタックメンバースイッチとその他のスイッチの間に L2 接続性が存在しない場合があります。この問題が発生するのは、IP アドレスがまったく割り当てられていない Procurve スタックメンバーデバイスが管理対象ネットワークに存在する状況に限定されます。

    NNM AE の Procurve Device Agent は、IP アドレスがまったく割り当てられていない Procurve スタックメンバースイッチを透過的に検出します。 これらの非IP スタックメンバースイッチは、トポロジデータベースでは、スタックコマンダースイッチとは区別された別のノードとして表されます。 これらの非IP スタックメンバースイッチは netmon プロセスによって検出されるのではなく、代わりに NNM AE の Procurve Device Agent によって動的に検出されるので、これらのスタックメンバーデバイスの周囲の接続性の検出および表示の正確さは、今のところ、スタックの周囲のその他のデバイスを様々な Device Agent が検出するときの命令の範囲に限定されています。 非IP スタックメンバーデバイスの周囲のトポロジに存在しない接続が表示されたり、非IP スタックメンバーデバイスへの接続の一部が存在しないかのように見える可能性があります。

    対策: 上述の接続性問題が見られる場合、現時点で利用可能な対策は、NNM AE で提供されている Connection Editor を使用することです。

    「既知の問題」へ戻る

    PA-RISC の HP-UX 11i v2 上で setupExtTopo.ovpl が kmtune の警告をレポートする

    PA-RISC 上の HP-UX 11i v2 で setupExtTopo.ovpl が実行されると、次の警告が生成されます。

      kmtune is a wrapper script which exists for compatibility reasons only. The underlying command
      used is 'kctune'. New or modified scripts or procedures should use kctune directly.

    この警告があっても、setupExtTopo.ovpl は正常に動作します。

    「既知の問題」へ戻る

    アクティブ問題アナライザ (ovet_poll)

    再起動にまたがる相関処理

    アクティブ問題アナライザ (APA) で生成された、ノード、インタフェース、アドレス、および接続のイベントの相関処理は、ovet_poll を再起動すると正しく動作しません。 特に、UP イベントが DOWN イベントまたは UNREACHABLE イベントを正しくキャンセルできなくなります。

    対策: 影響を受けるイベントを手動で削除します。

    「既知の問題」へ戻る

    中断を伴うシャットダウン

    ovstop を実行して ovet_poll を停止すると、場合によってはタイムアウトになり、ovstop が ovet_poll へ SIGTERM を送信することがあります。 これにより、ovet_poll と topo_api_notif の、pmd への接続が切断したという 2 つのエラーイベントが生成されます。 このシャットダウンに対しては重大な副作用はありません。

    対策: エラーイベントを手動で削除します。

    「既知の問題」へ戻る

    インタフェース番号の変更

    デバイスによっては、リブート時や、カードが追加されたり、シャーシから外されたりすると、SNMP MIB II インタフェーステーブルの中のインタフェース番号が変更されるものがあります。 次回の再検出が行われるまでは、APA が対象ノードに関して不正な結果を生成する可能性があります。

    対策: インタフェース番号が変わったことに気付いた場合は、影響のあるゾーンで、増分検出 (incremental discovery) を実行します。

    「既知の問題」へ戻る

    新しい管理対象ノードが ovw 上で「認識不能」ステータスのままになる

    APA が通常の IP 環境で有効になっているとき、何らかの形で検出が発生するか、APA がトリガーとなったステータスの変更が発生しない限り、新しく管理対象となったノードのステータスは NNM トポロジデータベース上で更新されません。

    対策: 対象になっているノードを含むゾーンについて、ゾーンベースの増分検出を開始する。

    「既知の問題」へ戻る

    APA が通常の IP 環境で有効になっているとき、フェイルオーバー ポーリングが機能しない

    リモート収集ステーションを持つ管理ステーション上にインストールされた APA は、フェイルオーバー ポーリングをサポートしません。 リモート収集ステーションのフェイルオーバー ポーリングが必須であるときは、管理ステーション上で APA を有効にすることは、お勧めできません。

    対策: なし

    「既知の問題」へ戻る

    ovtopmd/ovw と APA のインタフェースステータス

    通常の IP 環境で APA を有効にしている場合、「危険域」と表示されるべきインタフェースが、ovtopmd/ovw では「正常域」と表示されることがあります。ovtopmd のインタフェースオブジェクトと Extended Topology データベースのインタフェースオブジェクトとの照合を APA が試みる際に直接一致しないインタフェースオブジェクトは、 ovtopmd データベースと ovw では「正常域」と表示され、APA ログファイルにもそのようなメッセージが記録されます。 1 つのインタフェースが ovtopmd/ovw データベースに複数の形式で存在する場合は、それらのうち 1 つだけが更新されます。 この現象は概ね以下の条件で発生します:

    回避方法: Extended Topology による検出(全検出またはゾーン別検出のいずれか)を開始します。 検出完了後は条件が解消され、データベースが再び同期します。

    「既知の問題」へ戻る

    HP-UX 上で APA がアラームのレポートと統計情報の更新をしなくなる

    アクティブ問題アナライザ (APA) が障害アラームやステータス更新のレポートを停止し、それ以上統計情報が更新されなくなります。 これは、APA がハングしている(障害のポーリングや解析をしなくなった)ことを示しています。 APA がハングしていることを確認するには、次のコマンドを使って APA からの最近の統計情報の更新をチェックしてください。

    UNIX の場合: ovdumpevents -l 60 | grep Statistics

    Windows の場合: ovdumpevents -l 60 and search for "Statistics"

    イベントが全く表示されない場合は、APA はおそらくハングまたはデッドロック状態になっています。

    対策: APA のハングの最もよくある原因は、完全修飾名へ解決できない IP アドレスの DNS クエリに関連しています。 通常の IP 監視環境では、以下のように checkDNS.ovpl スクリプトを使って、どのアドレスが解決できないかを見ることができます。

    UNIX:

    $OV_MAIN_PATH/support/checkDNS.ovpl -v | grep NULL

    Windows の場合:

    %OV_MAIN_PATH%\support\checkDNS.ovpl -v

    ホスト名解決が "NULL" のアドレスを探します。

    APA がハングするのを一時的に防止するには、解決しない IP アドレスを ipNoLookup.conf (4) 設定ファイルへ書き込み、次の手順でポーリングプロセスを再起動します。

    1) 次のコマンドを実行して、解決しない IP アドレスのリストを作成します。

    UNIX:

    $OV_MAIN_PATH/support/checkDNS.ovpl -v | \
    $OV_BIN/Perl/bin/perl -lne 'print $1 if m/((?:\d+\.?){4}) --> NULL/' >/tmp/ipNoLookup.conf

    Windows の場合:

    %OV_MAIN_PATH%\support\checkDNS.ovpl -v >c:\temp\ipNoLookup.conf

    注記: c:\temp は適切な一時ディレクトリに置き換えてください。 このファイルを編集して、DNS にホスト名解決がない(checkDNS.ovpl の出力が "NLLL" になる) IP アドレスのリストを含むようにしてください。

    2) ファイルを次の場所へコピーします。

    UNIX:

    cp $OV_CONF/ipNoLookup.conf $OV_CONF/ipNoLookup.conf.backup # すでにファイルが存在する場合

    cp /tmp/ipNoLookup.conf $OV_CONF/ipNoLookup.conf

    Windows の場合:

    copy %OV_CONF%\ipNoLookup.conf %OV_CONF%\ipNoLookup.conf.backup

    copy c:\temp\ipNoLookup.conf %OV_CONF%\ipNoLookup.conf

    3) Administrator または root として、次のコマンドを使って APA を再起動します。

    ovstop ovet_poll

    ovstart ovet_poll

    HP-UX の場合、さらに、次の OS パッチまたはそれらの最新の後継パッチがシステムにインストールされていることを確認します。 これらのパッチは、DNS ホスト名解決に使われる connect() システムコールのハングを修正します。

    11.0 用:

    最小推奨 Transport パッチ : PHNE_28538

    依存関係にある streams パッチ:

    s700: 11.00: PHKL_21857 PHKL_22142 PHNE_27651

    s800: 11.00: PHKL_21857 PHKL_22142 PHNE_27651

    11.11 用:

    最小推奨 Transport パッチ : PHNE_28089; 最新: PHNE_28895

    依存関係にある streams パッチ:

    s700: 11.11: PHKL_25233 PHKL_25389 PHNE_26728

    s800: 11.11: PHKL_25233 PHKL_25389 PHNE_26728

    「既知の問題」へ戻る

    ログファイルが壊れていて APA を開始できない

    ovstart/ovstatus で次のメッセージを出力されて APA が開始できないことがあります。

    UNIX:

    (APA107) Extended Topology からトポロジデータをロードできません。 ovet_poll をシャットダウンして終了しています。 リストされた問題を解決してからプロセスを再起動してください。 (XLOG9) Unable to read log file /var/opt/OV/log/ovet_poll.log.bin

    Windows の場合:

    (APA107) Extended Topology からトポロジデータをロードできません。 ovet_poll をシャットダウンして終了しています。 リストされた問題を解決してからプロセスを再起動してください。 (XLOG9) Unable to read log file c:\Program Files\HP OpenView\data\log\ovet_poll.log.bin

    対策: 問題が続く場合は、administrator または root として次のコマンドを実行して ovet_poll のログファイルを削除してください。

    Unix の場合:

    rm /var/opt/OV/log/ovet_poll.log.*

    ovstart ovet_poll

    Windows の場合:

    c:\Program Files\HP OpenView\data\log フォルダへ移動して ovet_poll.log.bin と ovet_poll.log.txt を削除します。

    注記: NNM が別のドライブにインストールされている場合でも、ovet_poll のログファイルは C ドライブにあります。

    ovstart ovet_poll

    「既知の問題」へ戻る

    正常域のはずのノードが危険域/警戒域と表示される

    インタフェースの動作ステータスが停止中になると、APA がノードを危険域または警戒域に設定します。 次にそのインタフェースの管理ステータスが停止中(インタフェースがそれ以上ポーリングされないことを示す)になると、インタフェースとノードが危険域または警戒域ステータスのままになります。

    対策: administrator または root として ovstop/ovstart コマンドを実行して、APA (ovet_poll) を再起動します。

    ovstop ovet_poll

    ovstart ovet_poll

    「既知の問題」へ戻る

    相関処理されていないアラーム設定が原因で APA エラーが発生する

    MyHostID.xml ファイルにノード名または IP アドレスを追加することによって、デバイスに関連付けられた未相関処理アラームが常にアラームブラウザへ送信されるように APA を設定することができます。 MyHostID.xml ファイルにデバイスを追加して ovet_poll プロセスを再起動した後、次のようなエラーが発生する場合があります。 「Extended Topology からトポロジデータを更新できません。 ovet_poll をシャットダウンして終了しています。 リストされた問題を解決してからプロセスを再起動してください。 (xpl-307) 」

    対策: ワイルドカードおよび IP アドレス範囲を使って、MyHostID.xml ファイルへのエントリ数を制限します。

    「既知の問題」へ戻る

    スイッチ接続性

    ルーター接続性

    ハブとリピータの接続性

    IPv6 オブジェクトの固定

    IPv6 ポーリングの性能

    Solaris プラットフォームでは、IPv6 ノードにホスト名が設定されていないと、 monitorIPv6Agent がこれらのノードについてのステータスイベントを送るので、 pmd のパフォーマンスが落ちます。 この問題を軽減するには、ipNoLookup キャッシュを 設定してこれらの検索を防ぐ必要があります:

    1. IPv6 デバイスを検出する
    2. 検出したアドレスのリストをファイルに保存する
    3. "snmpnolookupconf -file filename" ("filename" は前の手順で 作成したファイル名に置き換える) を実行する

    詳細は、snmpnolookupconf(1) マンページおよび DNS improvement に関する ホワイトペーパー(/opt/OV/doc/WhitePapers/DNSImprovements.pdf) を参照してください。

    SNMP の設定

    NNM の SNMP コミュニティ文字列は NNM/ET に転送されますが、タイムアウトおよび 再試行の値は現在のところ転送されません。 正しいコミュニティ文字列を設定しているにも かかわらず NNM/ET による検出の間にタイムアウトが発生してしまう場合には、 これらのパラメータを変更する必要があるかもしれません。 そのような場合は、$OV_CONF/nnmet/DiscoSnmpHelperSchema.cfg を参照してください。問題のパラメータは、m_TimeOut と m_NumRetries で、ファイルの終端近くにあります。 パラメータの変更を反映するには、ovstop/ovstart または etrestart.ovpl によって NNM/ETのプロセスを再起動する必要があります。

    Cisco HSRP

    多くのリリースにおいて、Network Node Manager は HSRP 環境をサポートしてきましたが、 これは、Cisco ルーターがその ipAddrTable 内の浮動アドレスを通知しないという事実に 依存していました。 この場合、$OV_CONF/oid_to_type において、そのデバイス タイプに "D" フラグをセットする必要がありましたが、この設定により NNM は "ノードマージ" の問題もなく HSRP グループを正しく扱うことができました。 幸か不幸か(視点によります)、浮動IPアドレスがマップやデータベースに現れることは ありませんでした。

    Cisco IOS の最新バージョン(12.1(14) 以上と 12.2(13) 以上) は アクティブなルーターの内の浮動IPアドレスを公開します。これにより、従来の NNM のソリューションが使えなくなり、"ノードマージ" や、ノードが現れたり消えたりする動作が再び見られるようになります。 お使いの環境に、これらの新しいバージョンの IOS がある場合は、HSRP グループ の浮動IPアドレスを netmon.noDiscover ファイルに書き込んだ後、これらの 浮動アドレスのどれもデータベースに存在しないことを確認します。残念ながら、すべての浮動アドレスが何であるかをあらかじめ知っておく必要があり、netmon.noDiscover ファイルを手動でメンテナンスしなければなりません。

    最も安全な設定は、これら2つのアプローチを併用することです。すなわち、netmon.noDiscover を最新に保つと同時に、$OV_CONF/oid_to_type にも "D" フラグを セットすることです。

    以上の要件が満たされなければ、Extended Topology はこれらの HSRP デバイス上の インタフェースの一部を検出できません。

    ATM の検出

    ILMI 検出エージェントは、ifType のインタフェースを持つ atm(37) については、リモート近隣ノードだけの検出を行います。別のインタフェースタイプ (たとえば、sonet(39)) の ILMI 近隣ノードをレポートする ATM MIB をサポートするデバイスは、検出されません。

    「既知の問題」へ戻る


    トラブルシューティング

    ヒント: 次のディレクトリで、エラー・ログ・ファイルを探して、出力を調べてください。 キーワード "ERROR" を探してください。

    Windows 2000/XP/2003:
    \<installdir>\log\*.* および \<installdir>\tmp\*.*
    UNIX:
    $OV_SHARE_LOG, $OV_PRIV_LOG および $OV_TMP

    インストールのトラブルシューティング

    ネットワークを適切に設定するには、『ネットワークノードマネージャネットワーク管理ガイド』を参照してください。 インストールの際にネットワークの設定ミスが表示された時は、次の操作を試してください。 管理システムのコマンド・プロンプトで次のように入力します。

        ipconfig /all
    
    Windows 2000/XP/2003 の TCP/IP 設定情報 (ホスト名など) が表示されます。 さらに、次のコマンドを入力します。
        /sbin/ifconfig
    
    Linux の TCP/IP 設定情報(ホスト名など)が表示されます。 さらに、次のコマンドを入力します。
        nslookup <YOUR_IP_ADDRESS>
    
    ここで、<YOUR_IP_ADDRESS>は ipconfig が返したアドレスです。 ipconfig が返すホスト名と nslookup が返すホスト名が一致しない場合、NNM は動作しません。 どちらかのコマンドがホスト名を返さない場合、DNS 設定が間違っているか、DNS が使用不能になっています。 この nslookup の結果が 'ovw -server' の結果と一致することを確認してください。

    ノード検出のトラブルシューティング

    NNM は、インストール後5分以内に自動的にノード検出を開始し、ネットワークを表示します。 ただし、ノード検出が動作しない場合 (たとえばトップ・レベル・マップ上に空のインターネット・アイコンが表示される) や、インストールを有効にしたい場合は、『ネットワークノードマネージャネットワーク管理ガイド』の第 5 章のノード検出のトラブルシューティングを参照してください。 次の手順を実行すると問題の特定に役立ちます。

    NNM がローカル・ネットワークにあるはずのノードを、まったく検出できていない場合は、まずローカル・ノード、次に見つからないノードを個別にpingして接続を確認します(メニュー項目 [障害:Ping] を使用)。 管理ステーション・アイコンを選択して [設定:ネットワーク設定->ARPキャッシュ] メニュー項目を実行し、ノードがこれらを「認識」していることを確認してください。 ここで、新しいノードが ARP キャッシュに表示されているはずです。 管理ステーションを選択して [障害:ネットワーク接続性->ノードへのポーリング] メニュー項目を実行し、netmonプロセスがノードを再度照会するようにしてください。 新ノードがマップに追加されます。

    ノード検出を手動で誘導

    NNM がノードをまったく検出できない場合、ユーザ・インタフェースやコマンド・ラインを通じて、ノード検出を手動で誘導できます。 詳細は、『ネットワークノードマネージャネットワーク管理ガイド』の第 5 章、および NMM のオンライン・ヘルプのnetmonリファレンス・ページ (または UNIX の man ページ) を参照してください。

    具体的には、SNMP をサポートするノードをインターネットレベルで追加します。このノードがゲートウェイでなくても、NNM はそのデバイスを適切に検出し、必要なネットワークを作成し、それを適切なネットワークに置きます。

        rnetstat -I <nodename>
    
    NNM のユーザ・インタフェースからこのノードを手動で追加するには、次のようにします。
    1. NNM のユーザ・インタフェースをオープンします。
    2. トップ・レベル・サブマップで、インターネットアイコンを選択します。それをダブルクリックしインターネットサブマップを開きます。
    3. 編集:オブジェクトの追加] を選択します。'コネクタ' と 'ゲートウェイ' を選択します。
    4. ゲートウェイの名前を入力します。'ipmap' をダブル・クリックします。
    5. 正しいサブマップ (重要 !) とノード名を入力します。確認] と [OK] をクリックします。

    コマンド行からこのノードを追加するには (正確なサブネットマスクを知っている必要があります)、次のコマンドを実行します。

        echo <IPADDR> <NODENAME> | loadhosts -V -v -m <SUBNETMASK>
    

    ここで <IPADDR> は追加するノードの IP アドレス、<NODENAME> はノード名、<SUBNETMASK> はネットワークのサブネット・マスクです。

        echo 192.18.1.1 myrouter | loadhosts -V -v -m 255.255.255.0
    

    シードファイルを使って、ノード検出を手動で誘導することもできます。

    ノード検出を誘導した後、SNMP をサポートするノードから受信した情報に基づいてマップ上にノードが表示されるのが見えるはずです。 または ovtopodumpコマンドを実行しているときにはノードのリストが見えるはずです。

    データウェアハウスのトラブルシューティング

    ovstatus ovdbcheck"を実行してデータベースが実行されていることを確認します。

    次のように ovdwquery コマンドを使ってデータウェアハウスにデータが存在することを確認できます。

    ovdbdebug コマンドを使って、データベースが機能しているかどうかをテストできます。

    詳細は、『ネットワークノードマネージャ ネットワーク管理ガイド』を参照してください。

    「トラブルシューティング」に戻る