KVMその4(SPICE)

さて前回、KVMの画面描画にSPICEというプロトコル？が使えることは軽く書いた。

今回は実際に、SPICEプロトコルを使った画面の確認をしてみたいと思う。

SPICEは、RDPと同じように作業端末側から繋ぎに行く。そのための専用クライアントソフトがある。
手元のWindowsマシンで動くクライアントもある。
https://virt-manager.org/download/
この中の virt-viewer というエントリに、 Win x86 MSI/Win x64 MSI のそれぞれのリンクがあるので、手元のWindowsの32bit/64bitに併せてダウンロード、インストールしておこう。

--2016/07/19追記--
2016/06/30付で、virt-viewerの4.0がリリースされているようだが、これのWin x64版にはどうやらバグがある。(確認したのはWin x64版だけで、x86版にも同様にバグがあるかもしれない。)
一度画面描画された後、画面が更新されないというバグだ。ウィンドウを裏に隠してから、また表に出すと描画が更新されるが、毎回それをやらないといけない、というバグ。
そのため、再リリースされるまでは、3.1を使おう。
https://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.1.msi
https://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.1.msi
--2016/07/19追記ココまで--

作業端末にインストールが終わったら、さっそくaquariusにログインしよう…。と、言いたい所だが、F/W(ルータ)の外側からaquariusにログインする場合、sshトンネルを使ったリモートデスクトップその2の時と同じように、ポートフォワーディングの設定をしておこう。
SPICEは、使用するポート番号は特に決まっていないようなので、今回は暫定的に9001を使用する。
設定内容は以下の通り

• ローカルのポート：9001
• リッスン：127.0.0.1
• リモート側ホスト：127.0.0.1
• ポート：9001

ポートフォワードの設定が終わったら、今度こそaquariusにログインしよう。
ログインしたら、前回までと同様に、kvmを起動するが、spiceオプションを付けて起動する。
$ cd iscsivol/
$ kvm -machine type=q35 \
      -hda     test.img \
      -boot    c        \
      -m       512      \
      -cpu     host     \
      -smp     4,cores=2,threads=2,sockets=1 \
      -spice   port=9001,password=test &
(ちょっと長いため、改行を入れた。-machineオプション、-smpオプション、-cpuオプションは付けても付けなくてもいいぞ。)
今回は & 付きでバックグランド実行させている。そのため、プロンプトはすぐ戻ってきたはずだ。

この時点で今までだったら新しいウィンドウが立ち上がり、そこに仮想マシンの画面が表示されていたはずだ。
今回 spice オプションを付与したため、新しいウィンドウは立ち上がって無いはずだ。

ここで、先ほど作業用端末にインストールしたspiceクライアント(virt-viewer)を起動しよう。
プログラムの名前は「Remote Viewer」になっていると思う。

起動したら、以下のようなウィンドウが立ち上がってくるはずだ。

このウィンドウの「Connection Address」欄に、

spice://127.0.0.1:9001 と入力しよう。
＃自宅内LANから接続している等、sshポートフォワードをしていない場合は、IPアドレスは aquarius のIPアドレスになるぞ。

入力が終わったら、上記画面で示したとおり「Connect」ボタンを押そう。

「Connect」ボタンを押したら、新しいウィンドウがオープンし、パスワードを入力するダイアログが表示されたはずだ。
(「Username」欄は入力出来ない状態だ。)

Password欄には、kvmを実行した時のpassword=の値を入力しよう。
先ほどのコマンドなら、test のはずだ。
右下の「OK」ボタンを押すと、ウィンドウサイズがリサイズされて、今までと同じようなログイン画面が出てきたはずだ。

今まで通りログインしてコマンド類を実行してみよう。
普通に使えることが分かるはずだ。

piscesをOS再起動しても、spiceクライアントがそのまま利用出来るのも確認しておこう。
(pisces) $ sudo shutdown -r now

また、今までの X を用いた画面転送では、画面がクローズする(右肩のXボタンを押す)と、ゲストOS(pisces)も停止してしまっていた。
spiceクライアントを利用している場合は、spiceクライアントが停止しても、ゲストOSは稼働したままだ。
再びspiceクライアントから接続すれば、作業が継続出来る。

但し、ホストOSである aquarius からpsを見ると、passwordも丸見えなので、扱いには気をつけよう。

kvmコマンドの-spiceオプションは他にも色々ある。今回はsshトンネルを通しているため、特に暗号化を行う必要は無い(sshトンネルで暗号化されている)が、TLS(Transport Socket Layer)も使える。いわゆるSSL暗号化と言うヤツだ。(微妙に違うが…)
この辺りも、少しずつ調査をして記録していきたい。(要するに、まだ理解していないってことだ…)

稼働確認等が終わったら、忘れないようにshutdownしておこう。
(pisces) $ sudo shutdown -h now
SPICEクライアントも終了してウィンドウがクローズされたはずだ。

今回はここまで。

KVMその3(オプション色々)

さて、kvmコマンド(実際には、内部で /usr/bin/qemu-system-x86_64 を呼び出すラッパースクリプトだけど)には、多くのオプションがある。

オプション一覧は、
$ kvm -h
もしくは
$ kvm -help
で出てくるが、めちゃくちゃ多い。

とりあえず、分かるところ、よく使いそうなところだけピックアップして紹介。

[マシンタイプ関連(-machine)]
仮想マシンの基本構成に関するオプションになる。
$ kvm -machine help
でリストが出てくる。
どのチップセットとコントローラをエミュレートするのか？という選択肢で、事実上

• i440FX + PIIX
• Q35 + ICH9

のどちらかになるみたいだ。
ヘルプでは、xenfv / xenpv というのも指定出来るように書かれているが、これを使うためには、別途xen関連のライブラリをインストールする必要がありそうだ。
xenを使う予定は無いので、無視することにする。

基本的な使い方は以下の通り。
$ kvm -hda test.img -boot c -m 512 -machine type=pc
$ kvm -hda test.img -boot c -m 512 -machine type=q35

マシンタイプの設定に、アクセラレータの指定もある。
良く分からないのだが、kvm / xen / tcg の3つのどれかを指定できるようだ。

使い方例
$ kvm -hda test.img -boot c -m 512 -machine type=q35,accel=tcg
$ kvm -hda test.img -boot c -m 512 -machine type=q35,accel=kvm
(xen はmachinetypeを xenfv or xenpv にした時に意味があるようだ。xen 環境は使用する予定が無いので、こちらも無視することにする。)

kvm を指定する場合、CPU に仮想化支援機能(Intel だと vt-x)が搭載されていないと使えないように見受けられる。
従って、tcg を指定した場合が一番遅く、(恐らく)kvmを指定するのが一番速いのではないだろうか？

ただ、これは qemu-system-* コマンドを実行した時に意味がある気がする。
というのも、kvm コマンド自体は、内部で qemu-system-x86_86 コマンドを、-enable-kvm オプション付きで呼び出しているから、アクセラレータは自動的にkvmになるような気がする。
(というのも、軽く触ってみた感じでは、速度差があるようには思えなかったからだ。)

