2015/04/17DiskFullXenServerは、どうもlogrotate時にlogファイルを削除しない模様。DomainのDiskは4Gになる。DomainのDiskが埋まってしまう事がある。*.[0-9][0-9][0-9].gzすれば良い。間違ったファイルを消さないよう、事前に確認をちゃんとする事。この症状がなぜ出るのかは不明だが、以下の条件の場合には復旧できる可能性がある。選択するこのとき、管理者権限の認証(平たくいえばrootパスワードを聞かれる)がある。Addressを設定する再起動これで戻らない場合は、更に格闘が必要だが、そこまで至っていないので、どうなるのかは不明。Taskの一覧を見られる。VMをどうしてもrebootできないときVMがどうしてもrebootできないことがある。force=trueこれでも駄目だ。motoさん)当該VMに紐付いたディスクイメージ(Xen的にはvdi)が見つからない状態である。vm-name-label=examleVMコマンドを実行してvbdを特定する。通常、各VMにはDVD-ROMドライブとHDDドライブのふたつのvbdがattachされているので上のコマンドの実行結果にもふたつのvbdが表示される。このうちHDDのvbdにはvdiのuuidが付いており、上のコマンドの出力結果ではvdi-uuid欄に表示されているのでメモする。これをVDIUUIDとする。uuid=VDIUUIDコマンドを実行して当該VDIを一旦XenServerのデータベースから消す。uuid=VDIUUIDによって状況を表示するとデータベース上に存在していたvdiが消されたことがわかる。uuid=SRUUIDコマンドを実行する。XenCenterの当該SRのStorageタブに無名のvdiが出現するので、Property設定から名称などを指定する。XenCenterの当該VMのStorageタブでこのvdiを指定して当該VMがbootするディスクイメージとする。これでbootすれば復活できる場合がある。bootするまでに多少の時間が必要なことがある。起動しない場合に更にxe-toolstack-restartを実行する必要がある場合もある。SRが破損した場合の対応この記事は、以下の状況に陥った場合の解決策(解決できるかもしれない策)である。Diskシステムが発狂し、SRに記録されているMetaDataが破損していたり、SRのDBが破損したりする等が考えられる。available”が出力される。単順な対策に関しては、別に記載したが、その方法では復旧できない場合に、神に祈るような想いで実施する手順である。sr-scanでVDIが無いと怒られたである。sr-scan実行時に出力された異常なUUIDを探す見つからないはずこの状況であるなら、この記事に記載する方法によって復旧する可能性がある。availableとなったという状況であると考えられる。pool側では、そもそもSRが異常なので、そのSRにVDIが記録されている全てのVMが正しく動作しないはずである。volumeが見つかるはずである。見つからなかった場合、この記事のscopeではないので、別途格闘する必要がある。sr-scanを再度実行するこれでなおることがある。以前のリビジョンバックリンク文書の先頭へ。