私が参加しているプロジェクトでサーバーのログをログ集約サーバーに転送することになりました。
syslogの転送先サーバーはすでに構築されているので、こちらの作業はsyslogを転送する設定を入れるだけですが、勉強のために転送の設定についても調べてみました。
まずはsyslogについて。
syslogはsendmailの一部として開発されましたが、便利だと言うことでUNIX/Linux等のデファクトスタンダードのロギング方式となりました。
syslogが使用するポートは514/udpなのでデータの保証はないが、TCPでの実装版であるrsyslogがあります。使用するには"/etc/services"に"syslog 514/udp"のエントリが必要です(RHEL5ではデフォルトで登録されている)。このエントリが無い場合、ポートを開けることができないのでデーモンは終了します。
ポートがない場合

ポートがある場合

・転送先サーバー設定
"/etc/sysconfig"にある"syslog"ファイルの"SYSLOGD_OPTIONS"を元の"-m 0"から"-m 0 -r"に修正します。また、"/etc/init.d"にも"syslog"ファイルがあるので同じように"SYSLOGD_OPTIONS"を修正します。
-mオプションは後ろの数字の時間(分)ごとにタイムスタンプを記録させます。"-- MARK --"という文字列がログの代わりに記録されます。ここでは"0"なのでこの機能は使わない設定になっています。
-rオプションはネットワークからのメッセージを受信する機能を有効にします。ver1.3以降のデフォルト設定はオフになっており、オプションをつけない限り受信しません。
以上の設定を終えたらsyslogデーモンを再起動します。

・転送元サーバー設定
"syslog.conf"の設定に"@"で始まるIPアドレス/ホスト名を追加します。
(ホスト名の名前解決ができない場合には10回問い合わせをした後、エラーメッセージを出力します。RHEL5ではエラーメッセージの出力が確認できませんでした)。今後の保守性を高めるためにもhostsに記述されているホスト名を使用する方が良いです。
全くすべてのログを転送するのであれば"*.* @hostname"と記述します。今回は通常"/var/log/messages"と"/var/log/secure"に書き込まれるレベルを転送することにしました。
以上の設定を終えたらsyslogデーモンを再起動します。再起動し次第、ログが転送され始めます。

今回設定した際にログ転送先サーバーのファイアウォールのポートを開けるのを忘れていました。
ホストLINUX02でログインしてもログが記録されません。
ログイン


tcpdumpを使って、ログが転送されているのかを確認しました。プロトコルはudpで宛先ポートが514の通信を表示します。

ログ転送先のポートが開いているかを確認。514ポート(下図ではsyslogと表記)自体は開いてリスン状態になっています。

ここまで来たら後はファイアウォールが怪しいです。ファイアウォールでポートをふさいでいないか確認したところ、見事にふさいでおりました。

"system-config-securitylevel"コマンドで"514/udp"ポートを開きます。

注意書きに「"サービス名:プロトコル"で記述せよ」とあったので"syslog:udp"と入力しました。


ファイアウォールのポートを開き、ホストLINUX02でログインしたところ、ログが記録されました。転送先サーバーのログには下記の様にホスト名が表示され、どこのサーバーで出力されたログかがわかるようになっています。転送されたログのホスト名が小文字なのは仕様なのでしょうか?

転送先サーバーでログがどのように振り分けて記録されるのかについても確認しました。
転送先サーバーの設定は認証についてのログを"/var/log/secure"だけでなく"/var/log/messages"にも記録するようにしてありました。

これをデフォルト通り"/var/log/secure"のみに書き込むように変更しました。

すると、最初にログの転送を確認したときには"/var/log/messages"にも記録されていた認証についてのログが"/var/log/secure"のみに記録されるようになりました。

ログの書き分けルールは転送先サーバーの設定に従うと言うことがわかりました。
RHEL5で確認してあります。
syslogの転送先サーバーはすでに構築されているので、こちらの作業はsyslogを転送する設定を入れるだけですが、勉強のために転送の設定についても調べてみました。
まずはsyslogについて。
syslogはsendmailの一部として開発されましたが、便利だと言うことでUNIX/Linux等のデファクトスタンダードのロギング方式となりました。
syslogが使用するポートは514/udpなのでデータの保証はないが、TCPでの実装版であるrsyslogがあります。使用するには"/etc/services"に"syslog 514/udp"のエントリが必要です(RHEL5ではデフォルトで登録されている)。このエントリが無い場合、ポートを開けることができないのでデーモンは終了します。
ポートがない場合

ポートがある場合

・転送先サーバー設定
"/etc/sysconfig"にある"syslog"ファイルの"SYSLOGD_OPTIONS"を元の"-m 0"から"-m 0 -r"に修正します。また、"/etc/init.d"にも"syslog"ファイルがあるので同じように"SYSLOGD_OPTIONS"を修正します。
-mオプションは後ろの数字の時間(分)ごとにタイムスタンプを記録させます。"-- MARK --"という文字列がログの代わりに記録されます。ここでは"0"なのでこの機能は使わない設定になっています。
-rオプションはネットワークからのメッセージを受信する機能を有効にします。ver1.3以降のデフォルト設定はオフになっており、オプションをつけない限り受信しません。
以上の設定を終えたらsyslogデーモンを再起動します。

・転送元サーバー設定
"syslog.conf"の設定に"@"で始まるIPアドレス/ホスト名を追加します。
(ホスト名の名前解決ができない場合には10回問い合わせをした後、エラーメッセージを出力します。RHEL5ではエラーメッセージの出力が確認できませんでした)。今後の保守性を高めるためにもhostsに記述されているホスト名を使用する方が良いです。
全くすべてのログを転送するのであれば"*.* @hostname"と記述します。今回は通常"/var/log/messages"と"/var/log/secure"に書き込まれるレベルを転送することにしました。
以上の設定を終えたらsyslogデーモンを再起動します。再起動し次第、ログが転送され始めます。

