VMware vSphere 4.0でvCenter ServerのVirtualCenterサービスが起動しない

久々に技術的な話を。
vCenter Server 4.0のサービスがある日突然起動しなくなった。
アンインストールも上書きインストールも出来ない。
そのときの対応方法についてです。


あるお客さんから連絡があった。
VMware vSphere 4の仮想環境を半年以上運用しているのだが、あるとき突然、vCenter Serverにログインできなくなったらしい。

管理サーバ
・Windows Server 2008 Standard SP2 x86
・Oracle Database 11g R1 Standard Edition One 11.1
VMware vSphere Client 4.0 Update 1
VMware vCenter Server 4.0 Update 1
ESXホスト3台
VMware ESX 4.0 Update 1

管理サーバ上のvSphere Clientから自分自身のvCenter Serverにログインしようとすると、このメッセージが出てログインできない。


接続できませんでした

vSphere ClientvCenter Server「XXXXXXXX」と接続できません。
詳細:接続障害が発生しました。 (リモート サーバーに接続できません。)


VMware ESXホストに直接ログインは問題なく出来る。
コンピュータの管理でサービスの管理画面を表示すると、vCenter Serverのサービスである「VMware VirtualCenter Server」が開始中のままで止まっている。
vCenter ServerのデータベースであるOracle 11.1は正常に起動しているのに。

何でだろう。
半年以上何も問題なく動作していたのに。
試しにコマンドプロンプトからnet startでサービスを開始してみる。

(写真1)net startでVMware VirtualCenter Serverを起動してみる
net startでVMware VirtualCenter Serverを起動してみる


Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Users\Administrator>net start "VMware VirtualCenter Server"
VMware VirtualCenter Server サービスを開始します...
VMware VirtualCenter Server サービスを開始できませんでした。

サービス固有のエラーが発生しました: 2

NET HELPMSG 3547 と入力すると、より詳しい説明が得られます。


それならと、NET HELPMSG 3547を打ってみるても参考にならない。


C:\Users\Administrator>NET HELPMSG 3547

サービス固有のエラーが発生しました: ***


ここでvSphere Client 4.0 Update 1をアンインストール。
そしてvSphere Client 4.0 Update 2をインストール。
これは問題ない。


この日はvCenter Serverは再インストールするつもりでお客さんのところに行ったので、ここでvCenter Serverをアンインストールしてみる。
ところが以下のメッセージでアンインストールが出来ない。


Windows インストーラにより製品が削除されました。製品名: VMware vCenter Server、製品バージョン: 4.0.0.10021、製品の言語: 1041、削除の成功またはエラーの状態: 1603


ならば、次はvCenter Server 4.0 Update 1に対して同Update 2を上書きインストールしてみると、このメッセージで失敗してしまう。


VMware vCenter Server のインストールが完了する前に、ウィザードが中断されました。
システムは変更されませんでした。あとでインストールを完了するには、もう一度セットアップを実行してください。
「終了」をクリックして、ウィザードを終了してください。



(写真2)vCenter Server 4.0上書きインストール中に表示されたポート番号
vCenter Server 4.0上書きインストール中に表示されたポート番号
vCenter Server 4.0 Update 1を同Update 2で上書きしようとすると、途中でこの画面が表示された。
そこでnetstat -a -n |find /i "443"」などで他のアプリケーションとポート番号が競合していないか確認したが、重なっているポート番号も無し。

※上記画像は一部のポート番号をvCenter Serverの規定値から変更している。
(HTTPポート80 → 8000、WebサービスHTTPポート8080 → 8081)


うーん、にっちもさっちも行かない。


お客さんがVMware ESXのOEMメーカーのサポートに対して「vCenter Serverに接続できない」で問い合わせて返ってきた回答では、
(1)C:\Program Files\VMware\Infrastructure\jreフォルダ
このフォルダが空になっている場合、別のパソコンにvCenter Serverをインストールして、jreフォルダ内のファイルを管理サーバの同フォルダにコピーする。
(2)データベースのバックアップ
vCenter Serverのデータベースをバックアップする
(3)レジストリキーを削除
「HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure」を削除
(4)vCenter Serverをインストール

この手順でやってみるとの事なので、素直にやってみた。
確かにC:\Program Files\VMware\Infrastructure\jreは、フォルダは存在するが中身は空だった。
別のパソコンにvCenter Server 4.0 Update 1をインストールしてみる。
C:\Program Files\VMware\Infrastructure\jreフォルダ内にはJREのファイルが存在しているので、それを管理サーバの同フォルダにコピーする。
手間がかかる上にリスクが少ないため、データベースのバックアップは省略。

そしてvCenter Serverをアンインストールすると。。。
あら不思議、何事も無かったかのようにvCenter Serverがアンインストールできた☆
そこでサポートから指示されたとおり、Regeditで「HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure」のレジストリエントリを削除。

その後は普通にvCenter Server 4.0 Update 2をインストール。
問題なくインストールできる。
ああ、すばらしい。

(写真3)vCenter Server 4.0のVMware関連サービス
vCenter Server 4.0のVMware関連サービス
net start |find /i "VMware"でVMware関連のサービス起動を確認。
当然ながら、今度はVMware VirtualCenter Serverサービスも正常に起動している。

この2つは無償版のVMware vCenter Converter Standalone関連のサービス。
・VMware vCenter Converter Agent
・VMware vCenter Converter Server
この2つはVMware vCenter Server 4.0のサービス。
・VMware VirtualCenter Server
・VMwareVCMSDS


vSphere ClientからvCenter Serverへのログインも問題無し。
vMotionの動作確認もOK。
vcbMounterによるVCBのテストコマンドもOK。
ARCserve Backup 12.5でのVCBによる仮想マシンバックアップもOK。

