CentOS 6.8へのアップデート後にshutdownでエラーメッセージが表示される [CentOS]
shutdown 時に、下記のファイルが存在しない旨のメッセージが出力される。
・/var/lib/alsa/asound.state
(補足)
・CentOS 6.7 から CentOS 6.8 へのアップデート後に発生するようになった。
・/etc/init.d/halt 内の alsactl により使用される。
・該当するパッケージ: alsa-utils-1.1.0-8.el6.i686
2. 原因
アップデートにより、alsactl が使用するファイルのパスが変わったためである。
・alsa-utils-1.0.22-9.el6_6.i686 の場合
/etc/asound.state
・alsa-utils-1.1.0-8.el6.i686 の場合
/var/lib/alsa/asound.state
3. 対処方法
下記の手順で、当該ファイルを作成する。
# cd /var/lib # mkdir alsa # chmod 755 alsa # cd alsa # touch asound.state # chmod 644 asound.state
CentOS 6.8の不具合 [CentOS]
・現時点では原因は不明
・対応を検討中
1. ノード名を付けて指定したディスプレイをオープンできない
% xterm -display localhost:0 xterm Xt error: Can't open display: localhost:0 % xterm -display `hostname`:0 xterm Xt error: Can't open display: xxx.xxx.xxx:0 % xterm -display `hostname -i`:0 xterm Xt error: Can't open display: 192.168.0.11:0
(補足)
・当該パッケージ: xorg-x11-server-Xorg-1.17.4-9.el6.centos.i686
・'xhost +' を実行しても状況に変化はない。
・ノード名を付けない場合(-display :0)には、オープンできる。
2. rsh-server が正常に機能しない
(1) 即座にクローズされる。
% rsh `hostname` … テストのためローカルノード上で実行 rlogin: connection closed.
(2) ログインできても、プロンプトが表示されない。
% rsh `hostname` /bin/bash … テストのためローカルノード上で実行 exit ... コマンドの実行は可能
(補足)
・当該パッケージ: rsh-server-0.17-64.el6.i686
・rsh-server のバージョンはアップデート前と同じである。
3. telnet-server が正常に機能しない
・プロンプトの 1 カラム目が表示されない。
・入力がエコーされない(ただし、コマンドの実行、実行結果の出力は可能)。
% telnet `hostname` … テストのためローカルノード上で実行
Trying 192.168.0.11...
Connected to xxx.xxx.xxx.
Escape character is '^]'.
CentOS release 6.8 (Final)
Kernel 2.6.32-71.29.1.el6.i686 on an i686
ogin:
Password:
(補足)
・当該パッケージ: telnet-server-0.17-48.el6.i686
・telnet-server のバージョンはアップデート前と同じである。
CentOS 6.8へのアップデート後にlogrotateでエラーが発生 [CentOS]
/etc/cron.daily/logrotate の実行で、下記のエラーが発生する。
error: consolekit:1 duplicate log entry for /var/log/ConsoleKit/history error: found error in /var/log/ConsoleKit/history , skipping
(補足)
・CentOS 6.7 から CentOS 6.8 へのアップデート後に発生するようになった。
・該当するパッケージ: ConsoleKit-0.4.1-6.el6.i686
2. 原因
/etc/logrotate.d/ に ConsoleKit と consolekit が存在するため。
(補足)
バージョンアップの際に、consolekit が削除されなかったものと思われる。
・ConsoleKit-0.4.1-3.el6.i686: /etc/logrotate.d/consolekit を使用
・ConsoleKit-0.4.1-6.el6.i686: /etc/logrotate.d/ConsoleKit を使用
3. 対処方法
/etc/logrotate.d/consolekit を削除する。
ntpdとchronydの違い [CentOS]
そこで、ntpd と chronyd について、違いを調べてみた。
なお、以下はドキュメント・ベースでの情報である(chronyd を使用していないため)。
# ソフトウェアのバージョン
・chrony-2.1.1-1.el7.centos.x86_64
・ntp-4.2.6p5-22.el7.centos.1.x86_64
1. chronyd にのみある機能
(1) ハードウェアクロックを同期することができる。
# ハードウェアクロック(RTC) を同期する(11 分毎に実施)。 rtcsync
・/etc/chrony.conf の初期値として設定されている。
(2) step/slew モードの切り替えを細かく指定できる。
(例) # 時刻のズレが 10 秒よりも大きい場合、最初の 3 回は slew モードの代わりに # step モードを使用する。 makestep 10 3
・/etc/chrony.conf の初期値として設定されている。
(3) slew モードでの同期速度の指定ができる。
maxslewrate <rate>
・default: 83333.333 (msec/sec)
・ntpd の slew レートは 500 (msec/sec) 固定である。
(4) slew モードで同期できるズレの最大値を指定できる。
(例) # 最初のクロック更新後に 時刻のズレのチェックを 2 回無視し、その後の # チェックで 1000 秒よりもがズレが大きい場合に時刻同期を終了する。 maxchange 1000 1 2
(補足)
ntpd の場合には、下記の通りである。
・-x オプションの指定なしの場合: 128 (msec)
・-x オプションの指定ありの場合: 600 (sec)
(5) 使用するポートを指定できる。
port <port-number>
・default: 123
・ntpd での使用ポートは 123 固定である。
2. 備考
(1) CentOS 7 での ntpd の使用
chronyd を停止することにより、ntpd が使用可能となる。
# systemctl stop chronyd # systemctl disable chronyd # systemctl start ntpd # systemctl enable ntpd
(2) 参考情報
・access.redhat.com/documentation/
・chrony.tuxfamily.org/doc/
DRBDの試用 [CentOS]
詳細は、以下の通りである。
1. DRBD (Distributed Replicated Block Device) の機能
複数のノード間で、パーティションをミラーリングするソフトウェアである。
・TCP/IP ネットワークを利用して同期(ミラーリング)される。
・特別なハードウェアを必要としない。
・Linux 上で動作するオープンソース・ソフトウェアである。
・クラスタリングソフトと組み合わせて、Shared nothing 型の HA クラスタを構成できる。
2. システム要件
(1) ソフトウェアのバージョン
・OS: CentOS 6.7
・drbd84-utils-8.9.5-1.el6.elrepo.i686
・kmod-drbd84-8.4.7-1_1.el6.elrepo.i686
(2) 使用するノード
・vm1.private.net(192.168.0.21)
・vm4.private.net(192.168.0.24)
(3) 使用するデバイス
・パーティション: /dev/sdb1
・DRBD 用デバイス: /dev/drbd0
3. 導入手順
3-1. 手順-1
関係するすべてのノードで、下記の手順を実施する。
(1) ネットワーク環境の構築
(2) パッケージのインストール
(a) elrepo.org をリポジトリに追加
(b) パッケージのインストール
# yum install drbd84-utils kmod-drbd84
(3) DRBD の設定
(a) /etc/drbd.d/global_common.conf の編集
global {
usage-count no;
}
common {
handlers {
}
startup {
wfc-timeout 60;
}
options {
}
disk {
resync-rate 50M;
}
net {
protocol C;
csums-alg sha1;
verify-alg sha1;
}
}
・usage-count: DRBD プロジェクトへの情報提供の有無(yes/no)
・wfc-timeout: 起動時の他ノードとの接続タイムアウト(sec)
・resync-rate: 再同期に使用する最大帯域幅(Byte/sec)
・protocol: 同期プロトコルのモード(A:非同期, B:メモリ同期, C:同期)
・csums-alg: 更新の検出に使用するアルゴリズム
・verify-alg: 照合に使用するアルゴリズム
(b) /etc/drbd.d/r0.res の編集
resource r0 {
meta-disk internal;
device /dev/drbd0;
disk /dev/sdb1;
on vm1.private.net {
address 192.168.0.21:7788;
}
on vm4.private.net {
address 192.168.0.24:7788;
}
}
・meta-disk: メタ情報の保存方法
・device: DRBD デバイス
・disk: DRBD デバイスを構成するパーティション
・address: ノードのアドレス、使用するポート
(c) メタデータの作成
# drbdadm create-md r0
(補足)
パーティション内にファイルシステムが存在する場合には、エラーとなる。
(その旨のエラーが出力される。)
この場合には、下記の手順により当該パーティションを 0 クリアする。
# dd if=/dev/zero of=<dev-path> bs=1M count=1
(4) リソースの有効化
(a) リソースの有効化
# drbdadm up r0
(b) 状態の確認
# cat /proc/drbd
正常終了した場合には、下記のように出力される。
cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent
(5) drbd の自動起動の有効化
# chkconfig drbd on
3-2. 手順-2
該当するノードで、下記の手順を実施する。
(1) 初期同期
vm4.private.net(同期先) で下記の手順を実施する。
(a) 現在のデータの破棄
# drbdadm invalidate r0
(b) 状況の確認
# cat /proc/dbrd
同期完了後には、下記のように出力される。
cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate
(2) ファイルシステムの作成
vm1.private.net(同期元) で下記の手順を実施する。
(a) Primary への移行
# drbdadm primary r0
(b) ファイルシステムの作成
# mke2fs -j /dev/drbd0
(補足)
同期されるため、他ノードでの実施は不要である。
4. DRBD デバイスの使用方法
Primary ノードにおいて、通常のデバイスと同様に扱うことができる。
(1) Primary または Secondary ノードへの移行
下記のコマンドを実施する。
ただし、同時に複数のノードが Primary ノードとなることはできない。
[Primary ノードへの移行の場合] # drbdadm primary[Secondary ノードへの移行の場合] # drbdadm secondary (例) # drbdadm primary r0 # drbdadm secondary r0
(2) 状況の確認
下記のコマンドを実施する。
# cat /proc/drbd
[Primary ノードの場合]
cs:Connected ro:Primary/Secondary と出力される。
[Secondary ノードの場合]
cs:Connected ro:Secondary/Primary と出力される。
5. 参考情報
・http://qiita.com/takehironet/items/13518725ee7c694efe90
・https://blog.3ware.co.jp/drbd-users-guide-8.4/drbd-users-guide.html
Pacemaker + Corosyncでのクラスタ環境の構築 [CentOS]
詳細は、以下の通りである。
1. 要件
(1) ソフトウエアのバージョン
・OS: CentOS 6.7
・pacemaker-1.1.12-8.el6_7.2.i686
・corosync-1.4.7-2.el6.i686
(2) システム要件
(a) インターコネクト用 LAN
サービス LAN を インターコネクト用としても使用する。
(192.168.0.0/24)
(b) クラスタを構成するノード
KVM の VM 上に構築した 2 個のノードでクラスタを構成する。
(c) 共有ディスク
共有ディスク用のディスクイメージを追加し、該当する VM 間で共有する。
(共有ディスク: /dev/sdb)
(d) クラスタリングの対象とするサービス
NFS サーバー
2. 実施手順
2-1. パッケージのインストール
すべてのノードで下記コマンドを実施する。
# yum install pacemaker corosync pcs
・corosync: クラスタ制御
・pacemaker: リソース制御
・pcs: Pacemaker 設定用のコマンドライン・ツール
2-2. Corosync の設定
いずれかのノードで下記の手順を実施し、当該ファイルを他のノードにコピーする。
(1) /etc/corosync/corosync.conf の作成
# cd /etc/corosync # cp -p corosync.conf.example corosync.conf
(2) /etc/corosync/corosync.conf の編集
# diff corosync.conf corosync.conf.example 25c25 < bindnetaddr: 192.168.0.0 --- > bindnetaddr: 192.168.1.0
192.168.0.0 をインターコネクト用 LAN として定義する。
2-3. サービスの起動
すべてのノードで下記の手順を実施する。
(1) サービスの起動
# /etc/init.d/corosync start # /etc/init.d/pacemaker start # chkconfig corosync on # chkconfig pacemaker on
(2) 状態の確認
# crm_mon Last updated: ... Last change: ... Stack: classic openais (with plugin) Current DC: vm2.private.net - partition with quorum Version: 1.1.11-97629de 2 Nodes configured, 2 expected votes 0 Resources configured Online: [ vm2.private.net vm3.private.net ]
(補足)
crm_mon コマンドの終了: Ctrl+C
2-4. クラスタ特性の設定
いずれかのノードで下記の手順を実施する。
(1) クラスタ特性の設定
# pcs property set stonith-enabled=false # pcs property set no-quorum-policy=ignore
(2) 設定状況の確認
# pcs property list
2-5. リソースの定義
2-5-1. VIP の定義
いずれかのノードで下記の手順を実施する。
(1) リソースの定義
# pcs resource create vip ocf:heartbeat:IPaddr2 \ ip=192.168.0.20 cidr_netmask=24 \ nic="eth0" \ op monitor interval=30s
192.168.0.20/24 をリソースとして定義する。
(2) 状態の確認
# pcs status resources vip (ocf::heartbeat:IPaddr2): Started vm2.private.net
2-5-2. VIPcheck の定義
スプリットブレイン対策として、いずれかのノードで下記の手順を実施する。
ただし、リソース・エージェントの追加はすべてのノードで実施する。
(1) リソース・エージェントの追加
(a) VIPcheck リソース・エージェントの入手
http://sourceforge.jp/projects/linux-ha/downloads/45456/VIPcheck/
(b) リソース・エージェントの追加
# cd /usr/lib/ocf/resource.d # mkdir additional # cd additional # cp -p VIPcheck . # chown root:root VIPcheck # chmod 755 VIPcheck # cd ../heartbeat # ln -s ../additional/VIPcheck .
(2) リソースの定義
# pcs resource create vip-check ocf:heartbeat:VIPcheck \ target_ip=192.168.0.20 count=1 wait=10 \ op start interval=0s timeout=90s on-fail=restart start-delay=4s # pcs constraint colocation add vip with vip-check INFINITY ... (注1) # pcs constraint order vip-check then vip ... (注2) (注1) 実行するノードの設定 (注2) 実行順序設定
(3) 状態の確認
# pcs constraint Location Constraints: Ordering Constraints: start vip-check then start vip (kind:Mandatory) Colocation Constraints: vip with vip-check (score:INFINITY)
2-5-3. ファイルシステムの定義
いずれかのノードで下記の手順を実施する。
(1) リソースの定義
# pcs resource create fs-nfs ocf:heartbeat:Filesystem \ device=/dev/sdb1 directory=/share fstype="ext3" # pcs constraint colocation add fs-nfs with vip INFINITY ... (注1) # pcs constraint order vip then fs-nfs ... (注2) (注1) VIP が割り当てられたノードでリソースを有効にするための設定 (注2) VIP が割り当てられた後にリソースを有効にするための設定
/dev/sdb1 をマウントした /share をリソースとして定義する。
(2) 状態の確認
# pcs constraint Location Constraints: Ordering Constraints: start vip-check then start vip (kind:Mandatory) start vip then start fs-nfs (kind:Mandatory) Colocation Constraints: vip with vip-check (score:INFINITY) fs-nfs with vip (score:INFINITY)
2-5-4. サービスの定義 (nfsd)
(1)〜(3) の手順をすべてのノードで実施する。
また、いずれかのノードで (4) 以降の手順を実施する。
(1) nfs の自動起動の無効化
# chkconfig nfs off
(2) ファイルシステムの export
(a) /etc/exports の作成
# cat /etc/exports /share 192.168.0.0/24(rw,no_root_squash,sync)
(b) exportfs の実行
# exportfs -av
(3) nfs のカスタマイズ
系切り替え後の待ち時間を短縮するために、/etc/sysconfig/nfs を編集する。
# cd /etc/sysconfig/ # diff nfs nfs.org 50,52c50,52 < NFSD_V4_GRACE=10 < NFSD_V4_LEASE=10 < NLM_GRACE_PERIOD=10 --- > #NFSD_V4_GRACE=90 > #NFSD_V4_LEASE=90 > #NLM_GRACE_PERIOD=90
(4) リソースの定義
# pcs resource create nfs-server ocf:heartbeat:nfsserver \ nfs_init_script="/etc/init.d/nfs" nfs_ip="192.168.0.20" \ op start interval="0s" timeout="120s" \ op monitor interval="10s" timeout="60s" on-fail="restart" \ op stop interval="0s" timeout="120s" # pcs constraint colocation add nfs-server with fs-nfs INFINITY ... (注1) # pcs constraint order fs-nfs then nfs-server ... (注2) (注1) fs-nfs が割り当てられたノードで nfsd を起動するための設定 (注2) fs-nfs が割り当てられた後に nfsd を起動するための設定
(5) 状態の確認
# pcs constraint Location Constraints: Ordering Constraints: start vip-check then start vip (kind:Mandatory) start vip then start fs-nfs (kind:Mandatory) start fs-nfs then start nfs-server (kind:Mandatory) Colocation Constraints: vip with vip-check (score:INFINITY) fs-nfs with vip (score:INFINITY) nfs-server with fs-nfs (score:INFINITY)
2-6. テスト
(1) テストの準備
・vm2.private.net、vm3.private.net をそれぞれ Active、Standby ノードにする。
・NFS クライアントで、192.168.0.20:/share をマウントする。
(2) テストの実施
(a) test-1
・vm2.private.net 上で nfsd を停止する。
(# /etc/init.d/nfs stop)
・vm2.private.net 上で nfsd が再起動されることを確認する。
(b) test-2
・vm2.private.net 上で pacemaker を停止する。
(# /etc/init.d/pacemaker stop)
・すべてのリソースが vm3.private.net 上に移動することを確認する。
・クライアントで 192.168.0.20:/share がマウントできることを確認する。
(c) test-3
・vm2.private.net 上で eth0 を停止する。
(# ifconfig eth0 down)
・test-2 と同じことを確認する。
(補足)
リソースの状態は、下記のコマンドで確認できる。
# crm_mon -A
2-7. logrotate の設定
下記ログのローテーションを行う設定を追加する。
・/var/log/pacemaker.log
・/var/log/cluster/corosync.log
CentOS 6.x上のFirefoxの異常終了 [CentOS]
昨年末から CentOS 6.x(32.bit) 上の Firefox が度々異常終了する。
(現在 Firefox 45.0.2 を主に使用しており、上記の事象が発生する。)
(補足)
・mozilla.org からダウンロードした Firefox を使用している。
・Debian 7/8(32bit)、CentOS 7 上では発生しない(またはこれ程酷い状況ではない)。
・Firefox 45.0.2 では発生頻度が低くなったが、まだ発生する。
2. 対処方法
改善されるまで、Firefox 38.7.1esr を使用する。
(http://ftp.mozilla.org/pub/firefox/releases/38.7.1esr/)
(補足)
数日間使用してみたが、現時点では上記事象は発生していない。
Emacs 24でのコマンド引数のファイル名補完 [CentOS]
emacs-24.3-11.el7.x86_64
emacs-24.3-18.el7.x86_64
1. 発生事象
inferior shell において、コマンド引数のファイル名補完が想定通りにならないことがある。
(例)
rpm コマンドの引数指定で、指定ディレクトリのファイル名が補完されない。
・インストール済の RPM パッケージが補完対象となる。
(ミニバッファに "Getting list of installed rpms...done" と表示される。)
% ls -1 fcitx-4.2.8.4-1.fc20.x86_64.rpm fcitx-anthy-0.2.0-2.fc20.x86_64.rpm % ls -l fcitx <= Tab の押下後、カレントディレクトリのファイルで補完される % rpm -qpi fcitx <= Tab の押下後、カレントディレクトリのファイルで補完されない
2. 原因
Emacs 24 において、仕様が変更されたためである。
3. 対処方法
上記のような場合には、下記の手順を実施する。
(1) *Completions* バッファを kill-buffer する。
(2) M-? を押下し、補完候補を表示する。
M-? は comint-dynamic-list-filename-completions にバインドされている。
(3) *Completions* バッファ内の補完候補を選択する。
補完候補にカーソルを移動し、Enter を押下する。
または
補完候補をマウスの中ボタンでクリックする。
4. 備考
以前の仕様に近い動作にするためには、~/.emacs に下記の設定を追加する。
(add-hook 'shell-mode-hook
'(lambda ()
(add-to-list 'completion-at-point-functions
'comint-dynamic-complete-filename)))
(補足)
・ミニバッファに余分なメッセージが表示されることがある。
・コマンド名の補完では、一度 "No match" と表示される。
(しばらく待つか、再度 Tab を押下すると補完される。)
KVM上のVMへのP2V [CentOS]
実施した手順は、以下の通りである。
## OS のバージョン
・KVM ホスト: CentOS 7.2
・ゲスト OS: CentOS 6.7
## 方針
可能な限り、OS の提供する機能を使用する。
1. 準備
VM 上にコピーする OS のインストールメディアを用意する。
・rescue モードの command shell を使用するだけなので、minimail.iso で充分である。
・メジャーバージョンが一致すれは問題ないと思われる。
2. 物理サーバーのバックアップの取得
(1) パーティション毎のパックアップ
(例) # dump -0 -f - /dev/sda1 | gzip > root.dmp.gz # dump -0 -f - /dev/sda2 | gzip > home.dmp.gz
(2) KVM ホスト上へのバックアップデータのコピー
上記で取得したバックアップデータを KVM ホスト上へコピーする。
3. VM の作成
(1) VM の作成
・ディスクのサイズは、物理サーバーでの設定と同等にする。
・インストールメディアとして、上記で準備したファイルを指定する。
(2) Rescue モードの command shell の起動
(a) [Rescue installed system] の選択
(b) 言語、キーボードタイプの選択
・[Choose a Language] で [English] または [Japanese] を選択する。
・[Keyboard Type] で [jp106] を選択する。
(c) Network I/F の設定
・[Setup Networking] で [Yes] を選択する。
・IP address、Gateway、Name server に適当な設定を行う。
(d) command shell の起動
・[Rescue] で [Skip] を選択する。
・[shell] を選択した状態で、[Ok] を選択する。
4. command shell でのバックアップデータのリストア
(1) パーティションの作成
・fdisk が使用可能である。
・cfdisk を使用する場合には、KVM ホスト経由でコピーする。
(scp、rcp、ftp が使用可能)
・作成したパーティションには、ファイルシステムを作成する。
(mke2fs を使用)
(2) バックアップデータのリストア
(例) # mkdir /tmp/root # mount -t ext3 /dev/sda1 /tmp/root # cd /tmp/root # ssh <kvm_host> gzip -dc /work/root.dmp.gz | restore -rf - # rm restoresymtable # umount /tmp/root (/home についても同様)
(3) デバイスパスの変更
デバイスパスが変わる場合には、下記ファイルの設定を対応させる。
・/etc/fstab
・/boot/grub/grub.conf
(4) GRUB のインストール
(例) # grub grub> root (hd0,0) grub> setup (hd0) grub> quit
(5) command shell の終了
# exit その後、[reboot] を選択した状態で、[Ok] を選択する。
5. ゲスト OS での設定
・IP アドレス、ホスト名の変更
・swap の設定
KVMでのマイグレーションの実施 [CentOS]
実施手順は、以下の通りである。
# IP アドレスに関する情報
・192.168.0.12 … 既存の KVM ホスト、NFS サーバー
・192.168.0.11 … 追加した KVM ホスト
1. パッケージの追加
(1) openssh-askpass (SSH でのパスワードの入力機能)
# yum install openssh-askpass.x86_64
2. マイグレーションの実行環境の構築
2-1. KVM ホストの追加
(1) KVM ホストの複製
(a) 既存の KVM ホストを複製し、2 個目の KVM ホストを作成する。
(b) ホスト名、IP アドレスを変更する。
編集するファイルは、下記の通りである。
・/etc/sysconfig/network-scripts/ifcfg-enp2s0
・/etc/hostname
・/etc/hosts
(2) /etc/hosts の編集
KVM ホスト間で名前解決ができるように、当該ホストの設定を追加する。
2-2. 共有ディスクの設定
2 ノードからアクセスできる外部ディスクがないため、NFS を使用する。
実施手順は、下記の通りである。
(1) NFS サーバーの設定
KVM ホストの一方を NFS サーバーにする。
(a) NFS サービスの自動起動の設定
# systemctl enable nfs
(b) ディスクイメージの保存領域の別パーティション化
・/var/lib/libvirt/images 用のパーティションを作成する。
・上記パーティションを /kvm_data にマウントする。
・/var/lib/libvirt/images を /kvm_data にコピーする。
(c) /etc/exports ファイルの編集 (設定例)
# cat /etc/exports /kvm_data 192.168.0.0/24(rw,no_root_squash,sync)
(d) /etc/fstab の編集 (設定例、各エントリは一行で設定)
# /kvm_data のマウント /dev/sdc11 /kvm_data ext3 defaults 0 2 # /var/lib/libvirt/images の NFS マウント(ローカルディスクの NFS マウント) 192.168.0.12:/kvm_data /var/lib/libvirt/images nfs \ defaults,noac,hard,intr 0 0
(e) KVM ホストの再起動
(2) NFS クライアントの設定
他方の KVM ホストで、NFS サーバーの /kvm_data を NFS マウントする。
(NFS サーバーの起動が完了した後に実施する。)
(a) /etc/fstab の編集 (設定例、各エントリは一行で設定)
192.168.0.12:/kvm_data /var/lib/libvirt/images nfs \ defaults,noac,hard,intr 0 0
(b) KVM ホストの再起動
(補足)
NFS マウントは、KVM の設定で対応することも可能である。
手順は、下記の通りである。
・KVM の Storage 設定で、netfs タイプの Storage Pool を作成
Name: NFS (任意の名前で可) Type: netfs Target Path: /var/lib/libvirt/images Host Name: NFS サーバーのホスト名 Source Path: /kvm_data (NFS サーバー上のパス)
・Storage Pool の AutoStart 設定の変更
default(Filesystem Directory) を false に変更
NFS(Network Exported Directory) を ture に変更
2-3. virt-manager の設定
マイグレーション先の KVM ホストを追加する。
(1) virt-manager の起動
% virt-manager
(2) 接続先の追加
[File] -> [Add Connection] を選択し、接続先を登録する。
(a) 接続先の指定
Hypervisor: QEMU/KVM Connection to remote host: 選択 Method: SSH Username: root Hostname: マイグレーション先のホスト名
(b) [Connect] を選択
接続先での root のパスワードの入力が求められる。
2-4. その他の設定
(1) KVM ホストの UUID の変更
2 ノードで UUID が同じ場合には、下記の手順を実施する。
未実施の場合、同一のホストと判断され、マイグレーションを実施できない。
(a) KVM ホストの UUID の確認
2 ノードで下記のコマンドを実行する。
# dmidecode -s system-uuid
(b) random UUID の取得
# cat /proc/sys/kernel/random/uuid
(c) /etc/libvirt/libvirtd.conf の編集
host_uuid に上記の random UUID の値を設定する。
(d) libvirtd の再起動
# systemctl restart libvirtd
(2) ディスク・キャッシュの設定設定
下記の手順を実施し、キャッシュを none にする。
未実施の場合、下記メッセージが表示され、マイグレーションを実施できない。
(マイグレーション時に、[Allow unsafe] を選択する場合を除く。)
(a) 表示されるメッセージ
Unable to migrate guest: 安全ではないマイグレーション: ディスクが cache != none を使用していると、マイグレーションにより データが破損するかもしれません。
(b) 対処方法
VM 毎に下記の手順を実施する。
・メニューのアイコンから [Show virrual hardware details] を実行
・左側の一覧から該当するディスクを選択
・[Performance options] を展開
・[Cache mode] で [none] を選択
・[Apply] を選択
・ゲスト OS を shutdown
・ゲスト OS を 起動
3. マイグレーションの実施
(1) KVM ホストへの接続
マイグレーション元/先となる KVM ホストに接続する。
(2) VM の開始
マイグレーションを行う VM を起動する。
(3) マイグレーションの開始
・VM を選択し、右クリックで [Migrate] を選択
・マイグレーション先の VM ホストを選択
dandy さん
-
nice! 240
記事 393
テーマ パソコン・インターネット (15位)
プロフィール
ブログを紹介する
