仮想ディスク領域が共有されている状態でのライブマイグレーション

さて、多分これで、gemini 上で動いている leo を、稼働させたまま cancer へ移すことが出来るのではないか？
これを行うためには、gemini / cancer に接続可能なマシン上で virt-manager を動かすのが都合がいい。
やり方としては

1. gemini 上で virt-manager を起動し、cancer への追加接続する
2. cancer 上で virt-manager を起動し、gemini への追加接続する
3. sagittarius 上で virt-manager を起動し、gemini / cancer 両ノードへ追加接続する

等が考えられる。

今回は3番目を試してみることにする。

まずは、sagittarius 上で virt-manager を起動しよう。
(sagittarius) $ virt-manager
起動したら、メニューバーの「ファイル」から「接続を追加」だ。

出てきたダイアログを、以下の図のように設定。
ユーザー名は、gemini 上のOSアカウント名だ。
また、ホスト名は gemini の IPアドレスを入れよう。

接続ボタンを押すと、すぐには反応が無いはず。
この場合、 gemini に接続している teraterm を見てみよう。
「エージェント転送要求を受け入れますか？」というダイアログが出てきていたら、「はい」と答えよう。

無事に gemini への接続が行われ、leo が稼働しているのが分かるはずだ。

同じ手順で、 cancer にも接続しておこう。

もし、一連の作業が上手く行かなかったら、sagittarius から gemini / cancer へ ssh 接続してみよう。今回の設定は、ssh を使って接続しているので、そもそも ssh が利用できなかったら接続できない。
また、「エージェント転送を受け入れますか？」に関しては、 teraterm の設定で無条件に受け入れるようにすることも可能だ。セキュリティ的にどうかと思うが、面倒くさかったら自動受け入れにしてもいいだろう。teraterm.ini の ForwardAgentConfirm というパラメータだと思う。

ちなみにこの先、ちょっとオペレーションするたびに、「エージェント転送を受け入れますか？」と聞かれる。マジで鬱陶しい。teraterm.ini を書き換えたら、teraterm を再起動する必要があるので要注意だ。

さて、実際にライブマイグレーションする前に、状況を確認しておこう。
本当に稼働中かどうかを確認するために、leo へログインしておく。

gemini / cancer の仮想マシン状態をチェックしておこう。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all

また、gemini / cancer 両ノードから、 leo へ ping を打ち続けておこう。
(gemini) $ ping 192.168.55.138
(cancer) $ ping 192.168.55.138

先程起動した virt-manager の gemini の中にある leo を右クリック、表示されたコンテキストメニューから「移行」を選択だ。

出てきたダイアログに対し、「移行先のホスト」は cancer の接続設定を、モードは「ダイレクト」と「トンネル」があるが、今回は「ダイレクト」を選んでみた。「トンネル」では、条件が整わずに実行エラーになった。こちらは別途調査。移行先のアドレスは、まだ名前解決が出来ないので、cancer の IP アドレスを直接入力。

これで「マイグレーション」を押すと…
(例によって「エージェント転送を許可しますか？」と聞かれるので「はい」だ)

少し(10秒程度？)で、移行が完了したことが分かる。
(先程まで gemini にあった leo が、cancer の方に移動していることが分かる。)

ping も途切れていないし、leo へログインしていたセッションも切れていないはずだ。

では、gemini / cancer の状態を確認。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all

gemini から leo の定義ファイル(/etc/libvirt/qemu/leo.xml)が消えて、cancer に移っているのが確認でき、更に leo が cancer 側で動いているのが確認できる。

ライブマイグレーションはこのように実施できるのが確認できた。
cancer 上で leo の起動停止も出来るはずだ。
合わせて確認してみて欲しい。

次は、/etc/libvirt まで共有化し、その上でライブマイグレーションが可能かどうか？を確認したい。
それに備えて、先程の手順と同様に、leo を gemini に戻し、leo を停止させておこう。
(leo を停止してから移動、つまりオフラインマイグレーションはこの手順では出来ないようだ。)

今回はココまで。

sshのエージェント転送を使おう！

ゲストOSのpisces/ariesは、物理的にはホストOSであるaquariusの中に入っているけど、Open vSwitchのブリッジのお陰でネットワーク的にはaquariusや他のPCとフラットな関係にある。

そのため、作業用の端末を家のLANに繋いでいる場合、pisces/ariesへは直接sshログインが出来る。

ところが、外から接続する場合、今はルータの設定上、一度aquariusにログインした後、pisces/ariesへログインするという、sshを多段に通す必要がある。

ルータの設定で、pisces/ariesへポート転送すれば、外からも直接アクセス出来るようになるんだが、あまり穴を空けすぎるのも危険なので、外から接続する時は、aquariusを経由しなければならない制約は我慢することにする。

で、sshの鍵の配置について考えてみよう。

作業用端末を家のLANに直接繋いでいる状態で、pisces/ariesへ直接ログインする場合、作業用端末のssh公開鍵をpisces/ariesへ登録しておけばいい。
これは、sshで接続＠鍵認証で行った公開鍵の登録と同じ作業を行うということだ。

