ライタス株式会社公式ブログ

今日のトラブルは、Hyper-Vにまつわる話です。 これまでも、w32time周りでひどい目に遭ってきましたが、今日のもなかなか意味不明です。 話をする前に、簡単に今回の環境について、まとめておきましょう。 Hyper-Vホスト機 ：Windows Server 2008 R2 SP1 (Hyper-V 2.0)　時計はCisco 1812Jから取得 Hyper-Vゲスト機 ：Windows Server 2003 R2 SP2　時計は1812Jから取得 NTPサーバー ： Cisco 1812JのNTP機能 時計はNICTから取得 ちょっと特殊な気がしますが、こんな構成です。 今回、時刻同期ができなくなったのは、Hyper-Vゲスト機です。 これまでの経緯で、Hyper-V統合コンポーネントの時刻同期は外していたのですが、 どうもこれが災いした模様です・・・ w32timeが失敗すると、こんな警告が発生します。 ソース：W32Time イベントID：36 使用可能なタイム スタンプがタイム サービス プロバイダによって提供されなかったため、 タイム サービスは 86400 秒間、システム時刻を同期していません。タイム サービスは 現在同期されておらず、他のクライアントへの時間の提供、またはシステム クロック の更新を行うことができません。これ以上深刻な問題が発生していないことを確認 するために、イベント ビューアに表示されるシステム イベントを監視して ください。  これ自体は、たまに出る（！？）ので、w32tm /resyncコマンドか、w32timeサービスの再起動で大体が解決します。 ただ、今回は、いつもと少し違っていました・・・ w32tm /resyncを実行しても、 C:\Documents and Settings\Administrator>w32tm /resync 再同期のコマンドを送信:  local computer... 時刻データが利用できなかったため、コンピュータは同期をとり直しませんでした。 どうしたものやらと思って、伝家の宝刀　w32timeのログ出力を設定しました。 設定方法は、以下(ご利用の際は、各自の環...

朝、オフィスに出勤して、メールを確認していると、監視サーバーからメールが届いていました。 監視サーバー「Hyper-Vのサーバーがダウンしたけど復帰したよ！」 ・・・えぇっと・・・（汗 開発用サーバーだったのが幸運だったのか不運だったのか。 私が管理している、Hyper-VのサーバーがどうもSTOPエラーを吐き やがって 、その後自動で再起動した模様でした。 問題の署名:   問題イベント名:    BlueScreen   OS バージョン:    6.1.7600.2.0.0.272.7   ロケール ID:    1041 この問題に関する追加情報:   BCCode:    101   BCP1:    000000000000000D   BCP2:    0000000000000000   BCP3:    FFFFF88002200180   BCP4:    000000000000000A   OS Version:    6_1_7600   Service Pack:    0_0   Product:    272_3 この問題の説明に役立つファイル:   C:\Windows\Minidump\090810-36972-01.dmp   C:\Users\Administrator\AppData\Local\Temp\2\WER-69126944-0.sysdata.xml オンラインのプライバシーに関する声明をお読みください: http://go.microsoft.com/f...

ちょっと更新に間ができてしまいました。 前回の記事で、NLBが構成できない件を記載しましたが、これが解決できたので、書いておこうと思います。 テキストだと状況が分かりにくいので、絵にしてみました。（やっつけ仕事だなぁ・・・） Hyper-V Host A/B上に、それぞれHyper-V Guest 1/2を配置しています。 NLBの設定で、ユニキャストモードにする場合は、MACアドレスのスプーフィングが必要になるそうです。（私の環境では設定しなくてもなぜかできました） 参考： http://blog.livedoor.jp/itdesign/archives/1199582.html http://d.hatena.ne.jp/rlyeh/20090605/1244202714 私は、マルチキャストモードで動作させたかったので、Windows Server 2008 R2であれば、特に追加の設定は必要ありません。 クラスターIPにPingは届くのに、IISで表示すると、表示できない現象に遭遇しているのは、先述していますが、現象があまりによく分からないので、製造元のDELLのテクニカルサポートに支援してもらいました。（この時点で、私はNICの不具合、あるいは仕様を疑っています） DELLさんは、自分のところで組んだNLBだと問題ないので、実機でパケットキャプチャして欲しいとのこと。 パケットキャプチャしたところ、IISまでのリクエストは届いているが、サーバー側でRST応答している様子がわかりました。 なんで、サーバーがRSTを投げているのか、、、とりあえず、通信上の問題ではなく、ソフトウェアレベルで何かが起きていると推測し、その旨をDELLさんに報告したところ、「NIC のオフロード機能が疑わしい。さもなくばネットワーク機器かセキュリティ対策あたりが疑わしい。」とのこと。 オフロード機能ってなんだ？と調べてみたら、ネットワークの処理を、CPUではなくて、NICにやらせる機能のことのようです。 さっそくOFFにしたけども、現象は同じ。 外れだったか・・・と思いつつ、他の原因に当たりをつけようとメールを見返したら、「セキュリティ対策が疑わしい」とあったので、まさか・・・と思いつつ、インストールしてあった、Symantec End...

あるプロジェクトで、Hyper-Vホスト2台を用意し、それぞれにゲストOSを用意して、NLBを組ませようという、よくある話（？）です。 Microsoft的にはサポートしている構成だというので、余裕でできると思っていたのですが・・・ 事前テストとして、DELL OPTIPLEX 960 x2でNLBを組んでみたら、何事もなくうまくいったので、本番のDELL PowerEdge R410 x2でNLBを組んだら、なぜかうまくいきません。 手順としては、 ホストOSにHyper-Vインストール ゲストOS作成 ゲストOSにIISをインストール ゲストOSに負荷分散マネージャーをインストール 負荷分散マネージャーでクラスターを構成 だけなんですが・・・クラスターIPにPingは飛ぶのに、ブラウザでアクセスすると、アドレスが存在しない状態になります。 変だなぁと思って、R410で作ったHyper-VゲストをOPTIPLEX 960へエクスポートインポートしたら、何もしないで動いたので、原因は、R410にありそうとあたりはついた感じです。 NICのドライバがOPTIPLEX 960はIntelのオンボードなのに対して、R410はBroadcomのカードなのがなにか影響しているのではないかとにらんでいます。 不思議と、この辺の情報ってないんですよねぇ・・・困った・・・ 解決編は明日投稿予定です。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。

新しい仮想サーバーを作成する必要が出たので、作成しようとしたところ、ネットワークを選択する画面で、ネットワークの一覧が表示されなくなっていました。 仮想ネットワークマネージャーを開いたところ、以下のダイアログが表示されました。 どうやら、ネットワーク情報がHyper-V上から参照できなくなっているようで、イベントログにも何も出てない状態です。 よくよく調べてみたら、RPCサーバーが応答していない模様。 RPCサーバーの通信については、以下のブログが詳しいです。 http://blogs.technet.com/b/jpntsblog/archive/2009/09/02/rpc.aspx さらにいろいろ調べてみると、Symantec Endpoint Protectionのウイルス定義ファイルのアップデートに失敗していました。 これらから推測するに、リソースの枯渇が怪しい気がしてきました。 といっても、これといって対策しようがないので、サーバーを再起動してみたところ、治りました。 Windows Serverの連続稼働は無理なんでしょうか・・・　と、思うと悲しくなります。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。

皆様こんにちわ 今日もトラブルすぎて、楽しい日々を送られているのではないかと、思います（泣 定番となりました、Hyper-Vの 不 幸トラブルです。 Hyper-Vホストの移設をするため、ゲストOSを移行先へチクチクコピーしておりました。 ところがある時、いきなりホスト機のリモートデスクトップに接続できなくなりました。 なんで！？　と思いつつ、実機のコンソールにログインしてみると ソース：VMSMP ID：28 ポート 'SWITCH-SM-xxxxxx' は MAC アドレス 'xxxx' を使用できませんでした。このアドレスはポート 'xxxx' に対応しています。 なんていう警告が1秒間に10回ぐらいの間隔で大量に出続けているじゃありませんか。 （この時は、まだゲストOSには、リモートデスクトップで接続できてます） さすがにやばいなーと思いつつ、調べてみると、 「原因不明」 「再起動するしかない」 「Hyper-Vのネットワークを作りなおして再起動したら治った」 参考 http://blog.livedoor.jp/stock_value/archives/51272001.html http://www.packagedeploy.com/forum/microsoft-virtual-server-hyper-v/vmsmp-event-id-28-warnings-10520/ http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/365d5fe3-58a9-40e4-9568-da13d08f930a/ などの情報が手に入りました。 ぶっちゃけ、どうにもならないんだなーと思いつつ、 ホスト機のNICだけでも回復させようと思って、ネットワークの自動修復を仕掛けたところ・・・ 「ちょっと繋がらなくなったんだけど？」 「なんかした？」 「いつ治る　早く直して　てか今すぐに！」 きゃぁぁぁ　YABEEEEEE!!!!! NICが飛びやがった えぇっと・・・しょうがない　とりあえず再起動！ 再起動中に...

2015年11月11日に、マイクロソフトよりHyper-Vの脆弱性についての報告がありました。 本脆弱性は、KB3108604として修正されています。 詳しい内容は以下をご参照ください。 https://technet.microsoft.com/ja-jp/library/security/3108638 驚くべきところは、ゲストOSの特権を使えば、ホストOSをサービス停止させることができるという点ですね。 CPUの弱点を突く攻撃がゲストOSから可能であるということなので、修正されることをおすすめします。 また、Hyper-Vだけかと思ったら、XenやKVMにも同様の脆弱性を持っているようで、こちらも修正パッチがリリースされているようです。 http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-005933.html http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8104 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5307 メカニズムについては、分かる範囲で調べてみました。 ポイントは、CPU命令に搭載されているアライメントチェック（Alignment Check）の例外処理が誘発されることに起因します。アライメントチェックとは、メモリからCPUの命令を電送するときに、ちゃんとデータを送り届けるために整列（アライン）させます。これが正しく整列されているかをチェックする仕掛けが、アライメントチェックと言います。 詳しい解説は以下をご覧ください。非常に丁寧に解説されています。 http://www5d.biglobe.ne.jp/~noocyte/Programming/Alignment.html 今回の脆弱性は、アライメントチェックを利用して、CPUにアライメントチェック例外を引き起こす事ができるというもので、これが引き起こされた場合、Windowsであれば、ブルーバックになるものと思われます。 最近のWindowsはブルーバックになると、自動的に再起動されるので、原因が掴みかねる場合もありそうです。 Linuxではカーネル...

今回は、Hyper-Vにまつわるトラブル（というか、現象）のご紹介です。  ある客先で、Hyper-Vゲストをシャットダウン -> 起動をする必要に見舞われたため、 メンテナンス時間を設けて、シャットダウンしました。 通常であれば、ステータスが何もない状態になるはずが、 「結合処理実行中...」 とかでてます。（この時点で、すごくやな予感・・・） ちなみに、結合処理について、解説しておくと。。。 仮想マシンで、スナップショットなどを取得している場合、 差分ディスク（ディスクといっても、実態はファイル・拡張子はavhd）というものが生成されます。 差分ディスクは、スナップショットを取得した時点から、次のスナップショットが 取得されるまでの差分を記録するものです。 スナップショットが削除されると、仮想マシンが停止した段階で、 差分ディスクの内容を、本体のディスクファイルに整合性を保つように 変更しにいきます。これが、結合処理です。 細かい結合処理の起動トリガーについては、以下を参考にするとよいと思います。 http://www.atmarkit.co.jp/fwin2k/verification/vpcwin06/vpcwin06_03.html 今回は、上のURL的には、ケース1に該当していたので、 結合処理中を無視して、再起動してしまいました。 （といっても、ケースに該当していたことを知ったのは、この記事を書いているときなんだけれども・・・） ですので、今回は障害にならなくて済みましたが、 状況によっては、最悪、仮想マシンが復帰してこない状況もありえたので、 いま考えても、結構怖いです。（バックアップはとってますが、、、始末書モノです、、、） 対応策としては、 運用で使っている仮想マシンは、スナップショットを取らない どうしても取ったほうがいい場合は、時期を見てサーバーを停止させて、ときどき結合処理を実施させる 停止状態にしない(停止状態でなければ、結合処理は実施されない・・・はず) といったところでしょうか・・・ avhdファイルが大きければ大きいほど、結合処理に時間がかかるので、 くれぐれも、ご用心を 今回の環境では、計40GBほどのavhdファ...