2017年2月9日木曜日

共有ファイルシステム(corosync&dlm&gfs2その2)

というわけで、corosyncとdlmの2つを導入してみよう。

gfs2のマニュアルを見ると、corosyncをセットアップ後にdlmをセットアップする流れになっている。

というわけで、corosyncの導入から実施する。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install corosync
(gemini) $ sudo apt-get install corosync

そしたら、corosyncで導入されたファイル一覧を見てみる。
(gemini) $ dpkg -L corosync
/etc/corosync/corosync.conf というファイルが作られてるな。これを参考に設定ファイルを作ればいいだろう。

と思って/etc/corosync/corosync.confを見てみたが、結構色々な設定が入っている。
各種パラメータの意味を把握するのは必要に応じて実施するとして、とりあえず最低限の設定だけ入れてみる。
(gemini) $ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
(gemini) $ sudo vi /etc/corosync/corosync.conf

以下のように修正・追記していく。
totem {
cluster_name: debian

cluster_name: mycluster

interface {
bindnetaddr: 127.0.0.1

bindnetaddr: 192.168.55.0
}
}

差分確認しておこう。
(gemini) $ diff /etc/corosync/corosync.conf.orig \
/etc/corosync/corosync.conf

gfs2ファイルシステムを作成する時のオプション-tに用いたラベルのうち、前半分(前回の例だと-t mycluster:mygfs2のmycluster部分)と、corosync.confのcluster_nameは合わせる必要がある。

修正したところ以外が変更されてたりしないことを確認したら、corosyncの状態を確認して起動する。
(gemini) $ systemctl status corosync
(gemini) $ sudo systemctl restart corosync
(gemini) $ systemctl status corosync
これで良いのだろうか…。

続いて、dlmをセットアップする。
corosyncと同様に、導入するところからだ。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get --simulate install dlm
(gemini) $ sudo apt-get install dlm

む?dlmインストール時の自動セットアップでfailedになったな。
ちょっと確認してみるか。
(gemini) $ journalctl -xe
(gemini) $ systemctl -l status dlm.service
(gemini) $ systemctl -o verbose dlm.service
う~ん。/dev/misc/dlm-control とかいうデバイスファイルが無い、という理由でコケてるみたいだな…。
いやマテ…。/dev/dlm-controlというデバイスファイルは出来上がってるぞ…。
なぜ、/dev/miscという存在しないディレクトリを見に行っているんだ?

まさかと思うが…一旦再起動してみよう。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status
え?正常になってるぞ…?

(gemini) $ systemctl status dlm
あれ?やっぱり動いている。

まさか…
(gemini) $ ls -l /dev/misc
ぐはっ、ディレクトリも出来てて、シンボリックリンクも出来てる。
OS再起動が必要だったか…。(/dev 関係だから再起動した方がいいのだろうけど、エントリ追加ぐらいオンラインで出来るはずだよな…)

気を取り直して、とりあえずdlmパッケージにてインストールされたファイルは…と。
(gemini) $ dpkg -L dlm
設定ファイルの類や、サンプルファイルは無いな…。

と言っても、dlm.confのmanは存在している。これを見る限り、やっぱり/etc/dlm/dlm.confというファイルを作らないといけないようだな。

ファイルの内容はdlm.conのmanを見てもイマイチ分からない。
どうやら、現在の設定内容を出力するコマンドがあるらしい。それを使って設定ファイルのテンプレートを作ってみる。
(gemini) $ sudo mkdir /etc/dlm
(gemini) $ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
(gemini) $ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=0
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで

各パラメータの詳細はヨクワカラン。
ただ、lockspaceのところとかはちょっと書き換えておく。
(gemini) $ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_quorum_lockspace=1
↓この行を以下のように書き換え
enable_quorum_lockspace=0
--ココまで

書けたら、dlmを再起動してみる。
(gemini) $ sudo systemctl restart dlm
(gemini) $ sudo systemctl status dlm

なんかsyslogにたくさん出てくる…。quorumがどうとか…。
数十秒で止まったけど…。後日調査だな。

では今度こそマウント。
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
(gemini) $ df /mnt/gfs2
(gemini) $ grep gfs2 /etc/mtab
マウント出来た。