これで一件落着。


半年以上も正常に稼動したvCenter Serverが突然起動しなくなる原因まではわかりませんが、正常に稼動するように戻りました。
これが頻発するようだったら原因を調べる必要があるかもしれません。
そのときはまた考えます。

ARCserve 12.5 + Agent for Virtual MachinesでVMware VCB経由の仮想マシンバックアップ(3)

前回の(2)では、VMware ESX 4.0 Update 1、VMware Consolidated Backup Framework 1.5 Update 1、ARCserve Backup r12.5 SP1、Agent for Virtual Machinesを利用した、VCB経由での仮想マシンバックアップした。

今回は仮想マシンのリストアです。

(写真1)ARCserveリストアマネージャ - ソースタブ - 仮想マシンの復旧
ARCserveリストアマネージャ - ソースタブ - 仮想マシンの復旧
ARCserveのマネージャを起動し、リストアマネージャを起動します。
ソースタブで「仮想マシンの復旧」を選ぶとバックアップしたVMDKファイルを一時フォルダにリストアし、VMware Converterを使って自動的に仮想マシンとして復旧されるはず。
しかし今のところVMDKファイルの復旧まで進んだところで「VMware Converterが見つかりません」で仮想マシンの復旧に失敗してしまう。

そのためこの日記では、以下の2ステップで手動にて仮想マシンを復旧します。
・VMDKファイルを一時フォルダにリストア
・リストアしたVMDKファイルをVMware Converterにより仮想マシンとして復旧

(写真2)ARCserveリストアマネージャ - ソースタブ - ツリー単位
)ARCserveリストアマネージャ - ソースタブ - ツリー単位
プルダウンは規定値のツリー単位のまま。
左ペインでWindows システムの下を展開し、復旧対象の仮想マシンを表示させる。

(写真3)ARCserveリストアマネージャ - ソースタブ - 仮想マシンの復旧の警告
ARCserveリストアマネージャ - ソースタブ - 仮想マシンの復旧の警告
「ツリー単位」ではなく「仮想マシンの復旧」を選択可能であることの警告が出るが、今回はそれを無視し、そのままOK。

(写真4)ARCserveリストアマネージャ - ソースタブ - 仮想マシンにチェックをON
ARCserveリストアマネージャ - ソースタブ - 仮想マシンにチェックをON
左ペインで復旧対象仮想マシンの下の「RAW」にチェックを入れると、右ペインにバックアップされているVMDKファイルなどが表示される。
RAWはVMware ESXの仮想マシンのネイティブな形式であることを意味している。

(写真5)ARCserveリストアマネージャ - ディスティネーションタブ
ARCserveリストアマネージャ - ディスティネーションタブ
「ファイルを元の場所にリストア」のチェックを外す。
左ペインのWindows システムを展開し、一時的にファイルをリストアするフォルダを選択する。
ツールバーの「開始」ボタンを押す。

(写真6)ARCserveリストアマネージャ - リストアメディア
ARCserveリストアマネージャ - リストアメディア
リストア元になるメディアの確認画面が表示されるが、そのままOK。

(写真7)セッションユーザ名およびパスワード
セッションユーザ名およびパスワード
そのままOK。

(写真8)ジョブのサミット
ジョブのサミット
そのままOK。

(写真9)ファイルリストアの開始
ファイルリストアの開始
指定した一時フォルダに対し、VMDKファイルをリストア中。

(写真10)ファイルリストアの終了
ファイルリストアの終了
リストアが成功したことを確認してOK。

(写真11)リストアされたVMDKファイル
リストアされたVMDKファイル
指定した一時フォルダ内にVMDKファイルがリストアされた。


とりあえず今回はここまで。
(3)につづく。

ARCserve 12.5 + Agent for Virtual MachinesでVMware VCB経由の仮想マシンバックアップ(2)

前回の(1)ではARCserve 12.5 Agent for Virtual Machinesの環境設定ツールでVCBプロキシサーバから仮想マシンの情報を取得し、バックアップマネージャのソースに仮想マシンが一覧表示されるところまででした。

今回は実際のバックアップです。
ゲストOS側にはARCserveのエージェントは一切入れません。
VMware ToolsとVCBによる仮想マシンの丸ごとバックアップを、ARCserveから自動で実行することを目的としています。


(写真1)バックアップマネージャのスケジュールタブ
バックアップマネージャのスケジュールタブ
前回の(1)ではバックアップマネージャのソースタブでVMware VCB配下の仮想マシンにチェックを入れてを選択した。
ステージングタブやディスティネーションタブは通常通り指定します。
スケジュールタブですが、今回は1回限りを想定して「1度だけ」にします。
VCBで仮想マシンの仮想ディスクをエクスポートしたVMDKファイルは毎回新規に作成されるため、アーカイブビットには意味がありません。

ここで上部の開始ボタンの右側のオプションボタンを押します。

(写真2)オプションのエージェントオプションタブ
オプションのエージェントオプションタブ
Agent for Microsoft SQL Serverは関係ないので、その下のAgent for Virtual Machinesをクリックして、画面右側のオプションを指定します。

バックアップモードは「RAWモード」です。
「ファイルレベルリストアを許可する」のチェックは外します。
ファイルレベルリストアを許可するためには、ゲストOS上にAgent for Virtual Machinesをインストールする必要があります。
今回はゲストOSには一切手をつけず、VMware Toolsのみで仮想マシンをバックアップします。


(写真3)オプションのボリュームシャドウコピーサービスタブ
オプションのボリュームシャドウコピーサービスタブ
ファイルシステムバックアップの「VSSを使用する」は、チェックを入れています。
もしかしたら「VSSを使用する」はチェックを入れない方がいいのかも。
この辺は特に詳しくは調べていません。