試しに、kvm コマンドではなく、 qemu-system-x86_64 コマンドで呼び出してみよう。
$ qemu-system-x86_64 -hda test.img -boot c -m 512 -machine type=q35,accel=tcg
$ qemu-system-x86_64 -hda test.img -boot c -m 512 -machine type=q35,accel=kvm
ありゃ、tcgを使ったら、「TCGをサポートしてへんで」みたいなワーニングが出た。(CPU IDが違う？とかなんとか)
しかし、起動だけでものすごく時間がかかっている。やはり、tcgでは処理が遅いようだ。
軽く測ってみたところ、コマンド実行からログインプロンプトが表示されるまでの時間は、以下の通りだった。

accel=tcg	accel=kvm
65秒	10秒

accel=kvm の方が圧倒的に速い。ちなみに、シャットダウンしてウィンドウがクローズするまでの時間も段違いだった。
また、accel=kvm を指定した場合は、kvmコマンドで実行した時と同じ時間で起動出来ている様子。
ということは、-enable-kvm を使用した場合は、自動的に accel=kvm も指定されるということなのだろう。

マシンタイプ関連のオプションは他にもたくさんあるが、とりあえずここまでにして、必要に応じて書き足すことにしよう。

[CPU関連]
CPU関連のオプションは主に2つ。

• どのタイプのCPUをゲストに見せるか？(-cpu)
• 仮想マシンに幾つのCPUを割り当てるか？(-smp)

の2つだ。

-cpu は、仮想マシンのCPUの種別を指定するオプションで、かなりたくさんの種類がある。
kvm -cpu help
で一覧を確認することが出来るぞ。
例えば、Broadwell を指定すると、ゲストOSは搭載しているCPUが第5世代 Intel Core i に見えるはず…だ。ただ、Broadwell を指定しても、仮想マシンのCPUにvt-x(vmx)は搭載されていないように見えるようだ。
-cpu に host を指定した場合、ホストマシンのCPUの機能が仮想マシンにそのまま引き継がれるようだ。従って、仮想マシン側でも vt-x(vmx) が認識できる。
恐らく、-cpu host と指定することで、 nested KVM (KVMの仮想マシン上でKVMを建てる)なんてことが出来るようになるはずだ。
異なる世代のCPUを搭載した物理マシン間では、-cpu host と指定した仮想マシンは、オンライン移行(V-Mothion)は出来ないだろう。これは余裕があったら検証したい。

色々なオプションを指定しながら、ゲストOS側で cat /proc/cpuinfo を実行してみるとその差が分かると思う。
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host

