16.04から18.04へバージョンアップ(sagittarius)

aquarius のバージョンアップも何とか終わり、続いて sagittarius のバージョンアップを行う。
流れは基本的に aquarius で実施した手順と同じだ。
バックアップまでは前回実施済みなので、クラスタ停止とクラスタの自動起動停止からだ。

$ sudo pcs cluster stop sagittarius --force
$ sudo pcs cluster disable sagittarius

そしたらバージョンアップ実施。これはコンソールから実施しよう。

$ sudo LANG=C do-relase-upgrade

出てくるメッセージや、設定ファイルの更新の情報は、aquarius の時と同じはずだ。
同じように対応しよう。

あれ？何故か Postfix Configuration の画面が出てきた。
選択肢としては

No configuration
Internet Site
Internet with smarthost
Satellite system
Local only

となっていて、デフォルトでは Internet Site にフォーカスが当たってる。
Postfix なんて設定したかな…？まぁ、No configuration にしておくか。必要なら別途セットアップすりゃいい。

バージョンアップと再起動が終わったら、設定の確認と反映だ。

$ sudo systemctl status
$ sudo systemctl --state=failed

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

systemd の unit 定義も。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

fstab も直しておこう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

他にも、/etc/fstab エントリや、 /etc/auto.master.d/ とかで cifs マウント設定が入っているところがある。vers=1.0 を追加しておこう。

No longer supported になっているパッケージを削除して再起動だ。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

う～む。postfix が起動に失敗するなぁ。そもそも、aquarius には導入していない。どこで導入されたんだろうか…？
使ってないから削除しておこう。必要ならまた入れればいいからね。

$ sudo apt-get --simulate remove postfix
$ sudo apt-get remove postfix
$ sudo apt autoremove

再起動して、systemd が正しく動いているようなら、バックアップ取っておしまい。

次回以降、クラスタ再設定を行う。

あぁそうそう、18.04 の標準のネットワークは netplan になっている。
今回は 16.04 からそのまま引き継いで ifupdown にしていて、netplan には切り替えていない。
OpenvSwitch が netplan には対応していないようなので、そのまま ifupdown にしている。
もし、18.04 を素でインストールしたのなら、 netplan を削除して ifupdown を導入しないと駄目なので要注意。

16.04から18.04へバージョンアップ(aquarius)

さて、色々検証が中途半端になってしまったが、いい加減18.04にバージョンアップしよう。

過去に一度、sagittarius をバージョンアップしたが、別の問題が出てリストアしている。
今回はそのリベンジだ。

まずは慎重に、両サーバのパッチ適用(16.04の最新版)を行う。
aquarius から実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable aquarius
$ sudo pcs cluster start aquarius
$ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device

続いて sagittarius から実行。

$ sudo pcs cluster stop sagittarius
$ sudo pcs cluster disable sagittarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable sagittarius
$ sudo pcs cluster start sagittarius
$ sudo fence_scsi -o on -n sagittarius -d /dev/mapper/fence-device

両方のノードをバックアップしておこう。
バックアップスクリプトは今まで使用していたもので OK だ。

バックアップが終わったら、いよいよバージョンアップだ。
バージョンアップはコンソールから実行しよう。
aquarius から。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ LANG=C sudo do-release-upgrade

途中、No longer supported として gcc-5-base gcc-6-base tcpd の3つがリストアップされた。まぁ不要なので、あとで削除しておけばいいか。
設定ファイル類の反映で、幾つかが「カスタマイズされているけど、ディストリビューター版を入れるか？今使っているものをそのまま使うか？」という選択肢が出てくる。

/etc/default/libvirt-guests
過去に有効にした ON_SHUTDOWN=shutdown が無効になる。
こちらは、ディストリビューター版を採用して、後で書き換えよう。

/etc/ssh/sshd_config
差分が多いが、外からログインする時の設定以外はディストリビューター版で良さそうだ。
後から、

PasswordAuthentication no
Match Address 192.68.55.0/24
 PasswordAuthentication yes
Match Address 127.0.0.0/8
 PasswordAuthentication yes

を書き加えることにする。

/etc/apt/apt.conf.d/50unattended-upgrades
こちらは、カーネル類を自動アップデートしないように明示的に指定している。
これ、多分ディストリビューター版をそのまま採用して問題無いだろう。
ちなみに、Unattended-Upgrade::Package-Blacklist { } に

"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";

を足し込んでいる。

/etc/lvm/lvm.conf
こちらは、クラスタlvmを使用するために

locking_type = 3
use_lvmetad = 0

を指定しているが、ディストリビューター版を導入し、後から修正することにする。

無事にアップグレードが済み、リブートされたら、検証と設定の戻しを行おう。

$ sudo systemctl status
$ sudo systemctl --state=failed

lvm2-pvscan が一部失敗しているが、多分これは /etc/lvm/lvm.conf を修正すれば正しくなるはず。
設定ファイルを修正するのは以下の3ファイル
/etc/default/libvirt-guests
/etc/ssh/sshd_config
/etc/lvm/lvm.conf

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