作業用端末が外にあって、外からaquariusにsshログインし、そのセッションからpisces/ariesへsshログインする場合は？

普通に考えれば、aquariusで鍵ペアを作成し、その公開鍵をpisces/ariesに登録すればいいと思う。

この場合、作業端末で作成した鍵ペアと、aquariusで作成した鍵ペア、両方を管理しないといけなくなる。
今はまだいいが、将来増えてくると、ちょっと管理しきれなくなる。
そこで出て来るのが「エージェント転送」という機能だ。

エージェント転送は、sshで接続＠Agent認証その2の最後に名前だけ出している。ようやく、解説と実装する機会が来た、というわけだ。

エージェント転送とは…
sshの鍵認証のやり取り部分を、もう一つ手前のsshセッションに任せる、という感じの仕組みとなる。
文章だと分かりにくいが以下の図を見ればわかると思う。

つまり、踏み台になっているaquariusで鍵ペアを作る必要はなく、作業用端末で持っている秘密鍵で認証が出来るわけだ。

これなら、複数の鍵ペアを管理する必要は無い、だけでなくpisces/ariesへ直接ログインする時も、aquariusを経由してログインする時も、同じ鍵を使って認証出来る。

これを実現するためには、条件が2つある。
一つは、言うまでもなく、最終接続先であるpisces/ariesに、作業端末の公開鍵が登録されていることだ。

もう一つは、作業端末→aquariusの接続で、エージェント転送を許可していることだ。

それぞれ実装しよう。
まずは、pisces/ariesに公開鍵を登録する。
これは、sshで接続＠鍵認証と同じ手順でいいのだが、既にaquariusに登録されている鍵を、そのままpisces/ariesへ持っていって登録すればいい。

以下の手順で実施しよう。
piscesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.133:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.133
(pisces)$ mkdir .ssh
(pisces)$ chmod 700 .ssh
(pisces)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(pisces)$ rm authorized_keys.aquarius
(pisces)$ exit
ariesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.134:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.134
(aries)$ mkdir .ssh
(aries)$ chmod 700 .ssh
(aries)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(aries)$ rm authorized_keys.aquarius
(aries)$ exit

次は、作業端末→aquariusの接続でエージェント転送を許可、だ。

これは、teratermからのsshログイン時、ユーザ名を入力するダイアログにある「エージェント転送する(O)」にチェックボックスを入れておくだけでいい。

一旦ログアウトして、再度ログインする時にチェックを入れよう。

そこまで準備が整ったら、エージェント転送の確認だ。
既にaquariusへはログインしていると思うので、そこからpisces/ariesへログインしてみよう。
(aquarius)$ ssh 192.168.55.133
もしくは
(aquarius)$ ssh 192.168.55.134
「エージェント転送要求を受け入れますか？」というダイアログが出てきたと思う。

このダイアログに対して、「はい(Y)」を選択してみよう。
パスワードを入力することもなく、ログインすることが出来たはずだ。
これによって、鍵ペアを複数管理する必要もなく、ログインパスワードを入力する必要もなく、多段ログインが出来るようになった。

更に、作業端末を家のLANに直結して、pisces/ariesへ直接ログインする時も、パスワード認証をせずにログインが出来るようになったぞ。

というところで、今回のsshエージェントに関してはオシマイ。

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」に修正。

sshで接続＠Agent認証その2

前回で、Pagent用の秘密鍵は作成した。
 
次は、そのPagentを利用する流れだけど…。実はそんなに難しくない。
作成した秘密鍵をダブルクリックすると、パスフレーズを入力するダイアログが出てくるはずだ。そこに、秘密鍵のパスフレーズを入れればいい。


「OK」を押したら、ダイアログが消えて、何も無かったかのような状態になる。
が、タスクトレイ上に、pagentのアイコンが出来ているはずだ。


このアイコンを右クリックして出てくるメニューから、「View Keys」を選んでみよう。そうすると、このPagentが取り込んでいる鍵の情報が出てくる。
これが、先ほどダブルクリックした鍵だ。


Pagent側はこれで準備が整った。
 
今度はteraterm側だ。
teraterm側は、sshログインの認証方式を選択するダイアログで、以下の様な状態にすればいい。


ユーザ名を入力し、認証方式を「Pagentを使う」にすればOKだ。
これで、パスフレーズを入力することなく、鍵認証でログインすることが出来る。
何回ログインしても、パスフレーズを入力しなくていい。
これがAgent認証だ。
本当にPagentを使用しているか疑問に思えたら、タスクトレイからPagentを終了して、再度teratermからログインしてみたらいい。Pagentが無い、と怒られるはずだ。
 
ただし、手元のWindows端末を再起動する等で、常駐しているPagentが終了した場合は、再度秘密鍵をダブルクリックして、Pagentに鍵を読み込ませる必要がある。
この辺りは身体で覚えよう。
 
