Hyper-V

検証環境がガラッと変わりまして、Windows Server 2019のHyper-V環境でインターネットには2回NATが必要な状況になりました。 RRASサービスを使うか、NAT専用のVMを構築しようかとも思いましたが、Windows NAT(WinNAT)で簡単にHyper-V環境でのNATが構成可能になっているのでWinNATを利用して構成しました。 公式ドキュメントは下記です。 NAT ネットワークのセットアップ | Microsoft Docs 構成は管理者権限のPowerShellで簡単にできます。下記は例。 N N N e e e w w w - - - V N N M e e S t t w I N i P a t A t c d h d - r N - e a S s m w s e i t - M c I y h P N N A A a d T m d n e r e e t " s w S s o w r i 1 k t 9 c 2 - h . I N 1 n a 6 t m 8 e e . r " 0 n . a - 1 l S I w - P i P I t r n c e t h f e T i r y x f p L a e e c n e I g A n t d t h d e r r 2 e n 4 s a s l - P I r n e t f e i r x f a 1 c 9 e 2 I . n 1 d 6 e 8 x . 0 2 . 4 0 / 2 4 単純に ...

Announcing Azure Network Watcher – Network Performance Monitoring and Diagnostics Service for Azure | Blog | Microsoft Azure 1 user Have you ever felt the need to diagnose a critical problem and you needed access to packet data from a virtual machine? What if you c… [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 16 clicks 2017/03/23 - System Center Configuration Manager エージェントと Microsoft Intune (MDM) による管理の共存について – Japan System Center Support Team Blog 1 user みなさま、こんにちは。System Center サポート チームです。 Windows 10 の展開に伴い、タブレットなどのモバイル デバイスに搭載された Windows 10 端末の管理をご検討いただく中で、System Center Configuration… ...

前回、ディスクが見えなくて失敗してしまいました。でも、他の環境では普通に成功している方が多数。 私が試したのはWindows 10 Technical PreviewのEnterpriseエディションなので、エディションの違いが効いているはずです。 (というかEnterpriseエディションでもディスクが見えないってのは変ですが…) というわけで、今回は通常の評価メディア(Enterpriseではない)を使ってインストールを試みました。 インストール先は同様にクライアントのHyper-V上の第2世代の仮想マシンです。 新規に導入するので、「Custom: Install Windows only (advanced)」を選択します。 ちゃんとディスクが見えました！ 高速セッティングとカスタマイズがありますね。 高速セッティングを選んでしまえばすごく楽ちんですが…、せっかくなのでどんな設定ができるのかをみるためにカスタマイズを選択してみます。 位置情報をMicrosoftに送信する…という設定がちょっと気になるところですね。 規定値がオフになっているのが良心的です。 インストールできました！ メディアを変更してからは、実質10分程度でインストールが完了しました。 色々いじっていきたいと思います。 2015/10/07追記 当初タイトルが「Windows 10 Technical Preview を Surface 3 上のHyper-Vにインストールする 再挑戦」となっておりましたが、すいません。Surface 3ではなく、Surface Pro 3でした。失礼しました。

Windows 10 Technical Previewが出ましたね。私の誕生日を祝うように…。(10月1日産まれでございます。) すぐに評価に取り掛かりたかったのですが少々遅くなってしまいましたが、メインで使用しているSurface Pro 3上で動いているWindows 8.1 EnterpriseにHyper-Vの機能を有効にし、その上で仮想マシンとしてセットアップしようとしていますが、まだインストールできておりません…！ですが、とりあえずここまでのところを記録しておきます。 まずはHyper-Vの有効化。 Hyper-V有効化後は再起動が必要です。 再起動後、私の環境ではマウスポインタが表示されなくなるというトラブルがおきました。何度かマウスデバイスをデバイスマネージャーで削除した上で、再起動することを繰り返すと、きちんと表示されるようになりました。 さて、Hyper-Vを有効にしたのでHyper-V管理ツールが追加されました。 Hyper-Vマネージャーを起動します。 評価とはいえ外部とネットワーク的に接続したいので、仮想スイッチマネージャーで外部仮想スイッチを作成します。 「外部」で仮想スイッチを作成します。 「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」のチェックをつけておきます。 ※この辺りの外部、内部、プライベート等の意味がわからない方は拙著「Windows****インフラ管理者入門」を読んでいただければと思います！(宣伝) 仮想マシンを作成していきます。 第2世代にしておきました。 8GBのメモリを搭載しているので、半分を割り当ててみました。Windows 10 TP上でずっと暮らせるようならもっと割り当てたいと思っています。 ダウンロードしたWindows 10 TPのisoファイルを指定します。 さっそく仮想マシンを起動してインストール…と思ったら、仮想マシンが起動しませんでした…。 そもそもISOファイルのダウンロードに失敗していたようなので、ダウンロードをやり直しました。 その上で再度起動すると…以下のようにきちんとブート出来ませんでした。 第2世代で構成したのがうまくいかない原因の気がするので、第1世代に変更します。 作成後に変更はできないので、削除して再作成をしました。 これによってきちんと起動してきました。 日本語版は無いので、英語でインストールしつつ、日本のタイムゾーン、IMEと日本語キーボードレイアウトで設定します。 インストールは始まりましたが、さっそく、ドライバが無い…というメッセージが。 HDDが見えてきませんでした。 この現象はWindows 10でも、Windows 10 Serverでも同じでした。Hyper-Vの第一世代のディスクコントローラーのドライバが入っていないなんていうことがあり得るのでしょうか？ちょっと不思議です…。 http://answers.microsoft.com/en-us/windows/forum/windows_tp-winipp/unable-to-install-technical-preview-error-driver/60d9c6e8-203e-4cbf-8a05-577d4328c1f2 あちこちで同じようにドライバが入っておらずインストールできない現象は出ているようです。Technical Previewなのだから当たり前ではあるのですが。 ちなみにこの状況はWindows 10 Server Technical Previewのインストーラーでも同じでした。 ...

SCVMMで新規に仮想マシンを展開することができない事象が発生しました。 この評価時のメッセージのみからでは原因がよくわかりませんでした。タスクIDからメッセージを追うには以下のようにSQLサーバーのテーブルを直接覗く必要があるようです。 - [Task IDs in VMM 2012](http://social.technet.microsoft.com/Forums/systemcenter/en-US/8692629f-250e-47c0-b7e7-3d709402e3e3/task-ids-in-vmm-2012?forum=virtualmachinemanager) 今回の場合は新規に仮想マシンを展開しようとした時の評価結果をきちんと見たいだけなので以下のようにしてGet-SCVMHostRatingコマンドレットの結果を確認しました。 Get-SCVMHostRating -Cloud (Get-SCCloud)[0] -VM (Get-SCVirtualMachine)[0] 結果以下の様なメッセージでした。 VMHost : xxxxxxxx Cloud : xxx Cloud Rating : 0 ZeroRatingReasonList : {利用できるメモリが不足しています。ホストのメモリ合計は 0 MB です。既存および新しいバ ーチャル マシンが使用できるメモリ残量は 0 MB です。評価時のメモリ残量は 0 MB で、バー チャル マシンにより要求されたメモリ容量は 4160 MB でした。} メモリが足りないのが原因のようですが?でも、OS的にはまだメモリに余裕はある状況でした。実際にHyper-Vマネージャーからは新規に仮想マシンを作成し、その仮想マシンを起動することも出来る状態です。つまり、SCVMMがどのようにメモリを計算し、どのように「メモリが足りない」と判断しているのかが鍵になります。 調べた所、以下の記事にSCVMMの計算ロジックが書かれていました。 - [System Center 2012 - VMM Cluster Reserve Calculations - System Center: Virtual Machine Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/scvmm/archive/2012/03/27/system-center-2012-vmm-cluster-reserve-calculations.aspx) SCVMMの考え方としては ...

矢継ぎ早に新サービスが登場し続けるのでついていくのも大変な今日このごろですね。ですので、概要把握を素早くできて、もっと深く情報を得る必要があるかどうかの判断ができるレベルの情報が非常に貴重になってきていると思います。そんな中、Hyper-V Recovery Managerの概要把握にピッタリの情報があったので紹介です。 - [#MVPBUZZ CloudOS Roadshow : Microsoft Hyper-V Recovery Manager in #WindowsAzure #Hyperv #SCVMM | mountainss SystemCenter Blog](http://mountainss.wordpress.com/2014/03/12/mvpbuzz-cloudos-roadshow-microsoft-hyper-v-recovery-manager-in-windowsazure-hyperv-scvmm/) SCVMMとHyper-V Recovery Managerとで通信してメタデータ(仮想マシン一覧や稼働状況等)を同期し、必要に応じてAzure側からのキックで切り替えが可能というわけですね。 DR環境を構築して、拠点全体が使用不能になるようなシナリオや拠点間の通信が断絶するようなシナリオまで含めて自動的にサービス継続しようとすると、どうしても2拠点では実装できず、独立した3拠点目が必要になってきます。この点でそこをAzureにかぎらずPublic Cloudでおさえるという方向性はありなんだろうなと思います。 本来であれば複製先をAzureに指定できて、シームレスにAzureに複製できちゃえばいいのですが…、そういう形になるまでにはVHDX形式対応含めてまだまだ課題があるのだと推測します。

ずっとまえに書いたブログの下書きが残ったままでもったいないので公開しちゃいます。Windows Server 2012の検証環境で複数セグメントをネットワーク管理者の手を煩わせずに作りたくてVyattaを使っています。かなり簡単にお手軽にルーターを構築できるので助かってます。2013年6月ごろの手順ですが、今でもほぼ変わっていないだろうと思います。 ダウンロード - Download Open Source Vyatta Core Releases | Vyatta.org Community [**http://www.vyatta.org/downloads**](http://www.vyatta.org/downloads) 新規仮想マシンを作成してISOファイルをマウントする。 仮想マシンを電源ONして、コンソールを開く。 id: vyatta, password: vyattaでログイン install systemを実行 ディスクは1つしか接続していなかったのに、なぜかディスクが2つ見つかり、ミラーにするかと聞かれて困惑する。とりあえずNoと答えておく。 あとは、基本的に全部規定の回答でインストール。特に迷うところもありませんでした。 Windows Server 2012の統合当初は色々とネットワーク周りで問題があったようだが、2013/06/20現在では特になんの問題もなく(統合)ネットワークアダプタが認識されました。楽でいいですね。 今回まず2つのネットワークをルーティングしたかったので、NICを2つ接続しています。 ネットワーク設定をするために、どちらがどちらのネットワークに接続されているのかを知る必要があります。色々方法はあると思いますが、私は動的に設定されたMACアドレスを確認しました。 vyatta側のMACアドレスはshow interfacesコマンドで確認出来ます。 set interfaces ethernetコマンドでアドレスを設定します。 その後、commitで反映、saveで設定を保存するします。これでOKです。 なお、使っている中でNICのMACアドレスが意図せず変更され違うNICとして認識されてしまい構成が反映されないことがありました。これを防ぐにはMACアドレスが動的に設定されたあとで、同じ値を静的に登録しておくのが良いのでは無いかと思います。 構成する上では以下の記事が非常に参考になりました。 - 高機能なLinuxベースのソフトウェアルーター「Vyatta」を使う - さくらのナレッジ [**http://knowledge.sakura.ad.jp/tech/278/**](http://knowledge.sakura.ad.jp/tech/278/)

先日とあるセミナーで教えてもらった以下の富士通さんが出しているドキュメントの内容がよかったです。 - [Hyper-V よくある失敗集](http://jp.fujitsu.com/platform/server/primergy/technical/construct/pdf/win2008r2-hyperv-note.pdf) Hyper-Vのよくある問題が2008から2012R2まで色々まとまっています。一通り目を通しておくとよいと思います。 このドキュメントに限らず、富士通さんが出している技術文章は色々とクオリティの高いものがありますので、しばしばお世話になってます。

Hyper-Vクラスタ上の高可用性のホストが開始中で1%のままフリーズしてしまいました。数時間放おっておいても状況が変化しません。 200台強あるうちの1台だけの現象です。 Hyper-V: Virtual Machines Freeze at 10% When Starting Up - Premier Field Engineering - Site Home - TechNet Blogs http://blogs.technet.com/b/mspfe/archive/2013/03/18/hyper-v-virtual-machines-freeze-at-10-when-starting-up.aspx なるほど。ネットワークアダプターの構成がおかしいのが原因であるようです。 高可用性の仮想マシンなので、フェールオーバーしようと再起動しようとクラスタが何度でもサーバーをすぐに起動させようとしてしまうので、スタートアップの優先順位を「自動開始しない」に設定したうえでしばらく待っていると「失敗」となり、設定変更～正常起動が行えました。

メンテナンス中にトラブルがあってかなり無駄に時間を使ってしまったので反省も兼ねてメモしておきます。 Hyper-Vクラスタで予備ノードが無いテスト系のノードにhotfixを適用して再起動する作業をしていました。再起動を実行した所…Remote Desktopからはすぐにログオフさせられたもののいつまでたってもシャットダウンしない状況になってしまいました。結局起きていたことは以下の様なことでした。 - Hyper-Vのホストなので、稼働していた仮想マシンの状態を保存 - iSCSI接続に障害を併発しており(そもそもその対応のメンテナンスだったのですが)、ディスクへの書き込みパフォーマンスが出ていなくて時間がかかっていた - さらにディスクが見えなくなりHyper-V Virtual Machine Managementサービスが異常停止 - Hyper-V Virtual Machine Managementサービスはしばらくして自動的に開始 - その間にClusterサービスが停止中のままになる(デッドロック?) 結局Remote PowerShellでは接続できたので、Enter-PSSessionで該当ノードに入り、clusterサービスの実体であるclussvcを殺すことで再起動処理が先に進みました。 get-process clussvc | kill シャットダウンプロセスが進まない場合には、停止処理中で止まってしまっているサービスを見つけてそのプロセスを切るというのはすぐに思いつけないといけないですね。今日はこれに気がつくまでに1時間くらいかかってしまいました。反省です。また、そもそもHyper-Vクラスタでは予備ノードが無いとメンテナンスが非常に厳しいですね。

業務で社内にSystem Centerを使ったプライベートクラウドを作成し、エンジニアが自由に検証サーバーを作成できるセルフサービスの仕組みをSCACを使って提供しているのですが、実際に利用してもらうとすぐに「コンソールに接続できない」という問題が発生してしまいました。SCACを使ってWebブラウザから簡単に利用できなければ意味が無いのに、コンソールが開かないのでは全く意味がありません。情報があまりなく、解決まで結構時間がかかってしまったのですが、先日やっと解決出来たのでこちらでも紹介しておきます。 現象 現状は以下です。 - エンドユーザーがSCACから仮想マシンを作成し、コンソールを開くと、接続できず、以下のようになる。 - 必ず接続できないわけではなく、接続できる場合もある。接続できない場合もある。何に依存しているのかは不明。法則性は無いように見える。 さらに調査を進めていくとSCACだけの現象では無いことがわかりました。 - SCVMMのコンソールをエンドユーザーが自身の端末に導入し、そこからコンソールを開いても同じ現象が発生する(場合が多い)。 - SCVMMのVirtualMachineManager.exeを直接利用しても、Hyper-Vのvmconnect.exeを直接利用しても結果は同じ。 原因 色々と情報を探した所、結局これはHyper-Vに対しての権限が足りないことが原因で発生していました。説明と回避方法が以下のブログで紹介されていました。 - [Allowing non-Administrators to control Hyper-V - Ben Armstrong - Site Home - MSDN Blogs](http://blogs.msdn.com/b/virtual_pc_guy/archive/2008/01/17/allowing-non-administrators-to-control-hyper-v.aspx) 上記の記事によると、そもそも管理者以外はHyper-Vコンソールは利用できないとのことです。でもそうだとすると、エンドユーザーは100%の確立でコンソールに接続できないはずなので今回発生している事象とは異なります。しかし、回避策は今回の事象でも有効でした。 回避策 承認マネージャーにて権限を割り当ててあげることで問題を回避出来ました。以下の手順を全てのHyper-Vホスト上で実施する必要があります。 「ファイル名を指定して実行」から「mmc」を起動します。 mmcにて承認マネージャーを追加します。 承認ストアとして「C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml」を開きます。 Administratorの役割に、コンソールを開く権限が必要なユーザー、グループを追加します。(※Administratorでは権限が強すぎるかもしれません。その場合役割自体を定義するのだと思われます(未検証)。) ここまでの操作でXMLファイルには自動的に保存が完了しています。mmcを閉じる際に以下のように質問されますが、どのように操作しても目的の操作には影響有りません。 これでどのコンソールからでもきちんと接続が可能です。これでやっとまともに利用できます。 接続形態 ところで、そもそもこれらのコンソールはどのような接続形態になっているのかわかっていなかったのですが、調べた所以下の説明が見つかりました。 - [How Virtual Machine Manager Administrator Console uses VirtualMachineViewer.exe - Virtual Machine Management - Site Home - TechNet Blogs](http://blogs.technet.com/b/m2/archive/2008/06/02/how-virtual-machine-manager-administrator-console-uses-virtualmachineviewer-exe.aspx) これによると、直接仮想マシンに接続するのではなく、RDPを使ってHyper-Vホストに接続し、そこからコンソールに接続する流れになっているとのこと。Remote Desktop Serviceも入っていないのに通常のRDPの2セッションの上限は超えられるし、Remote Appのようにアプリケーションの画面のみ表示しているようなイメージで動作もしているし…、なかなかおもしろいですね。 ...

Hyper-V Replicaの設計支援ツールが公開されています。Hyper-V Replicaはまだまだ本番導入事例は少なく、設計のための情報も少ないですからこういったツールの提供はありがたいですね。 私はビジネス継続性、ディザスタリカバリ、テスト目的などHyper-V Replicaは色々と使いでがある技術だと思ってます。 - [ Capacity Planner for Hyper-V Replica ](http://www.microsoft.com/en-us/download/details.aspx?id=39057&ocid=aff-n-we-loc--ITPRO40886&WT.mc_id=aff-n-we-loc--ITPRO40886)

前回の記事で見たように、Hyper-VクラスタのCSVに配置した仮想マシンはHA構成にするしか(サポートされる)選択肢がありません。 - [Hyper-Vクラスタの高可用性のオンオフと仮想ディスクの配置先の話。(高可用性にしないとCSVにディスクを配置できない) | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/06/12/hyper-v%e3%82%af%e3%83%a9%e3%82%b9%e3%82%bf%e3%81%ae%e9%ab%98%e5%8f%af%e7%94%a8%e6%80%a7%e3%81%ae%e3%82%aa%e3%83%b3%e3%82%aa%e3%83%95%e3%81%a8%e4%bb%ae%e6%83%b3%e3%83%87%e3%82%a3%e3%82%b9%e3%82%af/) きちんとCSVで共有するディスク領域と、個別のノードに配置するためのディスク領域を計算し、割り当ててあげればよいわけですが、個別に割り当てる…という話になるとどうしても容量に偏りが出たり、構成が複雑になったりなど少々気乗りしない感じです。全部HAにして良いのであればこういう苦労はしなくていいわけで、そういう構成が現実的に取れるのかどうか確認してみます。 まず、気になるのは製品自体でクラスタ構成を組むようなものです。 Hyper-VのHAとExchange Server 2010以降のDAGの組み合わせはExchange Server 2010 SP1以降ではサポートされるとのこと。 - [http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx](http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx) Exchange Server 2013もOKです。 Exchange サーバーの仮想マシン (データベース可用性グループつまり DAG の一部となっている Exchange メールボックス仮想マシンなど) は、移動されたりオフラインになったりしたときにディスクの状態を保存または復元しないように仮想マシンが構成されている限り、ホストベースのフェールオーバー クラスター化および移行テクノロジと組み合わせることが可能です。ハイパーバイザー レベルで発生するフェールオーバー動作はすべて、フェールオーバー先のノードで仮想マシンがアクティブになったときに、コールド ブートする必要があります。計画されたすべての移行は、シャットダウンしてコールド ブートするか、Hyper-V ライブ移行のような技術を利用したオンライン移行になる必要があります。仮想マシンのハイパーバイザー移行はハイパーバイザー ベンダーがサポートするため、ハイパーバイザー ベンダーが Exchange 仮想マシンの移行をテストしており、サポートすることを確認する必要があります。Microsoft は、これらの仮想マシンの Hyper-V ライブ移行をサポートしています。 Exchange 2013 の仮想化: Exchange 2013 Help http://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.150).aspx その他は、できるけれどもやる必要ある？やらないほうが良くない？という情報が見つかります。 - Hyper-V2.0のホストクラスタとゲストクラスタの共存は可能でしょうか [http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/](http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/) 今回改めて調べるまでは私も上記のような認識だったのですが、そこよりはサポートする方向に年月がたって傾いてきている印象です。 NLBはどうでしょうか？…と思って結構頑張って調べたのですが、ズバリ言及している情報を見つけることができませんでした。私は30分ほど検索して見つからない場合には「無い」ものとして扱うことにしており、それ以上探すことはしません。Googleさんのインデックス能力はそれだけ高いと思っています。 一応以下の記事では高可用性のVMにNBLを追加で構成することのメリットに言及しているので、「あり」ということのように受け取れます。 NLB の機能によってフェールオーバー クラスターのノードになっている VM では、VM のメンテナンス中でもワークロードで高可用性が実現されます。VM で更新やなんらかのメンテナンスが必要な場合は、その VM のワークロードを同じホストの別の VM に転送したり、すべてを別のホストに転送したりすることができます。 仮想化: Hyper-V と高可用性 http://technet.microsoft.com/ja-jp/magazine/hh127064.aspx 動作しない理由も特にないので、普通に動作するものと思われます。テストして確認してみようと思います。 ...

Windows Server 2012で作成したHyper-Vクラスタが、いつからかきちんと動作しない状態になってしまっていました。 発生していた現象は以下のようなものです。 - 仮想マシンを起動しようとすると「コンピューター'xxxxx'のメモリまたはディスク領域が不足しているため、要求された操作の実行に失敗しました。」とのエラーで仮想マシンの起動ジョブに失敗する。しかし実際には起動できている。 - その他の操作も色々な場面で不規則に失敗したり、成功したりする。 - 仮想マシンのライブマイグレーションが実行できない。フェールオーバークラスタマネージャーからは実施できる。 - 仮想マシンの設定が開けない。SCVMMからも、フェールオーバークラスタマネージャーからも、Hyper-Vマネージャーからも同様。 クラスタノードを削除したり、エージェントを再インストールしたりなど色々と試したのですが改善しませんでした。結局、Webを検索し以下のフォーラムの情報を見つけました。 - [クラスタ共有ボリュームへの仮想マシン作成](http://social.technet.microsoft.com/Forums/ja-JP/winserver8/thread/b8207e48-8966-4941-9aa1-6882d85f6716) 原因はフォーラムでの情報と同じように物理ホストにMcAfee VirusScan Enterpriseを導入していたことでした。 VirusScan(オンアクセススキャン)を停止させることで問題なく動作するようになりました。 やはりWindows Server 2012への各種ソフトウエアの対応はまだまだですね。基本的な構成でも事前の確認が必要なようです。

前回Hyper-Vの外部ネットワークについて解説しました。今回はHyper-Vの内部ネットワークとプライベートネットワークについて解説します。とはいっても、外部ネットワークが一番わかりずらいのでそれがわかってしまえばこちらは簡単です。 まず、下図がNICが1つだけ搭載されているサーバーにHyper-Vを有効化しただけの状態です。 内部ネットワーク ここに対して内部ネットワークを有効にすると以下のようになります。 内部ネットワーク用の仮想スイッチが内部的に作成され、それに接続された仮想NICが親パーティションに見えてきます。このスイッチに対してはもちろん子パーティションのホストも接続出来ます。 このように外部には出ていかないHyper-V内の内部的なネットワークが作成できるようになるわけです。これが内部ネットワークです。 プライベートネットワーク プライベートネットワークは内部ネットワークから更に親パーティションの仮想NICでの接続を省いたものです。 子パーティションが1台だとあまり存在している意味が無いですね。2台書いてみます。 このように子パーティション同士の接続のみが行えるスイッチになるわけです。 ここまで理解上で上の設定画面を見ると・・・・どうでしょうか意味がわかりますでしょうか？個人的にはなぜ外部ネットワークの時には親パーティションへの仮想NIC作成がチェックボックスなのに、内部では違うのか理解に苦しみます。こんな感じのGUIのほうが直感的じゃないですかね？ もっと言うと文言も変更したいです。 こんなかんじでどうでしょうか。どうでしょうかって言われても困りますね。ごめんなさい・・・。

Hyper-Vを一番はじめに触ってまず混乱するのがネットワーク周り、特に外部ネットワークの部分だと思います。図を用いながらなるべくわかりやすくなるように解説してみたいと思います。 Hyper-V導入前 まず、単純に1つのNICを持ったサーバーがあります。 このように、単純にサーバーが1つあり、NICが1枚ついており、単純に物理スイッチのポートに刺さっているだけです。何も難しいことはありませんね。この物理NIC1には普通にTCP/IPの設定がなされることになります。 Hyper-V導入 Hyper-Vの役割を導入します。この状態では見た目上は目立った変更はありません。NICの状態にも図にも変化無しとして良いと思います。ですが、私はHyper-Vにおいては「親パーティションと子パーティションは同じレベルで存在している」という捉え方をするほうが理解しやすいと思っています。なので、以下のように書き換えて理解することをおすすめします。 上記の図で言いたいことはHyper-Vの役割を有効にした時点で親パーティションも物理サーバーとは切り離されて、仮想化されているということです。ただ、まだ何も特別な設定をしていないので、物理NIC1は親パーティションに直接見えている状態です。 外部ネットワークの追加 ここでHyper-Vの仮想スイッチマネージャーで外部スイッチを新規に作成します。 すると、以下の様に仮想NICが親パーティションに見えてきます。 この状態は図で表すと以下のような状態です。 もともとの物理NICだったもの(画像では名前が「イーサネット」になっているもの)は、プロパティを見ると以下の状態となっており、仮想スイッチとして動作していることがわかります。 #個人的にはアイコンも変更すべきだと思うのですが。 新しく出来たvEthernetという名前のNICが仮想NICであり、親パーティションのメインのNICになったものです。TCP/IPのプロパティはこちらに引き継がれています。これは、下記の図の「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」のチェックがONになっているために生成されています。 つまり「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」=「親パーティションに仮想NICを1つ追加して、それをこの外部ネットワークとつながる仮想スイッチに接続する」という意味なわけです。このチェックを外せば親パーティションから仮想NIC1が消えることになります。 そして、生成された仮想スイッチはスイッチなわけですから複数のNICが接続できます。子パーティションを2つほど追加し、直接外部ネットワークに接続する様子は以下のようになります。 子パーティションは仮想NICを作成し、それを仮想スイッチに接続します。これは論理的には以下のように接続されていることと全く同じです。 物理ホストに2つNICがある場合 物理ホストには、ホスト管理専用のNICを設けることが推奨されています。これまでの図のように仮想スイッチ経由で仮想NICをもち、それをそのまま管理用にすることもできますが、トラブルが発生した時などの切り分けが難しくなるからですね。その場合誤ってやってしまいがちなのが以下のような構成です。 → 左がHyper-Vを有効にしただけの状態。右側がNIC2を外部スイッチにし、子パーティションを1つ追加し外部スイッチに接続している状態です。この時やってはいけないのは、親パーティションと子パーティションを同じセグメントに接続することです。親パーティションに注目した時に、物理NIC1と仮想NIC1が同じセグメントに接続してしまっていると、通信はどちらから発信されるかわかりません。この結果通信が出来たり出来なかったり不安定な状態になってしまいます。この間違いはHyper-V初心者はほぼ全員やるんじゃないかというくらいメジャーな構成ミスですので特に注意してください。 この状態を正すにはHyper-Vマネージャーにて仮想スイッチの設定から「管理オペレーティング・システムにこのネットワークアダプターの共有を許可する」のチェックを外せばよいです。すると以下のようになります。 親パーティションには物理NICが1つのみ割り当てられており、管理用に使用出来ますし、子パーティションはきちんと仮想スイッチ経由で外部ネットワークにアクセスできるようになっています。 これがHyper-Vの外部ネットワークの基本です。

Hyper-V.nuにてLiveMigration用のKerberosの委任設定が、サービス自体が存在せず行えないという事例が紹介されていました。 - [Microsoft Virtual System Migration Service–Service is missing ](http://www.hyper-v.nu/archives/pnoorderijk/2013/03/microsoft-virtual-system-migration-serviceservice-is-missing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%253A+hyper-v-nu+%2528Hyper-v.nu%2529#utm_source=feed&utm_medium=feed&utm_campaign=feed) 回避策としては以下になります。 - ドメインに参加してからHyper-Vロールを有効にする - 個別にSPNを設定する ところで、Kerberosの委任設定画面に出てこない、ということと、SPNの存在がひもずいているというのは言われてみれば当たり前なのですが気がついていませんでいた。Kerberos周りのトラブルシュート時には一般的に言えることですね。

ウイルス対策ソフトはどのサーバーにも基本的には導入されると思います。その上で必要な箇所に除外設定を行うことになります。主要なサーバー製品/役割の除外設定を集めてみました。まだ全部は集まっていませんので情報があったら追記していきます。 SCOM 2012 管理サーバー - ~:\Program Files\System Center 2012\Operations Manager\Server\Health Service State\Health Service Store - *.EDB, *.CHK, *.LOG SCOM 2012 エージェント - %ProgramFiles%\System Center Operations Manager\Agent\Health Service State\Health Service Store DPM 2012 ・\XSD フォルダー ・\Temp\MTA フォルダー ・%ProgramFiles%\Microsoft Data Protection Manager\DPM\bin フォルダーの dpmra.exe ・%ProgramFiles%\Microsoft　DPM\DPM\Volumes\Replica フォルダー ・%windir%\Microsoft.net\Framework\v2.0.50727 フォルダーの csc.exe <SQL Server 2012 の場合> ・%ProgramFiles%\Microsoft SQL Server\MSSQL11 < インスタンス名 > \MSSQL\Binn フォルダーの SQLServr.exe ・%ProgramFiles%\Microsoft SQL Server\MSRS11 < インスタンス名 > \Reporting Services\ReportServer\Bin フォルダーの ReportingServicesService.exe ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SystemCenter2012 ウイルス対策ソフトの除外設定 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/25/systemcenter2012-%E3%82%A6%E3%82%A4%E3%83%AB%E3%82%B9%E5%AF%BE%E7%AD%96%E3%82%BD%E3%83%95%E3%83%88%E3%81%AE%E9%99%A4%E5%A4%96%E8%A8%AD%E5%AE%9A/)

Dave’s blogでHyper-V Replica設定時のKerberosエラーに関してのトラブルシュートの記録が書かれていました。原因もさることながらトラブルシュートの方法が参考になりました。 The Case of the Unexplained Windows Server 2012 Replica Kerberos Error : 0x8009030C 0x00002EFE - Dave’s blog - Site Home - TechNet Blogs 発生したエラーの直接の原因はローカルセキュリティポリシーで「ネットワーク経由でのアクセス」が規定から変更されており、アクセス権がなかったから…ということだったそうです。そこに至るまでに調査したのは以下の項目。 - イベントログ(アプリケーション、システム) - Microsoft Exchange Server Error Code Look-up toolでのエラーコードの調査 - SPNの確認 - Kerberosの委任設定の確認 - ADとの接続確認 - Kerberosチケット確認 - パケットキャプチャ - プロセスモニタ - logman.exeでのkerberosイベント確認 - イベントログ(セキュリティ) 結局、はじめからセキュリティ監査ログを見ていれば…という結論にはなっていますが調査項目は参考になりますね。