(写真4)バックアップジョブのステータス
バックアップジョブのステータス
バックアップオプションを指定したら、(写真1)の画面に戻って開始ボタンを押します。
バックアップが開始され、ジョブのステータスがアクティブになります。
右下ペインのジョブの詳細には、バックアップターゲットがVMware VCBプロキシであることが表示されます。


(写真5)VCBによりマウントポイントにVMDKファイルがエクスポートされたところ
VCBによりマウントポイントにVMDKファイルがエクスポートされたところ
バックアップジョブ開始後、しばらくはVCBによる仮想マシンのエクスポートが実行されます。
今回はRAWモードなので、vcbMounterコマンドによるfullvmに相当します。
したがってマウントポイントにはVMDKファイルのコピーがエクスポートされます。

Agent for Virtual Machinesの環境設定ツールではVCBのマウントポイントを「E:\mnt」と指定していますが、実際にはその下にVMwareVcbMountDirフォルダが作成され、その下にさらに仮想マシン名のフォルダが作成されて、その中にVMDKファイルなどがエクスポートされます。
エクスポートされるパスはこうなります。
[環境設定ツールでの指定パス]\VMwareVcbMountDir\[仮想マシン名]


(写真6)vCenter Serverで仮想マシンのスナップショットを確認
vCenter Serverで仮想マシンのスナップショットを確認
仮想マシンのエクスポートが始まったときにvCenter Serverでその仮想マシンのタスクおよびイベントを見ると、仮想マシンのスナップショットが作成されていることが確認できます。

(写真7)バックアップ完了後に開放されたVCBのマウントポイント
バックアップ完了後に開放されたVCBのマウントポイント
バックアップが完了すると、マウントポイントにエクスポートされたVMDKファイルは自動で削除され、仮想マシン名のフォルダごと削除された状態に戻ります。


VMware ESX 4.0 Update 1、VMware Consolidated Backup Framework 1.5 Update 1、ARCserve Backup r12.5 SP1、Agent for Virtual Machinesを利用した、VCB経由での仮想マシンバックアップができました。


次は仮想マシンのリストアについてもまとめたいと思います。
(3)につづく

ARCserve 12.5 + Agent for Virtual MachinesでVMware VCB経由の仮想マシンバックアップ(1)

VMware vSphere 4.0、VCB、ARCserve 12.5で仮想マシンのバックアップを行ったときのメモです。
今回はARCserveのAgent for Virtual Machinesで環境設定を行って、ARCserveのバックアップマネージャ画面にVMware VCB経由で仮想マシンが見えるようになるところを掲載します。


環境

[ESXホスト]
VMware ESX 4.0 Update 1

[管理サーバ兼VCBプロキシサーバ兼バックアップサーバ]
Windows Server 2008 SP2 (32ビット)
VMware vCenter Server 4.0 Update 1
VMware Consolidated Backup Framework 1.5 Update 1
・CA ARCserve Backup r12.5 SP1
・CA ARCserve Backup r12.5 Agent for Virtual Machines

CA ARCserve Backup r12.5 SP1をインストールし、インストールするコンポーネントとしてAgent for Virtual Machinesを選択します。
このときにAgent for Virtual Machinesのライセンスキー入力を要求されます。
Agent for Virtual Machinesのパッケージの中にはライセンスキーを印刷した紙が入っているだけで、媒体は何も入っていません。


(写真1)ARCserve Backup Agent管理の起動
ARCserve Backup Agent管理の起動
ARCserve BackupのコンポーネントにAgent for Virtual Machinesを追加した上で、「Backup Agent管理」を起動します。


(写真2)ARCserve Backup Agent管理から環境設定を起動
ARCserve Backup Agent管理から環境設定を起動
Backup Agent管理では複数のエージェントをプルダウンして選択するのですが、ここでは当然「Agent for Virtual Machines」を選択します。
そしてメニューバーのオプションから、環境設定を起動します。


(写真3)ARCserve Backup Agent管理から環境設定の実行
ARCserve Backup Agent管理から環境設定の実行
これがAgent for Virtual Machinesの環境設定ツールの画面です。
左上にはARCserve本体を実行しているサーバの名前、ARCserveの管理者IDとパスワードを入力します。
右上にはVCBプロキシサーバの名前、Windowsの管理者IDとパスワードを入力します。
そして一番下の実行ボタンを押します。

Agent for Virtual Machinesが指定したVCBプロキシサーバに接続して、仮想マシンを検出してくれます。
内部的にコマンドを生成して実行されているのが表示されます。


(写真4)ARCserve Backup Agent管理から環境設定の警告
ARCserve Backup Agent管理から環境設定の警告
httpsで接続している場合、しばらくすると証明書の警告が出ますが無視して「はい」です。
ARCserveのマニュアルのどれかに、VCBサーバから証明書をダウンロードして登録する説明があったような気がするけど。。。うーん、僕は気にしていません。

このポップアップは何故か環境設定ツール画面の背面に表示されるため、「いつまで経っても仮想マシンの検出が終わらないなあ」と何度も罠に陥りました。
タスクバーにこのポップアップが出てくるのを注意深くチェックしなければなりません。


(写真5)ARCserve Backup Agent管理から環境設定の結果
ARCserve Backup Agent管理から環境設定の結果
VCBプロキシサーバから仮想マシンを検出した結果が表示されます。
この例では9個の仮想マシンを検出しています。
その結果をARCserve内部のDBに保存しますが、Insertが何件、Updateが何件などと表示されます。

これで検出に失敗すると、バックアップできないので、この結果確認はとても重要です。
しかしできれば日本語化して欲しいよ。