-smp で仮想マシンから認識可能なCPUの数を指定できる。
結構細かく指定できるのだが、あまり差異は無いと思われる。
今私が使っているマシンは、2コア4スレッドで、論理4コアのため、恐らく4を超える数字を指定することは出来ないだろう。
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 4
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 8
なんと、8個も指定できてしまった。(16も指定できた…）
これ、8CPUではなく、2sockets * 2cores * 2thread の論理8CPUとして定義してみたらどうだろうか？
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 8,cores=2,threads=2,sockets=2
う～ん、指定できた。しかも、きちんと2ソケット2コア2スレッドの合計8CPU(論理)で認識されている。ちょっと驚きだ。

[network関連(-netdev)]
ネットワーク関連のオプションは、かなり複雑怪奇。
なお、-netというオプションもあるが、どうやらこちらは古いオプションで、今後は-netdevを使用することになるようだ。

network関連をきちんと使うには、libvirtを使用する形(virsh等で設定)が良いようだ。
現時点ではまだvirshやvirt-managerは使っていないため、次のタイミングで要調査とする。

[storage関連(-fd?/-hd?等)]
こちらも、オプションがたくさんあるが、virsh等を用いた方が効率が良いようだ。
virshやvirt-managerを使うタイミングで記載することにしよう。

[display関連]
こちらもオプションは多く、一つ(-spice)だけ紹介することにする。(詳細は後日…)
今までの状態では、サーバ側でゲストOSの画面が作成され、それがXプロトコルにて手元の操作端末に転送されていたと思う。
Xプロトコルというのは、実はお世辞にもそんなに速いプロトコルではなく、更に手元の端末のWindowsの画面描画と仕組み的に合わず、VcXsrv等のソフトウェアが上手いこと差分を吸収してくれている。

但しこれだと、Xで描画が出来なくなった状態(サーバと作業端末の間のXプロトコルが切断されてしまった場合、ネットワークトラブル等)で、仮想マシンがダウンしてしまう。
これでは、仮想マシンを運用するメリットが無いと言い切ってもいいだろう。

そこで幾つかのオプションがある。

そのうちの一つが、画面転送でよく使われているvncプロトコルを利用するオプション(-vnc)だ。
だけど、敢えてvncではなく、spiceの方(-spice)を利用する。
spiceは、vncのような画像転送プロトコルだが、非常に優れた機能を持っている(らしい)。

spiceの使用に関しては、また別途記載する。

長くなったので、一旦ココまで。

KVMその2

さて、KVMを使って、暫定的に仮想OSを作ってみよう。
仮想OS作るためのオプションはたくさんあって、本気で運用するのなら、事前にしっかり設計しておく必要がある。
でも、それも仮想OSを立ててみないと分からないことも多い。なので、とにかく一つ作ってみよう、というのが今回のテーマだ。

作るOSはUbuntuの一つ前のLTSバージョン、14.04だ。2年前のLTSだから、しっかり情報が揃っているから、初めて作るには丁度いいと思う。
ただ、14.04はバグフィックス等を含んだ5世代目？がリリースされている。一応、ダウンロード実施時点(2016/06/16)の最新版は14.04.4だ。wgetでコレをダウンロードしておこう。
ダウンロード先は、先日マウントしたiSCSI領域にしよう。
$ cd iscsivol
$ wget http://releases.ubuntu.com/14.04.4/ubuntu-14.04.4-server-amd64.iso
$ ls -l

OSのインストールメディアが手に入ったら、次は仮想OS用の仮想ディスクだ。
こちらも、iSCSI用にext4を作った5GB(iscsivol)の中に、3.5GBで作成してみよう。
(4GBで作成しようと思ったんだけど、どうやら4GBは空き領域が足りなくて確保できないみたいだった。)
$ cd ~/iscsivol
$ qemu-img create -f qcow2 test.img 3.5G
$ ls -l
なんと、出来上がったファイルは200MBほどしか無い。
どうやら、シンプロビジョニングのような形で確保されるようだ。

仮想ディスクも出来上がったので、とりあえず仮想マシンをブートしてみよう。
もちろん、まだ何もインストールしていないので、空っぽの仮想マシンの起動になる。
$ kvm -hda test.img -cdrom ubuntu-14.04.4-server-amd64.iso -boot d -m 512
これを実行すると、KVMその1の時と同じようにウィンドウが立ち上がって、Ubuntuのインストーラ画面になると思う。
(X Windowを使用する必要が有るため、事前にVcXsrvの環境を作っておこう)

仮想マシン上で、Ubuntu 14.04.4のメディアイメージからブートした、ということになる。
軽くインストールしておこう。
ちなみに、Ubuntuのウィンドウをマウスでクリックすると、そのウィンドウからマウスが外せなくなると思う。そうなったら、左Ctrl+左Altの同時押しで外せるぞ。
ざっくり、以下の設定でインストールすることにする。(それ以外は適宜設定してくれい)

• 言語：日本語
• ホスト名：pisces
• ディスクのパーティショニング：ディスク全体を使い、LVMをセットアップする
• ソフトウェアの選択：OpenSSH Serverのみチェック
• GRUBブートローダ：マスターブートレコードへインストール

インストール後、再起動を行うと、再びUbuntu 14.04.4のメディアイメージからブートしてしまう。
一旦、teratermの方(kvmコマンドを実行したターミナル)に、Ctrl+Cを押して、KVMプロセスを停止しよう。
(インストール画面も消えたはずだ)

仮想HDDのサイズをls -lで確認してみると、最初は200MB程度だったはずだが、2GB弱まで大きくなっているかと思う。やはり、シンプロビジョニングのような状態だったわけだ。

さて、この仮想HDDに本当にインストールが出来たのか、試しに起動してみよう。
$ kvm -hda test.img -boot c -m 512
起動処理が走って、暫くするとログイン画面になるはずだ。
OSのホスト名も指定したpiscesだし、問題なさそうだ。

ログインして確認してみよう。

どうやら、問題なく使えているようだ。

ちなみに、NICは1系統、IPアドレスは10.0.2.0/24が自動付与されている。DHCPクライアントに設定されているようだ。(デフォルトはDHCPクライアント)

ホストであるaquariusのNICを通じて、外(The Internet側)へのアクセスも可能で、sudo apt-get update が普通に稼働する。

とりあえず動くのは確認できた。

ちなみに、Ubuntuインストール時のKVMコマンド
kvm -hda test.img -cdrom ubuntu-14.04.4-server-amd64.iso -boot d -m 512
こちらだが、オプションは以下のとおりらしい。

• -hda
  IDEチャネル1番目のHDDイメージファイル
  (今回は、test.imgファイル。ファイルではなく、デバイスを直に指定することも可能だと思う。)
• -cdrom
  IDEチャネルに接続しているCD-ROMドライブのイメージファイル
  (今回は、ubuntu-...isoファイル。こちらも、デバイスを直にしているすることは可能だと思う。)
• -boot
  何番目のデバイスからブートするか？dを指定しているので、2番目のデバイス。
  (FDDが、a,bで、IDEチャネル1番目のHDDがc、今回はdを指定しているので、CD-ROMイメージからブートする事になる。)
• -m
  仮想マシンに割り当てるメモリサイズ(今回は512MBを割り当てた)

インストール後、ブートしなおした時のKVMコマンド
kvm -hda test.img -boot c -m 512

• -boot
  c(IDEチャネル1番目のデバイスからブート)ということで、仮想HDD(test.img)からブートした形だ。

メモリサイズは512MBを割り当てているので、freeコマンド等で確認してみて欲しい。

この他にも、kvmコマンドにはたくさんのオプションがあるようだ。
おいおい調査して記載していくことにする。

最後に、piscesの方は停止しておこう。
(pisces) $ sudo shutdown -h now
ウィンドウがクローズして、kvmを起動したプロンプトが返ってきたはずだ。

これから暫くは、この test.img に格納された pisces を使って KVM を実験してみたいと思う。

iSCSIを利用しようその4

KVMを色々検証していく過程で、どうしてもある程度のディスク容量を確保しておく必要がある。

iSCSI関連のブログで、暫定的に10GBのiSCSI領域を確保し、そのうち5GBを使ってファイルシステムを作っておいた。
それをKVMの検証の初期に利用したいと思っているのだが、OSを再起動する度にiSCSIとのセッションが切れて、毎回コマンドでiSCSIターゲットにログインしないといけない。
これではメンドクサイので、まずはOS起動時に自動的にiSCSIターゲットにログインし、ファイルシステムのマウントまで行われるように設定しておこう。

今は、OS再起動によってiSCSIターゲットにログインしていない状態とする。

まずは、OS起動時に自動的にiSCSIターゲットにログインする方法だ。
iscsiadmのマニュアル(man iscsiadm)を読んでみよう。
-L, --loginallのオプションに、[all|manual|automatic]という記載がある。これのような気がする。
-Lや--loginallのオプションは、-m nodeオプションと組み合わせて使用することになっているようだ。
iscsiadm -m node [ -hV ] [ -d debug_level ] [  -P  printlevel  ]  [  -L
all,manual,automatic  ]  [ -U all,manual,automatic ] [ -S ] [ [ -T tar‐
getname -p ip:port -I iface ] [ -l | -u | -R | -s] ] [ [ -o operation ]
[ -n name ] [ -v value ] [ -p ip:port ] ]

更に、man iscsiadmの下の方の「FILES」という部分に関連するファイルが記載されているのだが、そこを見ると以下のエントリがある。
/etc/iscsi/iscsid.conf
The configuration file read by iscsid and iscsiadm on startup.

/etc/iscsi/initiatorname.iscsi
The file containing the iSCSI InitiatorName  and  InitiatorAlias
read by iscsid and iscsiadm on startup.

/etc/iscsi/nodes/
This directory contains the nodes with their targets.

/etc/iscsi/send_targets
This directory contains the portals.

この中で、/etc/iscsi/nodes/ の下の方を覗いてみると…。
$ sudo ls -alR /etc/iscsi/nodes
以下のようなディレクトリ・ファイル構造になっているのが分かる。
/etc/iscsi/nodes
└(iSCSIターゲットのIQN名)/
　└(iSCSIターゲットのIPアドレス,ポートNo,シーケンス番号)/
　　└default

このdefaultというファイルを見てみると、ノード(iSCSIターゲット)に対する設定情報が分かる。
$ sudo cat /etc/iscsi/nodes/(iSCSIターゲットのIQN名)/(iSCSIターゲットのIPアドレス,ポートNo,シーケンス番号)/default
--ここから--
# BEGIN RECORD x.x-xxx
--一部省略--
node.tpgt = 1
node.startup = manual
node.leading_login = No
--一部省略--
# END RECORD
--ここまで--

この、node.startup = manual という設定、iscsiadmの-Lオプションである、[all|manual|automatic]に並びそうだ。
ということは、この default ファイルの node.startup = manual を、node.startup = automatic に書き換えればいいような気もする。

で、書き換え方法だが、どうも直接viで編集、というタイプでは無く、iscsiadmコマンドで書き換えるタイプのようだ。
書き換え方は、以下の通り
iscsiadm -m node -T (iSCSIターゲットのIQN名) -p (iSCSIターゲットのIPアドレス):(ポート番号) --op=update --name=(書き換えたいパラメータの名前) --value=(書き換え後の値)
多分、-pオプションは不要な気がする。

以下のようにコマンドを実行してみよう。
$ sudo iscsiadm -m node -T (iSCSIターゲットのIQN名) --op=update --name=node.startup --value=automatic

これで、先ほどの default ファイルを見てみると、見事に node.startup の値が automatic に書き換わったのが確認できる。

これで自動的にiSCSIへログインしてくれるのか、OS再起動して確認してみよう。
$ sudo shutdown -r now

再度ログインしたら、lsblkで見てみる。
$ lsblk
なんと、/dev/sdbだけじゃなく、その下の/dev/sdb1、それを用いたVG(vg-test)やLV(lv-test1)も認識出来ている。

後は、これを起動時にマウントするようにすればいい。

マウントポイントは今はあくまで暫定なので、自分のホームディレクトリに iscsivol というディレクトリでも作って、そこにマウントするようにしよう。
マウントポイントの作成と、手動マウント
$ cd
$ mkdir iscsivol
$ sudo mount /dev/vg-test/lv-test1 iscsivol
$ id
$ sudo chown (自分のユーザ名):(自分のグループ名) iscsivol
$ ls -ld iscsivol
$ df iscsivol
$ grep iscsivol /etc/mtab

マウント出来るのが確認できたら、/etc/fstabに書き加えて、OS起動時にもマウントされるようにしよう。

$ sudo vi /etc/fstab
--以下の行を追記--
/dev/mapper/vg--test-lv--test1 /home/(自分のユーザ名)/iscsivol ext4 _netdev 0 0
--ココまで

OSがブートする時の順番は、/etc/fstab でのエントリからファイルシステムのマウントをした後、ネットワークが立ち上がる。
ところが、iSCSI や NFS のマウント情報を /etc/fstab に記載しておくと、ネットワークの設定が終わらないうちにネットワーク先のファイルシステムをマウントしないといけない、という矛盾が発生する。
そのため、/etc/fstab の4番目のフィールドに _netdev オプションを記載しておく。これによって、ネットワーク設定が完了するまでマウントを遅延させることが出来る。

一旦アンマウントして、fstabに沿ってマウントされるか確認してみよう。
$ cd
$ sudo umount iscsivol
$ df iscsivol
$ cat /etc/mtab | grep iscsivol
$ sudo mount -a
$ df iscsivol
$ grep iscsivol /etc/mtab

再び再起動して、マウントされるか確認しよう。
$ sudo shutdown -r now

再びログインして確認
$ df iscsivol
$ grep iscsivol /etc/mtab

これで、iscsivolの下に5GBのファイルシステムがマウントされた。
とりあえずKVMの検証は、このファイルシステムを利用することにする。
＃いずれすぐに変更されることになるけどね。

あと、自動マウントを辞めたい場合は、/etc/fstabの記載から当該エントリを削除し、iSCSIの node.startup を manual に変更すればいいだろう。

今回はここまで。

KVMその1

というわけで、ようやく本命のKVMに入れる。
(初めて触るので、正直どこまでやれるか…)

なので、まずは環境整備から。

KVMを使用するためには、作業用端末でX Window System(以下X)を利用できる状態にする必要があるようだ。(サーバ本体でX Window Systemを動かしてもいいんだけど、それだと常にサーバの前にいないといけないので…)

で、作業用端末がWindowsの場合、X Window Systemが動くようにするには、幾つかの方法がある。

• 製品を買う。(ASTEC-XとかReflextionXとか)
• Cygwin-Xで頑張る
• VcXsrvを使う
• その他…

細かいことは抜きにして、今回はVcXsrvを使用することにする。(フリーだし、同じくフリーで実績のあったXmingの分離版らしいし。)
VcXsrvはsourceforgeからダウンロード出来る。(https://sourceforge.net/projects/vcxsrv/)
但し、動かすためには、VC++2015 Runtimeが必要だ。併せて入手しておこう。

細かいところは省略するけど、VC++RuntimeとVcXsrvをそれぞれインストールしておくこと。

導入が終わったら、VcXsrvを立ち上げておく。
スタートメニューから、VcXsrv→XLaunchを起動しよう。
起動したら、Display settingsで、画面の形式を指定するダイアログが表示される。
デフォルトの「Multiple windows」のまま「次へ」
Display numberもデフォルトの-1のままで構わない。

次のClient startupも、「Start no Client」でいいだろう。

次のExtra settingsも、デフォルトのままでいい。

最後に、この3画面分の設定を保存することが出来る。保存してもいいし、都度XLaunchから設定しても構わない。

タスクトレイに「X」みたいなアイコンが表示されたら起動完了だ。

続いて、teratermのssh転送で、X転送が可能なようにしておこう。
これは簡単で、ログイン前のteratermのメニューから、「設定」→「ssh転送」

出てくるダイアログの「リモートの(X)アプリケーションをローカルのXサーバに表示する」のチェックを入れて「OK」してから、sshでUbuntu Linuxへログインすればいい。

これで作業用PCの設定は終わりだ。
続いてUbuntu Linux側の環境を整えよう。

幾つか必要なパッケージがあるけど、最低限qemu-kvmは入れておく必要が有る。
$ dpkg-query -l qemu-kvm

OS構築の時に「Virtual Machine」というパッケージグループを入れているので、入っているはずだ。
もし入っていなかったら、以下のコマンドで入れておこう。
$ sudo apt-get install qemu-kvm

それ以外にも、virt-managerというのが入っていると便利らしいのだが、今はまだ入れないでおく。
この先、導入する予定だ。
$ dpkg-query -l virt-manager

で、qemu-kvmを導入した時かどこかのタイミングで、/dev/kvmというデバイスファイルが出来る。
このデバイスファイル、ubuntuの場合はグループがkvmグループになるはずなんだけど、そのためには一度再起動をしておく必要が有るらしい。
$ ls -l /dev/kvm

もし、/dev/kvmの所有グループがkvmではなかった場合は、一旦再起動しておこう。
$ sudo shutdown -r now

で、kvm関連の操作には、/dev/kvmへのアクセス権限も含めて、kvmグループに属しておく必要があるらしい。そのため、以下のコマンドで自分のアカウントをkvmグループに含める。
$ grep kvm /etc/group
$ id
$ sudo adduser (自分のユーザ名) kvm
$ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
$ id

あと、カーネルにkvmモジュールが組み込まれているか確認しておこう。
$ lsmod | grep kvm
使っているマシンがIntel NUCなので、kvm_intelとkvmの2モジュール出てくるはずだ。

ここまで来たら、kvmコマンド自体は使用可能になっているはず。簡単な操作で確認してみる。
$ kvm -monitor stdio
これを実行したら、勝手に一つウィンドウが開いたのではないだろうか？
これを表示させるために、先にVcXsrvをインストールした。
(作業用PCをUbuntu Linuxの間のネットワークが、モバイルネットワーク(4G回線等)の場合、表示されるまでに非常に時間がかかると思うが、数分待ってみて欲しい。)

よく見てみると、「Booting from Floppy」だの「Booting from DVD/CD...」だの、PCが起動する時のBIOSのメッセージに似ているというのに気付くはずだ。
最終的に「No bootable device.」で終わっている。
過去に、PCのOS用HDDがクラッシュしたことのある人なら、恐怖とともに見たことがあるメッセージではないだろうか？
QEMU環境で、簡単なBIOSブートをしてみた、というのがこの画面だ。
この画面が出れば、QEMU(KVMのベースとなる環境)が稼働しているということになる。

teratermの方を見てみると、プロンプトが(qemu)となっているはずだ。
これが、qemuを操作するためのプロンプトだが、詳細は不明なので、おいおい書いていくこととする。

qemuのプロンプトから、kvmの状態確認コマンドを打ってみる。
(qemu) info kvm
kvm spport: enabled と表示されるはずだ。
このマシンで kvm が利用できる、ということらしい。

最後に、quitで抜けておこう。
(qemu) quit
先ほど起動したウィンドウも消滅したはずだ。

まずはココまで。
--2016/06/20追記
間違って「X Windows System」と書いてしまってた場所が有ったので、「X Window System」に修正。
同じく「Flopply」と書いていたので、「Floppy」に修正。

iSCSIを利用しようその3

前回、iSCSIで10GBのディスク容量を確保出来た。

今度はそれをLVMでボリューム作成、ファイルシステム作成、及びマウントと読み書きをしてみたい。

その前にLVMって何？って話だけど…。
既にLinuxディストリビューションを使っていたり、HP-UXやAIXを使っている人なら説明は要らないと思うけど、念の為に書いておく。

LVMというのは、Logical Volume Managerの略だ。
物理HDDを、一度論理的に束ねて、それを今度は論理的に分割、ファイルシステムを載せるためのブロックデバイスにする仕組みだ。
これは、HDDの容量不足が起きた時に、システム停止をゼロもしくは出来るだけ短くするための仕組みだ。(実際には、さらに拡張され、ミラーリングやRAID5等の冗長構成も組めるようになっている。)

で、LVMを説明する時に、自分が必ず描く画がある。

これは、HDDからファイルシステム、ファイルまでの各層を示したものだ。
私は必ず、こういった画を描くようにしている。

実際のHDD(今回はiSCSIで見えてきた /dev/sdb を意味する)からファイルシステムまでの間に、複数の層が存在し、これらの層を通ってようやくファイルへのI/Oが出来るようになっている。

この内、LVMとなっている3つの層が、LVMで扱う層だ。
LVMが無かった頃は、mbr/gptパーティションのすぐ上に、File Systemの層が来ていた。

LVMの層をよく見て欲しいのだが、Volume Groupによって、複数のPhysical Volumeを一つにまとめ、それをLogical Volumeとして分割している。
これが、複数のHDDにまたがっている点が重要だ。

10GBのHDDが3本あるが、25GBの大きな一つの領域が必要だという場合、従来ならもっと容量の大きなHDDを買ってくる必要があった。
LVMによって、3つのHDDを束ね、25GBという大きなLogical Volumeを作れば、25GBという容量のファイルシステムを用意することが出来る。

また、使っている容量が不足気味になってきた場合に、新しいHDDを足して、Volume Groupに追加すれば、その上のLogical Volumeを拡張することが出来る。

これらが、LVMを使用する最大のメリットだ。

また、HDDを操作する場合、上記の層を意識しながら操作することで、自分が今何をやっているのか？それがドコに影響を及ぼすのか？が分かる。
より安全に操作することが出来る様になる訳だ。

では、先ほどの図に従って、下から順に作っていこう。(HDDは1本だけだけどね。)

まずは、mbr/gptパーティションの作成だ。
今回は、容量が10GBということもあって、mbrパーティションでも良いわけだが、敢えてgptで作ってみよう。
$ sudo parted /dev/sdb print
「ディスクラベルが認識できません」というようなエラーが出たはずだ。
これは、「このディスクをmbrで使いますか？gptで使いますか？」というフラグが立っていないために出るメッセージだ。
gptで使うよ、という指示をしておこう。
$ sudo parted /dev/sdb mklabel gpt
$ sudo parted /dev/sdb print

成功したら、パーティションの作成だ。今回は全体を使って、一つのパーティションにしよう。
$ sudo parted /dev/sdb mkpart primary 0% 100%
$ sudo parted /dev/sdb set 1 lvm on
$ sudo parted /dev/sdb print
"primary"と指定しているのは、名前に相当する部分らしい。マニュアルを見ると、primary / extended / logical を指定しろ、とのことだが、gptの場合は関係が無いはず。だが、コマンドラインでは何かを指定しないとパーティションが作成できない。
そのため、primaryを指定した。
先頭を0%と指定しているのに、出来上がったパーティションは1029kBから、となっていると思う。(ディスクのタイプによって異なるかも)
これは、gptの場合は先頭部分が少し利用できない(予約領域)からだ。1MB程度の容量減なので、気にしないでおこう。
また、2行目は、「この領域をLVMで使用するよ」というフラグだ。必要かどうかはイマイチ分かっていない。

パーティションが出来上がったら、/dev/sdb1が出来上がっているはずだ。
$ ls -l /dev/sdb*
この/dev/sdb1が、sdbに作った一つ目のパーティションだ。(一つしか作っていないので、sdb1しか無いのは正常だ)

今度は、これ(/dev/sdb1)を、LVMのPhysical Volume(PV)として定義しよう。
$ sudo pvcreate /dev/sdb1
$ sudo pvdisplay /dev/sdb1
$ sudo pvs /dev/sdb1
一つ目のコマンドが、/dev/sdb1をPVとして定義するコマンド。
二つ目、三つ目のコマンドは、PVとして定義されているかどうかの情報を見るコマンドだ。
PVとして定義されてなかった場合はエラーになる。

PVとして定義出来たら、今度はVolume Group(VG)を作成し、このPVをVGの1つとして定義する。
$ sudo vgcreate vg-test /dev/sdb1
$ sudo vgdisplay -v vg-test
$ sudo vgs vg-test
一つ目のコマンドがVGを作るコマンドだ。vg-testというのが今回作成したVGの名前で、既に存在しているVG名は使えない。また、最後のコマンドが、そのVGに格納するPVのデバイスファイル名だ。
二つ目、三つ目が、そのVGの詳細情報を確認するコマンドになる。
また、PVを確認する時の pvdisplay 及び pvs コマンドも、先ほどと若干異なる出力になるはずだ。(属するVGの名前の欄が、先程まで空欄だったのが、vg-testと入っているはずだ)

また、vgcreateには多くのオプションがあり、細かなチューニングが可能だが、デフォルトで特に不都合は無く使えるはずだ。この辺りは、いずれ必要になったら記載する。

これで、VGの作成が完了した。

VGが作られたら、次はLogical Volume(LV)だ。
上の図では、LVは4つ作っているが、今回はあくまでテスト的なものなので、1つだけ作る。
$ sudo lvcreate -L 5G -n lv-test1 vg-test
$ sudo lvdisplay -v vg-test/lv-test1
$ sudo lvs vg-test/lv-test1
例によって、一つ目がLVを作成するコマンドだ。
ここでは、vg-testから5GBの容量で、lv-test1というLVを作成する、というコマンドになっている。
二つ目、三つ目が詳細確認になる。
また、併せてVG確認コマンド、PV確認コマンドも使ってみて欲しい。
若干の変化があるはずだ。

ココまで来たら、今度はファイルシステムを作る流れだ。
ext4で作っておけばいいだろう。
$ sudo mkfs.ext4 /dev/vg-test/lv-test1
$ sudo blkid /dev/vg-test/lv-test1

そこまで行ったら、マウントしてI/O出来るか確認してみよう。
$ sudo mkdir -p /mnt/tmp
$ cat /etc/mtab | grep /mnt/tmp
$ sudo mount -t ext4 /dev/vg-test/lv-test1 /mnt/tmp
$ cat /etc/mtab | grep /mnt/tmp
$ sudo touch /mnt/tmp/hogehoge
$ sudo sh -c 'echo "foobar" >> /mnt/tmp/hogehoge'
$ cat /mnt/tmp/hogehoge
$ sudo rm -i /mnt/tmp/hogehoge
$ sudo umount /mnt/tmp

これで、iSCSI領域をI/Oすることが出来るようになった。

本来ならここで、LVMの活用例として

• HDDの追加
• VGの拡張
• LVの拡張
• FSの拡張
• PVの移動
• LVMミラー
• FSの縮小
• LVの縮小
• VGの縮小
• PVの取り外し

あたりを書くべきだと思うけど、それはおいおいやっていくことにして、ぼつぼつKVM周りのことを検証していきたい。

iSCSIを利用しようその2

というわけで、Ubuntu LinuxをiSCSIイニシエータ(使用する側)に仕立てあげよう。

まずはNAS側で、10GB程の新規LUN(Logical Unit Number:前回の図で言うところの、仮想HDDだ)を作成、併せてiSCSIターゲットを新規作成し、両者を結びつけておこう。
これは、NASの製品によって手順が違うので、各自NASのマニュアル等を参照して欲しい。

また、その時にiSCSIターゲットのIQNというのもメモしておこう。

IQNというのは、iSCSIターゲット、イニシエータ両方とも持つ特殊な名前で、iSCSIは相手の識別にこのIQNというのを使用する。
IQNという名前は決まったフォーマットで、iqn.YYYY-MM.com文字列:任意の文字列-文字列 みたいなちょっと面倒くさい名前だ。
これは大抵自動生成されるはず。一つのiSCSIネットワーク内でIQNが重複すると危険なので、自動生成されたものをそのまま使おう。

で、Ubuntu Linux側だ。
Ubuntu LinuxでiSCSIイニシエータを実現するパッケージはopen-iscsiというヤツだ。
こちらをインストールしてしまおう。
$ dpkg-query -l open-iscsi
なんと既に入ってたよ。

もしインストールされてなかったら、
$ sudo apt-get update
$ sudo apt-get --simulate install open-iscsi
$ sudo apt-get install open-iscsi
$ dpkg-query -l open-iscsi
でインストールしておこう。

インストール出来たら、自分自身(Ubuntu Linux自身)のiSCSIのIQNを確認しておきたい。
open-iscsiでは自分自身のIQNは、
/etc/iscsi/initiatorname.iscsi
というファイルが自動生成されて、そこに記録されるようだ。
中身を見ておこう。
$ sudo cat /etc/iscsi/initiatorname.iscsi

IQNが確認できたら、NAS側のiSCSIターゲットの設定で、そのIQNからのアクセスを許可しよう。(読み書き両方可能にしておこう)
これも、各NASのマニュアルを参考に。なお、私のNASでは「マスキング」という定義の名前だった。
また、NAS側で「CHAP認証」という機能が使えるかもしれないが、これは使わないようにする。
(ユーザ名・パスワードによるアクセス制御をかけるより、IQNのマスキングでアクセス制御を掛けた方が、遥かに楽だし、CHAPによるアクセス制御を掛けるメリットはほとんど無いはず。)

次は、iSCSIイニシエータ(Ubuntu Linux)側から、iSCSIターゲットを検出させる。
これはiscsiadmコマンドを使うらしい。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
これで、NASのiSCSIターゲットのIQNが表示されるはずだ。

そうしたら、iSCSIターゲットへログインする
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
これで、NAS側で定義した、10GBのディスクが見えてくるはずだ。

dmesgで確認してみよう。
$ dmesg

私の環境では、scsi 4:0:0:0、デバイスファイル名 /dev/sdb として見えてきた。
本当に /dev/sdb として見えているか確認してみよう。
$ lsblk /dev/sdb
設定した通りの10GBの容量で見えてきているだろうか？

これで、HDDを増設した時と同じように、/dev/sdb を操作することが出来るはずだ。

ちなみに、デバイス認識時にdmesgを実行することで、デバイスIDを確認することが出来る(先ほどの4:0:0:0)が、長期間使っていたらどうせド忘れしてしまうだろう。
その場合、/sys/blockを見ることで、ある程度分かる。
こちらの環境では、/sys/block/sdbというファイル(シンボリックリンク)が存在し、そちらの指し示す先で分かるようだ。
$ ls -l /sys/block/sdb
lrwxrwxrwx 1 root root 0  6月 12 17:46 /sys/block/sdb -> ../devices/platform/host4/session1/target4:0:0/4:0:0:0/block/sdb
これを見ると、4:0.0.0というパスが出てくる。これがデバイスIDのようだ。

とりあえず、iSCSIのディスクが見えるところまでは確認できた。
次回はコレをLVMでボリューム作成、ファイルシステム作成してマウントするところまでやってみたい。

--2016/06/13追記
NAS側で10GBのLUN(仮想HDD)を作っているが、この時「シンプロビジョニング」を指定していたら、後の方でmkfs.ext4が出来ないことが発覚。
恐らく、使っているNASが低価格モデルなので上手く動かなかったのかと。（同メーカーの上位モデルを使っている方は、シンプロビジョニングでも問題なく利用できている模様。）
そのため、私の方では、シンプロビジョニングを使用しない形で作りなおしている。

--2016/07/06追記
iSCSI LUNをシンプロビジョニングで作成したら、mkfs.ext4が上手く行かなかったと書いた。
具体的には、mkfs.ext4はすぐ終わるのだが、syslog(/var/log/syslog)にエラーが記録されていて、マウントしようとしたらエラーが出る、という状態だ。
どうやら、mkfs.ext4 に -D のオプション(direct I/Oのオプションらしい)を付けると、syslogにもエラーは記録されず、普通にマウント出来るようだ。
既に、iSCSI LUNをフルプロビジョニングで作成して利用してしまっているので、今回はこのまま続けていくけど、どこかのタイミングでシンプロビジョニングのLUNと入れ替えようと思う。

--2016/07/21追記
シンプロビジョニングのiSCSI LUNに対して、フォーマットはmkfs.ext4に-Dを付ければヨカッタんだけど、その後ファイルシステムに対してファイルの書き込みをやったらエラーになった。
どうも何かが違うなぁ…。

--2016/07/23追記
少しわかった。
コチラに記載しているけど、次からはLUNの作り方を少し変えることにする。

iSCSIを利用しようその1

私が使っているNASキットは、通常のCIFS(Windowsファイル共有)とNFSだけでなく、iSCSIも利用することが出来る。
これを使って、Ubuntu Linuxにディスク領域を提供し、データ置き場にしてみたい。
(そもそも、NASキットでiSCSIストレージが使えるから、Ubuntu Linuxを搭載するNUCは120GB程度のSSDにしたんだった)

で、「そもそもiSCSIってナニよ？」ってところなんだけど…。
ご存じの方はご存知の通りなので、軽く読み飛ばして欲しい。

ご存知ではない方へ…
iSCSIとは、「Internet Protocol上にSCSIプロトコル(SCSIコマンド)を流す仕組み」だ。
うん、さっぱりワカランね。

SCSIっていうのは、Small Computer System Interfaceの略で、小型コンピュータ(ココでは、一般家庭のPCや、Interl x86系プロセッサを搭載したサーバ機器等)と各種外付デバイスを接続する規格の一種で、コネクタ形状やケーブル形状といった物理規格、当然電気的な規格(電圧等)、そしてその中を流れるコマンド類まで規格化されている、らしい。

また、色々なSCSIデバイスが生み出されてきたが、その特性からHDDやCD-ROM等のブロックデバイスに使用されることが多かった。
＃いわゆる記憶媒体だけでなく、SCSIデバイスのスキャナもあった。
＃逆に、SCSI接続のマウス、みたいなキャラクタデバイスは見たことが無い。

こういったSCSI規格のうち、ソフトウェア的な部分(コマンド類)を、今までのSCSIケーブルではなく、IP上に載っけてしまおう、というのがiSCSI規格だ。

SCSIに於ける機器の関係は以下のとおり。

PCにSCSIアダプタを搭載し、そこからSCSIケーブルを伸ばし、HDDがつながっているSCSIコントローラに接続する、という形だ、思う。

iSCSIは、上図の「SCSIケーブル」のところがEtherケーブルになっていて、IPネットワーク上に構築される形だ。
多分こんな形

SCSIで「コントローラ」とされていた部分は、ソフトウェアで実装されており、通常のNetworkにデータが流れるようなイメージになっている。
また、HDD側も同様に、ソフトウェアでコントローラが実装されていて、通常のNetworkに接続されている。
(コントローラをハードウェアで実装しているものもある)

そして、PC側のコントローラを「iSCSIイニシエータ」、HDD側のコントローラを「iSCSIターゲット」と呼ぶ…らしい。(詳細はちょっと違うけど)
これ、「iSCSIクライアント」と「iSCSIサーバ」って表現にしてくれたら分かりやすかったのに。

で、HDD側で容量を適当に切り出して、

その領域をターゲットに紐付けて、

ターゲットごと、イニシエータに提供する(アクセス許可を与える)

それによって、PCにあたかも新しいHDDを追加搭載したように見える。

細かくは色々あるんだけど、ざっくりこんな感じだ。

で、上記の設定を施して、Ubuntu LinuxからiSCSIのディスク領域を使えるようにしよう、ってのが今の思い。

長くなったので、一旦ココまで。
次回分から、実装にとりかかる。

WoLでWindows機の遠隔起動

さて、前回(前回は閑話休題なので、前々回か)の予告通り、Wake on LAN(Wake On LANって書いてたけど、どうやら On は小文字の on が正解っぽい)でWindows機の電源を入れられるようにしよう。

とは言え、WoLを使えるようにするには、WoLを受ける側(Windows機)の方の設定も必要だ。
BIOS/uEFI及びOS側で設定を施す必要が有るらしい。この辺りは、機種、OSによって異なるし、機種によっては対応していないものもある。
なので、各自調べてみて欲しい。
基本的には、BIOSメニューに「Wake on LANの項目があるか？」と「OSから見たNetwork Interface Card(NIC)のプロパティに、Wake on LAN(モノに寄ってはWake On Magic Packet)の項目があるか？」辺りがポイントだ。
軽くググッたら、このページが見つかった。これを参考にWindows機を設定すればいいだろう。
http://www.atmarkit.co.jp/ait/articles/0602/25/news014.html

設定が終わったら、合わせてWindows機のMACアドレスを確認しておこう。
コマンドプロンプトからipconfig /allで確認可能だ。
A1-B2-C3-D4-E5-F6
という形式で確認出来ると思う。ただ、ハイフン区切りではなく、:区切りを利用することが多いので、:区切りでメモしておこう。
A1:B2:C3:D4:E5:F6

Windows機側の設定が終わったら、起動を仕掛けるUbuntu Linux側の設定だ。
WoLは、呼び出し元が特殊なパケットを流し、起動する側が(OSが眠っているにも関わらず)そのパケットを受け取って「お、呼ばれた！」って起動し始めるという流れ。
今回の構成の場合、呼び出し元がUbuntu Linuxで、起動する側がWindows機になる。

その呼び出し元であるUbuntu Linuxが、特殊なパケットを投げられるようになっている必要が有る。

で、調べてみたらそういうことが可能なパッケージが複数種類存在するようだ。

• powerwake
• etherwake
• wakeonlan
• gwakeonlan

それぞれ得手不得手があると思うんだけど良く分からない。
ただ、コマンドバージョンがwakeonlan、GUIバージョンがgwakeonlanという風に、CUI/GUI両方あるうちのコマンドバージョンwakeonlanを使いたいと思う。

さっそくインストールしよう。
$ dpkg-query -l wakeonlan
(まだインストールされていないはず)
$ sudo apt-get update
$ sudo apt-get --simulate install wakeonlan
$ sudo apt-get install wakeonlan
$ dpkg-query -l wakeonlan
(インストールされた)

さっそく使ってみよう。
の前に、対象のWindows機をスリープにしておこう。(休止状態やシャットダウン状態でも可能だと思うが、スリープからの起動が一番確実なので、まずはスリープから。)

そうしたら、Ubuntu Linuxから以下のように実行してみる。
wakeonlan 対象のWindows機のMACアドレス
具体的には以下だ
$ wakeonlan A1:B2:C3:D4:E5:F6
どうだろう？無事にWindows機は立ち上がってきただろうか？

無事に立ち上がってきたら成功だ。

一応、wakeonlanコマンドは他のパターンもある。

例えば、一度に複数のPCにWoLパケットを投げることが出来る。

この場合、単純にMACアドレスを複数並べるだけだ。
$ wakeonlan A1:B2:C3:D4:E5:F6 A6:B5:C4:D3:E2:F1

呼び出し元(今回のUbuntu Linux)が複数のNICを持っていて、起動したい対象がつながっている方にだけMagic Packetを投げたい場合。

wakeonlan -i (投げたい方のBroad Cast Address) 対象のMACアドレス
具体的には以下の通り
$ wakeonlan -i 192.168.0.255 A1:B2:C3:D4:E5:F6

また、MACアドレスを覚えるのでも大変なのに、どの機器のMACアドレスか？を覚えるのも大変だ。
そのため、ファイルに記載しておいて、そのファイルを読み出すオプションもある。
ファイルの書き方は、wakeonlanをインストールした時に一緒に導入されるサンプルファイルを見るとすぐ分かるはずだ。
サンプルファイルの場所：/usr/share/doc/wakeonlan/examples/lab001.wol

私は、Ubuntu Linux上のホームディレクトリに wol というディレクトリを作成し、そこに「起動したい機器のホスト名」のファイルを作成、そのファイルの中にMACアドレスを記載する形にしている。
＃要するに、wakeonlan対象機器が増えれば、その分 wol/* が増える、ということだ。

で、そのファイルの指定方法が以下の通り
wakeonlan -f (ファイル名)
具体的には以下
$ wakeonlan -f wol/filename

これで、Wake on LANでWindows機を起動することが出来るようになった。

あと、休止状態とシャットダウン状態のどちらからでも起動出来るかも確認しておこう。
一応、私の環境では

• スリープからの復帰：OK
• 休止状態からの復帰：OK
• シャットダウンからの復帰：NG

だった。Windows機の設定ミスか、ハードウェア的に実施NGなのか…。
とりあえず、シャットダウンしなければいいので、当面はそっちで逃げる。
どうせ古いPCなので、近いうちに作りなおす予定だからね。

あー、ちなみに起動する対象をWindows機に絞った表現だったけど、別にWindows機に限ったことじゃないから…。

2016/06/07追記
シャットダウン状態からのWoLが出来なかったのは、NICの設定漏れだった。
OS(Windows7)からNICのプロパティで、「シャットダウンからの云々」とかいうパラメータを「オン」にすることで、シャットダウンからのWoL起動も出来るようになった。

閑話休題

しかし、色々と技術系ブログを見ていると、みんな更新頻度高いなぁ。

記事一つ書くのにも、絵を書いたりして色々時間がかかるんだけど、みんな手が早いってことかな？

これぐらいのペースで書けるようになりたいよ…。

sshトンネルを使ったリモートデスクトップその2

前回は、軽くポートフォワーディングについて記載した。
んで、自宅内のWindowsマシンに、外出先からリモートデスクトップ(RDP)接続出来るようにしたい。

ただ、「外部からsshでログインその1」でルータに設定を施したように、Windowsマシンへも転送するようにすれば、別にsshを通す必要は無い。

これなら、RDPのポート番号さえ分かっていれば、簡単に実現できる。

ただこの場合、幾つか問題点がある。

1. WindowsPCが増えるたびに、ルータのポート転送を追加する必要がある
2. 当然、WindowsPCが減ったら、ルータのポート転送を削除する必要がある
3. ポートスキャンをかけると、RDPサービスだということがバレる
4. アクセス制御が、RDPの仕組み(ユーザ認証)しか無い
5. 生RDP通信であり、暗号強度が不安(どのような暗号アルゴリズムなのか不明)
6. ルータにたくさんの穴開けをしないといけなくなる(台数分)

1,2,6は、「そもそもそんなにWindowsマシン作らないよ」ということになると思うが、今後Ubuntu Linuxマシンや、Windowsマシン上に仮想マシンを作って、WindowsOSをどんどん作っていったら…？なんてことを考えると、意外と管理に手間がかかる。
(ま、WindowsOSのライセンスが高いので、そんなに作ることは無いと思うが)

3,4,5は、RDPセキュリティに関連するそのことだが、正直RDPの暗号強度が高いとは思えない。
また、「外部からsshログインその1」「その2」で書いたように、外部からのアクセスはユーザID/パスワードの組み合わせ以外の仕組みも使いたい。

そういった点を考慮しつつ、それでもRDPで接続出来るようにならないか？
というところで出てくるのが、先に紹介した「sshポートフォワーディング(ローカルポートフォワーディング)」だ。
ローカルポートフォワーディングを使って、以下のような接続状況を作ればいい。


と言っても、これだけではイマイチ良く分からない。
なので、実際に動かしながらやってみよう。

条件としては、外(The Internet側)から、家の中のUbuntu Linuxへsshログイン出来ること。
Ubuntu Linuxと同じネットワーク内(家のネットワーク)に、RDP接続を許可したWindowsマシンがいること。(そもそも、WindowsのHome EditionではRDP接続出来ないため、Professionalとかそういうエディションを使うこと)
作業用PC(クライアント)は、Windows＋teratermでサンプルを書く。

1. teratermでsshログインする前の設定
   ログインする前に、teratermの設定でSSHポート転送を有効にしておこう
   
   
   
   設定内容は以下の通りだ。
   
   • ローカルのポート
     13389
   • リッスン
     127.0.0.1
   • リモート側ホスト
     接続先Windows機のIPアドレス
   • ポート
     3389
2. sshログイン
   上記の設定を施したら、「OK」ボタンで設定を確定し、今まで通りにUbuntu Linux機へsshログインしよう。
3. RDPクライアントでログイン
   端末側でRDP接続を起動して、以下のようにログイン情報を入力する。



• コンピュータ
  127.0.0.1:13389 (sshポートフォワードの設定で入れた「リッスン」と「ローカルのポート」を「:」で繋いだもの）
• ユーザ
  接続先Windows機のユーザアカウント名
これで接続すると、通常のRDP接続と同様、パスワードを聞いてくるダイアログが出てくる。(証明書関連の警告も出てくると思うが、そちらは普段通りにOKしてくれればいい)
また、ここで入力するパスワードは、操作用PC(クライアント)のパスワードではなく、接続先の(自宅内の)Windowsマシンのパスワードだ。



この時のダイアログをよく見てみて欲しい。
「これらの資格情報は、127.0.0.1(RDP接続先のIPとして指定したIP)への接続に使用されます。」となっているはずだ。
このアドレスは、自分自身を示すアドレスのため、「遠隔のWindows機ではなく、自分自身へ接続しようとしている」ことになる。
これが、ローカルポートフォワーディングの基本的な考え方だ。
つまり「ローカル(自分自身)への接続を、他のマシンへ転送する」ということだ。
4. リモートデスクトップ接続に成功する
   成功すれば、リモートデスクトップの画面が出てくるはずだ。
   
   
   
   これで普通に操作が可能だ。
   ウィンドウタイトル部分をよく見てみると、接続先が「127.0.0.1:13389」になっていると思う。これは、RDPクライアントとしては「127.0.0.1:13389」へ接続していると思い込んでいる、ということだ。実際には、sshがパケット転送をしてくれて、自宅内のWindows機へ接続している形になっている。

さてこれでRDP接続が出来るのが確認できた。
そこで、一体どのようなフローで接続できたのかを確認しておきたい。

簡単な図に書いてみたが、先にポートフォワードを有効にしてsshログインを行うことで、作業用PCとUbuntu Linuxの間でポート転送の設定が行われる。
その上で、RDP通信を行うと、上記図のようにRDP通信がsshのコネクション内を通って行く形になる。
そして、そのRDP通信を受けたsshd(sshサーバ)が、指定されたIP:ポートへパケットを転送する、という形だ。
TCP通信のため、当然戻りパケットも発生するが、これは同じ経路を通って流れていく。
ちょうど、sshで作成したコネクションをトンネルにして、他の通信(この場合RDP通信)が流れていくため、「sshトンネル」等と呼ばれている。

この図で記載したが、赤い線で示した区間は、sshによる暗号化通信が行われている。そのため、単純にパケットを読み取られても、それがRDP通信であることは分からない。（ssh暗号を解読して、初めてRDPであることが判明する。）
そのため、非常に強固で安全性の高いRDP通信を行うことが出来る。(当然、sshの暗号アルゴリズムは強固なものを使う前提だ)

更に、ブロードバンドルータ側には、RDPのための設定は一切行っていない。ポート転送はsshのみだ。

最初にsshによる認証が必要になり、こちらは既に公開鍵認証方式のみ利用できる設定にしているため、外部からのパスワード推測系の攻撃を受けても、突破されることは無い。

とまぁこのように、セキュリティレベルをある程度維持したまま、宅内のWindows機へRDP接続が出来るようになった。
以後は必要に応じて、このパターンでRDP接続しよう。

となると、普段電源を落としている or スリープモードにしている or ハイバネーション(休止状態にしている)Windowsマシンを、遠隔で電源入れられるようにしたい。Wake On LANだ。
次はWake On LANに挑戦したい。

今回は以上。