「 2010年03月 」一覧

いろいろな罠


ここ最近はまった罠を書いておこうと思います。

Mondorescueのバックアップにて

除外パスの設定で、末尾を”/”で終わるとバッファオーバーフローのエラーとなる。
除外パスは、そのディレクトリ名までで終わること。

この設定を施して SCSIのマウント関連を除外してやったら
VMware上でのバックアップもうまくいっている感じ。


mondorescue -E “/home/Recycled /home/Hoge”

VMware vCenter Converter Standaloneにて

VMwareWorkstationの仮想マシンをESXiに注入するときに、
このソフトを用いて設定しようとしたときに、”The session is not authenticated”というエラーが。
対象ESXiサーバーにログインし、仮想マシン一覧も取得できているのになぜ?という状態で起こる。

調べてみるとタスクが残る(残っている)ことがあるようで、それを終了すればこのエラーは復帰するらしい。
Windows7環境ではよくわからなかったのと、別件でPCを再起動する予定があったので、
PCを再起動させて再度チャレンジしたところ、この問題は解決した。


ESXi上の仮想マシンのバックアップを考える その2


前回の結論にどうも納得が出来ない状況だったので、
通常のバックアップをどうするかを検討してみました。

通常バックアップに求められる要件

  • 簡単にバックアップ処理/リストア処理ができること
  • バックアップ処理が割と高速に出来ること
  • システム全体を丸ごとバックアップ出来ること。

ESXiで管理されているスナップショットについて

なるべくなら残しておきたいが、通常運用時のバックアップファイルがあれば
通常運用が継続できる。スナップショットが失われても被害は少ない(はず)。
スナップショットを残して、どうにかしたい場合はESXiの管理下のファイルを丸ごと取っておく、とか。

バックアップ検討

ESXi上でのスナップショットや設定をあきらめることで、バックアップの新しい方法が見えてきた。
といっても新しい代物ではなく、Linuxマシンをシステムごとバックアップ取るという通常のものに戻っただけ。

そこでいろいろとバックアップ関連を調べてみたところ、
dumpコマンドによるものやほかのツールを使うものが該当した。
ここでは、mondorescueというツールを使って試してみることにした。

mondorescueの利点

  • isoファイルとしてバックアップデータを書き出せる。リストア時はこのイメージから起動して元に戻せる
  • コマンド1発でバックアップ処理が可能。

mondorescueの欠点

  • LVMを扱っている状態だと、リストア時に問題発生可能性が高い。
  • 環境によってはリストア出来ない・・・。expertモードで何とか出来るらしいが。

那由多屋 開発日誌さんのところでexpertモードによるリストア処理が説明されていて参考になりそうでした。

これらのことよりmondorescueを試してみることにした。

mondorescue

とりあえずインストール作業をして使用可能状態にしておく。

バックアップ処理

次のコマンドを入力して、4.2GBのDVDディスク向けとした状態でバックアップ処理を開始。

mondoarchive -O -i -L -d /backup/ -E /backup -s 4200m

この場合だと、/backup/mondorescue-1.iso というファイルができあがっていた。
これを元に続いてリストア処理を試してみる.

リストア処理

いくつか罠がある。
リストアの処理を確認するために、VMwareWorkstation6.5上の仮想マシンを利用した。

mondorescueでは、バックアップの環境とリストアの環境は全く同じハード状態を想定しているのか、
ハードディスクのサイズが違うとリストアに失敗した。
少なくとも、元サイズと同じディスクを接続しておかなくてはならない。

また、IDE/SCSI接続どちらで仮想PCを使っていたか、という点についても同じにしなくてはならなさそう。
(Expertモードによる復旧ならばこれもIDE->SCSIへの変換も可能なのかもしれないが)

この注意点に気をつければ、LVMパーティション使っていても正常にリストア処理が完了した。
ただし、ESXi上の仮想マシンをこれでバックアップし、VMwareWorkstation上で展開したのだから
きわめて近い状態へ書き戻しを行っているという点に注意する必要がある。