(写真6)ARCserve バックアップマネージャに表示されるVCB経由の仮想マシン
ARCserve バックアップマネージャに表示されるVCB経由の仮想マシン
ARCserve本体のマネージャ画面を起動し、バックアップマネージャを起動します。
ソースタブの「VMware VCBシステム」を展開すると、仮想マシンの一覧が表示されます。

図は1つの仮想マシンを指定してチェックを入れたところです。
右下のペインを見れば、ゲストOSの種類やIPアドレス、VMware Toolsの有無などが検出されていることがわかります。

注目すべき点は仮想マシンのUUIDも認識している点です。
手動でVCBを実行するとき、vcbMounterコマンドでバックアップ対象を指定する際、
・ゲストOSのホスト名
・仮想マシン名
・仮想マシンのUUID
などで指定する方法があります。

ARCserveとAgent for Virtual Machinesは、どうやらUUIDで仮想マシンを識別するようです。
これがあとになってまた少しややこしいことになるのですが、それはまた今度。


(2)につづく

VMware ESX 4.0ストレージ領域に割り当てるLUNサイズは2TB未満に

引き続きVMware ESX 4.0 Update 1の話です。

VMware ESXで利用可能なストレージ領域って言うんでしょうか、VMFSパーティションて言うんでしょうか、要するにWindowsと同様に1パーティションは2TBまでって制限は有名です。
私だって知っていますし、ESX 3.5の頃に2TB以下のパーティションにエクステントを追加してして2TB超のVMFSボリュームを作成したこともあります。
Storageって言葉があいまいで間違いやすいので、ここではESXのVMFSの部分をストレージと呼びます。
ハードディスクの方はディスクアレイ装置と呼びましょう。


ではディスクアレイ装置のLUNサイズが4TBの場合、2TBのVMFSパーティションが2つ確保できるのかな?。
いや、LUNサイズが2TBまでの制限なのかな?。
その辺はあいまいなのでやってみました。

ESXホストは内蔵SAS 10000rpm 146GB×2本 RAID1です。
FC接続のディスクアレイ装置は、SAS 15000rpm 450GB×10本 RAID6です。(8D+PQ)
これが1つのRAID、つまりプールとなり、OSから見える論理的なサイズは、ほぼ3TBです。


(写真1)ディスクアレイ装置に確保した2TBのLUN
ディスクアレイ装置に確保した2TBのLUN
まずディスクアレイ装置の管理画面で、2TBのLUNを確保します。
1024×1024×2で、2097152MBぴったりです。

(写真2)ディスクアレイ装置に確保した1TBのLUN
ディスクアレイ装置に確保した1TBのLUN
次にディスクアレイ装置の管理画面で、1TBのLUNを確保します。
1024×1024×1で、1048576MBぴったりです。

(写真3)vSphere Clientで見たESXのデータストア
vSphere Clientで見たESXのデータストア
内蔵RAID1の134GBがStorage1です。
ディスクアレイ装置の1TBのLUNをStorage2として割り当てます。
ここまでは問題ありません。
次に右上のストレージの追加のリンクをクリックします。

(写真4)ストレージタイプの選択
ストレージタイプの選択
ストレージタイプで「ディスク/LUN」を選択します。

(写真5)ディスクまたはLUNの選択
ディスクまたはLUNの選択
この画面には確かに2.00TBのLUNが表示されています。
一安心して次に進みます。

(写真6)ホスト構成中のエラー
ホスト構成中のエラー
現在のディスクレイアウトで、無情にもこんなエラーが発生します。
ホスト構成中のエラー:Failed to get disk partition information
しかも背面には「ハードディスクが空です。」と出ているではないか。
いやいや、2TBもの広大な空き領域がそこに存在しているのに。

(写真7)プロパティでデータストア名を入力
プロパティでデータストア名を入力
それでも手順は次のステップに進みます。
プロパティ画面で、データストア名を入力して次へ。

(写真8)フォーマットができません
フォーマットができません
フォーマット画面でこんなエラーが表示されました。
オブジェクト参照がオブジェクト インスタンスに設定されていません。


これ以上はどうやっても先に進みませんでした。

WindowsではLUNが2TBを超える場合、そのLUNの先頭から2TBずつパーティションを確保できます。
しかしVMware ESXでは、ディスクアレイ装置のLUNサイズが2TBだと、パーティションを確保することができませんでした。
結局今回は1.5TBのVMFSボリュームを2つで利用することにしました。

この辺はホワイトペーパーの「VMware vSphere 4の新機能ストレージ」にそれらしいことが書いてあります。
はっきり断言されているわけではありませんが、7/11ページに「LUNあたり最大2TBまで」と記載されています。


http://info.vmware.com/content/apac_jp_cp10q1vsph_wp_lp?src=web_10Q1_VMW_VSP-JPpx&ossrc=web_10Q1_VMW_VSP-JPpx
・VMware vSphere ホワイトペーパーキット 2010年2月版

VMware ESX 4.0のVCBによるバックアップでゲストOS内のプリコマンド・ポストコマンドを実行させる

VCB (VMware Consolidated Backup)による仮想マシンバックアップのとき、ゲストOS内でプリコマンド・ポストコマンドを実行することができます。
このゲストOS内でのプリコマンド・ポストコマンドの実行はVMware Toolsを通じて処理されるため、VMware ESX上で正式にサポートされたゲストOSであり、適切なVMware Toolsが提供され、それをゲストOS内にインストールしている必要があります。

仮想マシンをシャットダウンしてからバックアップするのが一番いいのですが、少しでもサービス停止時間を短縮したいとか、ホスト側から仮想マシンのシャットダウンや起動のスクリプトを作りこむのが複雑だとかの理由により、ゲストOS内で特定のサービスを停止してバックアップする方法はとても有効だと思います。