今回設定した際にログ転送先サーバーのファイアウォールのポートを開けるのを忘れていました。
ホストLINUX02でログインしてもログが記録されません。
ログイン


tcpdumpを使って、ログが転送されているのかを確認しました。プロトコルはudpで宛先ポートが514の通信を表示します。

ログ転送先のポートが開いているかを確認。514ポート(下図ではsyslogと表記)自体は開いてリスン状態になっています。

ここまで来たら後はファイアウォールが怪しいです。ファイアウォールでポートをふさいでいないか確認したところ、見事にふさいでおりました。

"system-config-securitylevel"コマンドで"514/udp"ポートを開きます。

注意書きに「"サービス名:プロトコル"で記述せよ」とあったので"syslog:udp"と入力しました。


ファイアウォールのポートを開き、ホストLINUX02でログインしたところ、ログが記録されました。転送先サーバーのログには下記の様にホスト名が表示され、どこのサーバーで出力されたログかがわかるようになっています。転送されたログのホスト名が小文字なのは仕様なのでしょうか?

転送先サーバーでログがどのように振り分けて記録されるのかについても確認しました。
転送先サーバーの設定は認証についてのログを"/var/log/secure"だけでなく"/var/log/messages"にも記録するようにしてありました。

これをデフォルト通り"/var/log/secure"のみに書き込むように変更しました。

すると、最初にログの転送を確認したときには"/var/log/messages"にも記録されていた認証についてのログが"/var/log/secure"のみに記録されるようになりました。

ログの書き分けルールは転送先サーバーの設定に従うと言うことがわかりました。
RHEL5で確認してあります。
リモートでのイベントビューアー確認~その一 接続でリモートからイベントビューアーを確認するとサーバーの役割についての確認が取れませんでした。
調べてみたところ、WindowsのクライアントOSからサーバーOSを確認する場合、「リモート サーバー管理ツール」をクライアントにインストールする必要があります。インストールすることにより、Windows Server 2008 R2、Windows Server 2008、Windows ServerR 2003 を実行しているコンピューターにインストールされた役割と機能を管理できるようになります。
この「リモート サーバー管理ツール」ですが、現在はVISTA/VISTA(64)/7の三種類がリリースされており、概要は下記の通りです。
・Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール
Windows Vista Business 64-bit edition; Windows Vista Enterprise 64-bit edition; Windows Vista Ultimate 64-bit edition
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows Vista 用 Microsoft リモート サーバー管理ツール
Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows 7 用のリモート サーバー管理ツール
Windows 7
Windows 7 用のリモート サーバー管理ツールは、Enterprise、Professional、Ultimate の各エディションの Windows 7 を実行しているコンピューターのみにインストールでき、管理対象となるサーバーにはインストールできません。
まずはリモートサーバー管理ツールをMicrosoftのページからダウンロードして、インストールします。




次に必要なツールを有効にします。
コントロールパネル -> プログラム -> Windowsの機能の有効化または無効化 -> リモートサーバー管理ツールから必要なツールのチェックボックスをオンにします。







プログラム一覧の管理ツールを開くと、先ほど追加したツールが追加されていることが確認できます。

Hyper-Vマネージャーを起動する前にいくつか準備をする必要があります。
まず、ファイアウォールの設定です。サーバー側もクライアント側も"Windows Management Instrumentation(WMI)"の規則を有効化します。
サーバー側




クライアント側




次に、サーバー側の設定で、サーバーマネージャーのトップページで「サーバーマネージャーのリモート管理の構成」というメニューがあるので「有効」に設定します。




最後に、クライアント側の設定で、dcomcnfgでCOMセキュリティを変更します。
dcomcnfgを検索・実行し、コンポーネントサービス -> コンピューター -> マイコンピューターと進み、右クリックからプロパティを開きます。COMセキュリティタブを開き、アクセス許可の「制限の編集」をクリック。ANONYMOUS LOGONのリモートアクセスを「許可」します。






これで設定は終了なので、Hyper-Vマネージャーを開くとサーバー上に構築されている仮想マシンが表示され、サーバー上にいるのと全く変わりなく管理することができるようになりました。



仮想マシンに接続しようとすると「お使いの資格情報は機能しませんでした」というメッセージとともにログインウィンドウが開きます。
これはWorkgroupで管理しているからかもしれません。要調査です。

ここで入力するユーザーはサーバー上のAdministrators権限を持っていなければいけないようです。権限を持っていない場合、下記のエラーが発生します。このエラーについても要調査です。

「MSDN Code Gallery」が参考になりました。
調べてみたところ、WindowsのクライアントOSからサーバーOSを確認する場合、「リモート サーバー管理ツール」をクライアントにインストールする必要があります。インストールすることにより、Windows Server 2008 R2、Windows Server 2008、Windows ServerR 2003 を実行しているコンピューターにインストールされた役割と機能を管理できるようになります。
この「リモート サーバー管理ツール」ですが、現在はVISTA/VISTA(64)/7の三種類がリリースされており、概要は下記の通りです。
・Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール
Windows Vista Business 64-bit edition; Windows Vista Enterprise 64-bit edition; Windows Vista Ultimate 64-bit edition
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows Vista 用 Microsoft リモート サーバー管理ツール
Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows 7 用のリモート サーバー管理ツール
Windows 7
Windows 7 用のリモート サーバー管理ツールは、Enterprise、Professional、Ultimate の各エディションの Windows 7 を実行しているコンピューターのみにインストールでき、管理対象となるサーバーにはインストールできません。
まずはリモートサーバー管理ツールをMicrosoftのページからダウンロードして、インストールします。




次に必要なツールを有効にします。
コントロールパネル -> プログラム -> Windowsの機能の有効化または無効化 -> リモートサーバー管理ツールから必要なツールのチェックボックスをオンにします。







プログラム一覧の管理ツールを開くと、先ほど追加したツールが追加されていることが確認できます。