リストアの処理は、isoファイルをマウントしてこのディスクから起動するようにする。
そして、boot:で聞かれた時には、nuke を入力して放置。
これだけで自動でリストア処理が完了する。うまくいけばかなり手軽に戻せる。

boot: nuke

しかし物理マシン丸ごと交換の場合はこの方法は使えないだろう。
また、仮想環境のホストを交換して、このバックアップからリストア処理を用いてデータ移行するという方法も
ちょっと厳しいのではないかと考えられる。

mondorescueのインストールについて

rpmforgeリポジトリを有効化してある状態ならば、yumでインストールが可能のようだ。
これで入るのが、mondo-2.2.4-1.el5.rf だった。最新ではない点には注意。

最新版をインストールする

ftp://ftp.mondorescue.org/rhel/5/mondo-2.2.9.2-1.rhel5.x86_64.rpm
からダウンロード可能だったので、これに更新してみる。

CentOS5用に出ていたのでこちらを使用してみます。
ftp://ftp.mondorescue.org/centos/5



まだまだ依存関係があるようだ。
# wget ftp://ftp.mondorescue.org/rhel/5/mindi-busybox-1.7.3-1.rhel5.x86_64.rpm

これで旧バージョンでは作業中に停止してしまいバックアップがうまく出来ないケースがあったが、
この更新によりバックアップ処理が最後までいくようになった。

ESXi上の仮想マシンのバックアップを考える


ESXiの制約

  • 動作中のVMのディスクにアクセス出来ない。
    • 故にスナップショットを使用して直前までのデータをバックアップとする。
  • scpくらいしか転送コマンドが使えない
    • ESXiホストにrsyncは入っていなかったし、ほかの圧縮・アーカイブ系のツールも含まれていない。
  • スナップショットの挙動が怪しい。操作が特殊なのかも
    • 試してみて解決です。詳細は後述します。

家環境での制約

  • スナップショットは複数使用している。
    • 故に、多くの環境でやられている snapshot.removeAll コマンドが使用できない。
  • バックアップをとる側はWindows上のVMwareマシン(CentOS)
  • 故に、マシン環境でルーティングを挟むため、通信帯域は少ない方がいい

バックアップ方針

  1. ESXiでvim-cmdを利用してスナップショットを作成
  2. scpにより別のPCへバックアップデータを書き込む
  3. 作ったスナップショットを削除する

スナップショットをとるものの、現在使用中のものはアクセス不能のためコピーできない。

scpの暗号化に -c オプションで指定をつける。
ローカル環境なのでそこまで強固な暗号化は不要ということで。

scp -c aes128-ctr

arcfourというものの方が軽いらしいのだが、手元の環境では使用できなかった。

メモ

VMのIDを取得する方法

VMの情報を取得
vim-cmd /vmsvc/getallvms
これで、vimIdを取得できる。

最新のスナップショットのみ削除する方法

vim-cmd /vmsvc/snapshot.remove 0 <削除スナップショット>

ここで、”削除スナップショット”の番号については下記のコマンドで求める。
vim-cmd vmsvc/snapshot.get | grep CHILD | wc -l

結果

コピーされた結果可変ディスク(シンディスク)であっても、全体のデータサイズで取れてしまう。
よって、使用領域数GBにも関わらずディスクサイズが 128Gとかになっている場合は 128GBの空き領域が必要。
だけどコピーそのものは出来た。

問題点

仮想ディスク全サイズ分占有問題は1つのVMだけで数時間におよぶ転送時間がかかることにつながるので、
ちょっと実用は難しいのかも。もっともこれが許容できるならばこれでバックアップとしても良いのかもしれない。

またスナップショットを作成してコピーしているが、
最新の動作状況に関する情報がコピーできないため、設定ファイル群とディスクとの不整合が起こっている可能性がありそう。

この方式を実用に向けて再チェックするときにこのあたりを仮にリストア処理させてみることで確認してみようと思う。


Windowsの共有フォルダのマウント