ここまで編集したら、再起動しよう。

$ sudo systemctl reboot

あれ？リブートしたら、ネットワークの起動が上手く行かなかった。

$ sudo ifdown extsw
$ sudo ifup extsw

通信はできるな…。もう一度再起動してみる。

$ sudo systemctl reboot

やっぱり駄目だ。

見てみると、networking.service 起動時に、/var/run/openvswitch/db.sock が無い、というエラーになっている。
どうやら、ifupdown で使用する interface 定義、OpenvSwitch 関連のところが誤っていたようだ。(誤っていたのか、仕様が変わったのかは良くわからないが…)

ちょっと原因が違ったので、ここから先は全面書き換え。

ココを見ると、systemd の unit 定義が間違っているようだ。
なので、それの対応を行う。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

全面書き換えココまで

これで再起動したら、問題なく上がってくるはずだ。

ここで、クラスタへの組み直しをやってみたいところだが、corosync のバージョンが異なる機器間でクラスタを組もうとすると、内部DB(cib) のフォーマットが違うためか、マトモに動かない。
それどころか、syslog や corosync.log に大量にログが吐き出され、 /var/log がパンクしてしまうという事象が発生する。
そのため、クラスタ組み直しは、sagittarius のバージョンアップが終わってからにしよう。

最後に、No longer supported になっている3つのパッケージを削除しておこう。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

とりあえずこれで、18.04へのバージョンアップは完了かな？
おっと、せっかく18.04へのバージョンアップが出来たので、バックアップを取っておくのを忘れないように。
だけど、18.04 にしてから CIFS へのアクセスが異常に遅くなった。
バックアップするのもシャレにならないほどの遅さだ。どうやら、cifsのデフォルトが変わったことによるものらしい。
aquarius はバックアップボリュームのマウントを、fstab で指定しているので、それを修正しよう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

これで大丈夫なはず。

ちょっと長くなってしまったので、sagittarius のバージョンアップは次回。

16.04のpacemakerのsystemd定義修正

どうにも挙動がよくわからないので色々調べてみたら、定義に問題がありそうだ…。
/lib/systemd/system/pacemaker.service を見ると、どうもRHEL系の定義っぽい。またパッケージミスかよ。ちなみに、18.04の同ファイルは、.deb系に書き換わっている様子。
ちょっと手直ししておこう。

sudo cp -pi /lib/systemd/system/pacemaker.service /etc/systemd/system/
sudo vi /etc/systemd/system/pacemaker.service
--ココから
23-24行目
EnvironmentFile=-/etc/sysconfig/pacemaker
EnvironmentFile=-/etc/sysconfig/sbd
↓
EnvironmentFile=-/etc/default/pacemaker
EnvironmentFile=-/etc/default/sbd
--ココまで
sudo systemctl daemon-reload
sudo systemctl reboot

とりあえずこれでヨシ。

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

リリース後にいくつか問題があったUbuntu18.04.1だけど、どうやら致命的なバグは解決したらしい。

本来なら、Ubuntu18.04.1がリリースされた2018/07/末で、16.04→18.04へのアップグレードが可能になるはずだったんだけど、何か致命的なバグがあって、アップグレードできない状態だった。

それが解決したようで、アップグレードパスが整った模様。

実施するのなら、root権限で

% do-release-upgrade

とする。

ただ、自分が運用しているaquarius/sagittariusは、gfs2ファイルシステムをpacemaker配下で運用していないので、正しい状態じゃない。

正しい状態じゃない環境をアップグレードしたら、トラブルのは目に見えている。

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

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

1804でGFS2(失敗)

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

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だ。

さて、続きは次回。

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

Ubuntu Desktop 作ってみる

前回に引き続いて、日本語入力関連だ。
今までは Windows をメインマシンに据えて、そこから ssh で Ubuntu マシンにログイン、操作するというやり方だった。
この Windows の部分を、Ubuntu Desktop に置き換えてみようというのが今回の主旨。

まずは、Ubuntu Linux のサイトから、Ubuntu Desktop のメディアをダウンロードしよう。今回は 17.04 を入手した。

そしたら、仮想マシンの作成だ。
スペックは以下の通り。

• 仮想マシン名 : taurus
• ホスト名 : taurus
• IP Address : 192.168.55.135 / 24
• CPU : 4コア*1スレッド(4スレッド)
• メモリ : 4GB
• HDD : 72GB
• ソフトウェア等構成 : デフォルト
• ディスクレイアウト : お任せ＆LVM

実は、この blog には記載していないけど、過去に taurus は作っている。
あくまでテスト的な存在だったので、今はもう不要だ。
これをバッサリ削除して、完全に新規に作成する。

ざっくりインストールして、taurus 上で日本語入力が出来ることを確認しておこう。
あとは、個人的に FireFox は利用していないので、chromium-browser を導入しようと思ったが、google から Debian / Ubuntu 用の chrome がリリースされているようなので、それだけ入れておいた。

導入が終わったら、taurus にログインして、ssh で gemini / cancer にログインできることを確認しておこう。

次回から、日本語入力周りを再確認する。

