ほほほのほ

文書の過去の版を表示しています。

トラブル等関連

Last Update: 2015/04/17

DiskFull

XenServerは、どうもlogrotate時にlogファイルを削除しない模様。また、XenServerを普通にInstallすると、Control DomainのDiskは4Gになる。その結果、Control DomainのDiskが埋まってしまう事がある。そういう場合には、loginした上で、

# cd /var/log
# rm -f *.[0-9][0-9].gz
# rm -f *.[0-9][0-9][0-9].gz

すれば良い。ただし、間違ったファイルを消さないよう、事前に確認をちゃんとする事。

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から以下のコマンドを入力する
```
xe pool-emergency-transition-to-master
```
すると、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できないとき

VMがどうしてもrebootできないことがある。

そういう時にはまず
1. xe vm-reboot UUID=${vm_uuid}
だめなら、さらに強制的に再起動する
1. xe vm-reboot UUID=${vm_uuid} force=true
これでも駄目だ。もういい！
1. VM の UUID を確認
2. list_domains コマンドで VM の domain ID (!=UUID) を確認
  - list_domains | grep ${vm_uuid}
3. xl destroy ${ID}
  - しかし、これでは、PowerStateがRunningで、状態がおかしくて何もできん!!!
4. 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ではないので、別途格闘する必要がある。出会っていないので対策は不明
これが見つかった場合には、以下を実施
1. まず、当該のSRのFull Dump(もしくはDuplicate)を実施し、最悪の場合に元に戻せるようにする
2. lvremove /dev/VG_XenStorage-xxxx/VHD-[存在しないはずのVDIのUUID]を実行する
3. xe sr-scanを再度実行する

これでなおることがある。

参考: discypus Linux/LVM/LVMの削除

目次