CentOS5.4からWindows側で共有されているフォルダをマウントする方法。
以前smbfsがなくて、cifsでマウントすると書いたものの、
今現在また苦労したのでここにメモとして書いておこうと思います。

必要なもの

必要なものとして samba,samba-clientが必要。これらを忘れたためにマウント出来なかった。

yum install samba samba-client

インストールした後には、mount.cifsがパス上に存在すると思うので、それで確認してみるといいかも。

その後、共有フォルダをマウントするには下記のようにコマンドを打ち込む。

mount -t cifs -o username=hoge,file_mode=0755,dir_mode=0755 //192.168.1.1/ShareFolder /mnt/winshare

エラーメッセージ

インストールを忘れていると、ログインに失敗した意のエラーメッセージが出てくる。
cifsが使えないという意味のエラーメッセージではないため、上記の解決に至るまでちょっと時間がかかった。
LOGIN FAILUREとか出てきたら、mount.cifsがその環境で存在するかを確認してみるといいかもしれない。

ほかにも、Windows側のファイアウォールを無効化してテストしてみるのも有効だと思われる。
(デフォルトだとpingも通してくれないし、設定中はいろいろとFWが邪魔になります)


Hyper-VからVMwareESXiへ その2


前回はLinux編だけで終わってしまったので、今回はWindows編で。
こちらはVMware Converterの3,4の両方を試してみたけど、どうしてもうまく動かなかった。
Windows環境ではこのツールが使えるだろうと思っていただけに、予想外だった。

環境

  • WindowsServer2003R2 Standard (x64)
    • ドメインサーバーとして動いているもの

失敗例

先に失敗例を挙げておきます。

Windows標準のバックアップ機能を使ってみる

とりあえずシステム状態を保存したいので、この設定で。
相手先にWindowsServer2003R2をインストールして、その後バックアップでシステム状態を復帰するという方針。

実行した結果は、起動途中でブルースクリーンが出て再起動を延々繰り返す。

Hyper-Vの仮想マシンをVMware ESXi4へ移行する 【WindowsServer編】

まず、Hyper-V管理マネージャで既存のサーバーをエクスポートしておきます。
そしてエクスポートしてきたデータのうち、vhdファイルを変換します。

この変換には、NHCを使用します。
手元で試してうまくいったバージョンは、
NHC Ver.0 alpha35A 2010/02/2 というものです。

このツールで、VMDK(7)に変換します。
HDDのタイプですが、ここでも前回同様IDEを選択します*1

このできあがった状態を確認、およびESXiへ注入を確実にするために、
VMware Workstationを利用します。試したのでは VMware Workstation 6.5を使用しました。

新規にWindowsServerターゲットとしてマシンを構築します。
デフォルトで進めていって、電源オンしない状態で一度マシン作成を完了させます。
その後、仮想マシンの設定を開き、すでに設定されている仮想HDDを削除します。
代わりに今回コンバートして作ったVMDKファイルを設定します。

ここで、HDDの接続がIDEとして処理されているかを確認して下さい。

その後電源ONしてWindowsServerが起動するかを確認します。
大幅なハードウェア変更と検知され、システムが動き始めれば成功といえると思います。

手元の環境ではサウンドデバイスを追加されていたため、
サーバーには余計であると判断し削除しました。

続いて、Hyper-V統合サービスのアンインストールと、VMwareToolsをインストール。
このあたりはVMwareを使っていて定番の作業のため、割愛します。

VMware Workstationで動作を確認できたので、
VMware vCenter Converter Standalone 4を用いて、ESXiマシンへ転送します。
先ほどまで使用していた仮想マシンの設定ファイルをソースとして、
指示に従っていくだけでESXi上にマシンを移動することが出来ました。

その後、vSphere Clientで電源ONして動作を確認して完了です。

ここまでの手順を導き出すのに、いろいろと試行錯誤しましたが
やっとうまくいったので良かったと思います。

しかしもっと簡単な手順があればいいなーと思っていますが、
手元ではもう移動するものがないのでこれにて一件落着です。

*1 : ここで間違ってSCSIのLSI Logic選んでおくとブルースクリーンに悩まされます


