2018年9月7日金曜日

dlmとclvmdの依存関係(gfs2用)

dlmとclvmdリソースの起動順を定義しておく必要があるようだ。
#と言っても、dlmもclvmdもOS起動時にsystemdから起動されるので、あまり意味が無い気がするんだけど…。
#RHEL7だと、systemdから起動させず、各リソース定義から起動させるのだろうか…。

RedHat社のサイトだと、以下のコマンドとして記載されている。
pcs constraint order start dlm-clone then clvmd-clone
pcs constraint colocation add clvmd-clone with dlm-clone
起動順だけでなく、「clvmdもdlmも同じノードで起動するよ」という制約も付けていた。

まずは起動順から。
pcsd の画面から dlm-cloneリソース か clvmd-cloneリソース の Resource Ordering Preferences から設定するようだ。

dlm-clone リソースから設定する場合は、以下のように入力する。
  • Resource : clvmd-clone
  • Action : starts
  • Before/After : after dlm-clone
  • Action : starts
  • Score : 無し
これは、「dlm-clone が起動した後に、clvmd-cloneを起動させる」という意味だ。

clvmd-clone リソースから設定する場合は、以下のように入力する。
  • Resource : dlm-clone
  • Action : starts
  • Before/After : before
  • Action : starts
  • Score : 無し
これは「dlm-clone を先に起動させる」という意味。

リソースの起動順はこれでおしまい。

続いて起動ノードの制約。
こちらは pcsd の dlm-cloneリソース か clvmd-cloneリソース の Resource Colocataion Preferences という設定画面から設定可能。
設定内容は以下の通り。
  • Resource : 相手側のリソース名。clvmd-clone リソースから定義しているのなら、dlm-clone
  • Together/Apart : Together
  • Score : 無し(未設定だと INFINITY で設定される)
どちらか片方で設定すれば、もう片方からも自動設定されるぞ。

設定出来たら設定内容を確認してみよう。
(gemini) $ sudo pcs constraint show --full

依存関係等はこれで終了かな?

2018年9月6日木曜日

clvmdをクラスタリソースに(gfs2用)

RedHat社の手順だと、ココで clvmd をクラスタリソースとして定義している。

んが、gemini と cancer には、まだ clvmd をインストールしていない。
なので、このタイミングでまずインストールする。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install clvm
(gemini) $ dpkg -l clvm
(gemiin) $ dpkg -L clvm

cancer でも。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install clvm
(cancer) $ dpkg -l clvm
(cancer) $ dpkg -L clvm

インストールが終わったら、clvmd をクラスタリソースとして定義する。
RedHat社のサイトでは、以下のコマンドを実行している。
pcs resource create clvmd ocf:heartbeat:clvm \
  op monitor interval=30s on-fail=fence \
  clone \
  interleave=true \
  ordered=true

dlmリソースを作成した時とよく似ている。
ということは、その時と同じように設定すればいいってことだ。
pcsdの画面を使って、RESOURCESタブからAddを選択。
以下のように入力する。
  • Class/Provider : ocf:heartbeat
  • Type : clvm
  • Resource Group : None
  • Clone : チェックOn
  • Master/Slave : チェックOff
  • Disabled : チェックOff
  • ResourceID : clvmd
  • with_cmirrord : なし
  • configdir : なし
  • daemon_options : なし
  • active_vgs : なし
これで作成。

あれ?確かにclvmd-cloneとclvmdのリソースは作成されたけど、ステータスがblockedになってしまった。
clvmdが起動していないとダメなのか?

う~ん。強制的にリソースを起動してみると…。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
動いたけど…起動時に「lvmetadが無効になっているのに起動してるで。有効化して再起動しな。」って言われてる気がするが…。
lvmetad は無効化するのが正しいはずなので、lvmetad を停止すればいいのかな?
とりあえず、clvmdリソースは停止する。
(gemini) $ sudo pcs resource debug-stop clvmd
(gemini) $ ps -ef | grep clvmd

lvmetadの状態を確認してみよう。
(gemini) $ systemctl status lvm2-lvmetad.service
起動していて、かつ自動起動Offだ。(disabled)
止めてしまおう。
(gemini) $ sudo systemctl stop lvm2-lvmetad.service
(gemini) $ systemctl status lvm2-lvmetad.service
なんか、lvm2-lvmetad.socketが有効だぞ、と言われたけど、一旦無視する。

これでもう一回、強制起動を。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
先程のワーニングは消えた。

とりあえず止める。
(gemini) $ sudo pcs resource debug-stop clvmd

となると、systemctl から clvmd が起動してくれればイケそうだな。
以前、clvmd の起動はココで苦労したんだけど、この記事若干間違っているので、ここで再度整理して実行しよう。

lvm2-clvmd.service の定義ファイルが誤っているっぽいので、コピーして修正する。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
    /etc/systemd/system/
(gemini) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS

ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
以前の記事では、うだうだと色々いじっているが、実際にいじるのは上記だけだ。

これで起動してみる。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl start lvm2-cluster-activation.service

pcsd の画面から、 clvmd-clone リソースを Cleanup して暫く待ったら、無事に動き出した。(ただし、リソース自体はgeminiでしか動いていない。cancer側の修正が出来てないから当たり前だが)
(gemini) $ sudo pcs resource

lvm2-cluster-activation.service は自動起動になっていないようなので、自動起動にしておく。
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
(gemini) $ sudo systemctl enable lvm2-cluster-activation.service
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service

同じようにcancerをカスタマイズする。
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
    /etc/systemd/system/
(cancer) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS

ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----

起動してみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start lvm2-cluster-activation.service

また、pcsd の画面から、clvm-clone リソースを Cleanup して暫く待つ。
cancer側でも動いているのを確認する。
(cancer) $ sudo pcs resource

動いているのが確認できたら、cancer でも lvm2-cluster-activation.service を自動起動にする。
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
(cancer) $ sudo systemctl enable lvm2-cluster-activation.service
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service

