 |
≫ |
|
|
|
パッチ名: PHCO_36111
パッチ摘要: s700_800 11.23 VxVM 4.1コマンドパッチ06
作成日: 07/09/07
公開日: 07/09/11
ハードウェアプラットフォームおよびOSリリース:
s700: 11.23
s800: 11.23
現象:
PHCO_36111:
1. (SR:8606491002 CR:JAGag43357)
SYMANTEC不具合番号: 867085(600447)
/etc/vx/diag.d/vxprivutilユーティリティを使ってVxVMディスクヘッダーを
表示しようとすると、次のようなエラーメッセージが表示されます。
VxVM vxprint ERROR V-5-1-326 unrecognized
value for variable, context: last_platform=0x0 #bad
2. (SR:8606491003 CR:JAGag43358)
SYMANTEC不具合番号: 899703(524016)
EMC Symmetrix DMX-1000アレイをCVMクラスタに追加すると、以下のようなDMP
disable/enableブートメッセージがコンソールに表示されます。
NOTICE: vxvm:vxdmp: disabled path 31/0xa1100
belonging to the dmpnode 1/0x8
NOTICE: vxvm:vxdmp: disabled path 31/0xb1100
belonging to the dmpnode 1/0x8
NOTICE: vxvm:vxdmp: disabled dmpnode 1/0x8
NOTICE: vxvm:vxdmp: enabled path 31/0xa1100
belonging to the dmpnode 1/0x8
3. (SR:8606491004 CR:JAGag43359)
SYMANTEC不具合番号: 925690(9000090)
VxVMルートディスクを使ってigniteインストールを行った後、最初のリブート
時に、重複したディスクIDを持つMSA LUNが検出されます。
4. (SR:8606491806 CR:JAGag43991)
SYMANTEC不具合番号: 992607(967551)
マスターCVMノードがクラスタから離脱すると、スレーブノードはマスターの
役割を引き継いで、共有ボリュームを復元する必要があります。ところが、
DRLログ付きボリュームの復元に時間がかかリ過ぎるため、復帰するノードが
クラスタに参加できません。
5. (SR:8606491009 CR:JAGag43364)
SYMANTEC不具合番号: 996706(995883)
ブートディスクグループに属するボリュームの取り込み時に、VxMSが次のよ
うなエラーメッセージを表示します。
VxMS API Msg ==> vxvm vxms plugin:
Plugin-internal error: dg_set_current on bootdg failed
6. (SR:8606491010 CR:JAGag43365)
SYMANTEC不具合番号: 996707(995886)
VxMSがパッシブパスをサポートしません。
7. (SR:8606491012 CR:JAGag43367)
SYMANTEC不具合番号: 996708(961548)
プラグインが"/"オブジェクトを取り込もうとするため、VxMSが次のようなエ
ラーを生成します。実名ではなくガーベッジシンボルが表示されます。
VxMS API Msg ==> vxvm vxms plugin:
Plugin-internal error: dg_set_current on,`E80w,` failed
8. (SR:8606491014 CR:JAGag43369)
SYMANTEC不具合番号: 1021717(1012502)
非常に大きなファイル(>1GB)に対してNet Backup Unit(NBU)のfsmapユーティ
リティを実行すると、コアダンプが取られるか、"Not Enough Space"というエ
ラーメッセージが表示されます。
9. (SR:8606491015 CR:JAGag43370)
SYMANTEC不具合番号: 1034909(1019973)
VxMS VxVMプラグインが、DRLログプレックス付きのボリュームをオープンでき
ません。
10.(SR:8606493362 CR:JAGag45535)
SYMANTEC不具合番号: 768086(314738)
2ノードCVM環境の場合、スレーブ上でのマスターの引き継ぎ後、"vxdg split"
コマンドが次のようなエラーメッセージを表示します。
VxVM vxdg ERROR V-5-1-4597
snaptdg : Internal configuration daemon error
split failed : Internal configuration daemon error.
11. (SR:8606493364 CR:JAGag45537)
SYMANTEC不具合番号: 1079279(1079281)
"vxconfigrestore -p"を使ってディスクグループ構成を復元しようとすると、
フィールド数がawk(1)での上限(199)を超えます。多数(>200)のVxVMオブジェ
クトをディスクグループに関連付けると、この問題が起きます。
"awk: The field 243 must be in the range 0 to 199.
The source line number is 1.The error context
is {print >>> $243 <<< }"
12.(SR:8606493367 CR:JAGag45540)
SYMANTEC不具合番号: 1075637(1075636)
システムのリブート後、Array Policy Modules(APM)がロードされません。
13.(SR:8606492213 CR:JAGag44384)
SYMANTEC不具合番号: 990611(793534)
マスクされたEMC LUNがデバイス検出時に取り込まれるため、これらのLUNに対
するIOがエラーになります。
14.(SR:8606492216 CR:JAGag44387)
SYMANTEC不具合番号: 415080(365919)
vxvmconvert(1M)のような一部のコマンドが異常終了することがあります。
複数の一次/二次パスが構成されているマシンの場合にこの問題が起きます。
次のようなエラーメッセージが表示されます。
VxVM vxvm-reconfig ERROR V-5-2-375
The partitioning of c1t0d0 failed.
15.(SR:8606492218 CR:JAGag44389)
SYMANTEC不具合番号: 564844(520888)
vxconfigdが2000個のボリュームを起動するのに1.2分かかります。
16.(SR:8606413219 CR:JAGaf73080)
SYMANTEC不具合番号: 1002929(1019506)
"vxdisk list"コマンドがディスクの容量を正しく表示しません。
17.(SR:8606492221 CR:JAGag44392)
SYMANTEC不具合番号: 781337(792815)
"vxddladm listsupport"コマンドがHP EVA 4/6/8KディスクアレイのHSV200/
HSV210コントローラを表示しません。
18.(SR:8606492222 CR:JAGag44393)
SYMANTEC不具合番号: 832354(832350)
vxdctl(1M)のマンページに、「"vxdctl initdmp"コマンドは/dev/vx/[r]dmpデ
ィレクトリ内のすべてのファイルを削除します。」という不正な説明が記載さ
れています。
19.(SR:8606492223 CR:JAGag44394)
SYMANTEC不具合番号: 914946(914941)
vxautoconvert(1M)ユーティリティのマニュアルページがありません。
20.(SR:8606492225 CR:JAGag44396)
SYMANTEC不具合番号: 990719(524096)
"vxdisk -o alldgs"が、切り離されたディスクのDISK列にDisk Media(DM)名を
表示しません。
21.(SR:8606492226 CR:JAGag44397)
SYMANTEC不具合番号: 990722(541911)
複数のdgインポートがほぼ同時に発生すると、vxconfigdがそれらを直列化す
るため、全ディスクの再オンライン化呼び出しが、dgインポートのたびに繰り
返し実行されます。これは非効率的なので最適化する必要があります。
22.(SR:8606485196 CR:JAGag38229)
SYMANTEC不具合番号: 1067429(1067501)
vxdisksetup(1M)を使ってIAプラットフォームのVxVMブートディスクを初期化
しようとすると、次のようなエラーメッセージが表示されることがあります。
vxfs mkfs: ERROR: V-3-25495: read failure at
devid/blknum 0/2400191
vxfs mkfs: ERROR: V-3-21080:
vxfs: No such device or address
23.(SR:8606492227 CR:JAGag44398)
SYMANTEC不具合番号: 1026855(418674)
/tmpディレクトリ内に多数のvx[0-9]+.[0-9]+.[0-0]+ファイルがあります。
24.(SR:8606494641 CR:JAGag46574)
Symantec不具合番号: 1105097(318531)
エンクロージャベースの命名(EBN)方法を使用すると、システムの起動時に、
vxconfigd内でセグメンテーションフォルトが起きます。コアダンプは次のよ
うなスタックトレースを示しています。
tree_concatenate+0x8
real_realloc+0xab8
_realloc+0xe4
realloc+0x1b0
xrealloc+0x34
bmap_realloc+0x3c
build_disk_attr_list+0x5c8
dmp_reconfig_db+0x98
ddl_find_devices_in_system+0x630
find_devices_in_system+0x4c
mode_set+0x1b0
setup_mode+0x24
startup+0x324
main+0x10c0
_start+0xc0
25.(SR:8606494643 CR:JAGag46576)
Symantec不具合番号: 1110521(995886)
デイスクが二次アクティブパスだけを持ち、一次アクティブパスを持っていな
いと、NetBackup Unitバックアップが失敗します。Shadow Image MSCバックア
ップの場合、"bpmap_failed err:3"というエラーメッセージが表示されます。
この問題が起きるのは、バックアップジョブ内のNetBackupがDMPプラグインを
使用する場合だけです。
26.(SR:8606494644 CR:JAGag46577)
Symantec不具合番号: 1110528(995883)
あるエラー状態の場合、NetBackupのVMプラグインが同期ロックを解放しませ
ん。そのため、NetBackup Unitバックアップジョブがハングすることがありま
す。この問題は、コードのレビュー時に見つかりました。
27.(SR:8606494633 CR:JAGag46566)
SYMANTEC不具合番号: 989943(209580)
VxVMテストケースの実行中に、vxassistコマンドがvxconfigdに接続できませ
ん。次のようなエラーメッセージが表示されます。
VxVM vxassist ERROR V-5-1-684 IPC failure: Configuration
daemon is not accessible
VxVM vxassist ERROR V-5-1-10128 Configuration daemon
is not accessible
28.(SR:8606494634 CR:JAGag46567)
SYMANTEC不具合番号: 990576(497302)
HA/CampusCluster内でホストのフェイルオーバーが起きると、hostidの不一致
により、vxreattachがDAをオリジナルのDMレコードに再接続できません。
29.(SR:8606494635 CR:JAGag46568)
SYMANTEC不具合番号: 990639(895525)
複数のdrlログ付きボリュームを作成する際に、drlログを作成するために必要
なスペースを計算するアルゴリズムが、drlログに必要なブロック数を正しく
計算しません。
30.(SR:8606494636 CR:JAGag46569)
SYMANTEC不具合番号: 990701(497300)
"failing"フラグがオンの場合に、"vxdisk list"を使って切り離し済みDMレコ
ードを表示すると、"nohotuse"フラグが表示されません("failing"フラグだけ
が表示されます)。
31.(SR:8606494638 CR:JAGag46571)
SYMANTEC不具合番号: 990709(524055)
サブディスクのレイアウトが断片化され、かつ、サブボリューム当たりのログ
プレックス数が3以上のボリュームに対して"vxassist grow"を実行すると、
エラーメッセージが表示されます。ところが、"vxassist maxgrow"は、そのボ
リュームを拡張可能と報告します。ログサブディスクが存在すると、この問題
が起きます。これらを削除すると、問題は起きません。
問題点の説明:
PHCO_36111:
1. (SR:8606491002 CR:JAGag43357)
SYMANTEC不具合番号: 867085(600447)
構成情報のダンプ時に、バージョン番号が110より小さいディスクグループの
last_platformフィールドが"0x0 #bad"と表示されていました。
解決方法:
last_platformフィールドの値を表示するようにコードを修正しました。
2. (SR:8606491003 CR:JAGag43358)
SYMANTEC不具合番号: 899703(524016)
DMP_DEV_OPEN ioctl()コマンドの問題により同じLUNを正しくオープンできな
かったため、DMPは、デバイスやドライバから検出した特定の状態に応じて、
デバイスを使用不可にしていました。そのため、システムの起動後、"vxdctl
enable"コマンドを使ってデバイスを再使用可能にせざるを得ませんでした。
解決方法:
rc2.dの段階で"vxdctl enable"を実行するようにコードを修正しました。これ
で、フェンス処理が開始される前に、すべてのパスを使用可能にするrestore
デーモンが再起動されます。
3. (SR:8606491004 CR:JAGag43359)
SYMANTEC不具合番号: 925690(9000090)
Array Support Library(ASL)がインストールされていないと、pre_init_rcか
らのvxconfigdの最初の実行時に、MSAアレイはJBODとして認識されません。
ところが、SCSI-3モードページを使ってLUNシリアル番号をチェックし、LUNへ
のパスが複数存在するかどうか調べるようにDDL/DMPに指示するために必要な
/etc/vx/.aascsi3ファイルが、vxconfigdが起動されるまで追加されませんで
した。
解決方法:
/etc/vx/.aascsi3ファイルを作成するようにpostinstallスクリプトを修正し
ました。このスクリプトは、VRTSvxvmファイルセットのswinstall後実行され
ます。
4. (SR:8606491806 CR:JAGag43991)
SYMANTEC不具合番号: 992607(967551)
共有ミラー化ボリューム上にDRLが構成されている場合、全共有ボリュームの
DRLマップが復元されない限り、CVMノードはクラスタに参加できません。とこ
ろが、1つ以上の共有ボリュームが、1つ以上のディスクを別のDRL付き共有ボ
リュームと共有していると、DRLマップの復元操作がボリュームの再同期の完
了待ちになることがあります。再同期に要する時間は、それらのボリュームの
サイズによって異なります。そのため、CVMノードがクラスタに参加しようと
しても、DRLマップが復元されるまでは、"recovery in progress"エラーにな
っていました。
解決方法:
まず、ボリュームのDRLマップを復元してから再同期を開始するようにコード
を修正しました。
5. (SR:8606491009 CR:JAGag43364)
SYMANTEC不具合番号: 996706(995883)
VxMS VxVMプラグインは、ブートディスクグループ上に作成されたボリューム
をオープンできませんでした。
解決方法:
bootdgディスクグループの場合は、別名指定されたディスクグループの名前を
特定し、そのディスクグループ名を使って関数を呼び出すようにコードを修正
しました。
6. (SR:8606491010 CR:JAGag43365)
SYMANTEC不具合番号: 996707(995886)
VxMS DMPプラグインはアクティブパスとパッシブパスを返していました。パッ
シブパスはそれ以上マップできないため、VxMSは表示目的以外にはそれらのパ
スを必要としていませんでした。VxMSはパッシブパスをダミーパスとマークす
る必要があります。
解決方法:
パッシブパスを示すフラグを追加しました。
7. (SR:8606491012 CR:JAGag43367)
SYMANTEC不具合番号: 996708(961548)
"/"、"/dev"または"/dev/dsk"のようなオブジェクトを取り込もうとして、
VxMS VxVMプラグインは、disk group/volumeフィールド内のヌル値を使って
dg_set_currentを呼び出していました。そのため、エラーが生成されていまし
た。
解決方法:
オブジェクトが"/"、"/dev"、"/dev/vx/dsk"またはその他の類似オブジェクト
の場合は、通常の方法でエラー終了するようにプラグインを修正しました。
8. (SR:8606491014 CR:JAGag43369)
SYMANTEC不具合番号: 1021717(1012502)
subobj_link_propオブジェクトを格納するためにVxMSのVxVM/DMPプラグインで
使用していたメモリーを正しく解放していかったため、メモリーリークが起き
ていました。
解決方法:
subobjvector()関数内でメモリーリークが起きないようにコードを修正しまし
た。
9. (SR:8606491015 CR:JAGag43370)
SYMANTEC不具合番号: 1034909(1019973)
VxMS VxVMプラグインはログプレックスのプライベートデータを初期化してい
なかったため、ボリュームに対するbuildmapdomain()がエラーになっていまし
た。
解決方法:
プレックスがボリュームのログプレックスかどうかチェックし、ログプレック
スの場合は、関連ログ情報を使ってサブディスクデータを初期化するようにプ
ラグインを修正しました。
10.(SR:8606493362 CR:JAGag45535)
SYMANTEC不具合番号: 768086(314738)
クラスタ環境では、クラスタ内の各ノードはそのdgimport idを取得するため
に独自のvolstatusカレントシーケンス番号を保持しています。ところが、
マスター切り替えが起きると、代替マスター上の新たに取得したdgimport id
とインポート済み共有ディスクグループのdgimport idが衝突していました。
解決方法:
インポート時に一意のシーケンス番号が取得されるように、マスター上の
volstatusカレントシーケンス番号をスレーブより大きな値に変更しました。
11.(SR:8606493364 CR:JAGag45537)
SYMANTEC不具合番号: 1079279(1079281)
HP-UXでは、awk(1m)がサポートするフィールド数は200未満に制限されている
ため、フィールド数が199を超えないようにする必要がありました。
解決方法:
awkのフィールド数制限(200未満)を回避するために、split(1)のコードをawk
(1)と結合しました。
12.(SR:8606493367 CR:JAGag45540)
SYMANTEC不具合番号: 1075637(1075636)
モジュールのステータスを正しく判別していなかったため、登録済みモジュー
ルがロード済みモジュールとみなされていました。
解決方法:
モジュールをカーネル内にロードする前に、モジュールのステータスを正しく
判別するようにコードを修正しました。
13.(SR:8606492213 CR:JAGag44384)
SYMANTEC不具合番号: 990611(793534)
"symcli rmdev"コマンドを使ってホストからマスクしたデバイスのSCSI照会が
成功し、非ゼロ値0x7Fに設定された周辺装置修飾子が返されていました。
しかし、これらのデバイスに対するI/Oはエラーになります。これらのデバイ
スのシリアル番号に関する情報は不正な可能性があり、コア上のDMPデータベ
ースを破壊する可能性があるので、デバイス検出プロセスで、VxVMはこれらの
デバイスを取り込んではいけません。
解決方法:
照会データ内の周辺装置修飾子ビットをチェックし、周辺装置修飾子が0x7Fに
設定されている場合は、そのデバイスを取り込まないようにコードを修正しま
した。
14.(SR:8606492216 CR:JAGag44387)
SYMANTEC不具合番号: 415080(365919)
複数の一次/二次パスが構成されている場合、vxdmpadm(1M)は有効なパスを
"ENABLED(A)"と表示しますが、vxadm_lib.sh内のget_primary_path関数は文字
列"ENABLED"だけしか認識していませんでした。その結果、有効な一次パスが
ある場合でも、二次パスが選択されることがありました。
解決方法:
vxdmpadm(1M)の出力内の"ENABLED(A)"を認識するように関数を修正しました。
15.(SR:8606492218 CR:JAGag44389)
SYMANTEC不具合番号: 564844(520888)
Disk Media(DM)レコードの処理方法に問題があったため、vxconfigdの起動時
間が長くなっていました。詳しく調べたところ、レコードリストが4回処理さ
れていたため、必要以上に大きなレコードリストが生成されていることがわか
りました。レコードリストが大きいということは、実際の構成より多くのボリ
ュームやオブジェクトがディスクグループ内に含まれていることを示していま
す。そのため、vxconfigdの起動に余計な時間がかかっていました。
解決方法:
全レコードリストを調べずに、ボリュームに関連付けられたDMレコードを見つ
けるために、検索用にリストされた関連レコードだけを抽出するようにコード
を修正しました。
16.(SR:8606413219 CR:JAGaf73080)
SYMANTEC不具合番号: 1002929(1019506)
(MAXTORディスクから取得した)モードセンスデータが不正だったため、ディス
クジオメトリが正しく計算されませんでした。その結果、ディスクがより小さ
い容量値を使って初期化されていました。
解決方法:
明示的DIOC_IOCTL ioctl(2)から取得したモードセンスデータとデータを両方
ともチェックしてから正しいディスクジオメトリを計算するようにコードを修
正しました。
17.(SR:8606492221 CR:JAGag44392)
SYMANTEC不具合番号: 781337(792815)
"vxddladm listsupport"コマンドは/etc/vx/ddl.supportファイルからアレイ
サポート情報を読み取ります。ところが、このファイル内には、同じVIDフィ
ールドを持つ複数の行が存在することがあるため、最初のサポート対象PID以
外のサポート対象PIDがすべてスキップされていました。
解決方法:
"PID"行を連結してから情報を表示するようにコードを修正しました。
18.(SR:8606492222 CR:JAGag44393)
SYMANTEC不具合番号: 832354(832350)
カーネル内に対応するdmpnodeがない場合、"vxdctl initdmp"コマンドは、
/dev/vx/[r]dmpディレクトリ内のエントリを削除しません。
解決方法:
マンページでの不正な説明を修正しました。
19.(SR:8606492223 CR:JAGag44394)
SYMANTEC不具合番号: 914946(914941)
vxautoconvert(1M)ユーティリティのマニュアルページがありませんでした。
解決方法:
マニュアルページを追加しました。
20.(SR:8606492225 CR:JAGag44396)
SYMANTEC不具合番号: 990719 (524096)
これは、切り離されたディスクのDM名も表示するようにvxdisk(1M)を変更する
拡張要求です。
解決方法:
切り離されたディスクのDM名も表示するようにコマンドを拡張しました。
21.(SR:8606492226 CR:JAGag44397)
SYMANTEC不具合番号: 990722(541911)
"vxconfigd"デーモンは、同時に発生した複数のディスクグループインポート
を直列化していました。そのため、ディスクグループインポート呼び出しのた
びに、ディスクをオンラインにする必要がありました。しかし、これは非効率
的なので最適化する必要があります。
解決方法:
dgインポートの処理中、つまり、ディスクをオンラインにする再オンライン化
呼び出しの実行中に別のdgインポート要求を受け取ったら、新たなdgインポー
ト要求の処理時には再オンライン化呼び出しをスキップするようにコードを修
正しました。
22.(SR:8606485196 CR:JAGag38229)
SYMANTEC不具合番号: 1067429(1067501)
IAブートディスクはEFIパーティションディスクです。ルートdg用として使用
できるのはパーティションs2だけです。ところが、s2パーティションの実サイ
ズが非常に小さい場合でも、サイズ計算時に、vxdisksetup(1M)は不正に、
"vxdisk list"の出力に基づいて非パーティション化ディスク名"cXtYdZ"を使
用していました。
解決方法:
"vxdisk list"の出力"cXtYdZ"にs2パーティションを追加する("cXtYdZs2")よ
うにコードを修正しました。
23.(SR:8606492227 CR:JAGag44398)
SYMANTEC不具合番号: 1026855(418674)
ライブラリvxadm_lib.shは、使用されない多数の一時ファイルを作成していま
した。
解決方法:
終了呼び出し時に未使用ファイルをクリーンアップする新たな関数を追加しま
した。
24.(SR:8606494641 CR:JAGag46574)
Symantec不具合番号: 1105097(318531)
OS固有の命名方法では、デバイスの名前がディスク名として使用されますが、
EBN(エンクロージャベースの命名)方法では、ディスクは割り当て済みのイン
デックスに基づいて命名されます。ディスクインデックスを格納するために使
用するビットマップが一杯になると、そのビットマップのメモリーが再割り当
てされます。ところが、メモリーを再割り当てするために渡す値を正しく計算
していなかったため、セグメンテーションフォルトが起きていました。
解決方法:
正しい値を渡すようにvxconfigd(1M)のコードを修正しました。これで、メモ
リー違反は起きません。
25.(SR:8606494643 CR:JAGag46576)
Symantec不具合番号: 1110521(995886)
これは、ディスクが二次アクティブパスだけを持ち、一次パスを持っていない
という稀なケースです。ところが、この場合、DMPプラグインが"アクティブ"
の二次パスを"パッシブ"と認識していたため、問題が起きていました。
解決方法:
"アクティブ"の二次パスを正しく認識するようにDMPプラグインを修正しまし
た。
26.(SR:8606494644 CR:JAGag46577)
Symantec不具合番号: 1110528(995883)
あるエラー状態の場合に、一部の内部VMプラグインの同期ロックが解放されま
せんでした。
解決方法:
エラー状態の場合でも同期ロックを適切に解放するようにVMプラグインを修正
しました。
27.(SR:8606494633 CR:JAGag46566)
SYMANTEC不具合番号: 989943(209580)
次のようなエラーにより、6番目のノードがクラスタに参加できないことがあ
りました。
V-5-1-684 IPC failure: Configuration daemon is not accessible
この問題の主な原因は以下の2つです。
1) リスンソケットのバックログが僅か5でした。そのため、5つのクライアン
トがvxconfigdとの通信待ちになっていると、6番目以降のクライアントは
エラーになっていました。
2) バックログの満杯時に、環境変数VXVM_RETRY_SETをfalseに設定していまし
た。
解決方法:
もっと多くのクライアントがソケットをリスンできるように、バックログの値
を大きくしました。また、リスンソケットのバックログが満杯であっても
VXV_RETRY_SETをtrueに設定するようにコードを修正しました。
28.(SR:8606494634 CR:JAGag46567)
SYMANTEC不具合番号: 990576(497302)
HA/Campusクラスタ内のあるホストでクラッシュ/リブート/エラーが発生し、
かつ、ディスクグループ内のある記憶領域がアクセス不能になると、(ホスト
の)フェイルオーバーが行われます。ところが、引き継ぎホスト上のオンディ
スクhostidとホストのvolbootファイル内のhostidが異なるため、"vxdg -k
adddisk"がエラーになり、結果的にvxreattachがエラーになっていました。
解決方法:
(hostidをクリアする)新たなオプション"-C"を導入しました。このオプション
を使用すると、vxreattachは正常に実行できます。
29.(SR:8606494635 CR:JAGag46568)
SYMANTEC不具合番号: 990639(895525)
1つのボリュームを作成する場合、ボリュームのdrlログを作成するために必要
なスペースを計算するアルゴリズムは正常に機能し、drlログに必要なブロッ
ク数を正しく計算していましたが、複数のボリュームを作成する場合、アルゴ
リズムは、drlログに必要なブロック数を正しく計算していませんでした。
解決方法:
drlログに必要なブロック数を正しく計算するようにアルゴリズムを修正しま
した。
30.(SR:8606494636 CR:JAGag46569)
SYMANTEC不具合番号: 990701(497300)
切り離し済みDMレコードを表示する場合、不正に、"failing"フラグが最初の
位置に表示されていました。しかし、この場合、"failing"の状態は意味があ
りません。
解決方法:
切り離し済みDMレコードを表示する場合は"failing"フラグをチェックしない
ようにコードを修正しました。
31.(SR:8606494638 CR:JAGag46571)
SYMANTEC不具合番号: 990709(524055)
vxassistは、新たなサイズのボリュームの新たなレイアウトを正しく計算して
いませんでした。そのため、新たなレイアウトをvxconfigdに渡すと、"サブデ
ィスクがオーバーラップしているため、新たなボリュームを拡張できません"
というメッセージが表示されていました。
解決方法:
vxassistでの、新たなボリュームレイアウト内のログサブディスクのスペース
計算方法を修正しました。vxassistは、実際に新たなレイアウトをコミットす
る前に、新たなボリュームのメモリ上のレイアウトを作成します。ただし、
ログサブディスクの追加時に、ログサブディスク数に関連した不正なパラメー
タを渡すと、不正なレイアウトが作成されます。正しいパラメータを渡せば、
オーバーラップしていない正しいレイアウトが作成されます。
-----------------------------------------------------------------------------
Patch Name: PHCO_36111
Patch Description: s700_800 11.23 VxVM 4.1 Command Patch 06
Creation Date: 07/09/07
Post Date: 07/09/11
Hardware Platforms - OS Releases:
s700: 11.23
s800: 11.23
Products:
VxVM 4.1
Filesets:
VRTSvxvm.VXVM-RUN,fr=4.1.011,fa=HP-UX_B.11.23_IA,v=HP
VRTSvxvm.VXVM-RUN,fr=4.1.011,fa=HP-UX_B.11.23_IA,v=VERITAS
VRTSvxvm.VXVM-RUN,fr=4.1.010,fa=HP-UX_B.11.23_IA,v=HP
VRTSvxvm.VXVM-RUN,fr=4.1.010,fa=HP-UX_B.11.23_IA,v=VERITAS
VRTSvxvm.VXVM-RUN,fr=4.1.011,fa=HP-UX_B.11.23_PA,v=HP
VRTSvxvm.VXVM-RUN,fr=4.1.011,fa=HP-UX_B.11.23_PA,v=VERITAS
VRTSvxvm.VXVM-RUN,fr=4.1.010,fa=HP-UX_B.11.23_PA,v=HP
VRTSvxvm.VXVM-RUN,fr=4.1.010,fa=HP-UX_B.11.23_PA,v=VERITAS
VRTSvxvm.VXMS,fr=4.1.011,fa=HP-UX_B.11.23_IA,v=HP
VRTSvxvm.VXMS,fr=4.1.011,fa=HP-UX_B.11.23_IA,v=VERITAS
VRTSvxvm.VXMS,fr=4.1.010,fa=HP-UX_B.11.23_IA,v=HP
VRTSvxvm.VXMS,fr=4.1.010,fa=HP-UX_B.11.23_IA,v=VERITAS
VRTSvxvm.VXMS,fr=4.1.011,fa=HP-UX_B.11.23_PA,v=HP
VRTSvxvm.VXMS,fr=4.1.011,fa=HP-UX_B.11.23_PA,v=VERITAS
VRTSvxvm.VXMS,fr=4.1.010,fa=HP-UX_B.11.23_PA,v=HP
VRTSvxvm.VXMS,fr=4.1.010,fa=HP-UX_B.11.23_PA,v=VERITAS
VRTSvxvm.VXSE,fr=4.1.011,fa=HP-UX_B.11.23_IA/PA,v=HP
VRTSvxvm.VXSE,fr=4.1.011,fa=HP-UX_B.11.23_IA/PA,v=VERITAS
VRTSvxvm.VXSE,fr=4.1.010,fa=HP-UX_B.11.23_IA/PA,v=HP
VRTSvxvm.VXSE,fr=4.1.010,fa=HP-UX_B.11.23_IA/PA,v=VERITAS
VRTSvxvm.VXVM-ENG-A-MAN,fr=4.1.011,fa=HP-UX_B.11.23_IA/PA,v=HP
VRTSvxvm.VXVM-ENG-A-MAN,fr=4.1.011,fa=HP-UX_B.11.23_IA/PA,v=VERITAS
VRTSvxvm.VXVM-ENG-A-MAN,fr=4.1.010,fa=HP-UX_B.11.23_IA/PA,v=HP
VRTSvxvm.VXVM-ENG-A-MAN,fr=4.1.010,fa=HP-UX_B.11.23_IA/PA,v=VERITAS
Automatic Reboot?: No
Status: General Release
Critical:
Yes
PHCO_36111: ABORT HANG CORRUPTION
ABORT: JAGag43369(8606491014)
HANG: JAGag46577(8606494644)
CORRUPTION: JAGag44384(8606492213)
JAGag46568(8606494635)
PHCO_35890: ABORT
PHCO_35738: ABORT
PHCO_35476: ABORT HANG PANIC MEMORY_LEAK CORRUPTION
PHCO_34811: ABORT MEMORY_LEAK CORRUPTION
PHCO_33509: ABORT HANG PANIC
Category Tags:
defect_repair enhancement general_release critical panic
halts_system corruption memory_leak
Path Name: /hp-ux_patches/s700_800/11.X/PHCO_36111
Symptoms:
PHCO_36111:
(SR: 8606494638 CR: JAGag46571)
SYMANTEC Incident Number: 990709(524055)
'vxassist grow' on a volume with fragmented layout of
subdisks and more than two log plexes per sub-volume
reports error, while 'vxassist maxgrow' reports that the
volume can be grown. The problem is visible in presence
of the log subdisks. If they are removed, the problem
is not seen.
(SR: 8606493364 CR: JAGag45537)
SYMANTEC Incident Number: 1079279 (1079281)
When restoring a disk group configuration using
vxconfigrestore -p, Awk(1)'s limit of 200 fields is
hit. This happens when a large number (> 200) of VxVM
objects is associated with the disk group.
"awk: The field 243 must be in the range 0 to 199.
The source line number is 1.The error context
is {print >>> $243 <<< }"
(SR: 8606491002 CR: JAGag43357)
SYMANTEC Incident Number: 867085 (600447)
When using the /etc/vx/diag.d/vxprivutil utility
to display the VxVM disk headers, it fails and
displays the following error message:
VxVM vxprint ERROR V-5-1-326 unrecognized
value for variable, context: last_platform=0x0 #bad
(SR: 8606491003 CR: JAGag43358)
SYMANTEC Incident Number: 899703 (524016)
The addition of an EMC Symmetrix DMX-1000 array
to a CVM cluster results in the following DMP disable
and enable boot messages on the console:
NOTICE: vxvm:vxdmp: disabled path 31/0xa1100
belonging to the dmpnode 1/0x8
NOTICE: vxvm:vxdmp: disabled path 31/0xb1100
belonging to the dmpnode 1/0x8
NOTICE: vxvm:vxdmp: disabled dmpnode 1/0x8
NOTICE: vxvm:vxdmp: enabled path 31/0xa1100
belonging to the dmpnode 1/0x8
(SR: 8606491004 CR: JAGag43359)
SYMANTEC Incident Number: 925690 (9000090)
Following the first reboot after an ignite installation
with a VxVM root disk, MSA LUNs are discovered
to have duplicate disk IDs.
(SR: 8606491806 CR: JAGag43991)
SYMANTEC Incident Number: 992607 (967551)
After a master CVM node leaves the cluster, a slave
node takes over as a master and has to recover
shared volumes. Recovery of the volumes with
DRL logs takes a significant amount
of time and prevents the returning node from
joining the cluster.
(SR: 8606491009 CR: JAGag43364)
SYMANTEC Incident Number: 996706 (995883)
VxMS gives the following error when trying to
claim a volume on the boot disk group:
VxMS API Msg ==> vxvm vxms plugin:
Plugin-internal error: dg_set_current on bootdg failed
(SR: 8606491010 CR: JAGag43365)
SYMANTEC Incident Number: 996707 (995886)
Passive paths were not supported in VxMS.
(SR: 8606491012 CR: JAGag43367)
SYMANTEC Incident Number: 996708 (961548)
VxMS gives the following error when trying to
claim the object "/": Garbage symbols are displayed
instead of the real name:
VxMS API Msg ==> vxvm vxms plugin:
Plugin-internal error: dg_set_current on,`E80w,` failed
(SR: 8606491014 CR: JAGag43369)
SYMANTEC Incident Number: 1021717 (1012502)
The fsmap utility of Net Backup Unit (NBU) dumps
core or gives the "Not Enough Space" error if it is
run on very large files (>1GB).
(SR: 8606491015 CR: JAGag43370)
SYMANTEC Incident Number: 1034909 (1019973)
The VxMS VxVM plugin fails to open volumes with
DRL log plexes enabled.
(SR: 8606493362 CR: JAGag45535)
SYMANTEC Incident Number: 768086 (314738)
On a 2-node CVM environment, vxdg split command
fails with the following errors after master
takeover on slave:
VxVM vxdg ERROR V-5-1-4597
snaptdg : Internal configuration daemon error
split failed : Internal configuration daemon error.
(SR: 8606493367 CR: JAGag45540)
SYMANTEC Incident Number: 1075637 (1075636)
Array Policy Modules (APM) are not loaded after the
system reboots.
(SR: 8606492213 CR: JAGag44384)
SYMANTEC Incident Number: 990611 (793534)
Masked EMC LUNs are claimed in device discovery
and IO fails on these LUNs.
(SR: 8606492216 CR: JAGag44387)
SYMANTEC Incident Number: 415080 (365919)
Certain commands like vxvmconvert(1M) can fail.
It happens on machines with multiple
primary/secondary paths, with the error message like:
VxVM vxvm-reconfig ERROR V-5-2-375
The partitioning of c1t0d0 failed.
(SR: 8606492218 CR: JAGag44389)
SYMANTEC Incident Number: 564844 (520888)
Vxconfigd requires 1.2 minutes to start 2000 volumes.
(SR: 8606413219 CR: JAGaf73080)
SYMANTEC Incident Number: 1002929 (1019506)
The "vxdisk list" command shows the capacity
of the disk incorrectly.
(SR: 8606492221 CR: JAGag44392)
SYMANTEC Incident Number: 781337 (792815)
The"vxddladm listsupport" command does not list
HSV200 or HSV210 controllers for HP EVA 4/6/8K
disk arrays.
(SR: 8606492222 CR: JAGag44393)
SYMANTEC Incident Number: 832354 (832350)
The vxdctl(1M) manpage incorrectly states that the
command "vxdctl initdmp" removes all files present
in the /dev/vx/[r]dmp directory.
(SR: 8606492223 CR: JAGag44394)
SYMANTEC Incident Number: 914946 (914941)
There are no manual pages for the utility vxautoconvert(1M).
(SR: 8606492225 CR: JAGag44396)
SYMANTEC Incident Number: 990719 (524096)
vxdisk -o alldgs" does not indicate the Disk Media (DM)
names under the DISK-column for detached disks.
(SR: 8606492226 CR: JAGag44397)
SYMANTEC Incident Number: 990722 (541911)
Even if multiple dg imports occur roughly around the
same time, vxconfigd would still serialize them and as
result, the expensive call to reonline of all disks will be
invoked repeatedly for each dg import, and this needs
to be optimized.
(SR: 8606485196 CR: JAGag38229)
SYMANTEC Incident Number: 1067429 (1067501)
Initializing a VxVM boot disk for IA platforms using
vxdisksetup(1M) may fail with the following errors:
vxfs mkfs: ERROR: V-3-25495: read failure at
devid/blknum 0/2400191
vxfs mkfs: ERROR: V-3-21080:
vxfs: No such device or address
(SR: 8606492227 CR: JAGag44398)
SYMANTEC Incident Number: 1026855 (418674)
A number of vx[0-9]+.[0-9]+.[0-0]+ files are present
in the /tmp directory.
(SR: 8606494641 CR: JAGag46574)
Symantec Incident Number: 1105097 (318531)
Symptoms:
In the Enclosure Based Naming(EBN) scheme, at the
time of system startup, vxconfigd encounters a
segmentation fault.
The core dump shows the following stack trace:
tree_concatenate+0x8
real_realloc+0xab8
_realloc+0xe4
realloc+0x1b0
xrealloc+0x34
bmap_realloc+0x3c
build_disk_attr_list+0x5c8
dmp_reconfig_db+0x98
ddl_find_devices_in_system+0x630
find_devices_in_system+0x4c
mode_set+0x1b0
setup_mode+0x24
startup+0x324
main+0x10c0
_start+0xc0
(SR: 8606494643 CR: JAGag46576)
Symantec Incident Number: 1110521(995886)
NetBackup Unit backup fails if a disk has only
secondary active path(s) and no primary active path.
Error message from Shadow Image MSC backup is
"bpmap_failed err:3". This issue occurs only
with the DMP plugin used by NetBackup in backup jobs.
(SR: 8606494644 CR: JAGag46577)
Symantec Incident Number: 1110528 (995883)
The VM plugin for NetBackup does not release
synchronization locks in case of some error conditions.
It may cause NetBackup unit backup jobs to hang.
The issue was found during code review.
(SR: 8606494633 CR: JAGag46566)
SYMANTEC Incident Number: 989943 (209580)
While running VxVM test cases, vxassist command
breaks its connection with vxconfigd. Upon failure,
following error messages are seen:
VxVM vxassist ERROR V-5-1-684 IPC failure: Configuration
daemon is not accessible
VxVM vxassist ERROR V-5-1-10128 Configuration daemon
is not accessible
(SR: 8606494634 CR: JAGag46567)
SYMANTEC Incident Number: 990576(497302)
Vxreattach fails to reattach DAs back with their original
DM record due tohostid mismatch after certain
HA/CampusCluster failover.
(SR: 8606494635 CR: JAGag46568)
SYMANTEC Incident Number: 990639(895525)
If we have more than one volume for which drl logs
are required then the algorithm, used to calculate the
space needed to create drl logs gives the incorrect
number of blocks needed for drl logs.
(SR: 8606494636 CR: JAGag46569)
SYMANTEC Incident Number: 990701 (497300)
The "nohotuse" flag does not get displayed in
"vxdisk list" for the detached DM records if the
"failing" flag is on (and only it gets
displayed).
(SR: 8606494638 CR: JAGag46571)
SYMANTEC Incident Number: 990709(524055)
'vxassist grow' on a volume with fragmented layout of
subdisks and more than two log plexes per sub-volume
reports Error, while 'vxassist maxgrow' reports that the
volume can be grown. The problem is visible in presence
of the log subdisks. If they are removed, the problem
is not seen.
PHCO_35890:
(SR: 8606470105 CR: JAGag25246)
Veritas Incident Number: 899646 (862878)
After vxvmconvert, the vxresize command fails
with the following error:
# /opt/VRTS/bin/vxresize -F vxfs -g dg01 lvol1 300m
VxVM vxresize ERROR V-5-1-4283 resizing volume other
than FSGEN or RAID5 can result in loss of data.
Use -f option to force resize this volume.
(SR: 8606455268 CR: JAGag11831)
Veritas Incident Number: 899675 (900203)
When the /etc/vx/bin/vxbrk_rootmir script is
used to create an alternate bootable disk, the
script fails with the following error:
# /etc/vx/bin/vxbrk_rootmir -v -b c0t0d0
vxbrk_rootmir: 17:19: Checking specified disk(s)
for presence and type
vxbrk_rootmir: 17:19: Mirroring root disk
vxrootmir: 17:19: Gathering information on the
current VxVM root configuration
vxrootmir: 17:19: Checking specified disk(s) for
usability
vxrootmir: 17:19: Preparing disk c0t0d0 as
a VxVM root disk
vxrootmir: 17:19: Adding disk c0t0d0 to rootdg
as DM rootdisk02
vxrootmir: 17:19: Mirroring all volumes
on root disk
vxrootmir: 17:19: Mirroring volume standvol
vxrootmir: 17:20: Mirroring volume swapvol
vxrootmir: 17:25: Mirroring volume rootvol
vxrootmir: 17:26: Mirroring volume optvol
vxrootmir: 17:31: Mirroring volume tmpvol
vxrootmir: 17:31: Mirroring volume usrvol
vxrootmir: 17:34: Mirroring volume homevol
vxrootmir: 17:34: Mirroring volume varvol
vxrootmir: 17:40: Mirroring volume swapvol2
vxrootmir: 17:40: Mirroring volume testvol
vxrootmir: 17:41: Disk c0t0d0 is now a mirrored
root disk
vxbrk_rootmir: 17:41: Saving configuration data
for later restoration
sed: Function s/plex=.*$/plex=swapvol-02
cannot be parsed.
vxbrk_rootmir: 17:41: Breaking off root mirror
on DA c0t0d0
vxbrk_rootmir: 17:41: Setting broken off mirror on
c0t0d0 as unique root disk
vxvm:vxmake: ERROR: duplicate plex, context:
plex swapvol2-02
tutil0="
vxbrk_rootmir: ERROR: Attempting to recreate
volume meta-data on rootdisk02/c0t0d0
(SR: 8606474302 CR: JAGag28848)
Veritas Incident Number: 899681 (641439)
The vradmind command results in a core dump
while sending a snapshot to the client.
(SR: 8606471971 CR: JAGag26927)
Veritas Incident Number: 960396(855057)
While converting VGs with multiple LV
entries in the /etc/fstab file, vxautoconvert
does not update the /etc/fstab file correctly.
(SR: 8606467094 CR: JAGag22530)
Veritas Incident Number: 927439(832358)
I/O to a conflicting dmp metanode can lead to
disabling associated active dmpnode with the
following message in the syslog:
NOTICE: vxvm:vxdmp: disabled path 31/0x46000
belonging to the dmpnode 1/0x20
NOTICE: vxvm:vxdmp: disabled dmpnode 1/0x20
PHCO_35738:
(SR: 8606472168 CR: JAGag27068)
Veritas Incident Number: 795130 (795129)
In the MC/SG clustered environment, while
running the 'cmhaltcl' command on the second
or a third slave nodes, one of the Disk Groups
(DG) loses the shared flag, the cluster ID,
and the autoimport flag for all disks in
that DG.
(SR: 8606473669 CR: JAGag28300)
Veritas Incident Number: 831065 (804673)
When the "vxddladm addsupport all" command was
run, it dumped core with the following stack
trace:
#0 0x60000000c4557560:0 in __milli_memcmp+0x6c0 ()
from /usr/lib/hpux32/libvxscsi.sl
#1 0x60000000c4545a30:0 in nv_free+0x60 ()
from /usr/lib/hpux32/libvxscsi.sl
#2 0x402c600:0 in ddl_vendor_info+0x16f0 ()
#3 0x4029e30:0 in ddl_add_support+0x2a0 ()
#4 0x40185a0:0 in vxddl_addsupport+0x2f0 ()
#5 0x4016d50:0 in main+0x12f0 ()
(SR: 8606472173 CR: JAGag27073)
Veritas Incident Number: 833619 (610841)
When the 'vxbrk_rootmir' command is run to break
the mirror, the following error message is displayed:
'VxVM vxbrk_rootmir ERROR V-5-2-4008 rootdg DG
contains more than 1 disk.'
(SR: 8606473664 CR: JAGag28295)
Veritas Incident Number: 836473 (834318)
All the VxVM commands respond very slowly after
running the 'vxdisk scandisks' command repeatedly.
(SR: 8606472172 CR: JAGag27072)
Veritas Incident Number: 839168 (839077)
The 'vxresize' command fails on file systems
greater than 2 TB. This displays the following
error message:
'VxVM vxresize ERROR V-5-1-2605 cannot stat/mnt.'
(SR: 8606472171 CR: JAGag27071)
Veritas Incident Number: 833704 (833700)
Need to increase the maximum I/O Size on a VxVM
volume from 256k to 1MB.
(SR: 8606472174 CR: JAGag27074)
Veritas Incident Number: 844510 (783758)
The vgcreate (1M) fails while converting a VxVM root
disk to LVM root disk using the vxres_lvmroot (1M)
command. This displays the following error message:
"VxVM vxres_lvmroot ERROR V-5-2-1691: vgcreate
failed"
(SR: 8606473668 CR: JAGag28299)
Veritas Incident Number: 851396 (405564)
The vxdiskunsetup (1M) command takes a long time
to complete on large configuration.
PHCO_35476:
(SR: 8606467245 CR: JAGag22669)
Veritas Incident Number: 781473
vxvmconvert is not able to convert some volume
groups correctly. The converter is unable to
recognize and convert extent based volume
groups.
(SR: 8606467112 CR: JAGag22546)
Veritas Incident Number: 790788
Importing a disk group with many cascaded space
optimized snapshots fails with the following error:
"VxVM vxdg ERROR V-5-1-587 Disk group sf04dg: import
failed: No more space in disk group configuration"
(SR: 8606467110 CR: JAGag22544)
Veritas Incident Number: 788674
The vxsnap command executed with an argument
exceeding 100 characters results in the following
error:
"VxVM vxsnap ERROR V-5-1-447 Cannot execute
/usr/sbin/vxassist: Bad address"
(SR: 8606467113 CR: JAGag22547)
Veritas Incident Number: 795046
The "vxsnap -g <dg> print" process uses more than
1GB of memory.
(SR: 8606430187 CR: JAGaf89646)
Veritas Incident Number: 795049
In a mirror-stripe setup, while adding more LUNS
into the configuration and increasing the number
of stripes, if one controller (card in the system
or a controller on the storage or a storage box
itself) is down, then both plexes are disabled.
vxassist(1M) silently transfers the layout from
highly available to non-highly available.
(SR: 8606405601 CR: JAGaf65522)
Veritas Incident Number: 795065
When a mirror-stripe volume that spans across 16
disks (two plexes across 8 disks each) is being
configured, it results in the following errors:
vxvm:vxvol: ERROR: Volume vxvol01: READ error at
block 2147483648:
System error: Bad file number
xvm:vxvol: ERROR: Volume vxvol01: synchronizing
read loop failed, it should
vxvm:vxvol: ERROR: be stopped and restarted
vxvm:vxvol: INFO: Attempting to cleanup after
failure ...
(SR: 8606420552 CR: JAGaf80381)
Veritas Incident Number: 795965
The installation of VxVM fails with the following
NOTICE message in the syslog:
NOTICE: MOD: modld: Module already loaded
PHCO_34811:
(SR:8606445097 CR:JAGag02580)
Veritas Incident No:540604
During diskgroup deport, vxconfigd issues warnings
like:
VxVM vxconfigd WARNING V-5-1-11551 array_da_to_disk:
Cannot find active path for dmpnode EMC0_1 and then
dumps core with the following stack trace :
0xff1344e4 in strlen () from /usr/lib/libc.so.1
0xff186c30 in _doprnt () from /usr/lib/libc.so.1
0xff188960 in fprintf () from /usr/lib/libc.so.1
0x6ca28 in array_select_da ()
0x6c62c in da_select_diskid ()
0x65d18 in da_find_diskid ()
0x64394 in da_dg_deport ()
0x89008 in dg_deport_finish ()
0x88de4 in vold_dg_deport ()
0x85f60 in req_dg_deport ()
0xd1d8c in request_loop ()
0xb063c in main ()
(SR: 8606445098 CR:JAGag02581)
Veritas Incident No:496817
Built-in 4.1 MP1 ASL for HDS 9500 Tagmastore
needs to differentiate from the AMS 500
Tagmastore by serial number.
(SR:8606445099 CR: JAGag02582)
Veritas Incident No:496821
vxasldebug output: Failed to open two
discovery.d libraries:libvxautoraid.sl,
libvxdgc.sl.
Here's a segment showing first open error
on libvxautoraid.sl...
checking ASL library outputs
***********************************************
libvxautoraid.sl
***********************************************
ERROR: Error opening shared library
/etc/vx/lib/discovery.d/libvxautoraid.sl
***********************************************
libvxcscovrts.sl
***********************************************
libvxcscovrts.sl:vendor_info()
VID: CSCOVRTS
PID: MDS9
ANAME: MDS9Series
ATYPE: A/A
ASL_VERSION: vm-4.1-rev-1
libvxcscovrts.key()
ASL Name: libvxcscovrts.sl
Feature Needed : 95
VxVM Version Needed: 41
Device: /dev/rdsk/c10t0d0
Vendor Identification: HITACHI
Product Identification : DF600F
Revision Number: 0000
Serial Number: 750100490059
libvxcscovrts.sl:claim_device(): UNCLAIMED
Device: /dev/rdsk/c10t0d1
Vendor Identification: HITACHI
Product Identification: DF600F
Revision Number: 0000
Serial Number: 75010049005A
libvxcscovrts.sl:claim_device(): UNCLAIMED
(SR: 8606445101 CR: JAGag02584)
Veritas Incident No:540075
Under the following scenario, detached plexes
remain out-of-sync even after recovery. This
may lead to silent data corruption.
1) A volume has 2 or more plexes all of which are
ACTIVE (none is DETACHED).
2) The volume does not have any snapshots.
3) Some of the plexes become unavailable while
multiple I/Os are active on the volume.
4) System crashes after the unavailable plexes are
marked DETACHED but before the DCO captures the
differences between the good and detached plexes.
(SR:8606445103 CR:JAGag02585)
Veritas Incident No: 578954
Need to add on the fly debugging ability to
vxconfigd.
(SR: 8606445105 CR:JAGag02587)
Veritas Incident No:598403
Memory leak on vxnotify.
(SR:8606445109 CR:JAGag02591)
Veritas Incident No:608290
vxasldebug output for EVA8000 (HSV210) gives
an error:
Device : /dev/rdsk/c4t0d1
Vendor Identification : HP
Product Identification : HSV210
Revision Number : 5100
Serial Number : A299AS802LA2
libvxhpalua.sl:claim_device(): CLAIMED
VID : HP
PID : HSV210
CAB_SERIAL_NO : 50001FE150062930
LUN_SERIAL_NO : 600508B400107306000110000391000 0
REVISION : 5100
UDID : HP_HSV210_50001FE150062930_6005
08B4001073060001100003910000
LUN_OWNER : Y
CUR_OWNER : Y
PORT_SERIAL_NO : 50001FE150062939
ANAME : EVA8000
ERROR: vendor_info() VIDs don't match, inquiry
HP vendor_info COMPAQ.
(SR:8606445113 CR:JAGag02595)
Veritas Incident No:496847
In CVM environment, deport of shared disk group
takes lot of time. For example, two node cluster
with shared disk group having 10 disks of a size
1 GB each takes approximately 5 minutes for deport.
(SR:8606445114 CR:JAGag02596)
Veritas Incident No:604299
On account of keeping the major number associations
around after removing a driver package
(feature of HP-UX 11.23), EMC TPD drivers are not
getting cleared from the kernel even when the driver
is actually removed from the system. One can verify the
stale entry by running "lsdev" command as keeping the
major number of associations.
# lsdev | grep emcp
Character Block Driver
114 2 emcp
This gives a notion that VxVM disks are still
controlled by EMC TPD, but actually they aren't.
(SR:8606445117 CR:JAGag02599)
Veritas Incident No:596112
When vxconfigd debug is turned on, diskgroup import
can fail with error.
vxvm:vxdg: ERROR: Disk group sybdg: import failed:
Internal configuration daemon error.
(SR:8606445118 CR:JAGag02600)
Veritas Incident No:603234
In CVM cluster, there is a small window during
shared disk group deport operation on the slave node,
when a command like vxprint could cause vxconfigd
to generate some warnings like:
VxVM vxconfigd WARNING V-5-1-7989 Get of record
testvol from kernel failed:No such file or
directory.
(SR:8606445119 CR:JAGag02601)
Veritas Incident No:577108
Running vxdisksetup on a system with a large number
of luns (more than a thousand) takes very long time.
(SR:8606445120 CR:JAGag02602)
Veritas Incident No:519644
In a Clustered Environment with two arrays attached
to the cluster, a disk group is created spanning
both arrays. Powering off one array with I/Os in
progress, snapshot of a volume residing on one
array to disks on the second array, cause Serial
Split Brain errors like:
VxVM vxdg ERROR V-5-1-10127 associating disk-media
testdg04 with c4t5d0: Serial Split Brain detected.
Run vxsplitlines.
(SR:8606445121 CR:JAGag02603)
Veritas Incident No:521576
False Serial Split Brain hit on master if slave and
one of arrays are brought down together.
(SR:8606445122 CR:JAGag02604)
Veritas Incident No:303628
HP requests that a check is made for the pfto
argument in vxdisk not to be lower than 15s.
(SR:8606445312 CR:JAGag02782)
Veritas Incident No:493411
EVA GL 3000, 5000 disk arrays are not recognized by VxVM.
(SR:8606445313 CR:JAGag02783)
Veritas Incident No:519628
During CVM reconfiguration in a 2-node cluster,
vxconfigd dumps core with the following stack:
------------------------------------------------
strcpy.strcpy() at 0x1001c170
advreq_master(0x2017d7f8)
advreq(0x2017d7f8)
vold_getrequest(0x5)
send_slaves(0x1, 0x2ff225f8, 0x5, 0x0)
master_send_da(0x201aa2a0, 0x2ff22650, 0x1)
vold_dm_as_da(0x2018e220, 0x201aa050,
0x20181df0, 0x8)
req_dm_as_da(0x20181df0, 0x200760b8)
request_loop()
(SR:8606446350 CR:JAGag03724)
Veritas Incident No:565987
In a CVM environment, after disabling the primary
path of a shared disk via
"vxdmpadm disable ctrl=<ctrl_name>" on the CVM master,
I/Os doesn't fail over to the secondary path(s) on CVM
slaves nodes.
(SR:8606446351 CR:JAGag03725)
Veritas Incident No:569033
HP EVA ALUA ASL failed to claim HSV disks with
the following vxconfigd errors:
$ vxdctl enable
"VxVM vxconfigd ERROR V-5-1-8784 disk /dev/rdsk/c92t0d7
can't be claimed - DDL_ERROR hpalua
claim_device: AAS invalid hpalua claim_device:AAS
invalid: Error 0
VxVM vxconfigd ERROR V-5-1-8784 disk /dev/rdsk/c92t0d5
can't be claimed - DDL_ERROR: Error
vxcheckasl or vxasldebug shows
"libvxhpalua.sl:claim_device() : ERROR"
(SR:8606442723 CR:JAGag00460)
Veritas Incident No:618400
System becomes unbootable from EMC8830 if PHCO_33509
installed. The following messages appear while booting:
Starting vxconfigd in boot mode (pre_init_rc).
NOTICE: VxVM vxdmp V-5-0-111 disabled dmpnode 1/0x0
WARNING: VxVM vxio V-5-0-2 Subdisk ROOT block 82497:
Uncorrectable read error
WARNING: VxVM vxio V-5-0-2 Subdisk ROOT block 224068:
Uncorrectable read error
Synchronous Page I/O error occurred while paging
to/from disk
VxVM vxconfigd ERROR V-5-1-0 Bus error
(SR:8606455828 CR:JAGag12320)
Veritas Incident Number:602717
We have implemented a timeout for vxconfigd such that,
it can timeout if a long time is taken to read private
regions of faulty disks. The timeout value can be tuned
by the user and its usage is given in details in the
man page for vxdctl.
(SR:8606447238 CR:JAGag04585)
Veritas Incident Number:634791
vxdisksetup -iB allows overwriting for the disk
in use by LVM.
(SR:8606455839 CR:JAGag12331)
Veritas Incident Number:612603
For space optimized snapshot, vxsnap does not create
dco on the disk specified in alloc option.
(SR:8606449570 CR:JAGag06724)
Veritas Incident Number:633161
During overlapping CVM reconfigurations, such as a node
join being interrupted by another node leaving the
cluster, vxconfigd times out on any one of the nodes,
which can lead to MCSG halting the node in
ServiceGuard/CFS stack. This problem is reproducible
with internal testing/stress testing. A typical symptom
of this problem is that the kernel thread is spawned by
CVM node id daemon, while in node id protocol, is stuck
on vol_vold_in_join variable to be reset. Typical stack
trace of the kernel thread associated with the symptom
is:
kt_stat: TSSLEEP
kt_cntxt_flags: 0x0
kt_wchan: vol_vold_join_sync+0x8
swtch_to_thread+0x550
_swtch+0x30
real_sleep+0x9e0
sleep_spinunlock+0x1b0
_vol_syncwait+0x4a0
vol_set_membership+0x14c0
volcvm_set_members+0x15b0
kthread_daemon_startup+0x40
kthread_daemon_startup+0x0
swtch_to_thread+0x550
PHCO_33509:
(SR: 8606419256 CR:JAGaf79086)
Doing an ignite_ux install using the VxVM listener
"smapi", sometimes get error that device node
does not exist.
(SR:8606405497 CR:JAGaf65418)
1) Doing an ignite_ux install using the VxVM listener
"smapi" gets an error, if a "system volume" is specified
for a different disk group other than the root disk group.
2) Trying to install VxVM 4.1 rootdg that does not
contain a designated root disk fails.
(SR:8606419263 CR: JAGaf79093)
If a path to a dmpnode was disabled due to a port on a
SAN switch being disabled, it would go to DISABLED state.
Once the port was re-enabled and after waiting for a couple
of seconds (to allow host to redetect the fabric), a
'vxdisk scandisks' or 'vxdctl enable' should bring the
path back to ENABLED state. In this case, the path did
not go to ENABLED state until a few additional
'vxdctl enable' or vxdisk scandisks' were issued.
(SR: 8606419265 CR: JAGaf79095)
Creation of a new diskgroup using 'vxdiskadm' fails with
an error similar to the following one,
if Enclosure Based Naming is used:
VxVM vxislvm ERROR V-5-1-6218 vxislvm:
Cannot stat /dev/rdsk/TagmaStore0_2
VxVM vxislvm ERROR V-5-1-6218 vxislvm:
Cannot stat /dev/rdsk/TagmaStore0_2
VxVM vxdisk ERROR V-5-1-558 Disk dg02:
Disk not in the configuration
(SR: 8606419267 CR: JAGaf79097)
Overlapping reconfigurations during CVM node join
get hung in between and as a result, node's join
get timed out.
(SR: 8606408073 CR: JAGaf67976)
Messages like the following are emitted on the console
in a CVM environment:
"VxVM vxvol ERROR V-5-1-1217 Volume vol is already
started"
(SR: 8606413328 CR: JAGaf73189)
The cvm node join operation takes more than 30 minutes
to join. Therefore it might timeout if there are
many shared disk groups.
(SR: 8606419276 CR: JAGaf79106)
If a volume is mounted on bootdg, then the vxresize
command will fail to work.
# vxresize -g bootdg test1 15m
VxVM vxresize ERROR V-5-1-2741 volume test1:
Disk group is ambiguous.
Specify [-g diskgroup].
(SR: 8606406994 CR: JAGaf66900)
In CVM environment, cluster reconfiguration timed out
due to cvm node join time out.
(SR: 8606419264 CR: JAGaf79094)
Severe performance degradation due to vxplex attach of a
large number of volumes in a clustered environment.
(SR: 8606419266 CR: JAGaf79096)
DMP multipathing does not work as expected with EMC DMX
800 array.
(SR: 8606411927 CR: JAGaf71792)
During a cluster startup, the following message
appears on the console:
VxVM vxconfigd ERROR V-5-1-4109 -1 returned
from volcvm_establish
(SR: 8606419269 CR: JAGaf79099)
When run on an array with the "No Auto Trespass"
feature enabled, the
"vxdmpadm getsubpath dmpnodename=<Name>"
command can hang while getting the dmp subpath
information to display.
(SR: 8606419271 CR: JAGaf79101)
The vxrootmir command complains about not being
able to deal with plexes with an unassociated subdisk
i.e. name of "-".
(SR: 8606419272 CR: JAGaf79102 )
In CVM environment the master takeover
fails at the vxconfigd level join.
(SR: 8606413083 CR: JAGaf72945)
On a two node cluster, during master takeover,
the master fails to import the shared diskgroups.
The following messages are seen in syslog
of the new master:
"V-5-1-5537 AUTOimport-Importing shared disk groups"
"V-5-1-5536 imported 0 shared disk groups"
(SR:8606405567 CR: JAGaf65488)
Once the vxconfigd is started, previously
initialised disks were set to error state.
vxdisk list command confirms the same:
DEVICE TYPE DISK GROUP STATUS
c4t2d0 auto:hpdisk - - error
(SR: 8606419808 CR: JAGaf79638)
Need to make commands sent to other nodes in a cluster
use cmexec when SG is involved in cluster management.
(SR: 8606408077 CR: JAGaf67980)
Commands that receive/send information from the
vxconfigd process, e.g. vxprint, can get an
error message like:
"Configuration daemon is not accessible"
(SR: 8606419813 CR: JAGaf79643)
After forcibly unloading glm DLKM module,
if a user tries to start cvm as a part of a
cluster startup, the cluster command or script
returns success but fails to start cvm.
(SR: 8606419815 CR: JAGaf79645)
vxvol coredumps while trying to get the dg
configuration objects.
Stack trace is as follows:
#0 0x4087410:1 in get_srcvols at comstart.c:6548
#1 0x4065e80:0 in common_start_resync at comstart.c:293
#2 0x4065a40:0 in do_start at comstart.c:205
#3 0x4047e40:0 in main
(SR: 8606419816 CR: JAGaf79646)
vxdisk resize hangs.
Stack trace is as below:
bmap_test() + 18
priv_update_toc() + 318
priv_resize() + 794
da_resize_common() + 1dc
auto_disk_op() + 7c
vold_disk_resize() + d8c]
req_disk_resize() + 108
request_loop() + 8e4
main() + c1c
(SR: 8606419818 CR: JAGaf79648)
Serial Split Brain during vxdg adddisk on an imported
disk group.
(SR: 8606419820 CR: JAGaf79650)
Panic during a dco update on a NPFMR-2 snapshot
while firing I/Os to that snapshot for a volume
which also has PFMR-3 snapshot associated with it.
Stack trace is as below:
voldco_needupdate_instant+0x10
voldco_needupdate+0x30
volfmr_needupdate - frame recycled
vol_mv_write_start+0x17c
volkcontext_process+0x518
volkiostart+0x7f0
vxiostrategy+0xa8
bdev_strategy+0x90
ufs_putsummaryinfo+0x140
logmap_roll_dev - frame recycled
ufs_flush+0x1c8
ufs_unmount+0x1cc
dounmount+0x54
umount2+0x188
syscall_trap32+0xa8
(SR: 8606419821 CR: JAGaf79651)
IO errors while accessing a filesystem that disabled.
The log file syslog.log has SCSI write errors as well
as VxVM vxio errors, like:
WARNING: VxVM vxio V-5-0-2 Subdisk c4t0d0-01
block 1139762: Uncorrectable write error
The problem happens only if SCSI PGR keys are used.
(SR: 8606419822 CR: JAGaf79652)
vxsnap fails to take snapshots of a volume
in a shared DG and dumps core.
Stack trace follows:
#0 0x4147850:0 in real_free+0x2f0 ()
#1 0x41474d0:0 in _free+0x90 ()
#2 0x4152f70:0 in free+0x1d0 ()
#3 0x4093430:0 in vol_freeze_cluster at vxfsfreeze.c:400
#4 0x405fe40:0 in sync_volumes at fsgensync.c:196
#5 0x405e2c0:0 in do_snapsync at volume.c:5089
#6 0x4048440:0 in main at volume.c:402
(SR:8606423407 CR:JAGaf82930)
The new ASL for emc library doesn't get claimed
with all SYM 5x71 devices(<8k and >8k LUN's)
due to the error by VM because of
"ERROR: check_nvlists: Claiming error LUN_SER_NO
not specified".
(SR:8606423408 CR: JAGaf82931)
vxconfigd invokes an uninitialized function pointer in
the DDL static library resulting in a core dump.
The stack trace looks like the following:
#1 ddl_vendor_select_device volddl_claim.c:3881
#2 array_select_da () at daselect.c:171
#3 da_select_diskid () at daselect.c:101
#4 da_find_diskid() at da.c:5556
#5 dg_join_disks() at dgimport.c:3771
#6 dg_import_internal() at dgimport.c:1070
#7 req_dg_import() at dgimport.c:727
#8 request_loop () at request.c:488
#9 main() at main.c:534
(SR:8606423409 CR: JAGaf82932)
In a configuration where both swapvol(SWAP)
and dumpvol(DUMP) are separate, results in error.
Prior to the smapi version of ignite_UX (RA0509),
this configuration could be created without any error.
But with the smapi version of IUX,
we see the following error message:
ERROR: MAKE_BOOT: Volume dumpvol does not
contain a file system.
* smapi listener returned "ACTION_FAILURE"
for message "MAKE_BOOT"
(SR:8606423414 CR:JAGaf82937)
An harmless error message occurred when trying to
halt a one node cluster in CVM environment.
ERROR message:
VxVM ERROR V-5-2-0 VOLCVM_GET_NIDMAP failed
(SR:8606423411 CR: JAGaf82934)
In CVM environment, one of the vxconfigd utility
namely vxvol keeps forking child vxvol during
volume resynchronization. It leads to a standstill
of operations performed on shared disk groups.
Stack trace looks like the following:
#0 _wait_sys+0x10 ()
#1 wait+0x48 ()
#2 wait_readloop()
#3 fork_readloop()
#4 call_readloop ()
#5 common_start_resync()
#6 do_start ()
#7 main ()
(SR:8606423410 CR: JAGaf82933)
In CVM environment vxconfigd dumps core
when a gab write happens as a result,
the node id map is not getting updated
at vxconfigd level.
Stack trace looks like the following:
#0 mknod+0x18 () from /usr/lib/libc.2
#1 srand+0x4c () from /usr/lib/libc.2
#2 __hpmfcobol_strcoll_sb+0x118 ()
from /usr/lib/libc.2
#3 audit_daemon+0x8 () from /usr/lib/libc.2
#4 srand+0x4c () from /usr/lib/libc.2
(SR: 8606423412 CR: JAGaf82935)
DDL doesn't claim EVA 4k,6k LUNs in HPUX.
(SR: 8606419810 CR: JAGaf79640)
Veritas Storage Expert rules are not working.
# /opt/VRTS/vxse/vxvm/vxse_stripes2 info
/usr/lib/dld.sl: Can't open shared library:
/net/prague/u2/sap/nightly/obdev/hp/lib/libvxapi.sl
/usr/lib/dld.sl: No such file or directory
ABORT instruction (core dumped)
(SR: 8606419803 CR: JAGaf79633)
Cumulative VVR fixes
1)Veritas Incident Number:426233
vxmake rlink command fails with the following
error:
" could not get local host name "
2)Veritas Incident Number:415076
vradmin repstatus command can show blank
value for "Logging to:" field in some situations
3)Veritas Incident Number:415078
vradmind daemon may hang if there are more
than 256 volumes under RVG.
Defect Description:
PHCO_36111:
(SR: 8606491002 CR: JAGag43357)
SYMANTEC Incident Number: 867085 (600447)
When the configuration information is dumped,
the last platform field is displayed as "0x0 #bad" for
disk groups with a version number of less than 110.
Resolution:
The code has been modified to display the value of
the last_platform field.
(SR: 8606491003 CR: JAGag43358)
SYMANTEC Incident Number: 899703 (524016)
Due to problems with the DMP_DEV_OPEN ioctl() command,
DMP consistently fails to open the same LUNs, and disables
the devices in response to a specific condition that
it detects from the devices and from the driver. Once
the system comes up, the "vxdctl enable" command must be
used to re-enable the devices.
Resolution:
The resolution is to invoke "vxdctl enable"
during the rc2.d stage. This will stop and
start the restore daemon which will enable
all the paths before fencing is started.
(SR: 8606491004 CR: JAGag43359)
SYMANTEC Incident Number: 925690 (9000090)
There is no Array Support Library (ASL) for the
MSA array which is not recognized as a JBOD during
the first invocation of vxconfigd from pre_init_rc.
The /etc/vx/.aascsi3 file, which is not added
until after vxconfigd is started, is required to
instruct DDL/DMP to use the SCSI-3 mode pages to check
for the LUN serial number, and to determine if multiple
paths exist to a LUN.
Resolution:
The solution is to create the /etc/vx/.aascsi3 file
from the post install script, which is run following
the swinstall of the VRTSvxvm fileset.
(SR: 8606491806 CR: JAGag43991)
SYMANTEC Incident Number: 992607 (967551)
When a DRL is configured on shared mirrored volumes,
a CVM node can join a cluster only if the DRL maps for
all the shared volumes are recovered. If one or more shared
volumes share part of a disk or disks with another DRL
attached shared volume, recovery of the DRL map may have
to wait for the resynchronization of the volumes
to complete. resynchronization can take some time
depending on the size of the volumes that are involved.
In such circumstances, a CVM join of a node consistently
fails with "recovery in progress" error until
the DRL maps are recovered.
Resolution:
The DRL maps recovery is first completed on all the shared
volumes. Resynchronization is started after DRL recovery
is complete.
(SR: 8606491009 CR: JAGag43364)
SYMANTEC Incident Number: 996706 (995883)
The VxMS VxVM plugin fails to open volumes that have been
created on the boot disk group.
Resolution:
For the bootdg disk group, the name of the aliased disk
group is determined, and this disk group name is used to
invoke the function.
(SR: 8606491010 CR: JAGag43365)
SYMANTEC Incident Number: 996707 (995886)
The VxMS DMP plugin returned both active and passive paths.
As passive paths cannot be mapped any further, VxMS only
required those paths for display purposes. Passive paths
needed to be marked as dummy paths.
Resolution:
A flag was added to indicate a passive path.
(SR: 8606491012 CR: JAGag43367)
SYMANTEC Incident Number: 996708 (961548)
When the VxMS VxVM plugin attempts to claim objects
such as "/", "/dev" or "/dev/dsk", it attempts to call
dg_set_current with null values in the
disk group and volume fields.
This results in an error.
Resolution:
The plugin now fails gracefully if the object is
"/", "/dev", "/dev/vx/dsk" or other similar object.
(SR: 8606491014 CR: JAGag43369)
SYMANTEC Incident Number: 1021717 (1012502)
The memory that is used by the VxVM and DMP plugins
for VxMS for storing the subobj_link_prop object was
not freed correctly, resulting in a memory leak.
Resolution:
The memory leak in the subobjvector()
function was fixed.
(SR: 8606491015 CR: JAGag43370)
SYMANTEC Incident Number: 1034909 (1019973)
The VxMS VxVM plugin failed to initialize the
private data of the log plex, resulting in the
failure of buildmapdomain() for the volume.
Resolution:
The plugin now checks whether a plex is a log plex for the
volume. For log plexes, the sub disk data is initialized
using the associated log information.
(SR: 8606493362 CR: JAGag45535)
SYMANTEC Incident Number: 768086 (314738)
In the cluster environment, each node in the
cluster maintains its own volstatus current
sequence number to obtain its dgimport id.
When a master switch happens, the newly obtained
dgimport id on the alternate master collides
with already imported shared diskgroup's dgimport id.
Resolution:
Modify the volstatus current sequence number on master
to a value bigger than slave to get a unique sequence
number during import.
(SR: 8606493364 CR: JAGag45537)
SYMANTEC Incident Number: 1079279 (1079281)
In HP-UX, awk(1m) limits the number of fields to 200
and should therefore be avoided when the number of fields
is expected to be more than 199.
Resolution:
The solution is to combine the code of split(1) with
awk(1) to overcome awk's limit of 200 fields.
(SR: 8606493367 CR: JAGag45540)
SYMANTEC Incident Number: 1075637 (1075636)
The registered modules are considered as loaded
modules as the status of the loaded modules is accounted.
Resolution:
The status of the modules is correctly determined
before they are loaded into the kernel.
(SR: 8606492213 CR: JAGag44384)
SYMANTEC Incident Number: 990611 (793534)
When devices are masked from the host using the
"symcli rmdev" command, a SCSI inquiry on these
devices returns success with the peripheral qualifier
set to a non-zero value, 0x7F.
However I/O on these devices fails. These devices
should not be claimed by VxVM in the device discovery
process because the information about the serial numbers
from these devices can be wrong, and it can corrupt the
in-core DMP database.
Resolution:
The solution is to check for the peripheral qualifier
bits in the inquiry data and not claim the device if
the peripheral qualifier is set to 0x7F.
(SR: 8606492216 CR: JAGag44387)
SYMANTEC Incident Number: 415080 (365919)
With multiple primary /secondary paths, vxdmpadm(1M)
lists the enabled paths as "ENABLED(A)" but the
get_primary_path function in vxadm_lib.sh recognizes
only the string "ENABLED". As a result, a secondary
path may be selected even though there is an enabled
primary.
Resolution:
The function is fixed to recognize "ENABLED(A)" in
vxdmpadm(1M) output.
(SR: 8606492218 CR: JAGag44389)
SYMANTEC Incident Number: 564844 (520888)
Disk Media (DM) records are processed in a way that
extends vxconfigd startup time. During the investigation
it was found that the record list was processed four times,
therefore producing a larger than necessary record list.
A large record list indicates that there are more volumes
or objects in a disk group than the actual configuration.
This causes unnecessary delays to vxconfigd startup.
Resolution:
To find DM records associated with volume, we can avoid
examining complete record lists by extracting only
relevant records listed for searching.
(SR: 8606413219 CR: JAGaf73080)
SYMANTEC Incident Number: 1002929 (1019506)
Incorrect mode sense data (obtained from MAXTOR disks)
results in the calculation of faulty disk geometry.
This results in disks being initialized with a
smaller capacity.
Resolution:
The correct disk geometry is calculated after comparing
both the mode sense data and data obtained from the
explicit DIOC_IOCTL ioctl(2).
(SR: 8606492221 CR: JAGag44392)
SYMANTEC Incident Number: 781337 (792815)
The "vxddladm listsupport" command reads array support
information from /etc/vx/ddl.support file. In this file,
there can be multiple lines having the same VID field,
thus skipping all the supported PID's except the first one.
Resolution:
The solution is to concatenate the 'PID' lines and then
display the information.
(SR: 8606492222 CR: JAGag44393)
SYMANTEC Incident Number: 832354 (832350)
The command "vxdctl initdmp" is not expected to remove an
entry present in the /dev/vx/[r]dmp directory for which
there is no corresponding dmpnode in the kernel.
Resolution:
The manpage is updated to convey the correct meaning.
(SR: 8606492223 CR: JAGag44394)
SYMANTEC Incident Number: 914946 (914941)
There are no manual pages for the utility vxautoconvert(1M).
Resolution:
The manual pages have been added.
(SR: 8606492225 CR: JAGag44396)
SYMANTEC Incident Number: 990719 (524096)
This is an enhancement request to change vxdisk(1M) to
show DM names even for detached disks.
Resolution:
The command is enhanced to show DM names for detached disks.
(SR: 8606492226 CR: JAGag44397)
SYMANTEC Incident Number: 990722 (541911)
The "vxconfigd" daemon serializes multiple disk group
imports that occur simultaneously. Consequently,
each disk group import call needs to bring all the disks
online. This is an expensive call which needs to be
optimized.
Resolution:
If a dg import request arrives when another dg import is
still in the midst of a re-online call to bring disks
online, the new dg import request will skip the re-online
call.
(SR: 8606485196 CR: JAGag38229)
SYMANTEC Incident Number: 1067429 (1067501)
IA boot disks are EFI-partitioned disks. Only partition
s2 is available for the root dg. When making size
calculations, vxdisksetup(1M) wrongly uses the
non-partitioned disk name "cXtYdZ" based on the
output of "vxdisk list", although the
actual size of the s2 partition may be much smaller.
Resolution:
The solution is to add the code to append the s2
partition to the "vxdisk list" cXtYdZs2 output.
(SR: 8606492227 CR: JAGag44398)
SYMANTEC Incident Number: 1026855 (418674)
The library vxadm_lib.sh creates a number of
temporary files, which are left unused.
Resolution:
A new function has been added to clean up
the unused files upon an exit call.
(SR: 8606494641 CR: JAGag46574)
Symantec Incident Number: 1105097 (318531)
In EBN (Enclosure Based Naming) scheme,
disks are named based on indices assigned
whereas for OS Native Naming scheme the
name of the device is used.
When the bitmap which is used to store the
disk index is full, reallocation of the memory
of this bitmap is done. The value which was passed
to reallocate the memory was wrongly calculated
resulting in segmentation fault.
Resolution:
Modified the vxconfigd(1M) code to pass the correct
value to avoid the memory violation.
(SR: 8606494643 CR: JAGag46576)
Symantec Incident Number: 1110521(995886)
This is a corner case where a disk has only
secondary active path(s) and no primary path.
The problem is that the DMP plugin would identify
the secondary paths as passive,
even if they are active.
Resolution:
The DMP plugin was fixed to correctly
identify active secondary paths.
(SR: 8606494644 CR: JAGag46577)
Symantec Incident Number: 1110528 (995883)
On some error conditions, some of the internal
VM plugin synchronization locks were not released.
Resolution:
The VM plugin is fixed to release synchronization
locks properly even on error conditions.
(SR: 8606494633 CR: JAGag46566)
SYMANTEC Incident Number: 989943 (209580)
Sixth node may fail to join the cluster with
V-5-1-684 IPC failure: Configuration daemon is not
accessible.
The problem arises mainly due to two possibilities
1)One is that the backlog of the listen socket is only 5.
Thus when more than 5 clients are blocked
waiting to communicate with vxconfigd, any additional ones
will fail.
2)Secondly, the environment variable VXVM_RETRY_SET gets
set to false whenever backlog is full.
Resolution:
1)Modify the backlog by setting it to a bigger value so
more clients can listen to the socket.
2)Set VXV_RETRY_SET to true value, even if the backlog of
the listen socket is full.
(SR: 8606494634 CR: JAGag46567)
SYMANTEC Incident Number: 990576(497302)
Under certain conditions, such as some hosts
in a HA/Campus cluster crashing/rebooting/failing
*and* they losing of access to some storage in
a disk group, (host) failover will take place.
On the takeover host(s), the on-disk hostid would
be different from that in the host's volboot file,
as a result "vxdg -k adddisk" would fail,
hence the failure of vxreattach.
Resolution:
Implemented a new option "-C" (to clear hostid) to
allow vxreattach to succeed if issued with this option.
(SR: 8606494635 CR: JAGag46568)
SYMANTEC Incident Number: 990639(895525)
The algorithm used to calculate the space needed to
create drl logs for volumes works fine and gives the
correct number of blocks required for the drl logs.
But, if we have more than one volumes
then calculation gives the incorrect number of blocks
required for the drl logs.
Resolution:
Changed the algorithm of calculating the number of
blocks needed for drl logs to give the correct number of
blocks needed for drl logs.
(SR: 8606494636 CR: JAGag46569)
SYMANTEC Incident Number: 990701 (497300)
The "failing" flag should not be display in the
first place, as for a detached DM record, the state of
"failing" makes no sense.
Resolution:
Remove the check against "failing" flag
when printing detached DM record.
(SR: 8606494638 CR: JAGag46571)
SYMANTEC Incident Number: 990709(524055)
Vxassist incorrectly calculates the new layout of the
volume with new size. When it passes the new layout to
vxconfigd it reports that the subdisks overlap and hence
it cannot grow the new volume
Resolution:
Fixing the way vxassist calculates space for log subdisks
in the new volume layout solves the problem. Vxassist
forms an in-memory layout of the new volume before it
actually commits the new layout. When adding the log
subdisks, an incorrect parameter regarding the number
of log subdisks is passed which creates the incorrect
layout. With the correct parameter, the correct
layout without any overlaps is formed.
PHCO_35890:
(SR: 8606470105 CR: JAGag25246)
Veritas Incident Number: 899646(862878)
The vxvmconvert utility does not check for file
system existence and creates volumes of GEN type
instead of FSGEN. Subsequently, the vxresize of
a GEN type volume fails.
Resolution:
The code has been modified to check for the
existence of the file system in the fstab file,
as well as by using the fstyp command.
(SR: 8606455268 CR: JAGag11831)
Veritas Incident Number: 899675(900203)
The vxbrk_rootmir script does not handle volume
names with a substring of another volume name in
a disk group.
Resolution:
The script has been modified to handle volume names
with a substring of another volume name in a disk group.
(SR: 8606474302 CR: JAGag28848)
Veritas Incident Number: 899681(641439)
In the VRAS code, a RDS object
is accessed without checking if the RDS pointer
is not NULL. This code is executed when vradmind
sends a snapshot of its database to a vradmind client such
as VVR provider.
Resolution:
The length of the string is checked, and an error
is returned for lengths exceeding 64k.
This is done to avoid memory allocation problem.
(SR: 8606471971 CR: JAGag26927)
Veritas Incident Number: 960396(855057)
Due to a logical error in parallel conversion,
the entries are being overwritten by vxautoconvert.
Resolution:
The script which updates the /etc/fstab
entry has been modified to ensure that the
entries are appended.
(SR: 8606467094 CR: JAGag22530)
Veritas Incident number: 927439(832358)
When DMP builds its device tree through 'vxdctl initdmp',
it does not remove any existing or conflicting device
nodes in /dev/vx/(r)dmp. This can lead to duplicate or
stale dmp metanodes. An I/O to a non-existent device can
further cause the existing dmp node to disable due to
conflicting minor numbers. Also, the I/Os on
slice/partitions can end up disabling base devices that
conflict with stale devices.
Resolution:
The code has been modified to cleanup all existing dmp
device nodes during vxvm-startup phase and let
'vxdctl initdmp' recreate the nodes. This ensures that
no pre-existing stale device nodes are present in the
dmp device tree. Also, I/Os on the stale or non-existent
service partition are failed to avoid disabling of the
active base dmpnode.
PHCO_35738:
(SR: 8606472168 CR: JAGag27068)
Veritas Incident Number: 795130 (795129)
After the master node goes down, one of the
slave nodes takes over the responsibility
of the master node. This is known as
Master-Takeover operation. The shared DG
reimport occurring as part of the
Master-takeover operation on the slave node
at the userland (vxconfigd) level coincides
with the node abort signal from MC/SG. It
results in the cleaning-up of the shared DG
from the vxio kernel while vxconfigd still
trying to reimport this DG. Because of
this, vxconfigd encounters errors while
attempting kernel ioctl operation on the
DG. The Master-takeover code cannot handle
the ioctl error conditions that occur during
the shared DG reimport. The ioctl can fail
either due to the ENOENT (No such file or
directory) error or due to the EINTR
(interrupted system call) error during the
shared DG reimport.
Resolution:
The error-handling for the EINTR error is
introduced in the Master-takeover operation
code. The Master-takeover operation can now
handle both the ENOENT and EINTR kernel ioctl
failures.
(SR: 8606473669 CR: JAGag28300)
Veritas Incident Number: 831065 (804673)
No memory was allocated to nvlist structure in
the ddl_vendor_info()routine. Later a free()
was done on this, which was not required. This
causes a free() operation on a wrong address
and, as a result, vxconfigd dumps core.
core dump.
Resolution:
Redundant call to free nvlist has been removed.
(SR: 8606472173 CR: JAGag27073)
Veritas Incident Number: 833619 (610841)
There was a logical error in the vxbrk_rootmir
code while calculating the number of disks that
do not have all the volumes of the root disk.
This occurs because all the mirrors of the VxVM
root disk are not taken into account.
Resolution:
All mirrors of the boot disk are taken into
account while calculating the number of disks
that do not have all the volumes of the root
disk.
(SR: 8606473664 CR: JAGag28295)
Veritas Incident Number: 836473 (834318)
The licensing code reallocates some of the
structures without freeing the old ones.
This leads to a memory leak in vxconfigd
daemon.
Resolution:
Memory allocation for the structures is done
only after verifying that the memory for those
structures is freed.
(SR: 8606472172 CR: JAGag27072)
Veritas Incident Number: 839168 (839077)
The vxresize (1M) command uses statvfs (2) system
call to obtain the file system information.
The file systems that are greater than 2TB
in size cause an overflow in the "statvfs"
structure fields.
This can be verified by the tusc traces on
vxresize process, which shows EOVERFLOW error.
Resolution:
Use the 64 bit version of statvfs(), that is,
statvfs64(), to obtain the information about
the mounted file systems.
(SR: 8606472171 CR: JAGag27071)
Veritas Incident Number: 833704 (833700)
VxVM I/Os are limited by MAXIOSIZE, which is
currently set to 256Kb for HP-UX. This limit
is based on the old MAXPHYS definition. There
is a tunable, vol_maxio, to set the maximum IO
size but it is ignored for any value over 256Kb.
Physical I/Os can be up to 1MB in size.
MAXIOSIZE should be changed to allow 1MB I/Os.
Resolution:
Increase the MAXIOSIZE to 1MB. This change also
entails a change in the default value of
vol_maxspecialio that governs the maximum I/O
size of an IOCTL from 256k to 1024k.
(SR: 8606472174 CR: JAGag27074)
Veritas Incident Number: 844510 (783758)
If the original size of a physical extent is
small enough while creating the VG, the number
of physical extents (PEs) in a VG exceeds its
maximum value that results in this problem.
Resolution:
Run the vgcreate(1M) with the next power of
2 PE size if it is determined that the failure
is due to exceeding maximum number of PEs.
(SR: 8606473668 CR: JAGag28299)
Veritas Incident Number: 851396 (405564)
The last command used prior to the normal exit in
vxdiskunsetup (1M) was the "vxdisk -a online" command.
This command brings all the disks online, which
makes it slow. vxdiskunsetup (1M) performs the
'vxdisk online <disk>' command within its processing
loop after removing the VxVM partitions. So, the
'vxdisk -a online' command is redundant and should
be removed.
Resolution:
The call to the redundant command "vxdisk -a online"
has been removed from the vxdiskunsetup (1M) command.
PHCO_35476:
(SR: 8606467245 CR: JAGag22669)
Veritas Incident Number: 781473
Problem Description:
The "vg_timestamp" field was removed from the LVM
private structure. vxvmconvert was using this field
to identify the latest copy of the configuration.
Without this value vxvmconvert may use an outdated
configuration which may lead to corrupted/incomplete
volume Group.
Resolution:
Instead of using the LVM private structure, the
command line interfaces (vgdisplay/lvdisplay/pvdisplay)
are now used to obtain the information the converter
needs to accomplish the conversion. Using the LVM
command line interfaces also enables identification
and conversion of extent based volume groups (if
the configuration fits into a valid VxVM disk group
configuration).
(SR: 8606467112 CR: JAGag22546)
Veritas Incident Number: 790788
Problem Description:
While creating the temporary database, the DCO
blocks were not being considered for space
allocation resulting in the error.
Resolution:
The code has been modified to ensure that the
DCO blocks are considered when space is
allocated for creating the temporary database.
(SR: 8606467110 CR: JAGag22544)
Veritas Incident Number: 788674
Problem Description:
The maximum size of the argument allowed in vxsnap
was fixed to 100 characters. This resulted in an
overflow if the argument exceeded the set limit.
Resolution:
The problem has been resolved by ensuring
that the maximum size of argument to vxsnap
is now dynamically allocated.
SR: 8606467113 CR: JAGag22547)
Veritas Incident Number: 795046
Problem Description:
There were many memory leaks in the functions
printfmr3(), getsnaplist(), do_print_vols(),
print_mapinfo() and vol_getformat().
Resolution:
The code has been modified to fix the memory
leaks.
(SR: 8606430187 CR: JAGaf89646)
Veritas Incident Number: 795049
/Problem Description:/
The main defect found in this customer case is
that "mirror=ctlr"/"mirror=target" are broken
and do not provide a HA layout following relayout.
Resolution:
The code has been modified to switch the order in
which temporary storage (used by the relayout
operation to create TMP configuration records)
and real storage are allocated. The way columns
are expanded through relayout_expand_column() has
also been reordered.
(SR: 8606405601 CR: JAGaf65522)
Veritas Incident Number: 795065
Problem Description:
The resync of volumes consisting of more than a
single plex was failing after a 2TB offset. An
error was encountered while configuring a
mirror-stripe volume that spanned across 16 disks
(two plexes across 8 disks each). The total volume
size was less than 16TB. This resulted in the loss
of information when 64 bits were converted to 32
bits.
Resolution:
The code has been modified to use appropriate
type casting so that the error is avoided.
(SR: 8606420552 CR: JAGaf80381)
Veritas Incident Number: 795965
Problem Description:
During the VxVM installation, when a module was
loaded in the OS, VxVM was not checking the prior
existence of the module. If the module existed, the
installation would fail with a NOTICE message being
written to the syslog.
Resolution:
The code has been modified to ensure that VxVM checks
for prior existence of a module before it is loaded
in the OS.
PHCO_34811:
(SR:8606445096 CR:JAGag02579)
Veritas Incident Number:496405
Problem Description:
ASL is returning UNCLAIMED instead of SKIPPED.
So the disk is claimed under JBOD.
Resolution:
Corrected the string comparison in claiming
device function of the ASL.
(SR:8606445097 CR:JAGag02580)
Veritas Incident Number:540604
Problem Description:
Few of the disks on customer's system were ending
up with duplicate disk ids. Segmentation fault occurred
while vxconfigd was processing a disk group deport
request. If there was no ASL on the system and the disks
were just mirrors of each other, then the duplicate disk
id detection code merely reports about the duplicate
disks and returns back NULL (no device selected).
Resolution:
If any STD device is offline, warning message will be
printed as:
"VxVM vxconfigd WARNING V-5-1-11551 array_da_to_disk:
Cannot find active path for dmpnode EMC0_1".
The diskgroup deport operation continues to finish.
However if the EMC BCV is offline and STD device is
online for which the part of this DG, the duplicate
diskid selection code will not be entered. So no
problem can be encountered.
(SR: 8606445098 CR:JAGag02581)
Veritas Incident Number:496817
Problem Description:
Built-in ASL for HDS 9500 Tagmastore needs to
differentiate from the AMS 500 Tagmastore by Serial
number, though both use HDS' DF600 controller. The
built-in ASL simply recognizes the DF600 Product ID,
and displays it as a 9500 array controller.
Resolution:
Changed the HDS ALUA ASL to differentiate between
HDS9500V and AMS/WMS series based on serial number.
(SR:8606445099 CR: JAGag02582)
Veritas Incident Number:496821
Problem Description:
ASL is returning UNCLAIMED.
Resolution:
Corrected the string comparison, in claiming device
function of the ASL.
(SR: 8606445101 CR: JAGag02584)
Veritas Incident Number:540075
Problem Description:
DCO fails to capture all differences between good
plexes and detached plexes in this particular
scenario.
Resolution:
Capture all the differences between good and
unavailable plexes before marking any plex DETACHED.
If the system crashes after the plex is marked
DETACHED then it will be properly recovered since
DCO has information about all the differences between
the good and DETACHED plex. If the system crashes before
an unavailable plex is marked DETACHED, recovery will
use DRL, if one exists, or complete plex resynchronization.
(SR:8606445103 CR:JAGag02585)
Veritas Incident Number:578954
Problem Description:
Need to set debugging level on the fly i.e without having
to stop vxconfigd. The syntax for switching on or off
debugging is:
vxdctl debug 0-9 [file], 0 turns off debugging.
Resolution:
Add a vxconfigd operation to address such requests.
(SR: 8606445105 CR:JAGag02587)
Veritas Incident Number:598403
Problem Description:
The notify note or notification event received from vold
is returned back to the caller. Its allocated memory is
expected to be freed by the caller. This was not happening
in some cases.
Resolution:
Free the note in all cases.
(SR:8606445109 CR:JAGag02591)
Veritas Incident Number:608290
Problem Description:
vxcheckasl was not handling multiple VIDs properly.
Resolution :
Loop through the vendor id list and check for a match.
(SR:8606445113 CR:JAGag02595)
Veritas Incident Number:496847
Problem Description :
Once the deport of disk group is over on master node,
the control message SLAVE_DISK_OP_NOTIFY is issued to
all slaves nodes seperately for each of their DA records.
This, in turn, triggers a da_reonline_all_disks() on the
slaves, thereby delaying the execution of vxconfigd on
the slave side. Even on the master side, subsequent
vxconfigd operations does get impacted and finally the
cascading effect brings about a huge latency in deport
operation.
Resolution :
After the deport of disk group in master node, a single
control message SLAVE_DISK_OP_NOTIFY is issued for all
the Disk Access records rather than one for each record.
(SR:8606445114 CR:JAGag02596)
Veritas Incident Number:604299
Problem Description :
The detection of the existence of third party driver
(TPD) is based on the output of lsdev command which
resulted in a stale entry even after removing the
module from the system. So the detection of TPD's
should be done at the kernel level to verify whether
it is loaded rather than invoking user level lsdev
command.
Resolution:
kcmodule(1M) command is used to check for the presence
of the TPD driver.
(SR:8606445117 CR:JAGag02599)
Veritas Incident Number:596112
Problem Description:
The global error number - errno, used to interpret the
status of the configuration ioctls could unexpectedly
change on the way of the completion of the ioctl when
vxconfigd is operating in debug mode. In the ioctl
debugging code, one of the system calls failure may
bring about the change in the global errno.
Resolution:
Before the ioctl debug info printing code, save the
error value immediately after the ioctl completion,
and use this value to report the ioctl status.
(SR:8606445118 CR:JAGag02600)
Veritas Incident Number:603234
Problem Description:
A shared deport involves first unloading the disk group
objects from the kernel and then performing a deport at
the vxconfigd level. There is a small window between
the unloading of the disk group and prior to vxconfigd
level deport wherein any attempt to fetch the kernel
records for the disk group objects on the slave could
result in "Get of record failed" warnings. These are
harmless warnings that can be ignored as the kernel
objects are genuinely not available in that small
window.
Resolution:
Warnings are skipped for the shared disk group deport
operation by the slave node.
(SR:8606445119 CR:JAGag02601)
Veritas Incident Number:577108
Problem Description :
Found that we were doing a vxdisk scandisks command
each time we executed this script. This takes a long
time on a large configuration. There is no need to do
the vxdisk scandisks, if an autoconfig DA record already
exists for the disk that is being initialized.
Resolution:
Check if an autoconfig DA record exists first before
doing the vxdisk scandisks. If it does exist, then we can
skip doing the vxdisk scandisks operation and running
vxdisksetup will take less than a second.
(SR:8606445120 CR:JAGag02602)
Veritas Incident Number:519644
Problem Description:
The problem is in the function which increment SSBs
on private regions and DM records of all disks that
are online. It was not doing the undo of the private
region ssb_actualid increment after priv_change_header
failures.
Resolution:
Undo Serial Split Brain updates for private region
update failures.
(SR:8606445121 CR:JAGag02603)
Veritas Incident Number:521576
Problem Description:
The disconnecting of the array causes dmp to disable
paths/dmpnodes corresponding to the unavailable disks.
vxconfigd receives a signal and in the ensuing
processing, it tries to increment actual and expected
SSB ids. However, if the slave also dies at this
stage, the increment of expected SSB id will fail as
the transaction fails with VE_CLUSTER error.
Subsequently when the surviving master nodes tries to
form a single node cluster, again it traverses the
same code path to increment the SSB ids. Both the
expected & actual SSB ids will now be incremented by 1.
But there's already a lag between expected & actual SSB
ids, which leads to a false SSB hit.
Resolution:
Handle VE_CLUSTER error and skip incrementing actual SSB
id again so that actual & expected SSB ids are same again
at the end of cluster reconfiguration.
(SR:8606445122 CR:JAGag02604)
Veritas Incident Number:303628
Problem Description:
The FC/SCSI stacks (particularly the former) requires
a minimum of 15 seconds to ensure events are handled
correctly. The pfto argument of vxdisk therefore needs
to ensure the value is no lower than 15.
Resolution:
Introduced a check so that vxdisk pfto value is not
accepted as lower than 15.
(SR:8606445312 CR:JAGag02782)
Veritas Incident Number:493411
Problem Description:
Connect EVA GL array with following VID/PID
=========================================
Spec on EVA GL AA. VID, PID and behavior
EVA 3000 AA: VID= HP; PID = HSV101
EVA 5000 AA; VID= COMPAQ; PID = HSV 111
=========================================
to the system, and DDL layer in vxconfigd has no
information about the above VID/PID pair to
claim the device.
Resolution:
Added support to the above array in our DDL layer.
(SR:8606445313 CR:JAGag02783)
Veritas Incident Number:519628
Problem Description:
When slave node tries to communicate with master node,
it register its node-id on master for further
communication. The problem is that the node-id is
not getting registered properly, which resulted in
core dump.
Resolution:
Register the node-id of all the slave nodes in master
when CVM is coming up. Also, check for possible empty
contents while receiving the message from slave.
(SR:8606446350 CR:JAGag03724)
Veritas Incident No:565987
Problem Description:
Such disabling/enabling of DMP paths in a CVM
environment was not supported previously.
Resolution:
Add support for disabling/enabling of DMP paths in
a CVM environment.
(SR:8606446351 CR:JAGag03725)
Veritas Incident No:569033
Problem Description:
HP EVA ALUA ASL expects the vendor ID (VID) for the
EVA disks should be COMPAQ when in fact it is HP.
Resolution:
Fix the ASL to accept HP as the VID for HSV disks.
(SR:8606442723 CR:JAGag00460)
Veritas Incident Number:618400
Problem Description:
There is a bug in the 4.1 Patch1 that got released
w.r.t EMC arrays as the Mask bit that is responsible
for claiming the arrays got included in the libvxemc.sl
binary but unfortunately the vxconfigd binary(Static)
did not include these changes. This is the reason
behind EMC Arrays not getting claimed or
not getting booted with EMC's bootable disks.
It's not a source change, just that the building of
binaries are not done correctly.
Resolution:
Correct static vxconfigd binary was built and included
in 4.1 Cp2.
(SR:8606455828 CR:JAGag12320)
Veritas Incident Number:602717
Problem Description:
The availability of vxconfigd is necessary for most
of the vxvm utilities. If vxconfigd doesn't respond
then these utilities will hang. One major reason for
unavailability of vxconfigd is due to I/O hangs. I/O
hangs can happen with the misbehavior of disk drivers
in the system. vxconfigd usually waits in the kernel
for I/O completion, and if that I/O hangs, then
vxconfigd will be stuck in the kernel forever. So, an
I/O hang can make vxconfigd and vxvm utilities unusable.
Resolution:
This problem can be solved if vxconfigd initiated I/Os
timeout automatically. Fortunately most of the I/O waits
for vxconfigd happens in vxio module. So we can have some
control on these I/O waits. In case vxconfigd comes out,
without waiting for the I/O completion, the corresponding
operation will fail or abort, and it should abort in a
clean way.
(SR:8606447238 CR:JAGag04585)
Veritas Incident Number:634791
Problem Description:
The vxdisksetup script just checks for the valid primary
partition on the disk. It does not fail for the disk not
having valid primary partition even if the disk is under
control of LVM.
Resolution:
The format of the disk is checked before taking the
disk under vxvm control.
(SR:8606455839 CR:JAGag12331)
Veritas Incident Number:612603
Problem Description:
The user specified options are not copied properly in
the structure which contains attributes.
Resolution:
Copied the user supplied attributes into the attribute
structure.
(SR:8606449570 CR:JAGag06724)
Veritas Incident Number:633161
Problem Description:
If an overlapping reconfiguration, say a node leave, is
delivered when a join operation is in progress, the join
is expected to be aborted, node leave processing should be
completed and then join processing resumes. If such an
overlapping reconfig is delivered when the join is in vold
level, then vxconfigd does not clean up correctly and does
not abort the existing reconfig. Thus, vol_vold_in_join
is not reset. This leads to a subsequent reconfig waiting
forever in the kernel for this variable to be reset and
vxconfigd part of the reconfig finally times out.
Resolution:
If an overlapping reconfig is delivered in kernel, and
the current reconfig is in vold level, a special signal
is sent to vxconfigd, which in turn cleans up vold level
context associated with the existing reconfig and also
gets into kernel and aborts the current reconfig. This way
vol_vold_in_join is reset and subsequent reconfigs are
allowed to proceed.
PHCO_33509:
(SR: 8606419256 CR:JAGaf79086)
Veritas Incident Number:361769
Problem Description:
Device nodes in /dev/rdsk may not exist in ramdisk
FS, if the device that was selected was not a dmpnode
(i.e. not the device path with the highest controller
number).
Resolution:
Add routine to search the ignite_ux supplied
hw.info file for a match on the dmpnode name
of the specified device. Use the included HW path
to run an insf command to generate the required
device nodes in the ramdisk FS.
(SR:8606405497 CR:JAGaf65418)
Veritas Incident Number:370210
Problem Description:
1). If we encounter other disk groups with the same
name as the root disk group, we will deport the other
disk group. But in this case, it was not the root
disk group that contained the volume that the /var
file system was to be mounted on (e.g.rootdg1/varvol).
2). Found that we were always looking for a "rootdisk"
specification when creating rootdg.
Resolution:
1). Extend the policy of deporting disk groups that were
found with the reserved volume name to include non-root
disk groups.
2). Allow a rootdg to be created without a rootdisk
specification. In this case, use the first "disk"
specification to init the rootdg disk group with.
(SR:8606419263 CR: JAGaf79093)
Veritas Incident Number:374273
Problem Description:
After a switch port was disabled, the DMP path to it
(called as cur pri path) failed which resulted in DMP
failover to other port of the array. When such failover
happens the arrays sets a unit attention condition for
all initiators to notify them of a failover. If there is a
unit attention for any initiator set by an array, any
SCSI command other than an inquiry would fail with the check
condition status of unit attention. In our case due to a
unit attention, the RTPG command issued by ASL
failed which resulted in a device being UNCLAIMED
even though it was accessible. The device gets claimed
after a couple or more discovery commands because the unit
attention condition gets cleared after the data is
transferred to an initiator during failed SCSI command.
Resolution :
The fix was to retry the SCSI command if during a discovery
it was found failing with a unit attention status.
(SR: 8606419265 CR: JAGaf79095)
Veritas Incident Number:374371
Problem Description:
vxislvm is used to find out if the disk, which is being
initialized by vxdisksetup is already under LVM control. If
it is, we do not touch that. When Enclosure based naming
scheme is enabled, vxislvm expects an entry like
TagmaStore0_2 to be present in /dev/rdsk. Since this is a
VxVM generated name, it will not exist in /dev/rdsk.
It will be present in /dev/vx/rdmp only and
hence stat call fails on /dev/rdsk/ name.
Resolution :
Modify vxislvm to use dmpnode(entry in /dev/vx/rdmp)rather
than /dev/rdsk entries.
(SR: 8606419267 CR: JAGaf79097)
Veritas Incident Number:380327
Problem Description:
Due to a timing issue, the joinp structure of the cvmkernel
was not getting updated with the right state and as a
result, overlapping reconfiguration got hung.
Resolution:
Cleanly update the flag when aborting the current
reconfiguration to move on to the next one.
(SR: 8606408073 CR: JAGaf67976)
Veritas Incident Number:390570
Problem Description:
If a volume is started and we attempt to start it again,
a message saying that the "volume is already started"
is emitted. This message is an informational message and
should not be tagged as an error. Also, if different
disk groups have volumes with the same name it will be
difficult to distinguish for which
volume, the message has been emitted.
Resolution:
The message is now tagged as an INFO instead of an error.
Also, the name of the diskgroup, to which
the volume belongs, is printed.
(SR: 8606413328 CR: JAGaf73189)
Veritas Incident Number: 412680
Problem Description:
During vxconfigd level join when the dg is imported
the reonline of all disks is done which causes a
delay in dg import
Resolution:
reonline of disks should only be done when needed.
Thus a new check is in place in sliced_dg_join()
which does online/offline only if it is required.
(SR: 8606419276 CR: JAGaf79106)
Veritas Incident Number: 413980
Problem Description:
Let's say bootdg points to rootdg. There was an
ambiguity check while doing resize, which would find
the volume to be a part of rootdg and thus would
prevent vxresize on bootdg.
Resolution:
The fix is to allow vxresize on a bootdg if bootdg is
pointing to another dg.
(SR: 8606406994 CR: JAGaf66900)
Veritas Incident Number:414287
Problem Description:
1. Bug in advresp() due to which the vold used to
wait for 5 or 10 minutes doing nothing.
2. Extra da_reonline_all_disks in mode.c
3. Extra da_reonline during the join of the nodes.
Resolution:
Make sure that the check is moved from advresp() to
advresp_master() for peer clients. Extra da_reonlines
were removed to decrease the join times.
(SR: 8606419264 CR: JAGaf79094)
Veritas Incident Number:414387
Problem Description:
For large VxVM configuration involving large number
of volumes in CVM, plex resyncs take days to complete.
Oracle takes hours to come up.During this time any
VM commands tend to hang.The problem occurs when a
full resync is initiated.
Resolution:
This was a vxrecover fix given with the intention of
having slow=<IODELAY> option incorporated into the
/etc/default/vxrecover file, so that vxrecover uses
this during reboot(persistent). As a result of
this flag, the I/O load was reduced by pausing between
resyncs, which also brought down the ilock msg
load on the kmsg subsystem.
(SR: 8606419266 CR: JAGaf79096)
Veritas Incident Number: 414391
Problem Description:
When the vxcheckasl utility is run on the emc
shared library the lun serial number field
results in blank space and
check_nvlists results in error.
Resolution:
It is resolved by passing the correct pointer
to an emc lun id. Thereby vxvm does the correct
multipathing of array disks and
DMX luns show the correct LUN number.
(SR: 8606411927 CR: JAGaf71792)
Veritas Incident Number:414690
Problem Description:
The problem was that the join operation was retried
and the error message was printed.
Resolution:
Changed message type to informational.
(SR: 8606419269 CR: JAGaf79099)
Veritas Incident Number:414807
Problem Description:
dmp_getsubpaths() is calling the library
routine VOL_PART_IS_OS_PART() on the subpath that
is locked out. Therefore IO directed at this
subpath hangs and is eventually timed out.
Resolution:
Remove the call to VOL_PART_IS_OS_PART() in
dmp_getsubpaths() as well as dmp_get_whole_disk()
since it is not needed in both places.
(SR: 8606419271 CR: JAGaf79101)
Veritas Incident Number: 414808
Problem Description:
The problem was that there was an unassociated
subdisk in the configuration i.e. name of "-".
This caused the expression used, to pick up the
volumes to be mirrored having the name of "-" which
it need not.
Resolution:
Ignore volume names which are entirely "-".
(SR: 8606419272 CR: JAGaf79102)
Veritas Incident Number:416282
Problem Description:
The new master gets 2 VOLOP_CONNECT from the
joiner and hence gets confused. It thinks
that the slave is out of sync with the master
and hence stop the processing of the join.
Resolution:
Make sure that VOLOP_CONNECT on the slave
is not sent from the free_stale_client() context.
(SR: 8606413083 CR: JAGaf72945)
Veritas Incident Number:420819
Problem Description:
As a part of diskgroup import, the disks are
scanned and added to the diskgroup. During this
operation, the private region contents stored
incore are read to build the configuration
and log copies. This was failing leading to the
diskgroup import failure.
Resolution:
The disk private region contents are re-read,
if the above problem is encountered.
(SR:8606405567 CR: JAGaf65488)
Veritas Incident Number:423304
Problem Description:
A disk that was previously initialized and
used as cdsdisk can no longer be brought online.
/etc/vx/diag.d/vxprivutil scan sees valid label
but vxdisk list shows that it is a hpdisk.
Resolution:
vxdiskadm command is not re-initializing the
disk correctly. This may cause a problem
during the disk re-initialization
which could lead to another problem later.
(SR: 8606419808 CR: JAGaf79638)
Veritas Incident Number:415074
Problem Description:
Commands to resize a filesystem need to be run on the
master node. Need to use cmexec in the SG environment.
Resolution:
If we are running in an HP/SG environment, use cmexec.
(SR: 8606408077 CR: JAGaf67980)
Veritas Incident Number:407517
Problem Description:
The listen queue for vxconfigd was set to 5.
Resolution:
Increased listen queue length to 30.
(SR: 8606419813 CR: JAGaf79643)
(Veritas Incident Number:414109)
Problem Description:
Internal variable 'vol_join_allowed' was not reset
to zero before GAB/GLM initialization.
Resolution:
Reset 'vol_join_allowed' to 0 before any GAB/GLM
initialization.
Handle EFAULT return value from
VOLCVM_INIT/VOLCVM_INIT_CONFIG ioctls, which
indicates GAB/GLM init failures.
Add a new global vol_retry_join to distinguish
between GAB/GLM init failures and GLM_API_TRYLOCK
failure (which indicates another node is joining).
(SR: 8606419815 CR: JAGaf79645)
Veritas Incident Number:424888
Problem Description:
vxvol dumps core while trying to start the volumes.
vxvol gets the dg configuration objects while
starting the volumes. If the dg config. retrieval
fails, then a NULL is returned. This wasn't handled
properly and lead to a coredump.
Resolution:
Handle the return conditions properly.
(SR: 8606419816 CR: JAGaf79646)
Veritas Incident Number:413978
Problem Description:
The code is looping and accessing the same free bit
that was returned from the function while
updating the bitmap of the table of contents
in a private region.
Resolution:
The looping was due to incorrect handling of
the variable while scanning the bitmap in
the reverse direction. This was addressed by
decrementing the variable representing the
free-bit to start the next phase of free-bitmap
scan if that bit was set in the pending
allocation bitmap.
(SR: 8606419818 CR: JAGaf79648)
Veritas Incident Number:414744
Problem Description:
If a diskgroup is imported with -o selectcp option,
the DG goes into SSB state.
Resolution:
The problem was because we weren't resetting the
dm_expected ssbid on the disk, for -o
selectcp imports. Importing a DG by selecting a
config-copy should reset both the da_actual
ssbid on the disk and also the dm_expected ssbid.
We were clearing the da expected ssbid
but weren't doing it for dm ssbid.
(SR: 8606419820 CR: JAGaf79650)
Veritas Incident Number:415069
Problem Description:
Having 1 old style NPFMR2 snapshot + 1 instant(new
style PFMR3) snapshot of a source volume
and firing an I/O to the old style snapshot
would panic during a dco_update of the old snapshot.
Resolution:
The solution should be to disallow a snapshot prepare
of new-style FMR-3 snapshots on a volume
if it already has old format NPFMR2 SNAPSHOTS.
(SR: 8606419821 CR: JAGaf79651)
Veritas Incident Number:419448
Problem Description:
The filesystem is disabled after receiving IO errors as
PGR keys are not being set for all the
paths. PGR keys have to be set for
all the active/enabled paths of the dmpnode
in order for I/Os to succeed through them.
Resolution:
PGR keys weren't getting removed during unregistration
or deport leading to stale PGR Keys
during import which can fail PGR registrations.
(SR: 8606419822 CR: JAGaf79652)
Veritas Incident Number:420208
Problem Description:
Snapshots cannot be taken for a volume in a shared
DG as vxvol dumps core. The problem was an invalid
free of a variable in the function that freezes
the cluster before taking the snapshots.
Resolution:
Check for an invalid free of a variable.
(SR:8606423407 CR:JAGaf82930)
Veritas Incident Number:498461
Problem Description:
When the SPC-2 flag is off, the new ASL works
with or without PowerPath. It seems the new ASL
didn't interpret LUN_SER_NO in Pagecode 0x83
with regard to re-creating emcpower
links during boot with PowerPath release 4.5.
It was found that the vxdisk list duplicates
appear after running the first
vxvm script (vxvm-sysboot).
Resolution:
Solution is to wait until the root filesystem is
writable, then we can recreate the emcpower
links before running vxvm-sysboot.
Duplicates do not appear in this case.
(SR:8606423408 CR: JAGaf82931)
Veritas Incident Number:499360
Problem Description:
In one of the DDL routine we make a call to vendor info
function routine to get the function pointers for
appropriate routines such as VENDOR_INFO_ROUTINE,
VENDOR_CLAIM_ROUTINE, VENDOR_SELECT_DEVICE_ROUTINE and
VENDOR_GET_DYNAMIC_ATTR_ROUTINE. We don't check the
return values for these routines which leads to
invoking a wrong function pointer.
Resolution:
The function pointers in the DDL routine is
initialised to NULL variable so that the vxconfigd
code later will not attempt to invoke bad function
pointer.
(SR:8606423409 CR: JAGaf82932)
Veritas Incident Number:496511
Problem Description:
It was found that the special name "dumpvol"
was not being considered as an
exception to need to have a filesystem.
Resolution:
The fix is to check the volume name and if it
is equal to dumpvol, then we do
not require it to have a filesystem in place.
(SR:8606423414 CR: JAGaf82937)
Veritas Incident Number:430703
Problem Description:
While shutting down an HP/SG cluster the error
message:
VxVM ERROR V-5-2-0 VOLCVM_GET_NIDMAP failed
appears.Message is harmless and it might
cause confusion to the customer.
Resolution:
Remove the error message from the CVM code.
(SR:8606423411 CR: JAGaf82934)
Veritas Incident Number:427557
Problem Description:
In CVM environment when there are many mirrored
volumes on the disk group configuration, volume
resynchronisation forks vxvol for every plex in
the mirrored volume.
Resolution:
A default "plex fork" tunable option is implemented in the
CVM code.
(SR:8606423410 CR: JAGaf82933)
Veritas Incident Number:424893
Problem Description:
In CVM environment, the nodeid map namely
voldnid_map is not getting updated at the vxconfigd level
whenever vxclust utility is reinitialised.
Resolution:
Solution is to copy the kernel nodeid map at the
vxconfigd level during the cluster operation.
(SR: 8606423412 CR: JAGaf82935 )
Veritas Incident Number: 429306
Problem Description:
Addition of new EVA diskarrays namely EVA4k6k, EVA3000,
EVA5000 resulted in the VM code change to support
these ASLs.
Resolution:
These ASL's are included in DDL code with the
corresponding VID and PID so that the disks get claimed
in VxVM 4.1 HPUX.
(SR: 8606419810 CR: JAGaf79640)
Veritas Incident Number: 361716
Problem Description:
The problem is with the binaries vxse_stripes1 etc.
at run time they are looking for some shared libraries
on prague machine under
/net/prague/u2/sap/nightly/obdev/hp/lib which is
not accessible. This is because of the wrong library
path being picked up while compiling these binaries.
Resolution:
Pick up the correct library path for compiling the
binaries.
(SR: 8606419803 CR: JAGaf79633 )
Cumulative VVR fixes
1)Veritas Incident Number:426233
Problem Description:
If the hostname and domain name together exceed 31
characters, then the hostname lookup fails.
Resolution:
The error message has been enhanced to reflect
that the host name is too big.
2)Veritas Incident Number:415076
Problem Description:
In a multiple-secondary configuration, vradmin
repstatus command can show blank value against
the "Logging to:" field for one secondary if
primary RLINKs are detached.
Resolution:
The code is fixed to set the default value of the
"Logging to:" field to 20 (corresponding to SRL),
rather than -1. In case the RVG is in
pass-through mode, the "Logging to:"
field will be set to "N/A".
3)Veritas Incident Number:415078
Problem Description:
The hang might occur if there are more than 256
volumes in an RVG. The vradmind daemon will eat up
lots of system memory and stop responding.
Resolution:
The solution is to free the allocated memory after
it has been used.
Enhancement:
Yes
PHCO_36111:
With PHCO_36111 one can see show DM (Disk Media)
names even for detached disks in vxdisk(1M).
PHCO_34811:
With PHCO_34811 one can turn on vxconfigd daemon debugging
on the fly, i.e without having to restart vxconfigd.
The syntax for switching on or |