dlm_toolコマンドで確認してみよう。
(gemini) $ dlm_tool ls
(gemini) $ dlm_tool status
動いてるっぽいな…。

I/O確認もしておこう。
(gemini) $ sudo touch /mnt/gfs2/test
(gemini) $ sudo bash -c "echo hogehoge >> /mnt/gfs2/test"
(gemini) $ sudo bash -c "echo fugafuga >> /mnt/gfs2/test"
(gemini) $ cat /mnt/gfs2/test
(gemini) $ sudo rm /mnt/gfs2/test
問題なさそうだ。

ちなみに、前回書いた dlm_jadd コマンドは、ジャーナルを1つ追加してしまい、元に戻すことが出来ないようなので、当該ファイルシステムをマウントするホストが増えたら実施するようにしよう。
(Ubuntuで、gfs2ファイルシステムのジャーナル数を確認する方法が分からない…)

とりあえず、geminiでgfs2を作成、マウントすることは出来た。
次回はcancerで同じgfs2をマウント、両ノードでの書き込みテストをしてみる。

2017年2月8日水曜日

共有ファイルシステム(corosync&dlm&gfs2その1)

今度はgfs2だ。
こちらも初めて手を出すので、うまく動かせるか分からない。

とは言え、やってみなきゃ分からないので、ガシガシやってみる。

まずはパッケージの確認だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search gfs2
gfs2-utilsってのが該当っぽいな。

ではインストールしてみる。
(gemini) $ sudo apt-get install gfs2-utils

どんなファイルが入ったかな?
(gemini) $ dpkg -L gfs2-utils
あまりドキュメントは無い、というより、manに詳しく書いてあるみたいだ。
(gemini) $ man gfs2
色々複雑そうだ…。

とりあえずファイルシステムを作ってみる。
(gemini) $ sudo mkfs.gfs2 /dev/vg-gfs2/lv-gfs
おっと、オプションが足りないって怒られたわ。

manを見てみたらサンプルが載ってた。ちょっとサンプルに従ってみるか。
(gemini) $ sudo mkfs.gfs2 -t mycluster:mygfs2 \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/lv-gfs
おや?「シンボリックリンクだけどええか?」って聞かれた。今までファイルシステム作る時、そんなこと聞かれたことなかったが…。まぁ素直にyと答えておこう。どうせ実験環境だし。

ちょっと時間がかかった(10秒程度?)が、無事に出来たようだ。
デバイス名やUUID、Lock table等のパラメータが表示されたな。

これ、後から確認すること出来るんだろうか?
なんか、tunegfs2というコマンドがあるぞ…。これ、もしかしてext2系ファイルシステムで用いるtune2fsのgfs2版か?
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs
う~ん。ファイルシステム構築時に表示されたパラメータのうち、Device / Device size / Filesystem size / Journals / Resource groups は表示されず、Block size / Lock protocol / Lock table は表示された…。
それ以外にも、Block shift や Root inodeが表示されたけど、あまり意識しなくて良さそうだ。
とは言え、後から Journals が確認できないのはちょっと面倒かもしれない。
他にオプションやコマンドは無いかな…?

なんか、gfs2_jaddというコマンドが使えそうだけど、これはマウントしているファイルシステムでないと見られないっぽいな…。
マウントしてみるか。
(gemini) $ sudo mkdir /mnt/gfs2
(gemini) $ sudo mount -t gfs2 /dev/vg-gfs2/lv-gfs /mnt/gfs2
ダメだ。

man gfs2をよく読んだら、gfs2によるクラスタリング(共有ファイルシステム)はdlmの機構が必要だとのこと。んで、corosyncによってメッセージング(多分、更新情報等のやり取り)されるので、corosyncのセットアップが必要らしい。

だったらなんで、gfs2を導入する時に、前提パッケージとしてdlmやらcorosyncが指定されてないんだろう?と思ったけど、gfs2はクラスタ環境ではなく、スタンドアロン環境でも利用可能だから、か。

ということで、今回はちょっと止めて、dlmやらcorosyncやらを調べていくことにする。

2017年2月4日土曜日

共有ファイルシステム(ocfs2)

