差分

このページの2つのバージョン間の差分を表示します。

@@ 行 1: / 行 1: @@
+===== トラブル等関連 =====
+**//__ Last Update: 2024/07/18 __//**
+==== DiskFull ====
+XenServerは、どうもlogrotate時にlogファイルを削除しない模様。また、XenServerを普通にInstallすると、Control DomainのDiskは4Gになる。
+その結果、Control DomainのDiskが埋まってしまう事がある。そういう場合には、loginした上で、
+<code>
+# cd /var/log
+# rm -f *.[0-9][0-9].gz
+# rm -f *.[0-9][0-9][0-9].gz
+</code>
+すれば良い。ただし、間違ったファイルを消さないよう、事前に確認をちゃんとする事。
+==== No interface present ====
+XenServer 6.2SP1にHotFixを適用後再起動したら、PoolのSlave側で ''No interface present'' となった。
+この症状がなぜ出るのかは不明だが、以下の条件の場合には復旧できる可能性がある。
+  * XenServerのコンソールから ''Network and Management console'' をみると、No interface presentが表示される
+  * XenServerのコンソールから ''Local Command Shell'' を選択する
+    * このとき、管理者権限の認証(平たくいえばrootパスワードを聞かれる)がある。ここで、正しくPasswordが入力できれば、最小限のデータは壊れていない可能性が高い
+  * ifconfig -a を実行し、Ethernet portが認識されているかを確認する
+    * この時、正しくNICを認識していて、I/Fが見えている事を確認する
+  * xe pif-listを実行する
+    * 今回は、いつまでたっても(30秒くらい)返事が返ってこなかった
+この状況の場合、以下の手段で復旧する「ことがある」
+  - Local Command Shellから以下のコマンドを入力する<code>
+xe pool-emergency-transition-to-master
+</code>
+  - すると、pool構成員から(一時的に)masterに戻る
+  - Local Command Shellを抜け、Network and Management consoleを選択
+  - Management I/FにIP Addressを設定する
+  - 再起動
+これで戻らない場合は、更に格闘が必要だが、そこまで至っていないので、どうなるのかは不明。
+なお、XenServerでHAを構成している場合には、''xe host-emergency-ha-disable''の前に、''xe host-emergency-ha-disable''を入力して、HAをOffにすること
+==== Taskが進行せずPendingになった時の対処 ====
+* [[http://www.ballblog.net/2010/06/vm-stuck-in-pending-state-on-xenserver.html]]
+  - xe task-list でTaskの一覧を見られる。特にPendingに注意
+  - xe task-cancel force=true uuid=<UUID> でTaskをキャンセルできる
+  - この後、xe vm-reboot や xe vm-shutdownで更にPending Taskが出来る、もしくは、そもそもPending Taskが減らないようならば xe-toolstack-restart を実施
+  - これでXenCenterからVMの状態などを見て、必要なら更に xe task-cancel uuid=<UUID> する。
+==== VMをどうしてもrebootできないとき ====
+Last Update: 20240718 : refresh sequence and replace commands.
+VMがどうしてもrebootできないことがある。
+  * そういう時にはまず
+    - xe vm-reboot UUID=${vm_uuid}
+  * だめなら、さらに強制的に再起動する
+    - xe vm-reboot UUID=${vm_uuid} force=true
+  * これでも駄目だ。もういい！
+    - VM の UUID を確認
+    - list_domains コマンドで VM の domain ID (!=UUID) を確認
+      * list_domains | grep ${vm_uuid}
+    - xl destroy ${ID}
+      * しかし、これでは、PowerStateがRunningで、状態がおかしくて何もできん!!!
+    - xe vm-reset-powerstate --force uuid=${vm_uuid} もしくは xe vm-reset-powerstate --force vm=${vm_name}
+かなり危険
+//See [[https://xcp-ng.org/forum/topic/3771/vm-migration-failed-now-can-t-access-vm/7]]//
+==== VDI is not available ====
+The VDI is not available. というエラーメッセージが XenCenter の Logs タブに出現した時(By motoさん)
+  * 当該VMに紐付いたディスクイメージ(Xen的にはvdi)が見つからない状態である。
+  * 当該VMの名前が"exampleVm"であれば、__xe vbd-list vm-name-label=examleVM__コマンドを実行してvbdを特定する。
+    * 通常、各VMにはDVD-ROMドライブとHDDドライブのふたつのvbdがattachされているので上のコマンドの実行結果にもふたつのvbdが表示される。
+    * このうちHDDのvbdにはvdiのuuidが付いており、上のコマンドの出力結果ではvdi-uuid欄に表示されているのでメモする。これをVDIUUIDとする。
+    * xe vdi-list uuid=VDIUUIDを実行して、sr-uuidを確保する
+    * xe vdi-list name-label=Diskの名前で検索することも可能
+  * XenCenterで当該HDDをdetatchする
+  * __xe vdi-forget uuid=VDIUUID__コマンドを実行して当該VDIを一旦XenServerのデータベースから消す。
+    * 消す前後に xe vdi-list uuid=VDIUUIDによって状況を表示するとデータベース上に存在していたvdiが消されたことがわかる。
+  * SRのデータベースに再登録させるために__xe sr-scan uuid=SRUUID__コマンドを実行する。
+  * XenCenterの当該SRのStorageタブに無名のvdiが出現するので、Property設定から名称などを指定する。
+  * XenCenterの当該VMのStorageタブでこのvdiを指定して当該VMがbootするディスクイメージとする。
+  * これでbootすれば復活できる場合がある。
+    * bootするまでに多少の時間が必要なことがある。また、起動しない場合に更にxe-toolstack-restartを実行する必要がある場合もある。
+==== XenServerに接続しているiSCSI SRが破損した場合の対応 ====
+この記事は、以下の状況に陥った場合の解決策(解決できるかもしれない策)である。
+  - XenServerにiSCSIをSRとして接続している場合に於いて
+  - 何らかの理由で、XenServer側からiSCSI SRに記録されているVDIが見えなくなった
+    * iSCSI Diskシステムが発狂し、SRに記録されているMetaDataが破損していたり、SRのDBが破損したりする等が考えられる。
+  - 見えなくなった理由が、破損がVDI単位ではなく、SR単位であると考えられる
+このような障害に見舞われた場合、XenCenter等で"VDI is not available"が出力される。
+単順な対策に関しては、別に記載したが、その方法では復旧できない場合に、神に祈るような想いで実施する手順である。
+この記事の元になった障害事象は、
+  * XenCenter側で "The VDI is not available"が表示された
+  * Knowledge Centerに記載されている方法では復旧できなかった
+  * xe sr-scanでVDIが無いと怒られた
+である。
+　- まず確認すべき事項
+    - XenServerのPool Masterにloginする
+    - xe sr-scanを実行
+      * あるUUIDがおかしいといわれる
+    - ls /dev/mapperを実施し、iSCSI SRのUUIDと比較
+      * UUIDが同一の物を確認
+    - lvscanを実行
+    - xe sr-scan実行時に出力された異常なUUIDを探す
+      * 見つからないはず
+この状況であるなら、この記事に記載する方法によって復旧する可能性がある。
+これは、この状況に陥っている場合、
+  * LVM イメージは存在しないにもかかわらず
+  * LVM側のMetaDataには「存在しないはずの」LVMの情報が残っており
+  * sr-scanでLVM情報を確認してXenServerに読み込もうとしたが
+  * イメージが存在しないので読み込めず
+  * 結果The VDI is not availableとなった
+という状況であると考えられる。
+この場合、XenServer pool側では、そもそもSRが異常なので、そのSRにVDIが記録されている全てのVMが正しく動作しないはずである。
+(なぜなら、この状況では、XenServerはPoolからSRを切り離す等するはずだからである)
+以下復旧手順
+  - lvdisplayを実行し、xe sr-scanにて表示された「存在しないはずのVDIのUUID」を探す
+  - その結果、LV Nameに''/dev/VG_XenStorage-xxxx/VHD-[存在しないはずのVDIのUUID]''というLogical volumeが見つかるはずである。
+    * もし見つからなかった場合、この記事のscopeではないので、別途格闘する必要がある。出会っていないので対策は不明
+  - これが見つかった場合には、以下を実施
+    - まず、当該のSRのFull Dump(もしくはDuplicate)を実施し、最悪の場合に元に戻せるようにする
+    - ''lvremove /dev/VG_XenStorage-xxxx/VHD-[存在しないはずのVDIのUUID]''を実行する
+    - xe sr-scanを再度実行する
+これでなおることがある。
+参考: [[http://discypus.jp/wiki/?Linux%2FLVM%2FLVM%A4%CE%BA%EF%BD%FC|discypus Linux/LVM/LVMの削除]]