処理の流れはこうなります
・VCBでバックアップの開始を宣言
・ゲストOS内でプリコマンドの実行
・仮想マシンのスナップショットを作成
・ゲストOS内でポストコマンドを実行
・スナップショットされた仮想マシンをVCBプロキシサーバのマウントポイントにエクスポート
・仮想マシンをバックアップ(ここはバックアップソフトで)
・バックアップ終了
・VCBでバックアップの終了を宣言
・スナップショットされていた仮想マシンと差分ファイルが合成されて通常の運用に戻る

まあこれは私の想像みたいなもんなので、多少の違いがあるかもしれませんが。
実際に現在構築中の環境で試してみました。

仮想化ホスト環境
VMware ESX 4.0 Update 1

仮想マシン環境
・ゲストOSはWindows Server 2008 Standard SP2 (32ビット)
・仮想ディスクは1つ (シンプロビジョニング50GB中7.6GB使用済み)

管理サーバ兼VCBプロキシサーバ兼バックアップサーバ環境
・Windows Server 2008 Standard SP2 (32ビット)
・VMware vCenter Server 4.0 Update 1
・VMware Consolidated Backup 1.5 Update 1
・ARCserve Backup r12.5 (本体)
・ARCserve Backup r12.5 Agent for Virtual Machines


ゲストOS内のプリコマンド・ポストコマンドは、特定の場所に特定のルールでバッチファイルを用意することで自動的に実行されます。
そのルールはVMware ESXのバージョンによって大きく変わっています。

VMware ESX 3.5 Update 1およびそれ以前
プリコマンド(Pre-freeze)
C:\Windows\pre-freeze-script.bat

ポストコマンド(Post-thaw)
C:\Windows\post-thaw-script.bat

VMware ESX 3.5 Update 2およびそれ以降
プリコマンド(Pre-freeze)、ポストコマンド(Post-thaw)共通
C:\Program Files\VMware\VMware Tools\backupScripts.d フォルダ内のスクリプト

プリコマンドの場合、第1引数としてfreezeが渡される。
backupScripts.dフォルダ内のスクリプトはアルファベットの昇順に実行される。

ポストコマンドの場合、第1引数としてthawが渡される。
backupScripts.dフォルダ内のスクリプトはアルファベットの降順に実行される。



VMware ESX 3.5 Update 1およびそれ以前はわかりやすい。
特定のフルパスで指定されたバッチファイルだから迷わない。

しかしVMware ESX 3.5 Update 2およびそれ以降は、ちょっとはわかりにくい。
プリコマンドの場合はbackupScripts.dフォルダ内のスクリプトがアルファベットの昇順に、ポストコマンドの場合はアルファベットの降順に実行される。
プリコマンドの場合は引数としてfreezeが、ポストコマンドの場合はthawが渡される。
わかってしまえばどうって事無いけど、実際にやってみて試行錯誤して、この意味がわかりました。

スクリプトの例
@echo off
color 3f
title バックアップ前ジョブ後ジョブテストバッチ

set LOGFILENAME="C:\Program Files\VMware\VMware Tools\backupScripts.d\BackupScript.log"
echo %date% %time% 第1引数は%1です >>%LOGFILENAME%
echo %1 >Temp.txt

rem 第1引数によって、前ジョブと後ジョブを分岐させる。
:PRE01
FIND /I "freeze" Temp.txt
IF ERRORLEVEL 1 GOTO POST01
SET %ERRORLEVEL%=0

echo %date% %time% バックアップ前ジョブ実行 >>%LOGFILENAME%
net stop  "Windows Update" >>%LOGFILENAME%
GOTO JOBEND

:POST01
FIND /I "thaw" Temp.txt
IF ERRORLEVEL 1 GOTO JOBEND
SET %ERRORLEVEL%=0

echo %date% %time% バックアップ後ジョブ実行 >>%LOGFILENAME%
net start "Windows Update" >>%LOGFILENAME%

:JOBEND
del Temp.txt /q
echo %date% %time% ERRORLEVELは%errorlevel% >>%LOGFILENAME%
echo -------------------------------------- >>%LOGFILENAME%



リダイレクトで出力するログファイルは、変数%LOGFILENAME%で指定しています。
このスクリプトを実行するカレントパスが良くわからないので、ログファイルの出力先はフルパス指定が無難です。
フルパスで指定しないと%systemroot%\system32フォルダに出力されてしまったと思います。
(良くあることですが)

VCBからこのバッチファイルが自動実行されるとき、プリコマンド・ポストコマンドでそれぞれfreezeとかthawとかの引数が渡されます。
FINDコマンドでは%1を直接文字列検索できなかったので、第1引数をTemp.txtにリダイレクトして、そのTemp.txtをFINDで検索しました。

このサンプルスクリプトで停止・開始するサービスは何でも言いのですが、今回は一番害が無さそうなWindows Updateを選んでみました。
実際には運用環境に応じてOracle Databaseなり、AD DSなりのサービス停止・開始を行うようにします。(マイクロソフトはActive Directoryの復元にはシステム状態のリストアのみをサポートしますが)


スクリプトを実行したログファイルの例

2010/03/26  3:45:39.58 第1引数は"freeze"です
2010/03/26  3:45:39.60 バックアップ前ジョブ実行
Windows Update サービスを停止中です.
Windows Update サービスは正常に停止されました。

2010/03/26  3:45:42.21 ERRORLEVELは0
--------------------------------------
2010/03/26  3:46:20.15 第1引数は"thaw"です
2010/03/26  3:46:20.16 バックアップ後ジョブ実行
Windows Update サービスを開始します.
Windows Update サービスは正常に開始されました。