また、agent方式を使うと、agent転送という機能も利用できる。
上の認証方式を入力する画面でも「エージェント転送する」というチェックボックスがあるので、そういう名前の機能が存在することはわかると思う。
このエージェント転送、複数台のサーバを経由するようなログインには非常に便利なのだが、今はまだそういう機能を使うメリットが無い。いずれ使う機会もあると思うので、その時に書こうと思う。
 

sshで接続＠鍵認証

IPアドレスの固定化が出来たので、遠隔からログイン出来るようにしておきたい。
とは言っても、既にssh-serverは導入済みのはずなので、クライアント側の設定を行えばいい。
クライアント側は、Windowsならteratermやputty等を使えば、すぐにログイン出来るようになると思う。
ここでは、teratermとputtyの中のpagentを使い、agent認証でログインできるようにする。
が、まずは鍵認証が出来るように。

teratermのインストールが終わったら、まずは鍵ペアを作成しよう。
teratermの起動直後の「新しい接続」ダイアログは「キャンセル」。
メニューバーの「設定」から、「SSH鍵生成」を選択しよう。

鍵生成のダイアログが出てくる。

鍵の種類は色々あるけど、汎用性があってそこそこ使えるのはRSA。鍵長(ビット数)も、2048でとりあえずは十分だろう。これを長くすると、暗号強度は高まるが、処理にかかる負担も大きいので、大きくしたとしても4096までにしておいた方がいいだろう。
鍵の種類とビット数を決めたら「生成」ボタンを押す。
しばらくすると、ダイアログが以下のように変わるはずだ。


ある程度慣れている人だと、パスフレーズ無しの方が使い勝手がいい、ということで、パスフレーズ無しにしている人も多いと思うけど、agentを使うことも考えているので、ここはパスフレーズを入力しておく。


後は、「公開鍵の保存」と「秘密鍵の保存」の両方のボタンを押して、それぞれをファイルに保存しておこう。
(既に作っている鍵もあるので、ファイル名はそれぞれ id_rsa_usekey.pub と id_rsa_usekey にしてある)



ここまで出来たら、ログイン確認をする。
デフォルトでは確か、パスワード認証も鍵認証も両方許可されていたと思うので、ここでは両方試してみる。

まずはパスワード認証。
メニューバー「ファイル」から「新しい接続」を選ぶ。


ホストの欄に、前回設定したIPアドレスを、サービスはSSH(ポートも22番)で、SSHバージョンはSSH2にしておこう。(既にSSH1では接続出来ないはず。)


これで「OK」を押すと、以下のダイアログに変わるはずだ。
(初回接続時は、ホスト鍵保存していいか？というダイアログが出てくる。OKを押しておこう。)
下の方のラジオボタンは「プレインパスワードを使う」にしておこう。
ユーザ名にUbuntu上のアカウント名、パスフレーズに、そのアカウントのパスワードを入力し、「OK」を押すと、ログイン出来るはずだ。


通常のパスワードでログイン出来るのが確認できたら、次は先ほど作成した鍵を用いて認証出来るか試してみよう。

鍵認証を使用するためには、サーバ側(Ubuntu側)に、先ほど作成した鍵のうち、公開鍵を登録しておく必要がある。
ホームディレクトリの下に、sshというディレクトリを作成し、その中で authorized_keys というファイルに、鍵を追記していく形になる。
ログインしたままのteratermがあるはずなので、以下の手順でディレクトリを作成しておこう。

mkdir .ssh
chmod 755 .ssh

自分自身以外が書き込み出来ないよう、パーミッションを変更するのも合わせてやっておく。

先ほど作成した鍵(.pub となっている方)をサーバへアップロードする必要があるのだが、teratermなら簡単に出来る。
ログインしたままのteratermで、メニューバー「ファイル」から「SSH SCP」を選択する。


以下のダイアログが表示されるので、Fromに先ほどの鍵を、Toには、~/.ssh/id_rsa_usekey.pub と入力し、「Send」ボタンを押そう。


そうすれば、先ほど作成したファイルが、サーバ上に格納されているはずだ。

ls ~/.ssh/id_rsa_usekey.pub
/home/******/.ssh/id_rsa_usekey.pub

後は、このファイルを authorized_keys に追記すればいい。

cat ~/.ssh/id_rsa_usekey.pub >> ~/.ssh/authorized_keys

さて、鍵認証が出来るかどうか、もう一枚teratermを立ち上げて試してみよう。
ログイン先やサービスは先程と同じようにして、認証画面を以下のようにしよう。
ラジオボタンは「RSA/DSA/ECDSA...を使う」とし、秘密鍵を先ほど作成した鍵(.pubではない方)を選択する。
画面上部の「ユーザ名」は、サーバ側のアカウント、パスフレーズは、秘密鍵を作成した時に入力したパスフレーズだ。(OS側で設定したパスワードではない)


これで「OK」を押すと、すんなりログイン出来るようになるはずだ。

ただ、これではログインするたびに毎回パスフレーズを入力しなければいけない。
メンドウだ。
なので、次回はagent(pagent)を用いて、パスフレーズ入力を一回限りにするようにしてみたい。