さて、ocfs2を試してみよう。
まずは、パッケージの導入だ。
(gemini) $ sudo apt-get update
(gemini) $ apt-cache search ocfs2
どうやら、ocfs2-toolsというパッケージが該当のようだ。(他にも、ocfs2consoleというのがあるけど、これは何だろう?別途調べてみるか…GUIインターフェースのようだ。)

(gemini) $ sudo apt-get install ocfs2-tools
さて、どういったファイルが導入されたかな?

(gemini) $ dpkg -L ocfs2-tools
あれ?実行ファイルが導入されてないぞ?これでいいのか…?あ、見間違えた。

ユーザガイドがあるので読んでみる。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz

ユーザガイドによると、/etc/ocfs2/cluster.confという設定ファイルを作る必要があるようだな。
サンプル(/usr/share/doc/ocfs2-tools/examples/cluster.conf)があるので、それを利用してもいいだろう。
設定ファイルを作る方法は、大きく3種類あるようだ。
  1. テキストエディタで直接編集
  2. ocfs2consoleのGUIインターフェースを使用
  3. o2cb_ctlコマンドを使用
とりあえず、サンプルを使って作り込んでいく。
/etc/ocfs2ディレクトリは自動作成されたようなので、それをそのまま使う。
(gemini) $ sudo cp -p /usr/share/doc/ocfs2-tools/examples/cluster.conf \
/etc/ocfs2/cluster.conf
(gemini) $ sudo vi /etc/ocfs2/cluster.conf
以下のような内容で作成する。
--ココから
node:
ip_port = 7777
ip_address = 192.168.55.136
number = 0
name = gemini
cluster = ocfs2

node:
ip_port = 7777
ip_address = 192.168.55.137
number = 1
name = cancer
cluster = ocfs2

cluster:
node_count = 2
name = ocfs2
--ココまで

全然難しくない。ホントにこれでいいのか…?

続いて、ocfs2ファイルシステムを作成する。
(gemini) $ sudo mkfs.ocfs2 /dev/vg-ocfs2/lv-ocfs

マウントポイントを作ってマウント
(gemini) $ sudo mkdir /mnt/ocfs2
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
あれ?コケた。

クラスタサービスへのアクセスが出来ない、とな?
ocfs2サービスを再起動してみればいいのかな?
(gemini) $ sudo systemctl status ocfs2
(gemini) $ sudo systemctl restart ocfs2
(gemini) $ sudo systemctl status ocfs2

もう一度。
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ダメだ。
ってよく見てみたら「while trying initialize cluster」って書いてあるな…。
初期化処理が必要なのか。

どうやるんだろう?もう一度ユーザガイドを見てみよう。
(gemini) $ zcat /usr/share/doc/ocfs2-tools/users_guide.txt.gz

なんか、o2cbというサービスが関係しているようだ。
これを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ sudo systemctl status o2cb
う~ん。何か変わった、という感じはしないなぁ。