そろそろ cancer を復活させよう

gemini とペアで使っていた cancer が吹っ飛んで、暫く片方で運用してた。
その cancer を復活させたいと思う。
吹っ飛んだのは cancer の仮想ディスクだけで、仮想マシン定義は残っている。
なので、cancer 用の新規仮想ディスクを作成する。
ディスクサイズは 72GB にする。

今回、ディスクレイアウトは変更する。

• vda1 : 512M : vfat
• vda2 : 512M : ext2
• vda3 : vg-root : lv-root : 10GB : ext4
• vda3 : vg-root : lv-swap-1 : 4GB : swap
• vda3 : vg-root : (未使用) : 残り全て

この条件でサクッと作ろう。

出来上がったら、gemini と同じ環境に揃えていくのだが、パッケージの導入によって、ユーザ・グループが自動作成されていく。
そのため、パッケージの導入順序が違うと、ユーザ名とUIDの対応が gemini と異なる結果になってしまう。
なのでまずは、ユーザ・グループの順番が揃うようにパッケージを導入していく。

gemini / cancer の /etc/group を比較していくと、どうやら最初に kvm グループが作成されているようだ。
ということは、qemu-kvm パッケージを最初に導入すべきかな？
(cancer) $ sudo apt-get install qemu-kvm

次はどうやら scanner 関連っぽい。(導入した記憶は無いのだが、何かの拍子に自動インストールされたのか？)
gemini の方を見てみると、 libsane:amd64 と libsane-common がインストールされているようだ。
それを導入。
(cancer) $ sudo apt-get install libsane:amd64 libsane-common

次は colord か…。
(cancer) $ sudo apt-get install colord

続いて、libvirt 関連。
(cancer) $ sudo apt-get install libvirt-bin

あと、gemini には statd というユーザが存在している。
これはどうやら nfs-common によって作成された代物のようだ。
(cancer) $ sudo apt-get install nfs-common

これで、gemini と cancer の間の /etc/passwd、/etc/group が同じになった(はず)。
但しこれでは、パッケージの導入状態が全く違うので、gemini からパッケージ一覧を取り出して、 cancer に一括適用しよう。

まずは gemini でパッケージ一覧の取得
(gemini) $ dpkg --get-selections > pack.list
この pack.list を、scp 等を用いて cancer へコピーしよう。
(cancer は今現在、dhcp クライアントになっていると思うので、IP アドレスはコンソールから ip address show 等を実行して確認すること。)
(gemini) $ scp pack.list (ユーザ名)@(canerのIP):~/
(gemini) $ rm pack.list

そうしたら、cancer 側でそのパッケージリストを適用する。
(ちょっと面倒かも)
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install dselect
(cancer) $ sudo dselect update
(cancer) $ sudo dpkg --clear-selections
(cancer) $ sudo dpkg --set-selections < pack.list
(cancer) $ sudo apt-get dselect-upgrade
げ、multipath-tools の処理中にエラーになった…。
なんでやろ…
おや？カーネルモジュールの古いのを参照しに行ってるわ。
カーネルは入れ替わってるから、一度再起動が必要だな。
(cancer) $ sudo systemctl reboot
(cancer) $ sudo apt-get install multipath-tools

これでヨシ。

途中でコケちゃったので、一度確認してみる。
(gemini) $ dpkg -l | grep ^ii | wc -l
(cancer) $ dpkg -l | grep ^ii | wc -l
どちらも 742 と出た。インストール済みパッケージの数は合うようだ。

一応クリーニング。
(cancer) $ sudo apt autoremove

コピーしたパッケージ一覧ファイルは削除しておこう。
(cancer) $ rm pack.list

あとは細々と設定を施していくわけだが…。
次回以降で実施することにしよう。

カーネルの自動アップデートの停止

Ubuntu16.04 導入時、「自動アップデートの適用可否」という選択肢が出てきたので、「アップデートしない」にしておいた。
が、カーネルを含むセキュリティアップデートは自動で適用されてしまっているようだ。

他のパッケージならともかく、カーネルの自動アップデートが走ると、(カーネルは入れ替えじゃないため)どんどんディスクを消費していってしまう。
過去、とあるサーバで、気付いたら / がパンクしていてにっちもさっちも行かない状態になったことがある。
常に運用監視するサーバなら、自動アップデートは適用しつつ、適宜再起動を行ってカーネルを最新にしておくべきだが、ウチのマシンはそこまでガチガチに運用するツモリは無い。
また、一応外部(The Internet側)からは、ssh鍵が無いと入れないようにしているため、sshdのセキュリティにだけ気を付けていれば、とりあえず大丈夫なはずだ。
(いや、sshd の手前のネットワークドライバに問題があれば、ssh セキュリティ関係無く突破されてしまうか…)

というわけで、カーネルの自動アップデートだけは禁止にしておきたい。
その代わり、出来るだけ高頻度に、手作業で apt-get upgrade や apt-get install linux-headers-generic linux-signed-generic linux-signed-image-generic を実施するように。