2010/03/26  3:46:22.16 ERRORLEVELは0
--------------------------------------



プリコマンド実行時には第1引数としてfreezeが、ポストコマンド実行時には第1引数としてthawが渡されていることがわかります。
ブイエムウェア社の仮想マシンバックアップガイドには、ポストコマンド実行時の引数は「thawまたはfreezeFail」が渡されるとありますが、プリコマンドに失敗してポストコマンドにfreezeFailが渡されるところまでは確認していません。

この例では3:45:42にプリコマンドが終わり、3:46:20にポストコマンドが実行されています。
その間、約38秒ですが、つまりこの間にスナップショットが作成されたことになります。

vcbMounterコマンドでも試しましたが、ARCserve Backup 12.5とAgent for Virtual Machinesの組み合わせからバックアップしたした場合でもプリコマンドとポストコマンドの実行は確認できました。


納期に間に合わないかもしれないプレッシャーの中でこれを試すのは、結構疲れました。

Enterprise Watchの「VMware vSphere 4を試す」

参考になりそうな記事を見つけたので、メモ。
Enterprise Watchの「VMware vSphere 4を試す」シリーズです。


http://enterprise.watch.impress.co.jp/docs/series/virtual/20100201_343848.html
VMware vSphere 4を試す【第一回】 (2010/2/1)
http://enterprise.watch.impress.co.jp/docs/series/virtual/20100208_346619.html
VMware vSphere 4を試す【第二回】 (2010/2/8)
http://enterprise.watch.impress.co.jp/docs/series/virtual/20100209_346829.html
VMware vSphere 4を試す【第三回】 (2010/2/9)
http://enterprise.watch.impress.co.jp/docs/series/virtual/20100210_346830.html
VMware vSphere 4を試す【第四回】 (2010/2/10)
http://enterprise.watch.impress.co.jp/docs/series/virtual/20100212_346831.html
VMware vSphere 4を試す【最終回】 (2010/2/12)


VMware ESXi 4.0 Update 1 InstallableとvCenter Serverを使って、VMware vSphere 4の基本的な機能を利用するまでの流れが図入りで解説されています。
図がもう少し大きいとわかりやすいんですが、あまりにも小さくてちょっと残念です。
画像1つずつを拡大してみて、元の文書に戻るのを繰り返すのは面倒な上に、本文と画像が別々のWebページになって思考が分断されてしまうので、ある程度内容がわかるくらいの画像サイズだと言うこと無しなんですが。

第1回から最終の第5回までの主な内容は以下のとおりです。
【第一回】VMware ESX/ESXi/vSphere Client評価版のダウンロードとインストール。
【第二回】vCenter Serverのインストール と利用。
【第三回】iSCSIストレージの接続、仮想マシンの作成、ゲストOSのインストール。
【第四回】VMware VMotion、VMware HA、VMware FTを利用。
【最終回】VMware vSphere 4のエディションの違いによる機能と価格の違い。

今までVMware ESX 3.5でローカルSASディスクと、FC接続のSANしか経験がないので、ESX 4.0でiSCSI接続SANの記事はメモしておきたかった。

VMware vSphere 4 Essentialsで手動による仮想マシンのESXホスト間移動

昨日の続きです。

ESXホスト#1が故障などにより予期しないシャットダウンをすると、ESXホスト#1で実行されていた仮想マシンをESXホスト#2に移動することができない。

結局ちょっとインチキっぽい方法で回避することにした。


障害でESXホスト#1がダウンした後、ESXホスト#2に新規仮想マシンを登録する。
新規仮想マシンの仮想ハードディスク(.vmdkファイル)は、ダウンしたESXホスト#1で稼動していた仮想マシンの.vmdkファイルそのものを指定する。
で、ESXホスト#2の新規仮想マシンを起動する。
こんな感じ。

もしESXホスト#1がダウンせず、LANアダプタの故障などにより孤立した状態で仮想マシンが起動したままであれば、ESXホスト#1のサービスコンソールからshutdown -h nowなどで物理サーバをシャットダウン。
そのあとで上記の方法でESXホスト#2に新規登録した仮想マシンに、ESXホスト#1で仮想していた仮想マシンの.vmdkファイルを割り当てる。


なんかすっきりしないけど、まあ緊急事態のときの回避策としては、なんとかなるか。
ちゃんとやりたければHA機能付きのVMware vSphere 4 Essentials Plusにすれば、VMware ESXホストの障害時には仮想マシンは別のESXホストにフェールオーバーして再起動されので、当然だけど本来はそちらをお勧めする。
(と言うかVMware HA機能付き製品を選択するべき)

今回は「最小のコストで最大の効果。障害時は自動フェールオーバーではなく、管理者による手動操作でも構わない。」というお客さんの意向により、イレギュラーな方法での運用となった。

VMware vSphere 4 Essentialsで手動による仮想マシンのESXホスト間移動

現在とある物件で検証中。

VMware vSphere 4 Essentials
VMware ESXホスト 2台
VMware vCenter Server 1台
・ファイバチャネル接続の共有ディスクアレイ装置 1台

ご存知のとおりVMware vSphere 4 EssentialsにはVMware HA機能がありません。
しかしVMware vSphere 4 Essentialsは2CPUのESXホスト3台に、vCenter Serverまで付いて十数万円の圧倒的な低価格。
このVMware vSphere 4 Essentialsを使って小規模で低コスト、しかもESXホストの障害時に手動で別のESXホストに切り換えて仮想マシンを再起動できないか?。
って事を検証中。