Hyper-Vマネージャーを起動する前にいくつか準備をする必要があります。
まず、ファイアウォールの設定です。サーバー側もクライアント側も"Windows Management Instrumentation(WMI)"の規則を有効化します。
サーバー側




クライアント側




次に、サーバー側の設定で、サーバーマネージャーのトップページで「サーバーマネージャーのリモート管理の構成」というメニューがあるので「有効」に設定します。




最後に、クライアント側の設定で、dcomcnfgでCOMセキュリティを変更します。
dcomcnfgを検索・実行し、コンポーネントサービス -> コンピューター -> マイコンピューターと進み、右クリックからプロパティを開きます。COMセキュリティタブを開き、アクセス許可の「制限の編集」をクリック。ANONYMOUS LOGONのリモートアクセスを「許可」します。






これで設定は終了なので、Hyper-Vマネージャーを開くとサーバー上に構築されている仮想マシンが表示され、サーバー上にいるのと全く変わりなく管理することができるようになりました。



仮想マシンに接続しようとすると「お使いの資格情報は機能しませんでした」というメッセージとともにログインウィンドウが開きます。
これはWorkgroupで管理しているからかもしれません。要調査です。

ここで入力するユーザーはサーバー上のAdministrators権限を持っていなければいけないようです。権限を持っていない場合、下記のエラーが発生します。このエラーについても要調査です。