Nucleusのコメントスパム対策


最近やけにルーターのアクセスランプが点滅してるなと思ったら、
Nucleusブログへのコメントスパムアクセスだった。

そこで、対応すべくNP_Captcha を入れた。
ダウンロードしてきて出てきたファイルを展開し、nucleus/pluginsの中におくだけ。
あとは管理画面からプラグインのインストールで完了。

コメントを投稿するときに、画像が出てきて埋め込まれてる文字を入れてね、という感じで
スパムを拒否するようになるはずです。

・・・

うまく動いていない。
調査してみたところどうやらプラグインが動いていない。
ログアウトしてコメント投稿のチェックをしてみても
画像が出てくることもなかったので動いていないということを確信した。

このプラグインの駆動には別のモジュールを必要としていることが原因だった。
それは、phpのgdモジュール。
現システムにはgdすら入っていなかったためこれらをインストールした。

# yum install php-gd

これを実行して、動作を再度確認してみたところ、
目的の画像が出てくるようになったため正常動作していることを確認できた。

インストール自体は簡単なのに、変なところではまったなぁと思った。


Hyper-VからVMwareESXiへ その1


先日の日記にもあったように、Hyper-V上の仮想マシンやホストOSの挙動もおかしい感じで
安定動作しない状況だったため、VMwareESXi 4を次の乗り換え候補として検討中。

また、Hyper-Vの仮想マシンから VMware ESXiへの移行をチャレンジしたという情報が、
どこにも見あたらなかったため、ここに手順も含め記載しておこうと思います。
誰かの役に立ったら幸いですし、間違った方法である点を指摘してもらったらありがたいです。
いい方法がほかにもあるよ!という情報持っている人がいたら、教えていただけると嬉しいです。

問題点

VMware Converter Standalone Cllientがうまく動いてくれない。
動いてくれれば、それで簡単にESXiへ登録できたと思う。
うまく動いてくれなかったのは、ゲストOSがLinuxとWindowsServer2003R2の場合。*1

この問題のため、別の手段で移行する。

*1 : VSSのサービスが動いていないと!という話があり、それを試してみたがNG

Hyper-Vの仮想マシンをVMware ESXi4へ移行する 【Linux編】

CentOS5.2が仮想マシンで動いていて、それを移動する手順を示します。
標準的には、CentOSではLVMを利用しているため、若干トリッキーな手順になるかと思います。

概要

  • dump/restoreによるデータの復帰
  • LVMのスナップショットを利用
  • 最後にgrubの設定を更新

詳細手順

現在のファイルシステムらをスナップショットをとれるように縮小する*2

レスキューモードで起動して、既存システムをマウントしない。
この状態で、手動でLVMのボリュームを認識させてやる。コマンドは以下の通り。

これで認識されるのでLVM中のext3領域を縮小させる。

これでext3ファイル領域が縮小されたので、LVのサイズを縮小する。
LVのサイズ縮小はオンラインで出来るので、ここでレスキューモードを抜け、再起動しておく。

LVのサイズ縮小とダンプ処理

LVサイズ縮小には、次のコマンドで行った

dumpによるバックアップ操作の前に、スナップショットを作成しておく。
そしてこのスナップショットに対してdumpでバックアップをとる*3

boot領域については、非マウント状態で dumpコマンドを実行する。

リストア処理

とりあえずESXi側でCentOSを標準的にインストールしておく。
そして、インストール後レスキューモードで起動し、現在のシステムを自動マウントしないでおく。
しかしLVM領域は操作に必要なので、前述の通りに認識はさせておく。

バックアップ領域提供用NFSをこの環境でマウントさせて、リストア処理を行う。
/bootの領域については、下記のコマンド手順でリストアさせる。

続いて / 部分については下記のコマンド手順でリストアさせる。

スワップ領域は、移行前後で共通して存在すると思われるのでここでは作業しない。

Grubの領域を設定するために再起動し、再びレスキューモードで起動させる。
今度は、既存システムを自動マウントさせる。
そして次の手順でgrubの設定を行う。