運用系であるESXホスト#1で、ある仮想マシンを起動している。
待機系であるESXホスト#2では仮想マシンは何も起動されていないが、ホストは起動している。
vCenter Server管理画面では、2台のESXホストをひとつのクラスタに登録している。
vCenter Server管理画面で、ESXホスト#1で実行中の仮想マシンをシャットダウン。
この状態で仮想マシンを右クリックして「移行」(英語版ではMigrate)すれば、仮想マシンはESXホスト#1からESXホスト#2に移動する。
仮想マシンを起動すれば、確かにESXホスト#2で起動されている。

ここまではOK。


しかし、
仮想マシンがESXホスト#1に割り当てられている状態で仮想マシンをシャットダウン。
その後でさらにESXホスト#1もシャットダウン。
この状態では仮想マシンをESXホスト#2に移動することができない。
ESXホスト#1が仮想マシンを確保したままになってるんだろうな。

今回の目的はESXホスト#1に障害が発生したときに、ESXホスト#2に切り換えて仮想マシンを再起動すること。
このままではESXホスト#1が予期しないシャットダウンをすると、ESXホスト#1で実行されていた仮想マシンをESXホスト#2に移動することができない。

ちょっと調査中。
会社内でやった例があると聞いているので、今日その人に聞いてみよう。

VMware ESX 4.0ホストの再起動後にvSphere Client管理画面から接続するのに時間がかかる

私のチームでインストール中の、とある物件。

VMware vSphere 4 Essentials
VMware ESXホスト 2台
VMware vCenter Server 1台
・ファイバチャネル接続の共有ディスクアレイ装置 1台

お客さんに納品する前に、うちの会社内でプリインストール中です。
しかし管理サーバからESXホストに対する接続が異常に遅い。
vCenter Server 経由でもvSphere Clientで直接でも、ESXホストが正しく表示されるのに20分から30分、あるいはそれ以上も待たされる。
それまではvSphere Clientの管理画面上では、ESXホストは赤いエラーのアイコンになっていて接続できない。

で、社内のある人からの情報。
もしかしたらこれかも。(英文)


http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1012942
VMware KB: Cannot connect to ESX 4.0 host for 30-40 minutes after boot (1012942)


VMware ESXホスト上に参照するDNSサーバが定義されているが、そのDNSサーバと通信できない状況で発生するらしい。
確かに。

今はうちの会社内でプリインストール中なので、IPアドレスや参照するDNSサーバのアドレスは設定しているが、当然ながらDNSサーバは存在しない。
ESXホストでDNSサーバを参照しないようにすると、vSphere Clientからすぐに接続できたらしいので、やはりこれが原因なんだろうな。

と言うわけでESXを再起動したら気長に待つか、一時的にDNSサーバを参照しないようにするか、になりそうです。
VMware vSphere 4 EssentialsのESXホストをVMware ESX 4.0 Update 1で再インストールしても現象は変わらず。
管理サーバ側のVMware vCenter Server 4.0およびvSphere Client 4.0にそれぞれUpdate 1を適用しても現象は変わらずだった。

これで結構時間をとられてしまった。

Microsoft Translatorによる日本語訳はこちら。


http://www.microsofttranslator.com/BV.aspx?ref=BVNav&from=&to=ja&a=http%3A%2F%2Fkb.vmware.com%2Fselfservice%2Fmicrosites%2Fsearch.do%3Fcmd%3DdisplayKC%26docType%3Dkc%26externalId%3D1012942

テスト中

全ての記事を表示する

ブロとも申請フォーム

ブログ検索
プロフィール

norimaki2000

norimaki2000のブログにようこそ
・2013/01/05テンプレートをsantaからhouseに変更
・2012/10/29テンプレートをsweet_donutsからsantaに変更
Follow norimaki2000 on Twitter気軽に話しかけてね

ニューヨーク・マンハッタン(タイムズスクェア)180×135

千葉県在住で東京都内に勤務。SE歴20年超えました。

昔々はオフコンで販売管理などのアプリケーション開発していた。
ファミリーレストランの無線オーダリングやPOS、キッチンプリンタの全国展開なんかもやっていました。
最近はWindowsサーバーとVMware vSphereを中心としたサーバーインフラの提案・構築・保守を中心にやってます。
主な取り扱い製品は、
・Windows 2000 Server以降 (もちろんNT3.5やNT4.0も知っていますが)
・Active Directory (今で言うAD DS)
・Symantec Backup Exec
・Symantec System Recovery
・CA ARCserve Backup for Windows
・CA ARCserve Replication
・CA ARCserve D2D
・EMC RepliStor
・VMware vSphere
・某メーカーのクラスタソフトウェア

どれもこれも中途半端な知識と技術力ですが、なんとかやっています。
私自身は技術や製品を担当する立場ではなく、特定業種のお客さん(ユーザ企業)の対応窓口となるSEの役割りですから、必要であれば詳しい知識や経験豊富な別のSEを探してきてプロジェクトメンバに加えます。

もちろん小さな物件では自分で提案、インストール、お客さんへの導入、アフターサポートまでやります。
大きな物件では提案はやりますが、構築部分は専門部隊に依頼します。
その場合でもアフターサポート窓口は私がやりますので、お客さんに対しては一貫して窓口SEとなります。

サーバの世界の大きなトレンドは統合・仮想化。
2007年はVirtual Server 2005 R2によるサーバ仮想化も、2つのお客さんで本稼動させた。
2008年はVMware ESX 3.5を2セット構築。単純なローカル起動と、SANブート/VMotion/DRS/HA/VCBのフル装備もやった。
2009年はぜひHyper-Vの仮想環境を構築したいな。と思っていたが、なかなか機会に恵まれなかった。
2010年はVMware ESX 4.0でHA/VMotion/VCBバックアップを進行中。

そのほかにも、ドメインコントローラやファイルサーバの全国展開とデータ移行、特定のアプリケーションの実行基盤となるサーバ群のOS・バックアップ・DBクラスタなどインフラ部分の構築などをやっています。