で、どうも調べてみたら、
セキュリティアップデートを停止させるのは /etc/apt/apt.conf.d/50unattended-upgrades というファイルをいじるようだ。

セキュリティフィックスを適用するのを停止したかったら、このファイルの Unattended-Upgraede::Allowed-Origins {} の定義の "${distroid}:${distro_codename}-security"; を無効化すればいいっぽいけど、これを実施すると、全てのセキュリティフィックスが自動適用されなくなる。
ちょっと目的が違う。
今回は、カーネルの自動アップデートだけ避けたい。
この場合は、Unattended-Upgrade::Package-Blacklist {} に当該パッケージを指定すればいいっぽい。

というわけで、gemini / sagittarius / aquarius に実施してみる。
(cancer はまだ死んだまま、復活させていないので。)
$ sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
--ココから
16行目付近
Unattended-Upgrade::Package-Blacklist {
// "vim";
↓3行追記
Unattended-Upgrade::Package-Blacklist {
"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";
// "vim";
--ココまで

これで期待した動きをするのか…？
暫く様子見することにする。

今回はココまで

Ubuntu 17.04リリース

Ubuntuの17.04がリリースされた模様。
このリリースはLTSではないので、一応16.04をメインに使っていくよ。
＃デスクトップ用途なら17.04でもいいかも。

VGのSharedフラグ

クラスタマークを付けたVG(vgchange -c y)に対してvgdisplayを実行すると、Clusterdというパラメータの他に、Sharedというパラメータが表示される。

このSharedは、いつ見ても「no」になっていて、一体このフラグが何を意味しているのか？どういう状況で「yes」に変わるのか？が分からないでいた。

というわけで、今回はこれを調べてみたい。

が…Webで調べてもマニュアルを読んでも、このあたり全然情報が無い。調べ方が悪いのか？
こうなってくると、もうソースを読んで見るしか無いわけだが…正直なところ、あまりやりたくない。

ので、軽く調べて「分かりませんでした」という結論にしたいと思う。

まずはソースコードの入手。
Ubuntuのパッケージ検索サイトから、キーワード「clvm」、Distribution「xenial」で検索し、ヒットした結果の「lvm2ソースパッケージのダウンロード」から[lvm2_2.02.133.orig.tar.xz]をダウンロードする。
とは言っても、gemini/cancerにはwebブラウザは導入していないので、ダウンロードurlをwget/curlで取得しよう。
(gemini) $ wget http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz
もしくは
(gemini) $ curl http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz > lvm2_2.02.133.orig.tar.xz

ダウンロードしたらファイルの展開だ。
.tar.xz形式なので、オプションに注意だ。
(gemini) $ tar tvJf lvm2_2.02.133.orig.tar.xz
(gemini) $ tar xvJf lvm2_2.02.133.orig.tar.xz
lvm2-2.02-133というディレクトリが作成され、その下に展開される。

(gemini) $ cd lvm2-2.02.133
ここからは、ソースファイル(.c)やヘッダファイル(.h)を色々漁って探してみる。

vgdisplayというファイルがあるかも。
(gemini) $ find . -name "*vgdisplay*" -print
./man/vgdisplay.8.in
./tools/vgdisplay.c
あった。
前者はマニュアルなので、後者(./tools/vgdisplay.c)がそれっぽい。

中身を確認してみよう。
(gemini) $ view ./tools/vgdisplay.c
う～ん。何かチガウな…。

「Shared」というキーワードで調べてみよう…。
(gemini) $ find . -type f -print | xargs grep Shared
30行ぐらい出て来るが、その中の1つにそれっぽい行がある。
./lib/display/display.c: log_print("Shared %s",
だ。

どうやら、./lib/display/display.cに、vgdisplayのSharedフラグを表示する行があるっぽい。
見てみよう。
(gemini) $ view ./lib/display/display.c
あったあった。
一部引用する。
--ココから
void vgdisplay_full(const struct volume_group *vg)
{
(略)
log_print("--- Volume group ---");
log_print("VG Name %s", vg->name);
(略)
if (vg_is_clustered(vg)) {
log_print("Clustered yes");
log_print("Shared %s",
vg->status & SHARED ? "yes" : "no");
}
(略)
log_print(" ");
}
--引用ココまで
なるほど、vg構造体ポインタのstatus値でSHAREDフラグが立っていたら「yes」、立っていいなければ「no」か。
(構造体やら論理式やら三項演算子やらが入った行なので、分からなければ「一応、no固定で出しているわけじゃなく、yesかnoかを判定する処理は入ってるんだな」程度の理解でいいだろう。)

vg構造体(volume_group構造体)のstatusフラグか…。一体ドコに更新処理が入ってるんだろう…？この値が更新されないと、Sharedがyesになることは無いんだよな…。

ちょっと検索。
(gemini) $ find . -type f -print | xargs grep status | grep SHARED
う～む。
./lib/format1/import-export.c
./lib/format_pool/import_export.c
の2つのファイルで、SHAREDフラグを立ててるっぽいなぁ。
逆に、フラグを倒す部分が見つからなかった。検索漏れかな？

とりあえず、両ファイルを見てみるか。
(gemini) $ view ./lib/format1/import-export.c
(gemini) $ view ./lib/format_pool/import_export.c
後者はちょっと分からなかった…。
前者は、

• vgをexportする時、当該vgのSHAREDフラグが立ってたら、export情報にもSHARED情報を載せるよ。
• vgをimportする時、入力情報にSHARED情報が載っていたら、import時にSHAREDフラグを立てるよ。

というモノだった。
なんじゃそりゃ…。結局、明示的にSHAREDフラグを立てる方法は無いんかい！？

更に色々見ていったら、vgcreateのmanに、--sharedというオプションがある。
これ、vgcreate時に指定できるけど、vgchangeで変更出来るようには見えない。もしかしたら、vgchange --lock-typeで変更出来るのか…？

いずれにしても、lvmlockdというのが関連しているようなんだけど、Ubuntuにはlvmlockdは実装されていないっぽい。
もはや、vgのSharedフラグは無視してもいいんじゃないか…。

Sharedフラグがlvmlockdに関連すると仮定して、更にwebを調べてみたら、lvmlockdを使用する場合は/etc/lvm/lvm.confのlocking_typeを1(LVM uses local file-based locking, the standard mode.)に設定する必要があるようだ。
CLVMを用いる場合は、同フラグを3(LVM uses built-in clustered locking with clvmd.)に設定するため、どうやらCLVMとlvmlockdは排他使用のようだ。

Ubuntu16.04にはlvmlockdは実装されていないっぽい＆CLVMとlvmlockdは競合する、ということで、これ以上の調査は止めよう。

ということで、Sharedフラグは無視することに。

ゲストにPCIパススルー(キーボード、マウス)

というわけで、GPUのパススルーは出来た。
ただ、それだけだとキーボード・マウスによる入力が出来ない。

当初は、ゲストにUSB Host Deviceからキーボード・マウスを引き渡せばいいかと思ったのだが、どうやらそれでは上手くいかないようだ。
そこで、PCI-Eに挿すUSB拡張カードを買ってきて(今回は、4ポートのUSB3.0カードを買ってみた)、それをPCに挿入、そのPCI-Eカードごとゲストに引き渡す形にした。

ただし、PCI-EカードスロットによってはPCIパススルー出来ないようなので、駄目だったらスロットを変えてみよう。

USB拡張カードを挿入、ホストOS(sagittarius)から認識できたら、GPUのパススルーと同じように、USBカードのパススルーも実施しよう。
ここでは、併せてデバイスの削除も実施しておく。

削除するデバイス

• サウンド：ich6
• タブレット
• チャンネル：spice
• USBリダイレクター1
• USBリダイレクター2

追加するデバイス

• Intel USB 3.0

サウンドデバイスを削除しておくのは、GPUについているサウンドデバイスとバッティングするからだ。
タブレット、spiceチャンネルの削除は、今回の仮想マシン上では不要になるため。
USBリダイレクターに関しては、ちょっと使い方が分からなかったので、一旦削除している。
多分、spiceクライアントからUSBデバイスを接続するためのものかと。

これで起動すると、拡張USBカードに接続しておいたキーボード・マウスがゲストOSで使えるようになる。

駆け足だったけど今日はココまで。

現在は、ubuntuをゲストにしてPCIパススルー(GPUパススルー含む)を検証していたんだけど、この後ゲストOSをWindows7にすれば…と考えていた。
実はWindows7では、GPUパススルーを実現することが出来ないことが発覚した。
そのため、過去使っていたWindows7(物理ホスト、VMware Workstation上のゲスト複数)は、GPUパススルーしないKVMゲストに移植することにする。

次は、その辺りが書けるといいな。

ゲストにPCIパススルー(GPU割当)

続いて、PCIデバイスのグループ確認だ。
どうも、PCIデバイスはコントローラでグルーピング化され、そのグループ単位でしかゲストにブリッジ出来ないらしい。(同一のグループに属するPCIデバイスのうち、一つだけゲストにブリッジする、ということは出来ないらしい。)

と思ったんだけど、グループ確認しなくてもグラボとグラボに搭載されているサウンド、どうやらゲストにブリッジ出来たようだ。
ゲストOS側もUEFIにすることで、目的が達成できるみたいだ。

一度、以下の条件で仮想マシンを作ってみよう。

• ネットワーク：openvswitchで作成したブリッジ
• ファームウェア：UEFI x86_64(「インストール前に設定をカスタマイズする」にチェックを入れておくこと。)
• OS：とりあえず暫定的にubuntuを

これだけでは、おそらく普通にインストールされて、従来通りにvirt-managerやvirt-viewer等で操作出来る仮想マシンに仕上がるはずだ。
一旦、そのゲストマシンのIPアドレスを固定化して、sagittariusやaquariusからログイン出来るようにしておこう。

また、GUI(X Window)を確認しておきたいので、適当に導入しておく。今回は、ubuntu-gnome-desktopを入れておくことにする。

virt-manager/virt-viewerでX Windowが確認できたら、一度そのOSは停止しておく。

停止したら、virt-managerから、ハードウェアの追加をしよう。
PCI Host Deviceからグラボ(自分の場合はNVIDIA Corporationデバイスだ)をゲストに割り当てる。
グラフィック機能とサウンド機能、それぞれデバイスとして認識しているので、2つある。2つとも割り当てよう。

このままでは、まだGPUが利用出来ない。
既に割り当てられているデバイスのうち、以下のものを削除しよう。

• ディスプレイSpice
• ビデオQXL

削除が終わったら、この仮想マシンを起動してみよう。
virt-managerやvirt-viewerの画面には表示がなく、物理マシンのVGA(PCIスロットに挿入したVGA)が繋がっているモニタに表示されたのではないだろうか？

おそらくこれで、GPUをパススルーは成功だ…が、このままではキーボード/マウス入力が出来ない。
キーボード/マウスも渡す必要があるんだが、現時点ではやり方が不明だ。
もう少し調査する。

取り急ぎ、仮想マシンには、別途ネットワーク経由でログインして、シャットダウンしておこう。

キーボード/マウスのパススルーが分かったら、また記載することにする。

今回はここまで。

ゲストにPCIパススルー(IOMMU有効化)

Ubuntuメインの環境にしようと思っても、やっぱりWindowsの便利なツールは手放せない。
更に、自分が使っているデジイチ等、Windows用のアプリしか無いものも多い。
Windowsゲームもやりたい。
そのため、KVMのゲストOSにWindowsを入れるが、KVMのグラフィック機能ではゲームが楽しめない。多分、Blu-Rayディスクも再生させるのが難しいだろう。

そこで出て来るのがPCIパススルーだ。
その名の通り、PCIデバイスをゲストOSにそのまま渡す、という仕組みだ。

実は今回のPCリフレッシュで、PCI Expressのグラフィックボードも搭載している。GeForceの1060を搭載したグラボだ。
(実はこのために、今はCPU搭載GPUのみを使用している。)

lspciコマンドで一応確認してみよう。
(sagittarius) $ sudo lspci
以下の出力が確認できる。
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1c03 (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 10f1 (rev a1)

グラボはPCIEスロットの1番に挿しているが、もしかしたら1番ではPCIパススルーは出来ないかもしれない。その場合は付け直しすることにする。

で、グラボを含めたPCIパススルーは…、実は良く分かってない。
ただ、調べてみたら幾らか情報はある。
このあたりの情報を参考に、色々試してみる。
OVMF による PCI パススルー
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
KVM PCIパススルー (PCI PassThrough)
CentOS7 KVMでPCIパススルー（GPU含む）
Ubuntu 12.04LTS + kvmでPCIパススルー
Linux - PCI-PassThrough

どうやら、UEFIでvt-dを有効にするだけじゃなく、カーネルブートオプションでIOMMUなるものを有効にする必要があるらしい。
ブートオプションなので、カーネルの再ビルド等は不要だ。
念のため、事前の情報を取得しておこう。

(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.before
(sagittarius) $ cat iommu.before
[ 0.057006] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1
自分の環境だと、この1行だけしか出力されなかった。

これに対して、IOMMUを有効にしたらどうなるのだろうか？
どうやら、/etc/default/grubをいじるらしい。
(sagittarius) $ sudo vi /etc/default/grub
12行目あたり、GRUB_CMDLINE_LINUX=""になっていると思う。
これを、GRUB_CMDLINE_LINUX="intel_iommu=on"に書き換えて保存する。

反映させるためには、update-grub2を実行するようだ。
(sagittarius) $ sudo update-grub2

ブートパラメータなので、OS再起動させないと反映されないはず。
(sagittarius) $ sudo shutdown -r now

再起動してきたら、ログインして念のためにdmesgにエラーが無いか確認しておこう。
(sagittarius) $ dmesg | less

で、先程と同様に、iommu関連のログを取得してみる。
(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.after
(sagittarius) $ cat iommu.after
先程は1行だったのが、今度は大量に出た。
そのうち1行、以下の行が出ているのを確認する。
[ 0.000000] DMAR: IOMMU enabled
これが出ていれば、IOMMUは有効になっているはずだ。

とりあえずIOMMU有効化は終わり。
次はPCIデバイスのグループ確認かな？

相互にWoL

前回の記載の通り、今回はaquariusからsagittarius、sagittariusからaquariusに相互にWoLが出来るように設定してみる。
基本的には、aqauriusは起動しっぱなし、sagittariusは適宜停止させることを考えているため、sagittariusからaquariusを起動させることはまず無いのだが、せっかくなので両方設定しておく。

いずれのPCも、オンボードetherからブート出来るようにUEFIを設定しておいて欲しい。
このあたりは、UEFIの実装によって異なるので、各自実機を確認しておくこと。

設定は簡単。
まずは、aquariusからsagittariusを起動させるための設定だ。
sagittariusのOSレベルでWoLが受け入れられるかの確認。(enp0s31f6は、sagittariusのLANの名前だ)
(sagittarius) $ sudo ethtool enp0s31f6

以下の出力があるかを確認してほしい。
Wake-on: g
この Wake-on が g になっていない場合、WoLは出来ない。ethertoolコマンドで変更してほしい。
変更は、各自ググってみてくれ。簡単に見つかるはずだ。
自分の場合、初めから g になっていたため、特に変更することは無かった。

続いて、sagittariusのMACアドレスの確認だ。
(sagittarius) $ ip link show enp0s31f6
以下のような出力があるはずだ。
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
この、XX:XX:XX:XX:XX:XX がsagittariusのMACアドレスになる。

ここまで出来たら、sagittariusをシャットダウンさせよう。
(sagittarius) $ sudo shutdown -h now

停止したら、aquariusからsagittariusが起動できるか確認だ。
既に、wakeonlanコマンドは導入済みのはずなので、supernovaを起動させる時と同様の手順を踏もう。
(aquarius) $ cd ~/wol
(aquarius) $ vi sagittarius
先程確認したMACアドレス(XX:XX:XX:XX:XX:XXの部分)を記載する。(それ以外は記載しない。)

では実際に起動を仕掛けてみる。
(aquarius) $ wakeonlan -f sagittarius
無事に起動してきただろうか？
無事に起動が確認できたら、aquariusからsagittariusの起動確認は終了だ。

今度は逆に、sagittariusからaquariusの起動確認だ。
sagittariusの時と同様に、aquariusのMACアドレスを確認しておこう。
(aquarius) $ ip link show enp0s25

また、ethtoolでWoLが有効かも確認しておく。
(aquarius) $ sudo ethtool enp0s25

確認できたら、aquariusはシャットダウンしておこう。
(aquarius) $ sudo shutdown -h now

続いて、sagittariusの方で準備だ。
多分、sagittariusの方はwakeonlanコマンドが導入されていないと思うので、導入しておこう。
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get --simulate install wakeonlan
(sagittarius) $ sudo apt-get install wakeonlan

wakeonlan用にMACアドレスを記載したファイルを用意しておく。
(sagittarius) $ mkdir ~/wol
(sagittarius) $ cd ~/wol
(sagittarius) $ vi aquarius
先程確認した、aquariusのMACアドレスを記載しておく。

では実際に実行だ。
(sagittarius) $ wakeonlan -f aquarius
どうだろう、無事にaquariusが起動してきただろうか？
無事に起動してきたら成功だ。

いずれも、起動が上手くいかない場合は、UEFIの設定を再確認してみるといい。

今回は以上。

新PCにUbuntu導入

こちらで軽く書いたけど、デスクトップ(ミドルタワー)のPCを作り直している。
元々は、Inter Core2Quadにメモリ8GBというマシン、それにWindows7(ホスト名 supernova)を導入して動かしていた。
こちらでWake On LANの対象にしていたマシンだ。

これを今回バラして、新しく買ったパーツを組み上げて、完全リフレッシュ、というのをやっている。

スペックは、Intel Core i7-6700にメモリ64GBだ。
コア数は同じ4つだが、Hyper Threadingによってスレッド数は倍の8、メモリは8倍の64GBに増強された。

色々紆余曲折はあったが、ようやくUbuntu16.04の導入が終わった。
(ホスト名は sagittarius にした。理由？そりゃ聖闘士星矢で射手座が重要なポジションだったからでしょ。)
ディスクレイアウトは、aquariusが120GBのSSDに対して、sagittariusは240GBのSSDだ。
基本的なレイアウトはaquariusと同じだが、/var/crashを68GBに、swapを128GBにしている。
それ以外は、「Ubuntu 16.04 導入」と同じだ。

これによって、supernovaがいなくなった。(再構築前にシステムバックアップは取得してあるが)

aquariusを作っている時と同じように、openvswitch設定やiSCSI設定などを行っている最中だ。

マザーボードのデフォルトで、Intel-vtやvt-d、オンボードEtherからのWoLが無効化されていたため、UEFIからそれらを有効化することも行っている。

今回のリフレッシュによって、Linux機2台構成になったため、aquariusからsupernovaを起動するWoLは外し、aqauriusからsagittraius、sagittariusからaquariusが相互にWoL出来るように設定を行った。
この設定に関しては、次回記載する。

virt-managerで新規仮想マシンを作ろう その2

というわけで、仮想マシンtestは出来上がった。
とはいえ、OSも何も入っていないので、今回はOSを導入するところ(と、その前後の作業)だ。

まずは、新規仮想マシンにインストールするOSメディアの用意からだ。
testには、つい先日リリースされたばかりのUbuntu 16.10を導入してみよう。

というわけで、Ubuntu 16.10のインストールメディアの入手からだ。

(aquarius) $ sudo su -
(aquarius) # cd /var/lib/libvirt/images
(aquarius) # pwd
(aquarius) # df .
ディスクに空き容量があることは確認しておこう。

(aquarius) # wget http://releases.ubuntu.com/16.10/ubuntu-16.10-server-amd64.iso
(aquarius) # ls -l
(aquarius) # chown libvirt-qemu:kvm ubuntu-16.10-server-amd64.iso
(aquarius) # chmod 644 ubuntu-16.10-server-amd64.iso
(aquarius) # ls -l
(aquarius) # exit

これでメディアは用意できた。

今ダウンロードしたばかりの.isoイメージ、libvirtに認識されていないかもしれない。
一度認識させておこう。
(aquarius) $ virsh pool-refresh default
(aquarius) $ virsh vol-list default
(aquarius) $ virsh vol-info ubuntu-16.10-server-amd64.iso default
先ほどダウンロードしたメディアの情報が出てきたらOKだ。

続いて、spiceのポートを変更しよう。
仮想マシン作成時、spiceの設定は一切いじっていない。そのため、デフォルトのautoになっているはずだ。
これだと、遠隔接続でポート転送設定を組み合わせたい時に不便だ。なので、固定ポートを設定しておこう。
しまった、spiceのポートだ！で設定したことと同じことを行うのだが、piscesで9001、ariesで9003を使用しているので、testは暫定的に9005を指定しよう。

(aquarius) $ virsh edit test
以下のブロックを探し出そう。
    <graphics type='spice' autoport='yes'>
      <image compression='off'/>
    </graphics>
このブロックを、以下のように修正だ。
    <graphics type='spice' port='9005' autoport='no' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
      <image compression='off'/>
    </graphics>

これで、この仮想マシンには、piscesやariesと同じような形で接続が出来るようになった。(teratermでのポート転送は追加しておく必要があるが。)

ここまで出来たら、仮想マシンにOSをインストールする流れだ。
virt-managerを起動して、.isoイメージをマウント、仮想マシンの電源を入れる。
(aquarius) $ virt-manager
(すでにvirt-managerを起動していたら、わざわざ起動する必要は無いぞ)

test仮想マシンをクリックして選択し、メニューバーの「編集」から「仮想マシンの詳細」をクリックしよう。

仮想マシンのウィンドウが出たら、メニューバーの「表示」から「詳細」を選択だ。

仮想マシンの詳細設定が表示される。
この仮想マシンには、まだCD-ROMドライブを付けていないので、CD-ROMドライブを搭載する。
左下の「ハードウェアを追加」のボタンをクリックだ。

「新しいハードウェアを追加」の画面が表示されたら、左のハードウェアの種類で「Storage」が選択されていることを確認(選択されてなかったらクリックして選択)し、デバイスの種類を変更しよう。
(デフォルトでは、「ディスクデバイス」になっているはずだ)

デバイスの種類を「CD-ROMデバイス」に変更したら、マウントするメディアを指定するために、すぐ上の「管理」ボタンをクリック。

ストレージボリュームを選択する画面が出てくるので、「default」プールのubuntu16.10メディアを選択し、「ボリュームの選択」ボタンをクリック。

指定した.isoファイルが選択されているのが確認できたら、「完了」ボタンでウィンドウを閉じよう。

ハードウェア一覧に「IDE CD-ROM」が入ったのが確認できたら、今度は、CD-ROMからブートするために「ブートオプション」をクリックしよう。

起動デバイスの順序に、仮想ディスク、仮想CD-ROM、仮想NICの3つが入っていると思う。
仮想ディスクと仮想CD-ROMにチェックを入れて、ボックス右側の上下ボタンで、仮想CD-ROMが上に来るようにしよう。
設定したら、右下の「Apply」ボタンで確定する。

ブート順の指定が終わったら、仮想マシンを起動しよう。
まずは画面をコンソールに切り替えて、「仮想マシンの電源を入れる」ボタンだ。

すぐにメディアブートして、インストーラーが立ち上がってくるはず。
適当にインストールしてみよう。(この環境は、適当に動かしたらすぐ消すので、あまり細かいことは考えなくていいぞ。)
ホスト名は、仮想マシン名と同じく「test」にしておくことにする。

インストーラーの最後に、「メディアが取り除かれていることを確認してください」の画面が出てくる。
この時点で、仮想CD-ROMから.isoファイルを取り出しておこう。
「仮想マシンの情報を表示」ボタンを押す。(マウスカーソルが画面から出ない場合は、キーボードの左Ctrlキーと左Altキーの同時押しで出せるようになるぞ。)

画面左から「CD-ROM」ドライブを選択し、「Disconnect」ボタンで取り外せる。

取り外したら、もう一度コンソールを表示させ、作業を継続しよう。

インストールが完了したら、自動で再起動され、testが起動してくる。

ちなみに、sshのポート転送設定(9005番ポートの設定)が正しく出来ていれば、Remote-Viewerから接続することも可能だ。

この場合、今までつないでいたコンソールが「エラー： ハイパーバイザーホストへのビューアーの接続は拒否されたか切断されました。」というエラーになって切断されるが、正常動作だ。
仮想マシン設定の画面を一度閉じて、仮想マシンマネージャーから再度testを開けば、また見ることが出来るようになる。

これで、virt-managerから仮想マシンを作成する手順は終わりだ。
testを使用することは無いので、シャットダウンしておこう。
(test) $ sudo shutdown -h now

次回は、このtestを削除する手順だ。