さて、あとは op monitor interval=30s on-fail=fence と interleave=true ordered=true の設定だな。
サクッと片付けよう。
(gemini) $ sudo pcs resource show clvmd-clone
(gemini) $ sudo pcs resource op remove clvmd monitor
(gemini) $ sudo pcs resource op add clvmd monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show clvmd-clone

interleave=true と ordered=true は、pcsd の画面の Meta Attrib から足したらおしまいだ。

とりあえずココまで。

追記
cancerのlvmetadを止めておくのを忘れていたので止めておく。
(cancer) $ systemctl status lvm2-lvmetad.service
(cancer) $ sudo systemctl stop lvm2-lvmetad.service
(cancer) $ systemctl status lvm2-lvmetad.service

2018年9月4日火曜日

lvmconf(gfs2用)

続いて、lvmconfコマンド。
これは以前、この辺りで書いてた内容を、新しい gemini / cancer で実行するだけのお話。
さっそくやってみよう。
(gemini) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(gemini) $ sudo lvmconf --enable-cluster
(gemini) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
locking_type が 3に、use_lvmetad が 0 に更新された。

同じように cancer も。
(cancer) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(cancer) $ sudo lvmconf --enable-cluster
(cancer) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf

はて、lvmetadは可動しっぱなしだけど、OS再起動とか lvm2-lvmetad.service の停止は不要なのかの?

2018年9月3日月曜日

dlmリソース作成(gfs2用)

続いて、dlmをリソースとして作成する。
RedHat社のサイトを参照すると、以下のコマンドがサンプルとして載っている。
pcs resource create dlm \
  ocf:pacemaker:controld \
  op monitor \
       interval=30s \
       on-fail=fence \
     clone \
     interleave=true \
     ordered=true

今回は、pcsdを使ってセットアップしているので、このコマンド例を参考にpcsdの画面にどのように入力するのか?

まずは、pcsdの画面からgfs2-clusterを選択する。
そして、RESOURCESタブから「Add」を選んで、リソース情報入力ダイアログを表示させよう。
で、ダイアログを以下のように設定する。
  • Class/Provider : ocf:pacemaker
  • Type : controld
  • Resource Group : None
  • Clone : チェックOn
  • Master/Slave : チェックOff
  • Disabled : チェックOff
  • ResourceID : dlm
  • args : なし
  • configdir : なし
  • daemon : なし
  • allow_stonith_disabled : なし
これで、Create Resourceボタンを押して作ってみる。
cloneリソースとして作成しているので、自動的にdlm-cloneというグループ?が作られて、そこにdlmリソースが定義される。

作成したdlmリソースに関して、コマンドラインでも確認してみよう。
(gemini) $ sudo pcs resource show
(cancer) $ sudo pcs resource show
cloneリソースとして、dlmリソースが提議されているのが確認でき、Startedになっているのが確認できる。

詳細確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full

詳細を見てみると、start / stop / monitor の3つの項目に、それぞれ interval やその他のパラメータが設定されていることがわかる。
redhat社のサイトでは、op monitor interval=30s on-fail=fence と指定しているので、おそらく monitor 項目の interval パラメータを 30s 、on-fail パラメータを fence に設定しているのだろう。

pcsd の画面からはどうやって設定するのだろうか?
今回のリソースはクローンリソース(複数のノードで同じリソースが稼働するタイプ)で、interval項目は、個別のノードごとに設定を変える必要は無さそうだ。
つまり、全体に影響させればいい。
ということは、dlmではなくdlm-cloneリソースの方のパラメータだろう。
pcsdの画面から、dlm-cloneリソースを選択し、Resource-Meta-Attributeを開いてみる。
Meta Attribute と Value という入力項目があるので、そこに interval と 30s を入れてみる。
…変化なし…。

どうも良くわからないのだが、Operationsパラメータは、pcsdの画面からは修正することが出来ないようだ。
コマンドラインから設定してみることにする。
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
おっとエラーになった。
monitor 定義が既に入っているので、重ねて定義出来ないよ、もし重ねて定義したいのなら、--force を付けてね、とのこと。
同じ interval パラメータ等を定義しても意味が無さそうなので、一旦削除してから定義する。
(gemini) $ sudo pcs resource op remove dlm monitor
(gemini) $ sudo pcs resource show dlm --full
monitor定義が消えたのを確認して
(gemini) $ sudo pcs resource op add dlm monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show dlm --full

一応、cancerの方でも確認してみる。
(cancer) $ sudo pcs resource show dlm --full
反映されているようだ。

これで、redhat社のサイトに掲示されていたコマンドのうち、op monitor interval=30s on-fail=fence の部分は対応できた。
残りは interleave=true と orderded=true だ。
これは結論から言うと、pcsd の画面の dlm-clone リソースから Resource Meta Attribute を入力することで設定することになる。
というわけで、dlm-clone リソースの Resource Meta Attribute の Meta Attribute と Value にそれぞれ以下の値を入れよう。
Meta AtributeValue
interleavetrue
orderdedtrue

確認
(gemini) $ sudo pcs resource show dlm --full
(cancer) $ sudo pcs resource show dlm --full

Meta Attrs に値が表示されていればOKだ。

とりあえず今回はここまで。

2018年8月23日木曜日

クラスタ設定変更(gfs2用)

クラスタのベース部分が出来上がったところで、早速gfs2関連に手を出したいところだけど、その前に1つ、クラスタの設定を変更しておく必要がある。

redhatのサイトだけど、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/global_file_system_2/ch-clustsetup-gfs2
が分かりやすいかな?
あと、ちょっと古いslideshare情報だけど、
https://www.slideshare.net/takmatsuo/osc2010-tokyo-fall-pacemaker
ここも見ておく必要がある。

今回の構成は
  • 2ノードクラスタ
  • 使用リソースはgfs2で、これを両ノードでマウントして使用
なので、クラスタのno-quorum-policyをfreezeに設定しておく必要がある。
この先、Ubuntu18.04(aries/pisces)のクラスタでは、nfs4のサービスを作る予定だが、そちらの場合はno-quorum-policyはignoreに設定しておく必要がありそうだ。