「MSDN Code Gallery」が参考になりました。
「Hyper-Vの構築~その五 仮想マシンのインストール(Red Hat Enterprise Linux 5.4)」でLinux IC (統合コンポーネント)v2.0をインストールしました。
しかし、2010年7月にLinux Integration Services v2.1がリリースされています。対応しているLinuxゲストOSは下記の6つです。
Linux Distributions (4コア)
SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3、5.4および5.5 (x86 Editionまたはx64 Edition)
さらに、v2.1ではインストール方法が変更されています。
注意点は下記の二点です。
・v2.1をインストールするには対象Linux OS上の"/usr/src/kernels/2.6.18-155.el5-i686"にカーネルがインストールされている必要があります。
・Software Developmentパッケージがインストールされている必要があります。
それではインストールしていきますが、新規インストールも旧バージョンからのアップグレードも手順は全く同じになります。ここではアップグレードした際のイメージを載せておきます。
まずはCDをマウントし、中身をすべて"/opt"以下の任意のディレクトリにコピーします(MSのドキュメントでは"/opt/linux_ic_v21_rtm2となっています)。

コピーしたらそのディレクトリへ移動し、"make"コマンドを実行します。

"make"が完了したら"make install"でインストールします。


インストールが完了したらLinuxを再起動します。
再起動後にsshで接続した図ですが、前回のログイン時刻と現在時刻が大きくずれています。これは、v2.1で追加されたホストOSとの時刻同期が動いているためです。インストールから1週間で3時間ほどずれています。

サーバーマネージャーで確認をすると、ステータスのところで「ハートビート」が「OK」になっています。Linux ICをインストールする前は「OFF」となっていました。

また、サーバーマネージャーからOSのシャットダウンをすることもできます。



これもv2.1からの新機能です。サポートLinuxゲストOSでも書いてありますが、複数コアのサポート等もv2.1から追加されています。詳細についてはMicrosoftのドキュメントを参照してください。
Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
しかし、2010年7月にLinux Integration Services v2.1がリリースされています。対応しているLinuxゲストOSは下記の6つです。
Linux Distributions (4コア)
SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3、5.4および5.5 (x86 Editionまたはx64 Edition)
さらに、v2.1ではインストール方法が変更されています。
注意点は下記の二点です。
・v2.1をインストールするには対象Linux OS上の"/usr/src/kernels/2.6.18-155.el5-i686"にカーネルがインストールされている必要があります。
・Software Developmentパッケージがインストールされている必要があります。
それではインストールしていきますが、新規インストールも旧バージョンからのアップグレードも手順は全く同じになります。ここではアップグレードした際のイメージを載せておきます。
まずはCDをマウントし、中身をすべて"/opt"以下の任意のディレクトリにコピーします(MSのドキュメントでは"/opt/linux_ic_v21_rtm2となっています)。

コピーしたらそのディレクトリへ移動し、"make"コマンドを実行します。

"make"が完了したら"make install"でインストールします。


インストールが完了したらLinuxを再起動します。
再起動後にsshで接続した図ですが、前回のログイン時刻と現在時刻が大きくずれています。これは、v2.1で追加されたホストOSとの時刻同期が動いているためです。インストールから1週間で3時間ほどずれています。

サーバーマネージャーで確認をすると、ステータスのところで「ハートビート」が「OK」になっています。Linux ICをインストールする前は「OFF」となっていました。

また、サーバーマネージャーからOSのシャットダウンをすることもできます。



これもv2.1からの新機能です。サポートLinuxゲストOSでも書いてありますが、複数コアのサポート等もv2.1から追加されています。詳細についてはMicrosoftのドキュメントを参照してください。
Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
「Hyper-Vの構築~その三 仮想マシンのインストール(Windows XP)」、「Hyper-Vの構築~その四 仮想マシンのインストール(Windows 7)」の二回にわたってゲストOSとしてWindows OSをインストールしましたが、今回はLinuxをインストールしてみます。
Linux Integration Services v2.0で対応していたLinuxゲストOSは下記の5つです(現在はv2.1がリリースされています)。
Linux Distributions (1コア)
SUSE Linux Enterprise Server 10 with Service Pack 2 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3および5.4 (x86 Editionまたはx64 Edition)
今回はまずRed Hat Enterprise Linux (RHEL) 5.4をインストールします。
Hyper-VでLinuxを稼働するためにはLinux IC (統合コンポーネント)をOSインストール後に導入する必要がありますので、あらかじめMicrosoftからダウンロードし、展開しておきます。
LinuxのインストールもWindowsと全く同じです。
インストール後にネットワークを確認すると、ネットワークアダプターが認識されていません。

Linux IC (統合コンポーネント)をインストールしますので、メディア -> DVDドライブ -> ディスクの挿入を選んで解凍したLinux IC (統合コンポーネント)のLinuxIC v2.iso(現時点)を指定します。


ディスクを挿入すると、最近のLinuxディストリビューションは自動的にマウントしてくれます。
コマンドラインからCDのマウント場所に移動(cd /media/CDROM)し"./setup.pl drivers"とコマンドを実行するとLinux ICのインストールが開始されます。



Linux ICのインストールが終了してからネットワークを確認すると、"seth0"というアダプターが認識されています。これで外部との通信ができるようになります。

リモートデスクトップでサーバーにログインし、Linuxの仮想マシンに接続してウィンドウをクリックすると、メッセージが表示されてしまいます。要調査です。

ただ、LinuxもWindowsの様にリモートデスクトップで接続することもできますし、teratermなどからSSHで接続することができますのでそれほど問題にはなることはないと思います。
次はv2.1での確認をしたいと思います。
Linux Integration Services v2.0で対応していたLinuxゲストOSは下記の5つです(現在はv2.1がリリースされています)。
Linux Distributions (1コア)
SUSE Linux Enterprise Server 10 with Service Pack 2 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3および5.4 (x86 Editionまたはx64 Edition)
今回はまずRed Hat Enterprise Linux (RHEL) 5.4をインストールします。
Hyper-VでLinuxを稼働するためにはLinux IC (統合コンポーネント)をOSインストール後に導入する必要がありますので、あらかじめMicrosoftからダウンロードし、展開しておきます。
LinuxのインストールもWindowsと全く同じです。
インストール後にネットワークを確認すると、ネットワークアダプターが認識されていません。

Linux IC (統合コンポーネント)をインストールしますので、メディア -> DVDドライブ -> ディスクの挿入を選んで解凍したLinux IC (統合コンポーネント)のLinuxIC v2.iso(現時点)を指定します。


ディスクを挿入すると、最近のLinuxディストリビューションは自動的にマウントしてくれます。
コマンドラインからCDのマウント場所に移動(cd /media/CDROM)し"./setup.pl drivers"とコマンドを実行するとLinux ICのインストールが開始されます。



Linux ICのインストールが終了してからネットワークを確認すると、"seth0"というアダプターが認識されています。これで外部との通信ができるようになります。

リモートデスクトップでサーバーにログインし、Linuxの仮想マシンに接続してウィンドウをクリックすると、メッセージが表示されてしまいます。要調査です。

ただ、LinuxもWindowsの様にリモートデスクトップで接続することもできますし、teratermなどからSSHで接続することができますのでそれほど問題にはなることはないと思います。
次はv2.1での確認をしたいと思います。
前回、Hyper-Vの構築~その三 仮想マシンのインストール(XP)でHyper-Vの仮想マシンにWindows XPをインストールしましたが、今回はWindows 7をインストールしたいと思います。
が、仮想マシンを作成してからOSをインストールするところまで全行程でXPの時と全く同じになります。
では、なにが違うかというと、統合サービスがすでに組み込まれているところです。つまり、インストールしただけですでに物理 <-> 仮想マシン間でのマウス移動ができるわけです。



統合サービスは何もマウス移動が楽になるだけの機能ではないのでしっかりと調べたいと思います。
が、仮想マシンを作成してからOSをインストールするところまで全行程でXPの時と全く同じになります。
では、なにが違うかというと、統合サービスがすでに組み込まれているところです。つまり、インストールしただけですでに物理 <-> 仮想マシン間でのマウス移動ができるわけです。



統合サービスは何もマウス移動が楽になるだけの機能ではないのでしっかりと調べたいと思います。
Hyper-Vの構築~その二 ネットワーク設定でHyper-Vサーバーとしての体制が整ったので、仮想マシンをインストールしていこうと思います。
まずは今もなお支持され続けているWindows XPをインストールします。
Hyper-Vマネージャーを起動し右ペインの新規 -> 仮想マシンをクリックします。


「仮想マシンの新規作成ウィザード」が開きます。最初の画面は注意事項なので、『今後、このメッセージを表示しない』にチェックを入れてしまって問題ありません。

「名前と場所の指定」では作成する仮想マシンの名前と、保存場所を指定します。名前は必ず指定する項目ですが、保存場所は任意項目となっています。デフォルトは"C:\ProgramData\Microsoft\Windows\Hyper-V\"と、Hyper-Vのデータフォルダ内に保存されます。

「メモリの割り当て」では作成する仮想マシンに割り当てるメモリをMBで指定します。搭載している物理メモリ量が最大サイズのようです
。
「ネットワークの構成」では外部ネットワークと接続するか内部ネットワークのみにするかを選択します。今回は前回作成した外部ネットワークを指定します。

「仮想ハードディスクの接続」では三つのオプションがあります。
一つ目はハードディスクを今回新規作成する物で、名前・場所・サイズを指定します。
二つ目は既存のハードディスクを使用する場合。別のマシンで動かしていた物を別のサーバーで使用する際等に使います。
三つ目はとりあえず仮想マシン情報を作成しておく場合です。

「インストールオプション」ですが、仮想マシンへのOSのインストール方法について指定します。
一つ目は一旦仮想マシンの作成を終えて、今まで物理マシンにしていたようにインストールする方法です。
二つ目三つ目はインストールする際に使用するディスクを指定しておく方法です。仮想マシンを作成し終え、起動すると自動的にディスクが読み込まれます。
四つ目は確認していませんが、おそらくディスクを設定しておく場合と同じなのではないかと思います。

最後に「仮想マシンの新規作成ウィザードの完了」で指定した設定を確認します。

仮想マシンができあがると、Hyper-Vマネージャの中央ペインに作成した仮想マシンが表示されます。

右ペインの設定、もしくは右クリック -> 設定を開き、インストールに使用するディスクを指定します。今回はisoイメージを使用するのでIDEコントローラー1 -> DVDドライブのメディアでイメージファイルを指定します。


< OK >をクリックします。
Hyper-Vマネージャに戻ったら、右ペインの接続、もしくは右クリック -> 接続を開き、仮想マシンに接続します。

接続しただけでは仮想マシンは動いていませんので、電源ボタンをクリックして仮想マシンを起動します。
接続 -> 起動でも起動 -> 接続でも問題ありません。

仮想マシン接続ウィンドウでXPのインストールが始まります。
インストールが終了すると、Windows XPにログインしている状態が現れます。
Windows XPをインストールした直後は物理マシンと仮想マシン間でマウスを行き来させることができません。一度仮想マシンウィンドウの中でクリックすると、ウィンドウ枠外にそのまま移動することができません。仮想マシンでの作業を終えて物理マシンへ移動したい場合には、ウィンドウ下部に表示されているとおり「Ctrl + Alt + ←」を使います。

ただ、これでは不便なのでMicrosoftから標準で提供されている「統合サービス」をインストールします。

メニューから操作 -> 統合サービスセットアップディスクの挿入をクリックします。仮想マシンにこのディスクを認識させると自動的にサービスのインストールが始まります。インストールが終了すると再起動を促すポップアップが表示されるので再起動します。

再起動後は物理 <-> 仮想マシン間でのマウス移動が自由にできることがわかると思います。
まずは今もなお支持され続けているWindows XPをインストールします。
Hyper-Vマネージャーを起動し右ペインの新規 -> 仮想マシンをクリックします。


「仮想マシンの新規作成ウィザード」が開きます。最初の画面は注意事項なので、『今後、このメッセージを表示しない』にチェックを入れてしまって問題ありません。

「名前と場所の指定」では作成する仮想マシンの名前と、保存場所を指定します。名前は必ず指定する項目ですが、保存場所は任意項目となっています。デフォルトは"C:\ProgramData\Microsoft\Windows\Hyper-V\"と、Hyper-Vのデータフォルダ内に保存されます。

「メモリの割り当て」では作成する仮想マシンに割り当てるメモリをMBで指定します。搭載している物理メモリ量が最大サイズのようです

「ネットワークの構成」では外部ネットワークと接続するか内部ネットワークのみにするかを選択します。今回は前回作成した外部ネットワークを指定します。

「仮想ハードディスクの接続」では三つのオプションがあります。
一つ目はハードディスクを今回新規作成する物で、名前・場所・サイズを指定します。
二つ目は既存のハードディスクを使用する場合。別のマシンで動かしていた物を別のサーバーで使用する際等に使います。
三つ目はとりあえず仮想マシン情報を作成しておく場合です。

「インストールオプション」ですが、仮想マシンへのOSのインストール方法について指定します。
一つ目は一旦仮想マシンの作成を終えて、今まで物理マシンにしていたようにインストールする方法です。
二つ目三つ目はインストールする際に使用するディスクを指定しておく方法です。仮想マシンを作成し終え、起動すると自動的にディスクが読み込まれます。
四つ目は確認していませんが、おそらくディスクを設定しておく場合と同じなのではないかと思います。

最後に「仮想マシンの新規作成ウィザードの完了」で指定した設定を確認します。

仮想マシンができあがると、Hyper-Vマネージャの中央ペインに作成した仮想マシンが表示されます。

右ペインの設定、もしくは右クリック -> 設定を開き、インストールに使用するディスクを指定します。今回はisoイメージを使用するのでIDEコントローラー1 -> DVDドライブのメディアでイメージファイルを指定します。


< OK >をクリックします。
Hyper-Vマネージャに戻ったら、右ペインの接続、もしくは右クリック -> 接続を開き、仮想マシンに接続します。

接続しただけでは仮想マシンは動いていませんので、電源ボタンをクリックして仮想マシンを起動します。
接続 -> 起動でも起動 -> 接続でも問題ありません。

仮想マシン接続ウィンドウでXPのインストールが始まります。
インストールが終了すると、Windows XPにログインしている状態が現れます。
Windows XPをインストールした直後は物理マシンと仮想マシン間でマウスを行き来させることができません。一度仮想マシンウィンドウの中でクリックすると、ウィンドウ枠外にそのまま移動することができません。仮想マシンでの作業を終えて物理マシンへ移動したい場合には、ウィンドウ下部に表示されているとおり「Ctrl + Alt + ←」を使います。

ただ、これでは不便なのでMicrosoftから標準で提供されている「統合サービス」をインストールします。

メニューから操作 -> 統合サービスセットアップディスクの挿入をクリックします。仮想マシンにこのディスクを認識させると自動的にサービスのインストールが始まります。インストールが終了すると再起動を促すポップアップが表示されるので再起動します。

再起動後は物理 <-> 仮想マシン間でのマウス移動が自由にできることがわかると思います。

Hyper-Vの構築~その一 役割の追加でHyper-Vの役割を追加したのでこれから仮想マシンを作成・使用していくことができますが、その前に一つネットワークの設定を行います。
今回Hyper-Vの役割を追加したコンピューターにはネットワークアダプターが二つあります。ここでは仮にアダプターA(192.168.1.7)、アダプターB(192.168.1.8)とします。アダプターAはマザーボードについている物で、アダプターBは後付けの物です。デフォルトの設定であれば、A・Bどちらのアダプターを使用しても物理コンピューターにも仮想マシンにもアクセスすることができます。
役割の追加時にあった「このサーバーへのリモートアクセス用にネットワークアダプターを1つ確保しておくことをお勧めします。ネットワークアダプターを確保するには、そのネットワークアダプターを貸そうネットワーク用としては選択しないようにします。」というメッセージの通り、物理マシンに確実にリモートアクセスするネットワークが無いと万が一の場合にリモートからサーバーを操作することができなくなる恐れがあるためです(例えば、仮想マシンのネットワーク使用率が何かしらの原因で100%になってしまった時など)。
そのために、二つのネットワークアダプターを物理コンピューター専用のアダプターと仮想マシン専用の物とに役割を分担します。
マシンを構築した直後は下図の様にネットワークアダプターが三つ表示されます。

「ローカルエリア接続 2」と「ローカルエリア接続 4」は物理的なアダプターを指しており、どちらにもインターネットプロトコルがインストールされており、静定IPを指定して使用することができる状態となっています。


三つ目の「ローカルエリア接続」はHyper-Vをインストールしたことによって自動的に構成された内部ネットワークで下図の通り、「Microsoft 仮想ネットワーク スイッチ プロトコル」のみがインストールされています。

Hyper-Vに作られた仮想マシンはこの仮想ネットワークスイッチを経由して内部・外部ネットワークと接続します。
現状ではスイッチのWANポートは「ローカルエリア接続 2」と「ローカルエリア接続 4」と両方と接続している形になります。冗長化のイメージです。アダプターAが停止しても、アダプターBを使えば接続し続けることができます。
上で書いたように、今回はそれぞれの役割を与えます。
まず、Hyper-Vマネージャーを開きます。

右の「操作」ペインで「仮想ネットワークマネージャー」を開きます。

マネージャーが開くとすでに一つ仮想ネットワークが作成されていることがわかります。名前は「外部ネットワーク」。そうです、「ローカルエリア接続 4」の接続方法に設定されていたネットワークです。

マネージャーの「接続の種類」では外部が選択されており、仮想ネットワークが使用するアダプターが選択されています。そして、チェックボックス「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」にチェックが入っています。
このチェックボックスのチェックを外し、を押下します。

設定を変更することでメッセージボックスが表示されますが、仮想ネットワーク用のアダプターでは仮想マシンへのみアクセスができるように制限されるという意味ですので、<はい>を押下します。

先ほどは三つアダプターが表示されていた所、「ローカルエリア接続 4」が消えているのがわかります。管理オペレーティングシステムとの共有を解除したために、物理コンピューターからネットワークアダプターを操作できなくなったためです。

これで、物理ネットワークと仮想ネットワークが分離されました。
次は仮想マシンを作成していきます。
今回Hyper-Vの役割を追加したコンピューターにはネットワークアダプターが二つあります。ここでは仮にアダプターA(192.168.1.7)、アダプターB(192.168.1.8)とします。アダプターAはマザーボードについている物で、アダプターBは後付けの物です。デフォルトの設定であれば、A・Bどちらのアダプターを使用しても物理コンピューターにも仮想マシンにもアクセスすることができます。
役割の追加時にあった「このサーバーへのリモートアクセス用にネットワークアダプターを1つ確保しておくことをお勧めします。ネットワークアダプターを確保するには、そのネットワークアダプターを貸そうネットワーク用としては選択しないようにします。」というメッセージの通り、物理マシンに確実にリモートアクセスするネットワークが無いと万が一の場合にリモートからサーバーを操作することができなくなる恐れがあるためです(例えば、仮想マシンのネットワーク使用率が何かしらの原因で100%になってしまった時など)。
そのために、二つのネットワークアダプターを物理コンピューター専用のアダプターと仮想マシン専用の物とに役割を分担します。
マシンを構築した直後は下図の様にネットワークアダプターが三つ表示されます。

「ローカルエリア接続 2」と「ローカルエリア接続 4」は物理的なアダプターを指しており、どちらにもインターネットプロトコルがインストールされており、静定IPを指定して使用することができる状態となっています。


三つ目の「ローカルエリア接続」はHyper-Vをインストールしたことによって自動的に構成された内部ネットワークで下図の通り、「Microsoft 仮想ネットワーク スイッチ プロトコル」のみがインストールされています。

Hyper-Vに作られた仮想マシンはこの仮想ネットワークスイッチを経由して内部・外部ネットワークと接続します。
現状ではスイッチのWANポートは「ローカルエリア接続 2」と「ローカルエリア接続 4」と両方と接続している形になります。冗長化のイメージです。アダプターAが停止しても、アダプターBを使えば接続し続けることができます。
上で書いたように、今回はそれぞれの役割を与えます。
まず、Hyper-Vマネージャーを開きます。

右の「操作」ペインで「仮想ネットワークマネージャー」を開きます。

マネージャーが開くとすでに一つ仮想ネットワークが作成されていることがわかります。名前は「外部ネットワーク」。そうです、「ローカルエリア接続 4」の接続方法に設定されていたネットワークです。

マネージャーの「接続の種類」では外部が選択されており、仮想ネットワークが使用するアダプターが選択されています。そして、チェックボックス「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」にチェックが入っています。
このチェックボックスのチェックを外し、

設定を変更することでメッセージボックスが表示されますが、仮想ネットワーク用のアダプターでは仮想マシンへのみアクセスができるように制限されるという意味ですので、<はい>を押下します。

先ほどは三つアダプターが表示されていた所、「ローカルエリア接続 4」が消えているのがわかります。管理オペレーティングシステムとの共有を解除したために、物理コンピューターからネットワークアダプターを操作できなくなったためです。

これで、物理ネットワークと仮想ネットワークが分離されました。
次は仮想マシンを作成していきます。
自宅にファイルサーバーを作成し(ファイルサーバーの構築)、プリンターサーバーとしても使用(プリンターサーバーの構築~その一 役割の追加)していますが、その上に今度はHyper-Vサーバーとしても使用していこうと思います。
まずはサーバーマネージャーを開いて役割の追加をします。


インストールする役割の選択画面で「Hyper-V」を選択します。


サーバー自体を管理するネットワークアダプターとHyper-Vで作成した仮想マシンへアクセスするためのネットワークアダプターを別に用意することが推奨されています。我が家のマシンにはマザーボードの標準アダプターと、後付けのアダプターとがあるので二つ表示されています。後付けのアダプターを仮想マシン用に割り当てますので、今回は「ローカルエリア接続」にチェックを入れて進みます(ネットワークアダプターが一つしか無い場合でもインストールして仮想マシンを使うことは可能です)。

インストールする前に確認画面が表示され、<インストール>ボタン押下でインストールが始まります。

Hyper-Vのインストールには再起動が必要なため、「インストールの結果」画面では警告メッセージが表示されます。

<インストール>ボタン押下で再起動の確認メッセージが表示されます。他作業でサーバーを利用していなければここで再起動してしまいます。

再起動されると自動的に「インストールの結果」画面が表示され、『正常にインストールされました』と表示されます。

Hyper-Vをインストールした直後にサーバーマネージャーを確認すると、Hyper-Vにメッセージマークがついています。

メッセージを確認すると、『警告』レベルのメッセージが発生しています。

そのイベントメッセージを開いて確認すると、『物理コンピューターをシャットダウンします。すべての仮想マシンを停止および保存しています。』というメッセージです。
今回はインストールしたので仮想マシンは一つもありませんでしたが、仮想マシンを起動中に物理コンピューターをシャットダウンすると、仮想マシンは強制終了されるのと同じことになります。仮想マシンでそのような事態にならないよう、Windowsが停止もしくは保存をしてくれます。

これでHyper-Vサーバーとして仮想マシンを使用できるようになりましたが、次にネットワーク設定を行います。
まずはサーバーマネージャーを開いて役割の追加をします。


インストールする役割の選択画面で「Hyper-V」を選択します。


サーバー自体を管理するネットワークアダプターとHyper-Vで作成した仮想マシンへアクセスするためのネットワークアダプターを別に用意することが推奨されています。我が家のマシンにはマザーボードの標準アダプターと、後付けのアダプターとがあるので二つ表示されています。後付けのアダプターを仮想マシン用に割り当てますので、今回は「ローカルエリア接続」にチェックを入れて進みます(ネットワークアダプターが一つしか無い場合でもインストールして仮想マシンを使うことは可能です)。

インストールする前に確認画面が表示され、<インストール>ボタン押下でインストールが始まります。

Hyper-Vのインストールには再起動が必要なため、「インストールの結果」画面では警告メッセージが表示されます。

<インストール>ボタン押下で再起動の確認メッセージが表示されます。他作業でサーバーを利用していなければここで再起動してしまいます。

再起動されると自動的に「インストールの結果」画面が表示され、『正常にインストールされました』と表示されます。

Hyper-Vをインストールした直後にサーバーマネージャーを確認すると、Hyper-Vにメッセージマークがついています。

メッセージを確認すると、『警告』レベルのメッセージが発生しています。

そのイベントメッセージを開いて確認すると、『物理コンピューターをシャットダウンします。すべての仮想マシンを停止および保存しています。』というメッセージです。
今回はインストールしたので仮想マシンは一つもありませんでしたが、仮想マシンを起動中に物理コンピューターをシャットダウンすると、仮想マシンは強制終了されるのと同じことになります。仮想マシンでそのような事態にならないよう、Windowsが停止もしくは保存をしてくれます。

これでHyper-Vサーバーとして仮想マシンを使用できるようになりましたが、次にネットワーク設定を行います。
家にサーバーを一台立てましたが、サーバーを立てると管理をする必要が出てきます。
管理とは言っても、今のところはイベントビューアーでサービスに異常がないか位です。そのくらいであれば、リモートデスクトップでログインしてそこで確認すればよいのですが、せっかくなのでリモート管理できるように設定をしてみようと思います。
イベントビューアーは「別のコンピューターへ接続」というメニューがあり、リモートのマシン上のイベントビューアーをローカル端末で確認することができます。
まず、コントロールパネル -> 管理ツール -> イベントビューアーと進みます。




この状態では、このビューアーが見ているマシンは現在操作しているマシン。つまり「ローカルマシン」となります。左のツリーペイン/中央の概要ペイン/右の操作ペインにもそれぞれイベントビューアー(ローカル)となっております。
もちろんこの画面を定期的に開いて問題が発生していないかを確認することはとても大切なことですが、今回はローカルマシンのイベントビューアーを見るのではなく、リモートマシンのイベントビューアーを見ます。
ツールバーの操作 -> 別のコンピューターへ接続を選択します。

すると、接続先を選択するウィンドウが表示されます。ここではリモートマシンを選択します。「別のコンピューター」を選択し、テキストボックスに接続先マシンのIPアドレス/マシン名を入力します。同一ワークグループ/ドメインにあるマシンであれば、「参照」ボタンから選択することも可能です。
チェックボックスで「別のユーザーとして接続する」というメニューがありますが、ローカルマシンにログインしているユーザーと、リモートマシン上のユーザーが同一であり、権限があるのであれば設定する必要がありませんが、もし違うユーザーで操作していたり、特定のユーザーを指定したい場合には「ユーザーの設定」ボタンからユーザー名/パスワードを指定します。

最初はAdministratorで接続してみようと思います。

入力が済んだら「OK」を押下します。

すぐに画面が表示されるわけではなく、しばらく時間がかかるようです。

相手先サーバーでファイアウォールの設定を有効にしており、イベントビューアー用の設定をしていない場合、下記のメッセージが表示されます。

実は、ファイアウォールの[リモートイベントのログ管理]例外を有効にする必要があります。
接続先マシンでファイアウォールの設定を行います。
サーバーマネージャー -> 構成 -> セキュリティが強化されたWindowsファイアウォールを選択します。

さらに、セキュリティが強化されたWindowsファイアウォール -> 受信の規則を選択し、下記三規則を有効化します。
・リモートイベントログ管理(RPC-epMAP)
・リモートイベントのログ管理(NP受信)
・リモートイベントのログ管理(RPC)
受信の規則の中では下の方にあります。さらに、「リモートのログ管理」というグループの規則になります。

有効化すると、左端のチェックマークが灰色から緑色に変わるので確認できると思います。

ファイアウォールの設定が終了したらイベントビューアーを開いて接続します。



左のツリーペイン/中央の概要ペイン/右の操作ペインがそれぞれイベントビューアー(SHIKANCHA)となっております。

よくよく見ると、サーバー上で開いたイベントビューアーにはカスタムビューの下に「サーバーの役割」という区分があるのに、リモートから開くとその区分が表示されていません。
サーバー上で開いたイベントビューアー

リモートで開いたイベントビューアー

サーバーのAdministratorで接続しているので権限不足ということは考えられないと思うのですが、なにか設定があるのかもしれません。今後調べてみようと思います。
管理とは言っても、今のところはイベントビューアーでサービスに異常がないか位です。そのくらいであれば、リモートデスクトップでログインしてそこで確認すればよいのですが、せっかくなのでリモート管理できるように設定をしてみようと思います。
イベントビューアーは「別のコンピューターへ接続」というメニューがあり、リモートのマシン上のイベントビューアーをローカル端末で確認することができます。
まず、コントロールパネル -> 管理ツール -> イベントビューアーと進みます。




この状態では、このビューアーが見ているマシンは現在操作しているマシン。つまり「ローカルマシン」となります。左のツリーペイン/中央の概要ペイン/右の操作ペインにもそれぞれイベントビューアー(ローカル)となっております。
もちろんこの画面を定期的に開いて問題が発生していないかを確認することはとても大切なことですが、今回はローカルマシンのイベントビューアーを見るのではなく、リモートマシンのイベントビューアーを見ます。
ツールバーの操作 -> 別のコンピューターへ接続を選択します。

すると、接続先を選択するウィンドウが表示されます。ここではリモートマシンを選択します。「別のコンピューター」を選択し、テキストボックスに接続先マシンのIPアドレス/マシン名を入力します。同一ワークグループ/ドメインにあるマシンであれば、「参照」ボタンから選択することも可能です。
チェックボックスで「別のユーザーとして接続する」というメニューがありますが、ローカルマシンにログインしているユーザーと、リモートマシン上のユーザーが同一であり、権限があるのであれば設定する必要がありませんが、もし違うユーザーで操作していたり、特定のユーザーを指定したい場合には「ユーザーの設定」ボタンからユーザー名/パスワードを指定します。

最初はAdministratorで接続してみようと思います。

入力が済んだら「OK」を押下します。

すぐに画面が表示されるわけではなく、しばらく時間がかかるようです。

相手先サーバーでファイアウォールの設定を有効にしており、イベントビューアー用の設定をしていない場合、下記のメッセージが表示されます。

実は、ファイアウォールの[リモートイベントのログ管理]例外を有効にする必要があります。
接続先マシンでファイアウォールの設定を行います。
サーバーマネージャー -> 構成 -> セキュリティが強化されたWindowsファイアウォールを選択します。

さらに、セキュリティが強化されたWindowsファイアウォール -> 受信の規則を選択し、下記三規則を有効化します。
・リモートイベントログ管理(RPC-epMAP)
・リモートイベントのログ管理(NP受信)
・リモートイベントのログ管理(RPC)
受信の規則の中では下の方にあります。さらに、「リモートのログ管理」というグループの規則になります。

有効化すると、左端のチェックマークが灰色から緑色に変わるので確認できると思います。

ファイアウォールの設定が終了したらイベントビューアーを開いて接続します。



左のツリーペイン/中央の概要ペイン/右の操作ペインがそれぞれイベントビューアー(SHIKANCHA)となっております。

よくよく見ると、サーバー上で開いたイベントビューアーにはカスタムビューの下に「サーバーの役割」という区分があるのに、リモートから開くとその区分が表示されていません。
サーバー上で開いたイベントビューアー

リモートで開いたイベントビューアー

サーバーのAdministratorで接続しているので権限不足ということは考えられないと思うのですが、なにか設定があるのかもしれません。今後調べてみようと思います。
プリンターサーバーの構築~その二 プリンタードライバーの追加でサーバー側の作業を終えました。
最後にクライアント側での作業です。
まず、「デバイスとプリンター」を開いてプリンターの追加をします。

追加するのはネットワークプリンターになります。

自動で使用可能なプリンターを探してくれますが、出てこなかったので手動で追加することにしました(表示されればそのプリンターを選択してください)。

「共有プリンターを名前で選択する」を選びます。

「参照」ボタンを押下して出てくる選択画面で、サーバー上のプリンターを選択します。


おそらく何の問題もなく追加されます。

必要に応じて、通常使うプリンターに設定したり、テストページを印刷してください。

ファイルをプリントする際に、サーバー上のプリンターを選択します。
今まではPCとプリンターが1対1の環境だったので必要性を感じませんでしたが、多対1の環境ではプリンターサーバーはとても便利な機能です。
最後にクライアント側での作業です。
まず、「デバイスとプリンター」を開いてプリンターの追加をします。

追加するのはネットワークプリンターになります。

自動で使用可能なプリンターを探してくれますが、出てこなかったので手動で追加することにしました(表示されればそのプリンターを選択してください)。

「共有プリンターを名前で選択する」を選びます。

「参照」ボタンを押下して出てくる選択画面で、サーバー上のプリンターを選択します。


おそらく何の問題もなく追加されます。

必要に応じて、通常使うプリンターに設定したり、テストページを印刷してください。

ファイルをプリントする際に、サーバー上のプリンターを選択します。
今まではPCとプリンターが1対1の環境だったので必要性を感じませんでしたが、多対1の環境ではプリンターサーバーはとても便利な機能です。