これで再起動させれば、自分の手元環境ではESXi上でCentOSが起動できた。

Linux編だけで結構長くなってしまったので、
Windows編はまた次回で書きたいと思います。

*2 : すでにLVMのエレメントに空きがあって、スナップショットをとれるならばこの手順は不要

*3 : /tmp/nfs/Backupは別PCのバックアップ領域提供用NFSです

注意事項

VMware ESXiで新規マシンを作るときに、上記手順で移行を考えている場合には、
HDDは IDE接続を選ぶこと。推奨となっている LSI Logicで接続してしまうと、
うまく動かない。kernel panicを引き起こす。
パフォーマンスがSCSIのほうが良いらしいので、
こちらで何とか動かせないかと努力してみたが、うまく動かせなかった。


Subversion1.6使いたい


CentOSでSubversion1.6系列を使いたい。
標準のyumでは 1.4.2だったので、いろいろ調べてみた。

基本的にCentOSはRedHat EnterpriseLinux5互換ということで、
Redhat el5で使用可能な rpm パッケージなら使えるのではないだろうかと思って試してみた。

結果は、うまくインストールできた。

Subversionは、今はApacheプロジェクトの1部なのでそこからダウンロードする。
Redhat el5用は、
http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/1.6.9/
から入手できた。

必要なモジュールについては上記の場所でまとめられていたので楽に入れられました。

  • neon
  • sqlite
  • subversion

どうもおかしい…。


Hyper-V上で動かしているLinuxマシンがどうも調子がおかしい。
今回はとうとうあるパーティションが読めないとエラーが出て、fsckをかける羽目になった。

結局、fsckでも復帰できなかったため、過去にとってあったスナップショットと
直前の/homeからの書き戻し作業で何とか現在に至ってます。

また、Hyper-Vマネージャもなにやら挙動がおかしいままで、
使い始めの時のような安定性がないです。

ハードウェア構成がまずいためこのようなことに陥っているのかもしれませんが、
どうにもわかりません。
Hyper-Vのイベントログで報告される次のようなエラーがずっとあるのも何か気になります…。

仮想プロセッサでの修復不可能なエラーによりトリプル フォールトが発生したため、
‘vm01’ はリセットされました。問題が解決しない場合は、製品サポートにお問い合わせください。

方針

  • いったんVMwarePlayerで仮装マシンを用意してそちらに現状のものを移行させる。
  • 必要があれば、OSから新規インストールして同じような構成で作成する。
  • VM全てがVMware上で動かせるようになったら、現状のHyper-V構成を削除

もっともVMwareServerが問題抱えていないかをチェックする必要がありそうです。


VMware-serverとHyper-Vの共存


WindowsServer2008R2で、
VMwareServer2.0.2とHyper-Vは同時稼働できないのかもしれない。

以前は出来たような気もするけど、
VMwareServerをインストールして、Hyper-Vの役割インストールという方法で試した。

しかし今回逆に
Hyper-Vを構築の上で、VMwareServerをインストールしようとした場合、
インストーラーでHyper-vの動作を検知されインストールできない旨が表示された。

このことから実は両方同時に1つの環境に入れるというのは、
まずいことだった!というのが推測できる…

なぜそんなことを思いついたか

Hyper-Vで半月ばかり稼働させていたが、
今回Hyper-Vマネージャから仮装マシンへ接続が出来ないという症状に見舞われた。
リモート操作を許可しているVMならまだ方法があるが、そうでないものは画面を開けない以上強制シャットダウンしかない。

ここから先は推測だけど、
何かがリソースリークしているのではないだろうか・・・。
うちでは CPU i3であるけど、標準VGAで運用している。このあたりに問題が何か潜んでいるかも。
こうなっている理由は、WindowsServer2008R2(x64)に今公開されているグラフィックドライバを入れたら
Hyper-V有効化時に、ブルースクリーンに見舞われたからである。

そのときのエラー内容をみるに、グラフィックスドライバ(kernel内)でアクセス違反を起こしていた。

いつかなおってくれるといいなぁ。