先程のredhatのサイトでは、コマンドで設定するように記載されているけど、今回作成中の環境では、手抜きでvirgoのpcsdから設定する。

ブラウザからvirgoのpcsdにログイン後、Managed Clustersからgfs2-clusterを選択して、gfs2-clusterの設定画面に移動しよう。
移動後、画面上部にあるタブからCLUSTER PROPERTIESを選択すると、クラスタ全体に関わる設定値を確認・変更できる。
クラスタ設定項目に、No Quorum Policyという設定項目があるはずだ。
プルダウンからfreezeを選択し、画面下部のApply Changesボタンを押して反映させよう。

これで、no-quorum-policyの変更ができた。

一応確認してみよう。
#コマンドでの確認は、virgoから実行する方法が分からない。
#gemini/cancerで実行してみよう。
(gemini) $ sudo pcs property show no-quorum-policy
freezeになっているのが確認できると思う。

とりあえず設定変更はココまで。

2018年8月20日月曜日

GFS2/DLM導入(16.04)

gemini/cancerクラスタは、gfs2ファイルシステムの運用を想定している。
そのため、gemini/cancer両ノードにgfs2ファイルシステムを導入しておく必要があった。
また、gfs2ファイルシステムを複数のノードで共有するためには、dlmも必要になる。
一緒に導入しておこう。
(gemini) $ sudo apt-get install gfs2-utils dlm
(cancer) $ sudo apt-get install gfs2-utils dlm

さくっと導入できた。

2018年8月19日日曜日

クラスタベース作ってみる(16.04)

とりあえず、16.04のノード(gemini / cancer)でクラスタを作ってみたい。
同じ16.04のvirgoで動いているpcsdを使って実装してみる。

構成的には
  • virgo:クラスタ管理サーバ
  • gemini:クラスタノード1
  • cancer:クラスタノード2
になる。

ただ、pcsdを使う場合、管理サーバや各ノード間がpcsd同士で通信を行い、各種コマンドや状態のやり取りを行うようだ。
そのため、gemini/cancerでもpcsを導入しておく必要がある。
(gemini) $ sudo apt-get install pcs
(cancer) $ sudo apt-get install pcs

また、pcsdが起動してきてないと思うので、起動しておく。
(gemini) $ sudo systemctl start pcsd
(cancer) $ sudo systemctl start pcsd

gemini/cancerのhaclusterユーザも作成されているはずなので、このアカウントにパスワードを設定しておこう。
(gemini) $ sudo passwd hacluster
(cancer) $ sudo passwd hacluster
設定するパスワードは、virgoに設定したものと同じものが良いだろう。
#クラスタノード(gemini/cancer)でのパスワードは合わせておくのが推奨のようだ。

実はこの他にも、事前準備として実施しておく必要があるものがある。
まずは、/etc/hosts。
DNSが運用できているのであれば不要だと思うけど、ウチのN/Wではローカルの名前解決にDNSは導入できていない。(したいけど…)
そのため、名前解決のために3つのサーバそれぞれの/etc/hostsにエントリを書いておく必要がある。
  • virgo(クラスタ管理サーバ)はgemini/cancerの名前解決ができること
  • gemini/cancer(クラスタ構成ノード)は自分自身とお互いの名前解決ができること
が必要になる。