(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
変わらず…。

む?o2cbって、systemd配下じゃなくて、旧来のinit.d形式なのか。
ちょっと見てみよう。
(gemini) $ view /etc/init.d/o2cb
なんか、/etc/default/o2cbというファイルを見ているようだ。

このファイルに、O2CB_ENABLEDというフラグがある。
これ、デフォルトでは「false」になっているので、これを「true」に書き換えたらいいのか?
(gemini) $ sudo vi /etc/default/o2cb
O2CB_ENABLED=false を O2CB_ENABLED=true に書き換えて保存。

これでo2cbサービスを再起動してみる。
(gemini) $ sudo systemctl restart o2cb
(gemini) $ systemctl status o2cb
なんか動いたっぽいな…。

もう一度マウント
(gemini) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
ちょっと時間がかかったな…。マウント出来たかな?
(gemini) $ df /mnt/ocfs2
出来た。

ちょっと気になるので、syslogとかチェックしておこ…。
(gemini) $ dmesg | tail
(gemini) $ tail -30 /var/log/syslog
どうやらうまく行ってるっぽいな…。

じゃぁcancer側で同じように…。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install ocfs2-tools
(cancer) $ sudo vi /etc/ocfs2/cluster.conf
内容はgeminiで作成したものと同じだ。
(cancer) $ sudo mkdir /mnt/ocfs2
(cancer) $ sudo vi /etc/default/o2cb
変更内容はgeminiと同じ。
(cancer) $ sudo systemctl restart o2cb
(cancer) $ sudo mount -t ocfs2 /dev/vg-ocfs2/lv-ocfs /mnt/ocfs2
(cancer) $ df /mnt/ocfs2

ここまでは何とかなった。

ホントにこれでいいのかな?
とりあえずI/Oテスト。

(gemini) $ ls -ld /mnt/ocfs2
(gemini) $ sudo chmod 777 /mnt/ocfs2
(gemini) $ ls -ld /mnt/ocfs2
(cancer) $ ls -ld /mnt/ocfs2

(gemini) $ cp /etc/hosts /mnt/ocfs2/
(gemini) $ ls -l /mnt/ocfs2
(cancer) $ ls -l /mnt/ocfs2
両方から参照出来るみたいだな。

(gemini) $ cat /mnt/ocfs2/hosts
(cancer) $ cat /mnt/ocfs2/hosts
問題ないな。

(gemini) $ vi /mnt/ocfs2/hosts
(cancer) $ vi /mnt/ocfs2/hosts
後から実行したcancerの方が、「スワップファイルが既に存在しているよ」という警告が出た。
でもこれは、viによる排他制御だよな…。ocfs2による排他制御じゃないだろう。
いや、違うかな…?

というわけで、cancer側でまず強制的に開いて、geminiの方で更新して保存終了、cancer側でも更新保存してみるか。
お?別で更新されたことが報告された。

排他制御はうまくいっているようだな。
ただ、これがocfs2によるものか、viによるものかははっきりは分からないな。

次のテストだ。
(gemini) $ rm /mnt/ocfs2/hosts
(gemini) $ ls -l /mnt/ocfs2/hosts
(cancer) $ ls -l /mnt/ocfs2/hosts

(gemini) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
(cancer) $ dd if=/dev/urandom of=/mnt/ocfs2/randomio bs=1M count=1024
う~ん。同時に書き込めてしまったな…。
サイズも1GBだ。
これが正しい挙動なのか…な?

もしかしたら、排他制御は上位レイヤー(アプリケーションレイヤー)で組み込む、ということなのかもしれない。ocfs2はあくまで、更新されたという情報を、各ノードに通知する、という仕組みだけなのかもな。

とりあえず、なんとなく実装出来たので、ocfs2についてはこれでオシマイ。
次回はgfs2について考えてみる。

共有ファイルシステム(基礎)

いくつも実験したい項目はあるけど、今回はその中でも結構ポイントが高い「共有ファイルシステム」だ。
単純に共有ボリュームだけなら、別にiSCSIのLUNを複数のノード(OS)に見せておいて、どちらかでマウント、他のノードはアンマウント、としておけばいい。
HAクラスタ等を組む時の基本だ。

これだと、あくまでそのLUNを使うのは1ノードのみ。複数のノードからのI/Oは出来ない。(やってみれば分かるけど、ファイルシステムが壊れる。)

これを、複数のノードからI/O出来るような仕組みにしてみたい。

実はこれ、単純にNFSやCIFSを使えば解決しちゃうんだけど、NFSやCIFSはお世辞にも速いファイルシステムではないし、ファイルサイズ等の制約も厳しかったりする。

で、実現方法だけど、どうやらOCFS2とGFS2の2つがあるらしい。(商用製品等、他にもたくさんあるのだが…)

で、これを試してみたい。

まずは基本。以下の作業を行う。

  • 2つの仮想マシンを作成し、それぞれUbuntu16.04を導入する。(今回はホスト名gemini/cancerにした。)
  • 仮想ディスクをocfs2.qcow2という名前、10GBのサイズで1つ作成し、gemini/cancerに接続する。(警告が出るが、無視する。)
    -----2017/04/04追記-----
    こちらに書いたが、仮想ディスクをgemini/cancerに接続する時「共有可能」というチェックボックスにチェックを入れておかないと、ちょっと思った挙動を示さないようだ。
    チェックを入れておくこと
    -----2017/04/04追記終了-----
  • geminiから、新しいディスクに対して、partedパーティションの作成と、pv/vg/lvを作成する。(lvは1つでいいだろう。)
    (gemini) $ sudo parted /dev/vdb print
    (gemini) $ sudo parted /dev/vdb mklabel gpt
    (gemini) $ sudo parted /dev/vdb print
    (gemini) $ sudo parted /dev/vdb mkpart primary 0% 100%
    (gemini) $ sudo parted /dev/vdb print
    (gemini) $ sudo parted /dev/vdb set 1 lvm on
    (gemini) $ sudo parted /dev/vdb print
    (gemini) $ sudo pvcreate /dev/vdb1
    (gemini) $ sudo vgcreate vg-ocfs2 /dev/vdb1
    (gemini) $ sudo vgdisplay vg-ocfs2
    (gemini) $ sudo lvcreate -L 5G -n lv-ocfs vg-ocfs2
    (gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
  • cancerからディスクの再認識と、lvmの再認識を行う。(ちょっとめんどくさいので、再起動する。)
    (cancer) $ sudo shutdown -r now
    (cancer) $ ls -l /dev/vd*
    (cancer) $ sudo vgdisplay vg-ocfs2
  • もう1つ仮想ディスク(gfs2.qcow2/10GB)を作成し、gemini/cancerに接続する。
  • 先程と同様に、geminiからpartedパーティションの作成と、pv/vg/lvの作成を行う。
    (gemini) $ sudo parted /dev/vdc print
    (gemini) $ sudo parted /dev/vdc mklabel gpt
    (gemini) $ sudo parted /dev/vdc print
    (gemini) $ sudo parted /dev/vdc mkpart primary 0% 100%
    (gemini) $ sudo parted /dev/vdc print
    (gemini) $ sudo parted /dev/vdc set 1 lvm on
    (gemini) $ sudo parted /dev/vdc print
    (gemini) $ sudo pvcreate /dev/vdc1
    (gemini) $ sudo vgcreate vg-gfs2 /dev/vdc1
    (gemini) $ sudo vgdisplay vg-gfs2
    (gemini) $ sudo lvcreate -L 5G -n lv-gfs vg-gfs2
    (gemini) $ sudo lvdisplay vg-gfs2/lv-gfs
  • cancerからディスクの再認識と、lvmの再認識を行う。(こちらもめんどくさいので再起動しちゃおう)
    (cancer) $ sudo shutdown -r now
    (cancer) $ ls -l /dev/vd*
    (cancer) $ sudo vgdisplay vg-gfs2

とりあえず、ここまで実施しておいた。

次回、ocfs2の環境を作ってみたい。

スナップショットを使おう その5(内部スナップショットの破棄-停止状態)

というわけで、スナップショットの破棄のパターンをテストしてみる。

これまで色々いじってきた内容と基本的には被るわけだが、整理だと思ってくれい。
とりあえず、内部スナップショット-停止状態のパターンを書く。

piscesが稼動していたら停止させよう
(aquarius) $ virsh list --all

内部スナップショットの作成だ。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1.....
(aquarius) $ virsh snapshot-list pisces

piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2

piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1

piscesのスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh list --all
停止した状態でスナップショットを作成したので、停止した状態に戻るかと思ったんだが、起動したままになっている。

スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
スナップショットは削除されている。

piscesのファイルの状態は?
(pisces) $ ls -l 1
スナップショット作成後に作成したファイル、残っている。

ということは、この手順は、スナップショットは消えるが、スナップショットに対して行った作業は、ベースのディスクに反映されるってことか。

手順間違えた。もう一度実施だ。
まずは、pisces上のごみファイル(1)を削除する。
(pisces) $ rm 1
(pisces) $ ls -l

piscesはシャットダウンしておく。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all

もう一度、内部スナップショットを作成する。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1
(aquarius) $ virsh snapshot-list pisces

piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2

piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1

piscesをスナップショットまで戻してみる。
(aquarius) $ virsh snapshot-revert --domain pisces pisces-1
(aquarius) $ virsh list --all
この時点で、piscesは停止する。(もともと停止状態で取得したスナップショットに戻ったわけだから、正常な挙動だ。)

スナップショットの確認
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは残っている。

この状態でスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは削除された。

本当に元に戻ったか、piscesを起動して確認だ。
(aquarius) $ virsh start pisces
(pisces) $ ls -l 1
ファイルが存在していない。スナップショット取得前に戻った状態だ。

これで、
  • スナップショットを破棄する。(スナップショット取得前に戻す。)
  • スナップショットは停止状態で取得する。
  • スナップショット形式は「内部スナップショット」。
のパターンの検証と手順の確立は完了だ。

次は、同様のパターンで「起動状態でスナップショットを取得する」の手順の確立を実施してみたい。

と、途中まで書いていたが、ちょっとスナップショット関連は停止。
まだまだ色々やりたいことがあるので、色んなことやってく過程で、またスナップショットは記載する。

2017年1月30日月曜日

ゲスト側で休止状態、スリープ状態

KVMゲストにWindowsを突っ込んで色々試してたんだけど、Windows側の電源管理で休止状態やスリープ状態が使えなかった。
これ使えないとちょっと不便だなーと思ってたんだけど、すげー単純なことだった。


対象のゲストマシンを停止させた後、ゲストの設定を編集する。
(sagittarius) $ virsh edit pegasus
<features>~</features>の間に、<acpi/>があるか確認。無ければ追記。
<pm>~</pm>の間に、<suspend-to-mem enabled='yes'/>と<suspend-to-disk enabled='yes'/>のエントリを確認。無ければ追記、あっても宣言がnoならyesに書き換える。
これで保存して、対象のゲストを起動すれば…。

あら不思議、ちゃんとちゃんと「休止状態」や「スリープ」が選べるようになりました、よ、と。

https://libvirt.org/formatdomain.html#elementsPowerManagement

2017年1月22日日曜日

ゲストにUSBリダイレクト

SPICEプロトコルは、ゲストのモニタ・キーボード・マウスやサウンドをつなぐだけでなく、端末側のUSBポートをリダイレクトすることが出来るらしい。
ゲストの端末のUSBポートを、ゲストOS側につなぐことで、手元のPCのUSBに繋いだデバイスを、あたかもゲストOSに繋いだかのように振る舞うことが出来るようだ。

で、実はこれ、簡単に実現できる。

手元の端末がWindowsなら、spice-spaceのダウンロードサイトからUsbDkというツールをダウンロード、インストールするだけだ。
インストールする先はゲストOSではなく、端末側(Virt Viewer/Remote Viewerを動かす方)だから間違えないように。

ゲスト側は、仮想マシン上にUSB Redirectorというデバイスが用意されている必要がある。
ただ、Libvirtのデフォルトで用意されるはずだから、特に弄る必要は無いぞ。

端末側にUsbDkの導入が終わったら、Remote ViewerでゲストOSに接続しよう。

今までは、Remote Viewerのメニューバー「File」の、「USB device selection」が選択不可の状態だったのが、選択出来るようになっているはずだ。
これを選択すると、手元のPCのUSBポートに接続されたデバイスを選択するダイアログが表示される。
ノートPCの内蔵デバイスの場合、内部的にUSB接続のものもあるので、ここに一覧化されるぞ。
例えば自分のノートの場合、モニタの上に接続されているカメラや、SDカードリーダーが表示された。
この中の一つにチェックを入れて「Close」ボタンを押せば、該当のデバイスがゲストOSに接続される。
ただ、ネットワーク的に遠いところ(屋外から、ケータイやWiMAX等の通信回線を通して、SSHトンネルをからのSPICE接続等)では、めっちゃ遅いし途中で切断される可能性も高い。
実際、USBカメラは機能しなかったし、SDカードを開いて中身を書き換えようとすると、ものすごく我慢を強いられるぞ。(実は、この機能を使えば、デジイチで外で撮影したあと、喫茶店とかですぐにデータを家のPCに格納できるかも、とちょっと期待していたのだが…。この速度ではかなり厳しいな。)
とは言え、これが存在する/しないで意外と使い勝手が変わりそうだ。覚えておいて損は無いだろう。

とりあえず、今日はここまで。