WindowsやLinuxの設定などの勉強にはWindows Server 2008のHyper-Vを使っています。実機を用意しなくても良いのでとても役立っています。
仮想マシンを作る際、デフォルトのフォルダーではなく自分で指定したフォルダーに仮想マシンデータが格納されるようにしていました。デフォルトだとWindowsのシステムが格納されているCドライブをすぐに圧迫してしまうからです。場所を指定するのには毎回、仮想マシン作成ウィザード内で指定していたのですが、毎回のことなのでHyper-Vの設定を変更することにしました。「仮想マシン」「仮想HDD」の二カ所。
変更後、仮想マシンを作成しようとすると下図のエラーメッセージが出るようになりました。
権限が足らないというエラーメッセージです(0x80070005)。
最初は、Windows7のノートPCからHyper-Vマネージャーを使っているからおかしくなったのかなと思いましたが、サーバーにログインして作成しようとしてもエラーメッセージが出て作成に失敗します。Administratorでも・・・
Administratorでも作成できないのはおかしいと思い、Hyper-V関連のフォルダーについて権限を確認してみました。今まで通りウィザード内でフォルダーを変更した場合、指定した場所に仮想マシンごとのフォルダーが作成され、その中に仮想マシン設定・VHDが格納されていました。フォルダー階層は下記の通り。
新しい仮想マシン
├Virtual Machines
│├仮想マシンID(フォルダー)
│└仮想マシンID(XMLファイル)
└新しい仮想マシン.vhd
新しいマシンフォルダーには「仮想マシン」というユーザーの権限がついており、その下の「Virtual Machines」フォルダーには「仮想マシンID」ユーザーの権限がついていました。
作成に失敗する仮想マシンのフォルダーを同じように見てみると下図の二フォルダーしか作成されません。
新しい仮想マシン
└Virtual Machines
権限を見てみると、「Virtual Machines」には「仮想マシンID」ユーザーの権限ではなく、何かしらのユーザーのSIDで権限がついていました。つまり、「仮想マシンID」ユーザーが書き込むことができないわけです。
なぜこのような状態になったかはわかりませんが、そういう仕様なのか不具合なのか。数多くの仮想マシンを利用する場合、それぞれ個別のパックになっている方がメンテしやすいし、今回設定を戻しても今までのように仮想マシン作成できないので不具合なのではないかと考えています。ほかのマシンで試してみなければいけません。
「仮想マシン」のフォルダーを変更すると権限エラーで作成することができなくなるのですが、「仮想ハードディスク」のフォルダーは変更しても問題なく作成できます。
「仮想マシン」のフォルダーは"C:\ProgramData\Microsoft\Windows\Hyper-V"で、その中の「Virtual Machines」フォルダーに仮想マシンID(フォルダー)と仮想マシンID(XMLファイル)が作成されます。
今まで作ってきた仮想マシンについては上で表したフォルダー階層すべて指定した場所に作成され、"C:\ProgramData\Microsoft\Windows\Hyper-V"にはXMLファイルへのリンクが作成されていました。
今回の現象とは異なりますが、同じエラーメッセージが表示される問題がサポートで公開されています。こちらはIntelの問題で下記のソフトを使用している場合に発生します。
Intel Active System Console – version 3.0以下
Intel Server Management Pack – version 3.0以下
Intel One Boot Flash Update for Windows – version 9.70 Build 5以下
Intel System Configuration Utility for Windows – version 5.0.1 Build 8以下
Intel SNMP-SA – version 6.0.0.9999以下
Intel SELViewer – version 2.0.1 Build 5以下
サポートについては「Microsoft Article ID:969556」、「Intel TA-922」です。詳細については前記のMicrosoftおよびIntelのサイトで確認していただきたのですが、Windows 2008 Hyper-VがVMを格納しているストレージへアクセスする際のセキュリティセッティングをIntel IPMIドライバーが謝って変更してしまう現象です。仮想マシンを起動できない・作成できないと言った問題が発生します。修正プログラムが配布されているので、ダウンロードしたら解凍して実行し、再起動すれば直るようです。
仮想マシンを作る際、デフォルトのフォルダーではなく自分で指定したフォルダーに仮想マシンデータが格納されるようにしていました。デフォルトだとWindowsのシステムが格納されているCドライブをすぐに圧迫してしまうからです。場所を指定するのには毎回、仮想マシン作成ウィザード内で指定していたのですが、毎回のことなのでHyper-Vの設定を変更することにしました。「仮想マシン」「仮想HDD」の二カ所。
変更後、仮想マシンを作成しようとすると下図のエラーメッセージが出るようになりました。
権限が足らないというエラーメッセージです(0x80070005)。
最初は、Windows7のノートPCからHyper-Vマネージャーを使っているからおかしくなったのかなと思いましたが、サーバーにログインして作成しようとしてもエラーメッセージが出て作成に失敗します。Administratorでも・・・
Administratorでも作成できないのはおかしいと思い、Hyper-V関連のフォルダーについて権限を確認してみました。今まで通りウィザード内でフォルダーを変更した場合、指定した場所に仮想マシンごとのフォルダーが作成され、その中に仮想マシン設定・VHDが格納されていました。フォルダー階層は下記の通り。
新しい仮想マシン
├Virtual Machines
│├仮想マシンID(フォルダー)
│└仮想マシンID(XMLファイル)
└新しい仮想マシン.vhd
新しいマシンフォルダーには「仮想マシン」というユーザーの権限がついており、その下の「Virtual Machines」フォルダーには「仮想マシンID」ユーザーの権限がついていました。
作成に失敗する仮想マシンのフォルダーを同じように見てみると下図の二フォルダーしか作成されません。
新しい仮想マシン
└Virtual Machines
権限を見てみると、「Virtual Machines」には「仮想マシンID」ユーザーの権限ではなく、何かしらのユーザーのSIDで権限がついていました。つまり、「仮想マシンID」ユーザーが書き込むことができないわけです。
なぜこのような状態になったかはわかりませんが、そういう仕様なのか不具合なのか。数多くの仮想マシンを利用する場合、それぞれ個別のパックになっている方がメンテしやすいし、今回設定を戻しても今までのように仮想マシン作成できないので不具合なのではないかと考えています。ほかのマシンで試してみなければいけません。
「仮想マシン」のフォルダーを変更すると権限エラーで作成することができなくなるのですが、「仮想ハードディスク」のフォルダーは変更しても問題なく作成できます。
「仮想マシン」のフォルダーは"C:\ProgramData\Microsoft\Windows\Hyper-V"で、その中の「Virtual Machines」フォルダーに仮想マシンID(フォルダー)と仮想マシンID(XMLファイル)が作成されます。
今まで作ってきた仮想マシンについては上で表したフォルダー階層すべて指定した場所に作成され、"C:\ProgramData\Microsoft\Windows\Hyper-V"にはXMLファイルへのリンクが作成されていました。
今回の現象とは異なりますが、同じエラーメッセージが表示される問題がサポートで公開されています。こちらはIntelの問題で下記のソフトを使用している場合に発生します。
Intel Active System Console – version 3.0以下
Intel Server Management Pack – version 3.0以下
Intel One Boot Flash Update for Windows – version 9.70 Build 5以下
Intel System Configuration Utility for Windows – version 5.0.1 Build 8以下
Intel SNMP-SA – version 6.0.0.9999以下
Intel SELViewer – version 2.0.1 Build 5以下
サポートについては「Microsoft Article ID:969556」、「Intel TA-922」です。詳細については前記のMicrosoftおよびIntelのサイトで確認していただきたのですが、Windows 2008 Hyper-VがVMを格納しているストレージへアクセスする際のセキュリティセッティングをIntel IPMIドライバーが謝って変更してしまう現象です。仮想マシンを起動できない・作成できないと言った問題が発生します。修正プログラムが配布されているので、ダウンロードしたら解凍して実行し、再起動すれば直るようです。
１．Windows Server 2008のバックアップ・リカバリ～その一 バックアップ
２．Windows Server 2008のバックアップ・リカバリ～その二 リカバリ～１．同じサイズのHDDに戻すパターン
３．Windows Server 2008のバックアップ・リカバリ～その三 リカバリ～２．大きいHDDに戻すパターン
４．Windows Server 2008のバックアップ・リカバリ～その三 リカバリ～３．小さいHDDに戻すパターン（失敗パターン）
以前、上記四回にわたってWindows Server 2008でバックアップを取り、復元するのを確認しました。今回はWindows 7で同じことができるのか試してみたいと思います。
バックアップは標準のウィザードを利用してHDDにとり、
リカバリは下記三パターンを試してみる。
１．同じサイズのHDDに戻すパターン
２．大きいHDDに戻すパターン
３．小さいHDDに戻すパターン（失敗パターン）
テスト機の構成は下記の通り。
フルコンピューター名：WIN7-BKUP
ワークグループ：WORKGROUP
ローカルエリア接続2：192.168.0.104, IPv6(有効)
HDD：15GB(Windows 7のインストールをしただけの状態)
今回リカバリの確認用にファイルとフォルダーを作りました。
それではまずバックアップの取得から。
コントロールパネルを開き、「システムとセキュリティ」にある「バックアップの作成」をクリック。
初回のバックアップであれば、まだ何も設定されていないので右上にある「バックアップの設定」をクリック。
「バックアップの設定」の設定では保存先、保存内容を設定することができます。今回は何も変更せずにMicrosoftが薦める設定で行います。
バックアップ先には同一マシンに接続している別HDD上の「ボリューム(E:)」を選択。
バックアップの対象も推奨されている自動選択を選択。
「バックアップ設定の確認」では自動選択されたバックアップ対象が表示されます。また、バックアップのスケジュールはデフォルトで毎週日曜日の19:00に設定されます。
「設定を保存してバックアップを実行」をクリックすればバックアップが始まります。
バックアップが始まったら放っておけば良いのですが、「詳細の表示」をクリックするとプログレスバーとともにバックアップされているファイルが表示されます。
次はこのバックアップファイルを使ってリカバリをしたいと思います。
２．Windows Server 2008のバックアップ・リカバリ～その二 リカバリ～１．同じサイズのHDDに戻すパターン
３．Windows Server 2008のバックアップ・リカバリ～その三 リカバリ～２．大きいHDDに戻すパターン
４．Windows Server 2008のバックアップ・リカバリ～その三 リカバリ～３．小さいHDDに戻すパターン（失敗パターン）
以前、上記四回にわたってWindows Server 2008でバックアップを取り、復元するのを確認しました。今回はWindows 7で同じことができるのか試してみたいと思います。
バックアップは標準のウィザードを利用してHDDにとり、
リカバリは下記三パターンを試してみる。
１．同じサイズのHDDに戻すパターン
２．大きいHDDに戻すパターン
３．小さいHDDに戻すパターン（失敗パターン）
テスト機の構成は下記の通り。
フルコンピューター名：WIN7-BKUP
ワークグループ：WORKGROUP
ローカルエリア接続2：192.168.0.104, IPv6(有効)
HDD：15GB(Windows 7のインストールをしただけの状態)
今回リカバリの確認用にファイルとフォルダーを作りました。
それではまずバックアップの取得から。
コントロールパネルを開き、「システムとセキュリティ」にある「バックアップの作成」をクリック。
初回のバックアップであれば、まだ何も設定されていないので右上にある「バックアップの設定」をクリック。
「バックアップの設定」の設定では保存先、保存内容を設定することができます。今回は何も変更せずにMicrosoftが薦める設定で行います。
バックアップ先には同一マシンに接続している別HDD上の「ボリューム(E:)」を選択。
バックアップの対象も推奨されている自動選択を選択。
「バックアップ設定の確認」では自動選択されたバックアップ対象が表示されます。また、バックアップのスケジュールはデフォルトで毎週日曜日の19:00に設定されます。
「設定を保存してバックアップを実行」をクリックすればバックアップが始まります。
バックアップが始まったら放っておけば良いのですが、「詳細の表示」をクリックするとプログレスバーとともにバックアップされているファイルが表示されます。
次はこのバックアップファイルを使ってリカバリをしたいと思います。
私が参加しているプロジェクトでサーバーのログをログ集約サーバーに転送することになりました。
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で確認してあります。
大阪地検のFD改ざん事件ではファイルの更新日を変更していました。Linuxではtouchコマンドを使って作成日等を変更することができますが、Windowsではそれに該当するコマンドは無いようです。
WindowsでもtouchコマンドがあればいいのになとMSDNのライブラリを見ていた頃にメソッドがあったのを思い出して使ってみました。フリーウェアで探してみると結構たくさん出てきました。しかもとても使いやすそうな物も。そういったすぐれた物に比べればちゃっちいけれども、案外簡単に作れるなと言うのが正直な思いです。
使ったのはDirectoryクラスのメソッド６種類です。
GetCreationTime
GetCreationTimeUtc
GetLastAccessTime
GetLastAccessTimeUtc
GetLastWriteTime
GetLastWriteTimeUtc
【仕様】
.NET Framework1.0以上で動く。
テキストボックスに入力されたディレクトリもしくはファイルのタイムスタンプを変更する。
【課題】
課題は前回のMngDirと同じです
ファイル等のパスををドラッグ＆ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> Touche
zipを解凍して使ってください。
WindowsでもtouchコマンドがあればいいのになとMSDNのライブラリを見ていた頃にメソッドがあったのを思い出して使ってみました。フリーウェアで探してみると結構たくさん出てきました。しかもとても使いやすそうな物も。そういったすぐれた物に比べればちゃっちいけれども、案外簡単に作れるなと言うのが正直な思いです。
使ったのはDirectoryクラスのメソッド６種類です。
GetCreationTime
GetCreationTimeUtc
GetLastAccessTime
GetLastAccessTimeUtc
GetLastWriteTime
GetLastWriteTimeUtc
【仕様】
.NET Framework1.0以上で動く。
テキストボックスに入力されたディレクトリもしくはファイルのタイムスタンプを変更する。
【課題】
課題は前回のMngDirと同じです
ファイル等のパスををドラッグ＆ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> Touche
zipを解凍して使ってください。
Visual C++で物を作ることができるようになるとようやく決意して数日。一つ目のツールを作りました。
ディレクトリを作って削除するだけ。
仕事ではLinuxを使っているのだが、Linuxでは入れ子になったディレクトリを作成することも削除することもできるのに、何でWindowsではできないんだろうと疑問に思ってました（注：今確認したところ、入れ子ディレクトリはコマンドラインからもPowerSherllからも作成できますが、削除はPowerSherllでしかできませんでした）。
なので入れ子ディレクトリをいじくることができるツールを作ってみました。
正直、.NET Frameworkと言う物が何なのかすらよくわからなかったのですが、結構簡単に作れました。純粋にC言語で作ろうと思っていたのでどう作って良いのかあれこれ考えながらMSDNのライブラリを見ていたら、使いたいけど自分で作るしかない機能（関数）がたくさん用意されていました。
そうか。.NET FrameworkはStrutsなどと同じ用にFrameworkなんだと今更ながらに気がつきました。
なんだ、思っていたほど難しくはないな。パフォーマンスを要求する様な高度な物でなければ何とか作れるのかもしれません。
今回作ったツールについて：
【仕様】
.NET Framework2.0以上で動く。
テキストボックスに入力されたディレクトリを作成もしくは削除する。
【課題】
ファイル等のパスををドラッグ＆ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> MngDir
zipを解凍して使ってください。
ディレクトリを作って削除するだけ。
仕事ではLinuxを使っているのだが、Linuxでは入れ子になったディレクトリを作成することも削除することもできるのに、何でWindowsではできないんだろうと疑問に思ってました（注：今確認したところ、入れ子ディレクトリはコマンドラインからもPowerSherllからも作成できますが、削除はPowerSherllでしかできませんでした）。
なので入れ子ディレクトリをいじくることができるツールを作ってみました。
正直、.NET Frameworkと言う物が何なのかすらよくわからなかったのですが、結構簡単に作れました。純粋にC言語で作ろうと思っていたのでどう作って良いのかあれこれ考えながらMSDNのライブラリを見ていたら、使いたいけど自分で作るしかない機能（関数）がたくさん用意されていました。
そうか。.NET FrameworkはStrutsなどと同じ用にFrameworkなんだと今更ながらに気がつきました。
なんだ、思っていたほど難しくはないな。パフォーマンスを要求する様な高度な物でなければ何とか作れるのかもしれません。
今回作ったツールについて：
【仕様】
.NET Framework2.0以上で動く。
テキストボックスに入力されたディレクトリを作成もしくは削除する。
【課題】
ファイル等のパスををドラッグ＆ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> MngDir
zipを解凍して使ってください。
一昨年参加したカンファレンスでMicrofsoft Visual Studio 2008をもらった。PCにインストールしてLinuxツールのソース等を見るのに使っていたのだが、やっぱり自分で何かを作らなきゃもったいないし技術がつかないのであれこれ作ってみることにした。
自分のわかる範囲では存在していないけれど、あったら便利であろうソフト/ツールのアイディアはいくつかある。とは言っても、開発経験はほぼゼロなのでそんなソフト/ツールを作るどころか、しょうもないツールを作ることでもあっぷあっぷ。
とりあえず、「習うより慣れろ」で試行錯誤していこうと思う。「こんなん作ってどうするの？このツール使うより、手で作業した方が早いでしょ？」という台詞はしばらく封印する。
ところで、Visual C++とVisual C#、どっちをやったらよいのだろう・・・一つのツールを二言語で作ってみるか。
自分のわかる範囲では存在していないけれど、あったら便利であろうソフト/ツールのアイディアはいくつかある。とは言っても、開発経験はほぼゼロなのでそんなソフト/ツールを作るどころか、しょうもないツールを作ることでもあっぷあっぷ。
とりあえず、「習うより慣れろ」で試行錯誤していこうと思う。「こんなん作ってどうするの？このツール使うより、手で作業した方が早いでしょ？」という台詞はしばらく封印する。
ところで、Visual C++とVisual C#、どっちをやったらよいのだろう・・・一つのツールを二言語で作ってみるか。
リモートでのイベントビューアー確認～その一 接続でリモートからイベントビューアーを確認するとサーバーの役割についての確認が取れませんでした。
調べてみたところ、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の時と全く同じになります。
では、なにが違うかというと、統合サービスがすでに組み込まれているところです。つまり、インストールしただけですでに物理 <-> 仮想マシン間でのマウス移動ができるわけです。
統合サービスは何もマウス移動が楽になるだけの機能ではないのでしっかりと調べたいと思います。