virgoの/etc/hostsには、geminiとcancerのホスト名/IPアドレスを追記すればいい。
(virgo) $ sudo vi /etc/hosts
gemini/cancerは、既に自分自身のホスト名とIPアドレスの対応として、127.0.1.1がエントリされているはずだ。これをコメント化(先頭に#を付与)しつつ、自分自身と相手のIPアドレスを記載しよう。
(gemini) $ sudo vi /etc/hosts
(cancer) $ sudo vi /etc/hosts

virgo(クラスタ管理サーバ)では、pacemaker/corosyncは稼動させる必要がなく、稼動していたらちょっと他に影響が出るようだ。
そのため、pacemaker/corosyncを停止させ、自動起動も止める。
(virgo) $ sudo systemctl stop pacemaker
(virgo) $ sudo systemctl stop corosync
(virgo) $ sudo systemctl disable pacemaker
(virgo) $ sudo systemctl disable corosync

合わせて、/etc/corosync/corosync.conf が存在していては上手く動作しないようなので、リネームしておく。
(virgo) $ sudo mv /etc/corosync/corosync.conf /etc/corosync/corosync.conf.orig

続いて、gemini/cancerでの準備だ。
クラスタを組む前からpacemaker/corosyncが動いていると、「このノードは既にどこかのクラスタに属している」と勘違いされる。
また、corosync.confが存在しているだけでも、同様に勘違いされる。
そのため、pacemaker/corosyncを停止させ、corosync.confを削除しておく。
(gemini) $ sudo systemctl stop pacemaker
(gemini) $ sudo systemctl stop corosync
(gemini) $ sudo rm /etc/corosync/corosync.conf
(cancer) $ sudo systemctl stop pacemaker
(cancer) $ sudo systemctl stop corosync
(cancer) $ sudo rm /etc/corosync/corosync.conf

ちなみに、上記オペレーションは、pcsコマンドで一括実施できたりする。
(gemini) $ sudo pcs cluster destroy
(cancer) $ sudo pcs cluster destroy
なお、pacemaker/corosyncの自動起動停止はしない(自動起動のままにしておく)。

ここまでやったら事前準備完了だ。
クラスタを組んでみよう。

前回と同様、virgo上のpcsdにブラウザでアクセスする。
(pcsdへのログインは、haclusterアカウントだ)

ログインできたら、「MANAGE CLUSTERS」の中にある「Create New」をクリック。
これから作成するクラスタ名と、そのノード名、その他オプションを設定するダイアログが出てきた。
クラスタ名を gfs2-cluster
ノードをgemini/cancerとする。
その他のオプションはデフォルトのまま「Create Cluster」をクリック。

gemini/cancerのhaclusterアカウントのパスワードを聞いてくると思うので、設定したパスワードを入力しよう。

これでクラスタが出来上がる。
この時点で、gemini/cancerのpacemaker/corosyncともに起動する。
また、gemini/cancerで削除したcorosync.confも自動作成されているはずだ。

次回以降は、クラスタの基本設定から続けていく予定。

2018年8月14日火曜日

まずはpcsの導入

まずは、クラスタ管理用のサーバ(leo/virgo)にpcsを導入して、簡単な初期セットアップだけしてしまおう。

まずはleo(18.04)から。
(leo) $ dpkg -l pcs
(leo) $ sudo apt-get update
(leo) $ sudo apt-get --simulate install pcs
(leo) $ sudo apt-get install pcs
(leo) $ dpkg -l pcs
(leo) $ dpkg -L pcs
(leo) $ systemctl status pcsd
(leo) $ ss -natl | grep 2224
2224番ポートでlistenしているサービスができた。

ブラウザで、
https://(leoのIPアドレス):2224/
へアクセスすると、pacemaker/corosyncへのログイン画面が表示されるはずだ。
ただ、この状態ではどのID/PWDを入力してもログインできない。

この時点で、OS(leo)に hacluster というアカウントができている。これは pcsd を導入した時に(厳密には多分、依存関係にあるパッケージが導入されたタイミングに)作成されたものだ。
で、pcsd はこのアカウントを使用するため、このアカウントにパスワードを設定しておく必要がある。
ちなみに、pcsd が hacluster というアカウントを使用するというのは /usr/share/pcsd/settings.rb というファイルで定義されているからのようだ。
(leo) $ sudo passwd hacluster

hacluster のパスワードが設定できたら、先程のブラウザ画面に戻って、hacluster アカウントでログインしてみよう。
ログインできるのが確認できたら、右上の方のメニューからログアウトしておこう。
現時点ではまだ、ログインできるのを確認するだけだ。

leo での確認が終わったら、virgo でも同じように導入と確認しておこう。
コマンド類はまったく同じだ。
…と思ったけど、pcsd導入時に自動起動しなかった。なぜだろう?
とりあえず、起動しておこう。
(virgo) $ sudo systemctl start pcsd

導入後、leo と同じように hacluster アカウントにパスワードを設定し、ブラウザからアクセスしてみよう。
アクセスできることが確認できたら、pcsの導入は完了だ。

Ubuntu18.04.1へのアップグレードパス

リリース後にいくつか問題があったUbuntu18.04.1だけど、どうやら致命的なバグは解決したらしい。
本来なら、Ubuntu18.04.1がリリースされた2018/07/末で、16.04→18.04へのアップグレードが可能になるはずだったんだけど、何か致命的なバグがあって、アップグレードできない状態だった。
それが解決したようで、アップグレードパスが整った模様。
実施するのなら、root権限で
% do-release-upgrade
とする。

ただ、自分が運用しているaquarius/sagittariusは、gfs2ファイルシステムをpacemaker配下で運用していないので、正しい状態じゃない。
正しい状態じゃない環境をアップグレードしたら、トラブルのは目に見えている。

まずは、pacemakerの構築・運用を確立させてから、アップグレードすることにする。

2018年8月9日木曜日

pacemaker検証(各OS作成)

というわけで、各仮想マシンを作成し、OSをローディング。
構成は考えるのがめんどくさいので、基本的に全部統一。
  • EFIブート
  • メモリ4GB
  • CPU1コア2スレッド
  • HDD20GB
  • NIC1ポート
だ。
OSはデフォルトインストール+OpenSSHサーバ。
クラスタを組むサーバ(pisces/aries、gemini/cancer)には、各クラスタごとに100GBの仮想ディスクを割り当てた。(とりあえず、iSCSIではなく、qcow2形式の仮想ディスクだ。)

あとは、各ゲストごとにIPアドレスを割り当てる。
  • pisces : 192.168.55.133
  • aries : 192.168.55.134
  • gemini : 192.168.55.136
  • cancer : 192.168.55.137
  • leo : 192.168.55.138
  • virgo : 192.168.55.139
とりあえずここまで。


pacemaker検証(OSメディアの入手)

Ubuntuの16.04と18.04の両方を使って検証するので、OSメディアを入手しておく。
通常通り、ubuntuのサイト(https://www.ubuntu.com/)から入手してもいいんだけど、18.04は新しいタイプのインストーラー(ライブインストーラ?)になっている。
16.04時代と同じタイプのインストーラーを使いたかったら、UbuntuのサイトにあるAlternative Donwloadのリンクから、ファイル名に「live」が付いていない方を入手しよう。
ただし、こちらも日本語インストーラーが壊れているらしく、英語モードでインストールする必要がある。
結局、使うメディアは以下の2つにした。
  • ubuntu-16.04.5-server-amd64.iso
  • ubuntu-18.04.1-server-amd64.iso

2018年8月7日火曜日

pacemaker検証(古い環境の削除)

というわけで、これまで作った検証環境のうち、今回のpacemakerで使用する環境を一旦全て削除する。
  • pisces
  • aries
  • gemini
  • cancer
  • leo
  • virgo
だ。
併せて、NASキット側でgemini/cancer向けに作成したiSCSIターゲット、iSCSI LUNも削除してしまう。
一旦キレイに作り直して置きたいからだ。

2018年8月6日月曜日

pacemaker検証(ノード名)

とりあえず、以下のノードを新規作成/再作成してpacemaker検証用にしよう。
  • pisces/aries
    NFSv4クラスタ(Ubuntu18.04)
  • gemini/cancer
    gfs2クラスタ(Ubuntu16.04)
  • leo
    pcsd(Ubuntu18.04)
  • virgo
    pcsd(Ubuntu16.04)
インストール構成は基本的にデフォルトで。細かい設定情報は、別途記載する。

pacemaker再検証(事前情報)

どうやら、gfs2を使用するには、pacemakerと組み合わせるのが基本のようだった。
今現在、KVMホストになっているaquariusとsagittariusは、pacemakerを使用せずにgfs2でファイルシステムを共有している。
これでは不安定になるようなので、本格的にpacemakerの検証をしたい。

で、少し調べてみたら、pcsdというのを使うと、ブラウザから制御できるようだ。
いくつか検証中の仮想マシンを潰して、以下の環境を検証してみたい。
  • gfs2クラスタ検証(Ubuntu16.04)*2台
  • NFSv4クラスタ検証(Ubuntu18.04)*2台
  • pcsd検証(Ubuntu16.04)*1台
  • pcsd検証(Ubuntu18.04)*1台
gfs2クラスタ検証は、検証内容をaquarius/sagittariusにフィードバックするため。
NFSv4は、自宅とは別の環境で検証している環境用で、複数のLinuxノードのホームディレクトリ(/home)共有を目的としている。
できればOpenLDAPによるアカウント統合も検証したい。
pcsd検証が2環境あるのは、単に16.04と18.04でそれぞれ確認してみたいというだけの理由だ。
別途確認してみたら、一度pcsdの管理下に置いたクラスタは、pcsd管理から外してもすぐに管理下に起き直すことができるようだ。
そのため、pcsd自体をHAクラスタにしなくても、同じクラスタを複数のpcsd管理下に置けるのではないか?と考えている。
そのため、2種類のHAクラスタを、両方のpcsd管理下に置くことを想定している。

もちろん、gfs2クラスタやNFSv4クラスタの各ノードでpcsd自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。

まぁゆっくりと…。

2018年5月25日金曜日

NAT64

思うところがあって、別の環境でNAT64の検証してた。(taygaを使用)
結構苦労したんだけど、結局サクっと作れることが分かった。

他にも、DNS64だとかDHCP6だとかを作りたいんだけど、とりあえずNAT64が動かせるところまでは分かった。
う~ん。でも、16.04で構築したから、18.04で作り直そう…。

情報は時間に余裕が出来たら掲載します。

2018年4月14日土曜日

1804でGFS2(失敗)

1804のリリース前バージョンのバージョンアップ方法が分かったところで、sagittarius をバージョンアップしてみた。
結論、バージョンアップに失敗。
バージョンアップ自体は問題なく出来たが、共有ファイルシステムのgfs2がマウント出来ないという問題に当たった。
仮想マシンを配置する場所を全てgfs2にしているため、マウント出来ないのは致命的だ。
また、共有せずにローカルでgfs2を作成してもマウント出来なかった。
原因が判明しなかったため、事前に取得しておいた1604のバックアップでリストアし、元の環境に戻してある。
gfs2かLVMの問題だと考えられるため、仮想マシン上でgfs2を作成、マウント確認することで原因調査することにする。
調べてる時間あるかなぁ…。

2018年3月31日土曜日

sagittariusを18.04LTSに

さて、そういうわけで sagittarius を18.04LTS(リリース前バージョンだが)にバージョンアップしよう。

とりあえず、バージョンアップ直後にネットワーク関連の設定をいじる必要があるため、先にその設定を用意しておこう。

まずは sagittarius 上で netplan の設定ファイルを作っておこう。
ホームディレクトリ上に用意しておく。
(sagittarius) $ cd
(sagittarius) $ vi extsw.yaml
(IPアドレスやデバイス名は各自に合わせて設定するように)
--以下のように新規作成--
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      match: {name: "enp0s31f6"}
      wakeonlan: On
  bridges:
    extsw:
      interfaces: [enp0s31f6]
      dhcp4: false
      addresses:
        - 192.168.55.130/24
      gateway4: 192.168.55.1
      nameservers:
        addresses: [192.168.55.1]
--ココまで--

準備が出来たら、16.04の状態で最新版にアップデートしておこう。
(カーネル類のバージョンアップがあったら、dist-upgrade でアップグレードしてしまおう)
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get --simulate upgrade
(sagittarius) $ sudo apt-get upgrade

アップデート出来たら、一旦再起動して、(現時点で)問題無いことを確認しておく。
(この段階で問題ないことを確認しておかないと、バージョンアップ後に問題が出ても、それがバージョンアップによる問題なのか、元々抱えていた問題なのか判断出来ないためだ。)
(合わせて、仮想マシンが稼働していたら全て落としておくこと)
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ systemctl status

問題無ければ、バックアップを取っておく。
(sagittarius) $ sudo -i
(sagittarius) # cd backup/bin
(sagittarius) # ./0000_backup
(sagittarius) # exit

バックアップは、YYYYMMDDhhmmss という14桁の数字ディレクトリになっている。
バックアップツールは、この14桁のディレクトリの中で古いものを自動削除する設定にしている。
逆に言えば、このディレクトリ名を変更しておけば、自動削除対象から外れる、というわけだ。
今後のことを考えて、ディレクトリ名を変えておこう。
(sagittarius) $ sudo mount /media/backup
(sagittarius) $ cd /media/backup
(sagittarius) $ ls
最新のバックアップディレクトリを確認しておこう
(sagittarius) $ sudo mv (最新のバックアップディレクトリ名) (最新のバックアップディレクトリ名).1604fin
(sagittarius) $ ls
(sagittarius) $ cd
(sagittarius) $ sudo umount /media/backup

さて、いよいよバージョンアップだ。
ココからはコンソールから実行しよう。
(sagittarius) $ LANG=C sudo do-release-upgrade -d -c
(sagittarius) $ LANG=C sudo do-release-upgrade -d

途中で「/etc/default/libvirt-guests ファイルが、パッケージメンテナ版と違うけど、そのまま維持するか、パッケージ版を入れるか?」という質問が出てきた。
ホストOS(今回の場合、sagittarius)を停止させる時、その上のゲストOSにシャットダウンシグナルを送るか?という設定を加えていたため、その分の警告のようだ。
ココで書き加えている。
ON_SHUTDOWN=shutdown という行を書き加えているだけなので、今回は「パッケージメンテナの設定を採用する」として、後から ON_SHUTDOWN=shutdown を書き加えることにしよう。

続いて、sshd_config (/etc/ssh/sshd_config) についても同様に問い合わせが来た。
どうやら、16.04版と18.04版では大きく差があるようだ。
こちらも、パッケージメンテナ版を採用し、後ほどココで書き換えた内容を反映させることにしよう。

更に、/etc/apt/atp.conf.d/50unattended-upgrades というファイルで同様の問い合わせだ。
これも、ココで書き換えている。
こちらは「do a 3-way merge between available versions」というのが選択できる。
バージョン差異を上手いこと取り込んでくれる仕組みのようだ。
何をどう書き換えたかは、記録残してあるので、こちらはこの 3-way merge を選んでみよう。

次は /etc/lvm/lvm.conf だ。
新バージョンはコメントが大量に追加されている。この手のコメントは非常に重要なので取り込んでおきたい。
差分をよく見てみたら、
locking_type = 3 <-> locking_type = 1
use_lvmetad = 0 <-> use_lvmetad = 1
ぐらいが意味のある差異か。
lvmconf --enable-cluster を実行した時に出来た差異だ。
これも、一旦はパッケージメンテナのバージョンを導入し、後から必要な部分を変更することにしよう。

後は、不要なパッケージの削除だ。こちらも y で削除してしまう。

System upgrae is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.

Continue [yN]

終わったようだ。最後に y を押してリブートしよう。

さて…無事に起動してくるかな?

OSは何とか起動してきたが、networking.service と open-iscsi.service の起動に失敗しているようだ。
ネットワークの起動に失敗しているので、iscsi関連が失敗するのは当然。
う~ん。どうやら、openvswitch との兼ね合いのようだ。
この辺りは実は予想していた。
そもそも、openvswitchを起動する処理に手を加えて、 /etc/systemd/system/openvswitch-switch.service というファイルで配置していたからだ。と言っても、6秒の sleep を入れただけだったと思う。

バージョンアップによって、パッケージに入っている起動スクリプト(/lib/systemd/system/openvswitch-switch.service)も大きく変わっていて、起動処理に影響が出ている。
一旦、 /etc/systemd/system/openvswitch-switch.service の方は削除して、再度起動処理を見てみることにしよう。
(sagittarius) $ sudo rm /etc/systemd/system/openvswitch-switch.service
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl reboot

再起動後、サービスを確認してみたら、networking.service は失敗しているがネットワークにはつながったようだ。
そして、openiscsi-service ではなく、corosync.service と lvm2-pvscan@*.service が失敗している。
恐らく、lvm2-pvscan の方はネットワークの起動に関連して失敗したのだろう。

まずは、networking.service の部分を修正する。

予め用意しておいた netplan 用の設定ファイルを配置しよう。
(sagittarius) $ ls -l /etc/netplan
(sagittarius) $ sudo cp extsw.yaml /etc/netplan/
(sagittarius) $ ls -l /etc/netplan
(sagittarius) $ sudo systemctl stop networking.service
(sagittarius) $ sudo systemctl disable networking.service
(sagittarius) $ sudo mkdir /etc/network/interfaces.d.bk
(sagittarius) $ sudo mv /etc/network/interfaces.d/* /etc/network/interfaces.d.bk/
(sagittarius) $ sudo netplan --debug generate
(sagittarius) $ sudo netplan apply

合わせて、名前解決の部分も systemd に直しておく。
(sagittarius) $ systemctl status resolvconf-pull-resolved.path
(sagittarius) $ sudo systemctl stop resolvconf-pull-resolved.path
(sagittarius) $ sudo systemctl disable resolvconf-pull-resolved.path
(sagittarius) $ systemctl status resolvconf-pull-resolved.path

(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo rm /etc/resolv.conf
(sagittarius) $ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
(sagittairus) $ ls -l /etc/resolv.conf

これで再起動をかけて確認してみよう。
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ systemctl status
(sagittarius) $ dig www.yahoo.co.jp
(sagittarius) $ systemd-resolve --status

ネットワーク関連は問題無さそうだ。
ただし、corosync、dlm、lvm2-cluster-activation、lvm2-pvscan の4つが起動に失敗している。
ちょっと長くなってしまったので、この辺りは次のページで対処することにする。

おっといけない。
このままでは、外部から ssh でパスワード認証が通ってしまう。
セキュリティ的によろしく無いため、ssh だけは対処しておこう。
ココに合わせて設定しておこう。
(sagittarius) $ sudo vi /etc/ssh/sshd_config
--ココから
56行目付近
#PasswordAuthentication yes

#PasswordAuthentication yes
PasswordAuthentication no

最終行に以下を追加(192.168.55.0/24は各自の環境に合わせること)
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
--ココまで
(sagittarius) $ sudo systemctl reload sshd

これで、外部からパスワード認証が通らなければOKだ。

さて、続きは次回。

2018年3月30日金曜日

Ubuntu1804検証

Ubuntu の 18.04 が、4月末にリリースされる。
今使っている16.04は既に2年程経っているから、18.04が出たらバージョンアップをしたいと思っている。

が、いきなり18.04にバージョンアップしようとしても大きく変更が入っているはずなので、色々トラブるはず。
そこで、まずは単純に、16.04→18.04のバージョンアップ検証をしてみたいと思う。

まずは、仮想環境にUbuntu16.04を導入し、openvswitch 導入と固定IP化、最新16.04へupgradeしておく。
その後、本来ならバックアップを取得しておくべきだが、今回は仮想環境を使用した検証なので、スナップショットを作っておくことにする。

新しいバージョンにアップグレードするコマンドは do-release-upgrade だが、まだ正式リリース版ではなく開発版のため、-d のオプションが必要になる。
sshでログインしての実行は、N/Wダウンなどのリスクがある。出来ればコンソールから実施しよう。(仮想マシンなら、virt-viewer 等を使用する。)
特に、今回の構成は ssh でログインするポートが openvswitch を経由する。openvswitch のアップデート等で ssh が切断される可能性もあるため、コンソールから作業しよう。
$ sudo apt-get update
$ sudo do-release-upgrade -d -c
$ LANG=C sudo do-release-upgrade -d
#ssh でログインして実行している場合、安全のために追加で ssh を起動する、という確認が入る。そのまま y で継続して構わない。

パッケージ更新の確認で、いくつのパッケージが削除されるか?等の確認が入る。こちらもそのまま y で継続しよう。
途中で、/etc/default/grub の差分について確認の画面が入ることもある。そのままエンターでも、一つ上の「パッケージメンテナのバージョンをインストール(install the package maintainer's version)」でも構わない。

この後、暫く時間がかかる。数十分~数時間。ボーッとモニタを眺めていよう。
アップグレード後、不要なパッケージ(18.04では削除もしくは置き換えられたパッケージ)の削除をするか?と聞いてくる。HDDが無駄になるだけなので、削除してもいいだろう。
というか、どうせ後から削除するので、このタイミングで削除してしまおう。

作業が終わったら、再起動するか聞いてくる。再起動して反映させよう。

開発中のバージョンにアップデートしたため、まだ不具合が残っているかもしれない。
とりあえず、サービスだけは確認しておこう。
$ systemctl status

問題無ければ、念のために最新版にアップデートしておく。
(最新版を入れたはずなので、この数十分の間にパッケージが更新されて無ければ、何も更新は無いはずだ。)
$ sudo apt-get update
$ sudo apt-get --simulate upgrade
$ sudo apt-get upgrade

今回知ったのだが、パッケージ更新時にパッケージに含まれる設定ファイルのファイル名が変わる場合、古い(削除された)設定ファイルは残ってしまうようだ。
例えば、/etc/init/openvswitch-switch.conf。
このファイル、新しい openvswitch-switch パッケージには含まれていないが、16.04時代の openvswitch-switch パッケージには含まれている。
アップグレードすると、このファイルは削除されず、残ってしまう。
但し、「パッケージに含まれるファイル」という扱いではあるので、openvswitch-switch パッケージを削除する時には、一緒に削除してくれる。
つまり、素で18.04をインストールした時と、16.04から18.04にアップグレードした時とで、同じパッケージ構成にしていても、微妙にファイル数が異なる、ということだ。
害は無いが、ちょっと気にはなる。
まぁ対処しなくていいだろう。

さて、無事にアップデート出来たら、ちょっと手を出しておきたいところがある。
16.04の時、ネットワーク設定は ifupdown によって行われていた。
(/etc/network/interfaces 等を使用していた。)
どうやら、17.04か17.10から、ネットワーク設定はnetplan方式に変わったようだ。
(/etc/netplan ディレクトリが設定用ディレクトリ。)

アップグレード後でも、ifupdown 方式は使えるが、デフォルトが netplan 方式に変わったし、ifupdown 方式がいつ使えなくなるか(削除されるか)分からないので、今のうちにnetplan 方式に切り替えておこう。
#他にも、デフォルトが変わったものがあるかもしれないが、今の所ネットワーク関連だけ分かっている。

ちなみにこの netplan、systemd に組み込まれているようで、systemd-networkd というサービスによって起動されるようだ。

というわけで、今までの ifupdown 方式から、 netplan 方式に切り替える。
切り替える前にもう一度バックアップ取っておこう。(仮想環境なので、スナップショットを取っておく。停止してからスナップショットを取るのが安全だ。)

netplan の設定ファイルは、/etc/netplan/*.yaml というファイルで、中身は yaml 形式とか。manをよく読んで作ってみる。
$ sudo vi /etc/netplan/extsw.yaml
--以下のように作成--
--ens3の部分は、物理I/Fのデバイス名だ--
--とりあえず、暫定仮想マシンで作っているのでens3になっている--
--IPアドレスも含めて、各自の環境に合わせてみて欲しい--
network:
version: 2
renderer: networkd
ethernets:
ens3:
match: {name: "ens3"}
bridges:
extsw:
interfaces: [ens3]
dhcp4: false
addresses:
- 192.168.55.143/24
gateway4: 192.168.55.1
nameservers:
addresses: [192.168.55.1]
--ココまで--

出来たらチェックしてみる。
$ sudo netplan --debug generate

特にエラーっぽいメッセージが出て無ければ、反映させてみよう。
ネットワークを一時的に止めるので、コンソールから実施すること。
まずは、今までの networking を止める。
$ sudo systemctl disable networking
$ sudo systemctl stop networking
$ sudo systemctl status networking
$ ip address show

そしたら、systemd-networkd からnetplanを起動してみる。
$ sudo systemctl status systemd-networkd
$ sudo systemctl start systemd-networkd
$ sudo systemctl enable systemd-networkd
$ sudo systemctl status systemd-networkd
$ ip address show

これでネットワークにつながったはずだ。
念のために、古い方の設定で起動しないように、古いファイルは退避しておこう。
$ sudo mkdir /etc/network/interfaces.d.bk
$ sudo mv -i /etc/network/interfaces.d/* /etc/network/interfaces.d.bk

再起動して確認してみる。
$ sudo systemctl reboot
$ ip address show
上手く行っているようだが…
$ systemctl status
$ systemctl --state=failed
どうやら、resolvconf-pull-resolved.serviceというサービスが起動に失敗しているようだ。
$ systemctl status resolvconf-pull-resolved.service
調べてみると、resolvconf関連はこのサービスの他にsystemd-resolved.serviceというのがある。
このサービスは、systemdパッケージに含まれているようだ。
どうやら、16.04にも含まれていて、他のサービスとの兼ね合いで無効化されていたっぽい。
networkingを無効にし、systemd-networkd を有効にしたことで、systemd-resolvedが有効化され、今までしようしていたresolvconf-pull-resolvedとバッティングしているようだ。
というわけで、resolvconf-pull-resolvedを無効化して再起動してみる。
$ sudo systemctl stop resolvconf-pull-resolved
っと、どうやらこのサービスは、resolvconf-pull-resolved.pathを止める必要があるようだ。
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl stop resolvconf-pull-resolved.path
$ sudo systemctl disable resolvconf-pull-resolved.path
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl reboot
$ systemctl status
一応、問題無さそうだ。

ところがこの状態では、名前解決に失敗する。
$ host www.yahoo.co.jp

/etc/hosts に記載されていない名前解決には、/etc/resolv.conf に記載されているネームサーバが使用される。
Debian / Ubuntu は、この /etc/resolv.conf は自動作成されるようになっている(厳密には、別のファイルが出来て、/etc/resolv.conf はそのファイルに対するシンボリックリンクだ)が、resolvconf-pull-resolvdを停止させたことで、/etc/resolv.conf の中身が空っぽになってしまった。
$ cat /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /run/resolvconf/resolv.conf

新しく稼働したsystemd-resolvedは、どうやら/run/systemd/resolveの下に、resolv.conf と stub-resolv.conf という2つのファイルを生成するようだ。
そして、/etc/resolv.conf は /run/systemd/resolve/stub-resolv.conf を指すようにすればいいらしい。
バージョンアップではなく、ダイレクトに18.04をインストールした環境を見たら、そのようになっていた。
(現在、18.04はまだ開発中で、インストール自体がうまくいかない可能性もある。この場合は、ちょっと古いインストールイメージを使用すると良い。)

このことから、/etc/resolv.conf を作り直してみる。
$ sudo rm /etc/resolv.conf
$ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /etc/resolv.conf

ネームサーバとして、127.0.0.53 を指していると思う。
この辺り、ちょっと特殊な作りになっていて、ローカルでネームサーバが起動、127.0.0.53で待受しているようだ。
そして、各クライアントアプリ(リゾルバ)は、ローカルのネームサーバに対して問い合わせを行う仕組みのようだ。

とりあえず、名前解決が出来るか確認してみよう。
$ host www.yahoo.co.jp
無事に名前解決出来たと思う。

再起動しても問題ないか、確認しておこう。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題ないはずだ。

あと、networking.service と resolvconf-pull-resolvd は不要になったはずだ。
削除しておこう。
それぞれ、どのパッケージに入っているか再確認。

$ systemctl status networking.service
サービス定義ファイルが /lib/systemd/system/networking.service だということが確認できる。
$ dpkg -S /lib/systemd/system/networking.service
ifupdown に所属しているファイルだということが分かる。
一応、パッケージに所属しているファイルを一応見ておこう。
$ dpkg -L ifupdown

resolvconf-pull-resolvedについても同様に確認。
$ systemctl status resolvconf-pull-resolved
$ dpkg -S /lib/systemd/system/resolvconf-pull-resolved.service
$ dpkg -L resolvconf

削除してみよう。
削除に不安があるのなら、一度バックアップを取得しておけばいいだろう。(仮想環境なのでスナップショットをとっておく。)

では削除してみる。
$ sudo apt-get --simulate remove ifupdown resolvconf
一緒に ifenslave というパッケージも削除されるようだ。(パッケージの導入状態によっては、他にも削除されるものがあるかもしれない。)
bonding関連のようだが、netplanではteamingにて実現しているので、必要ないということだろう。
サクッと削除してみる。
$ sudo apt-get remove ifupdown resolvconf
再起動を促す画面が出てきた。
一応、再起動してからもう一度名前解決を確認しておく。

$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp

問題無ければ、不要となった設定情報も削除しておく。
$ sudo apt-get purge ifupdown resolvconf ifenslave

今回、16.04から18.04へのバージョンアップで、ネットワーク周りの変更が入っていたため、その変更を取り込む手順を確認した。
他にも変更が入っているかもしれないが、分かり次第取り込むことにしよう。

2018年3月10日土曜日

あれっ!?IPv6アドレスが…。

知らないうちに、うちのマシンにIPv6グローバルアドレス(2001:で始まるアドレス)が振られてる。
知らないうちに、プロバイダがIPv6のサービス始めたのか?
まだIPv6の準備出来てないのにー。

2018年2月8日木曜日

gpuパススルー

ゲストにWindows10を導入し、ホストにPCI-Eで接続しているグラボ(nVidia GeForce GTX 1060)をPCIブリッジでゲストに渡し、ゲストのWindows10で3Dゲームとか楽しもうと思ってる。
で、色々試してたんだけど、結局NGだった。

とりあえず、
https://uramocha02.blogspot.jp/2017/01/pciiommu.html
https://uramocha02.blogspot.jp/2017/01/pcigpu.html
https://uramocha02.blogspot.jp/2017/01/pci.html
この辺りの作業の後、以下の作業を実施。
---------------------------------------
/etc/modules に以下の行を追加
--内容
#PCI pass through
pci_stub
vfio-pci
--ココまで

/etc/modprobe.d/vfio.conf を新規作成
--内容
options vfio-pci ids=10de:1c03,10de:10f1,1912:0014
--ココまで

lsmod | grep -i vfio
dmesg | grep -i vfio
lspci -nnk -d 10de:1c03
lspci -nnk -d 10de:10f1

vi /etc/initramfs-tools/modules
--
pci_stub ids=10de:1c03,10de:10f1,1912:0014
--
lspci -nnk -d 1912:0014
---------------------------------------
それでも、上手くゲストにブリッジ出来ずに悩んでた。

で、どうやら、nVidiaのグラボをPCIパススルーするためには、libvirtのバージョンが1.3.3以上でないとダメのようだ。(AMDのグラボなら可能っぽい)
Ubuntu 16.04 の libvirt は 1.3.1 のようなので、微妙に機能が足りない。

新しい libvirt をビルドするという手もあるし、Ubuntu 18.04 を待たずに、17.10 にアップグレードするという手もあるにはあるけど、18.04 はあと3ヶ月弱でリリースなので、それまで待つことにしよう…。

ちなみに、参考にしてた URL は以下。
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
ハイパーバイザの作り方~ちゃんと理解する仮想化技術~ 第15回 PCIパススルーその1「PCIパススルーとIOMMU」
Libvirt: Domain XML format
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
GPU passthrough: gaming on Windows on Linux
HOW-TO make dual-boot obsolete using kvm VGA passthrough
Linux and Windows running simultaneously with GPU passthrough
PCI passthrough via OVMF
Ubuntu日本語フォーラム / ubuntu14.04上にlibvirt1.3.3 以上をインストールしたい。

Ubuntu 18.04 がリリースされたら、もう一度見直して挑戦しよう。