2011年のポイントも引き続き、【ご利用は計画的に】。
今まで長年に渡って仕事も私生活も行き当たりばったりなので、少しでも物事を計画的に進められるようにしたい。
いつも計画性の無さが災いして多くの人に迷惑をかけています。
自分自身も計画的な仕事ができないため、いつもいろいろ苦労しています。
今年はさらに計画的に仕事をするようにしなきゃ。

それと若手を上手に使うようにならなきゃならん。
若手の育成はもちろんだけど、僕自身も仕事を上手に他の人に振ることができるようになりたい。
仕事の種類のせいなのか性格なのか、どうしても一人で抱え込んでしまうから。

【Twitter】2010年の元旦から始めました。平均して1日あたり10ツィート程度です。
仕事関連の呟きが少し、くだらない呟きがほとんどかな。
Follow norimaki2000 on Twitter
・norimaki2000 on Twitter

Follow norimaki2000 on Twitter
・norimaki2000 on Twilog


オンライン上ではあるけれど、今まで知らなかった人たちと交流する機会を得ることになり、非常に刺激を受けます。
仕事でも私生活でも、いろんな人のつぶやきは息抜きにもなり、また助けられたり、あるいは「もっとがんばんなきゃ」と励みになったりします。
Twitterを考え出した人の発想、システムとして作り上げた努力と情熱はすごい!!


【好きな音楽】ベテランの皆さんなら浜田省吾、尾崎豊、エコーズ、若手なら鬼束ちひろ、平原綾香、現在注目の若手はいきものがかり

【好きなアイドル】千葉県柏市を中心に活動する地元アイドルの「コズミック☆倶楽部」を激推し中です。

【好きな飲み物】シャンパンはご存知モエ・エ・シャンドン ブリュット アンペリアル、ビールはキリン ブラウマイスター、水ならビッテル、お茶ならキリン生茶

【好きなTVドラマ】Xファイル、24、ミレニアム、ER、CSI:科学捜査班シリーズ、NCIS:ネイビー犯罪捜査班、ザ・プラクティス、ボストン・リーガル



パソコン困り事相談もよろしく


最近の記事
最近のコメント
カレンダー
11 | 2019/12 | 01
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -
カテゴリー
FC2カウンター
キーワード

Windows_Server VMware_ESX VMware vCenter_Server PowerShell VMware_Player PowerCLI vSphere_Client VirtualCenter Active_Directory vStorage_API Converter 文音 コズミック☆倶楽部 Windows Hyper-V Microsoft_Security_Essentials あいひょん なるみん Windows_8 vSphere Backup_Exec VMware_Converter sora カラオケ VCB Red_Hat_Enterprise_Linux System_Center Windows_Server_2012 SQL_Server VMware_vSphere Tech_Fielders 麗美 ARCserve_Backup Internet_Explorer メモリダンプ ESX System_Recovery remi RHEL Active Symantec Backup vSphere_CLI Server Twitter Firefox Directory vMotion Oracle DMC-FZ1000 VMware_HA Exec マークス ジン子 XenServer Vista DRS schtasks Office Sysinternals Oracle_Database Windows_Update 若手 Recovery vCenter_Converter コズミック倶楽部 SE Emily_Styler エミリースタイラー sonoka Visual_Studio 氷結 キリン wevtutil NTFS  路上ライブ System エイドリアン オレッツァ 圧縮 0x0000007B ATAPI Brio コマンドライン バルボア 破損 修復 2008 スパリゾートハワイアンズ corega おとなのおつまみ サクセス ベビースター スパークリングウォーター カルディ おやつカンパニー 一番搾り食物繊維 えびしお カーナビ 白石美帆 セキュリティ スタローン 糖質 ついにステップワゴンを契約してしまった 経済産業省 東京国際フォーラム ロッキー セルシオ ブラックホーク・ダウン ジョシュ・ハートネット シャンプー台のむこうに デュポン コロン ハワイ グレープフルーツ ウォーター 北野 神戸 ワイヤーアクション ムエタイ けんけつちゃん 献血 お茶のチューハイ ポケモン・スタンプラリー はばたき福祉事業団 日本赤十字社 マッハ 映画 東京タワー 写真 伊藤園 人口甘味料 CAB グランダム 掃除 雨どい 洗濯 洗車 スリムス サッポロ のどごし生 フィット カーポート 高原 関西空港 羽田  サーバ 夏休み 万座温泉 バーベキュー 鬼押し出し園 草津 キャンプ ラガー Word HUAWEI OneDrive 浜田省吾 Linux GR5 れみ wbadmin Windows_Serverバックアップ Paper.li VMware_ESXi IP38X/N500 バッチ Tween OpenOffice Apache iStorage Windows_Azure NVR500 AWS robocopy Intel Panasonic Wataru_Sato シンガーソングライター REAN つりあやめ 佐藤航 cana 動画 チャンカナ canaguitar -ayane- こずくら vSphere_Web_Client FZ1000 LUMIX Windows_Server_2016 コズミック☆LOVE イチトキ 加藤成実 エミリー・スタイラー グループポリシー SkyDrive PC-Success OREZZA NetBackup NR-7900A PCI Replication STOPエラー SAP Resource Kit IZZE CR-V CG CDRW-AB24JL CoolMax DVD IDE Hyperion Gathers SUPPLEX SweetGrass VMFS OpenOffice.org ジャンプフェスタ ITIL ARCserve_Replication ARCserve_D2D vStorag_API Virtual_Infrastructure バックアップ DSP OEM USB Tools Thunderbird USB2.0 Uptime.exe ULPC XP ツイート CD 

月別アーカイブ
リンク
RSSフィード