2016年12月31日土曜日

新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出来るように設定を行った。
この設定に関しては、次回記載する。

2016年12月27日火曜日

閑話休題(VMware Workstation on KVM)

う~ん…。
Linux KVMの上にWindows7を載せて、そのWindows7にVMware Workstation(11)を導入、そのVMware WorkstationでゲストOSを動かすことって出来ないのかなぁ…?
何度かやってるけど、起動しようとするとWindows7ごとハングして、暫くしたらWindows7が強制リブートされる…。
ネットで調べても見つからない…。
(逆パターンはいくらでも実績あるんだけどね…)

2016年12月26日月曜日

閑話休題(PCリフレッシュ中)

自宅では、先日購入したWin10タブレットを含めて、全部で4台のPCが動いている。
(常時稼動は1台だけだが。)

以下一覧。
  • メインのワークステーション(Windows7 / デスクトップ)
  • Linuxサーバ(Ubuntu Linux / NUC)
  • ノートPC(Windows7 / ノート型)
  • タブレット(Windows10 / ノート・タブレット型)

で、メインのワークステーションが古すぎるため、パーツを買って現在入れ替えをしている真っ最中だ。
もう随分前のCore2Quadから、第6世代Core i7に再構成している。

そちらを優先している関係で、KVMの検証が進んでいない。誰も読んでないと思うけど、少し待ってくれぃ。

2016年12月20日火曜日

スナップショットを使おう その4(仮想マシンスナップショットの目的整理)

スナップショット、色々試しているけど、ちょっと混乱してきた。
というわけで、まずはスナップショットを使う目的を整理しよう。

  1. ソフトウェアの導入検証
  2. ソフトウェア・OSのバージョンアップ検証
  3. ソフトウェア・OSの設定変更検証
  4. 同一ソフトウェアの異なるバージョンの検証

が主目的ではないだろうか?

1~3までは、「スナップショット作成→検証→元に戻す」を繰り返し、納得がいく状態になったらコミットする、という流れになる。
通常であれば、「バックアップ→検証→リストア」という手順になるが、バックアップおよびリストアは結構手間がかかる。それに比べ、仮想環境で取得可能なスナップショットは非常に短い時間、少ない手間で処理できるので、とても便利だ。

4は、「あるベースイメージから複数のスナップショットを作成→それぞれのスナップショットに異なるバージョンのソフトウェアを導入・検証→元に戻す」を繰り返し、問題ないバージョン(スナップショット)をベースイメージにコミットする、ということになるかと思う。
4に関しては、「ベースイメージを複数コピー→検証→破棄」という流れでも実施可能だ。このパターンなら、複数の仮想マシンに分かれるので、IPアドレス等がバッティングしなければ、同時に複数の仮想マシンを起動可能だ。
ただし、IPアドレスの変更は意外と影響範囲が大きく、思わぬところで躓く可能性があるため、十分注意する必要があるだろう。

というわけで、まずは1~3を目的としたスナップショットの操作手順をおさらいしていこう。

図にすると以下のような感じだ。

スナップショットの破棄パターン

スナップショットのコミットパターン


次回以降にそれぞれ記載していく。

今回はここまで。

2016年12月15日木曜日

いやー、まいった。

snapshotの検証やってたら、piscesを壊しちゃったよ。
pisces作り直しだ。

作り直すと、sshdのホスト鍵が変わるので、sshログイン時に「このサーバ、偽物ちゃう?」ってエラーが出る。
その場合は、ローカルのホスト鍵(known_hostsに書かれている)を削除しよう。

接続元がLinux/Unixの場合は、
$ ssh-keygen -R 接続先ホスト名orIPAddress
かな?

おうふっ!仮想マシンのメモリを128MBに縮小したままだと、インストーラの起動に失敗する。
インストール時は512MBまで拡張しておこう。

2016年12月4日日曜日

スナップショットを使おう その3

というわけで、今回はスナップショットの差分情報を仮想ディスクの内部ではなく、外部に持てないか?という検証。
(VMware Workstation ProやESXiと同じような。)

とりあえず、まだスナップショットが残っていると思うので、削除しておこう。
(aquarius) $ virsh snapshot-delete pisces pisces-1

仮想ディスクにスナップショットの情報が残ってないことを確認しておこう。
(aquarius) $ virsh vol-info pisces.qcow2 default
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ virsh snapshot-list pisces

では、ベースとなる仮想マシンを稼動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

スナップショットを作成する前に、pisces上にダミーファイルを一つ作っておこう。
(pisces) $ touch snap-1

さて、この状態でスナップショットを作るのだが、メモリ情報やディスクのスナップショット情報を外出しにするにはどうすればいいのだろうか?
どうやら、メモリ情報を外出しにするには--memspecというオプション、ディスクは--diskspecというオプションらしい。しかも、--diskspecでファイルをスナップショットファイルを指定する場合、フルパスでないといけないようだ。(メモリは相対パスでもいける)
どこに配置するのが綺麗なのか判らないので、とりあえず仮想ディスクファイルが存在する場所を指定する。
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1 \
--memspec file=/var/lib/libvirt/images/pisces-1.mem,snapshot=external \
--diskspec vda,snapshot=external,file=/var/lib/libvirt/images/pisces-1.vda.qcow2

これで作れたっぽい。
確認してみよう。
(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.mem
-rw------- 1 root root 183578840 12月 4 18:51 /var/lib/libvirt/images/pisces-1.mem

(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 198144 12月 4 18:51 /var/lib/libvirt/images/pisces-1.vda.qcow2

それぞれファイルが出来上がっている。

メモリファイルの方をチェック。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.mem
/var/lib/libvirt/images/pisces-1.mem: Libvirt QEMU Suspend Image, version 2, XML length 3980, running

QEMU Suspend Imageとなっているってことは、仮想マシンを一時的にSuspend状態にして、その瞬間のメモリ情報が格納されているんだろうな。
ってことは、もしかしたら単純に仮想マシンをSuspendさせる時も、同じように--memspecオプションがあるかも。後日調べてみよう。

仮想ディスクファイルのチェック。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.vda.qcow2
/var/lib/libvirt/images/pisces-1.vda.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/libvirt/images/pisces.qcow2), 77309411328 bytes

backing fileとして、元の仮想ディスクファイルが指定されている。
ということはきっと、元の仮想ディスクファイル(pisces.qcow2)からの差分情報が、このファイル(pisces-1.vda.qcow2)に格納されているんだろう。

だとすれば、仮想マシンの定義と、メモリファイル、ベースとなっている仮想ディスクファイル(pisces.qcow2)をバックアップしたら、仮想マシンそのもののバックアップになるのだろうか?
これも後日確認だな。

スナップショットの定義確認。
(aquarius) $ virsh snapshot-info pisces pisces-1
名前: pisces-1
ドメイン: pisces
カレント: はい (yes)
状態: running
場所: 外部
親: -
子: 0
子孫: 0
メタデータ: はい (yes)

お、「場所」の項目が「外部」になっているから、期待した動きのようだ。

前回と同様、仮想ディスクファイル(元の仮想ディスクファイル)を確認してみる。
(aquarius) $ virsh vol-info pisces.qcow2 default

スナップショットの情報は出てこなかった。

qemu-imgコマンドでも確かめてみる。
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2

何も出てこない。

ってことは、元の仮想ディスクファイルには、スナップショットの情報は記録されておらず、新しい差分ファイル(pisces-1.vda.qcow2)の方にのみ、情報が記録されているってことだな。

一応、差分ファイルの方をqemu-imgコマンドで確認してみよう。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.vda.qcow2
image: /var/lib/libvirt/images/pisces-1.vda.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/pisces.qcow2
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

backing fileの定義がある。やっぱりそうみたいだ。

ついでに、仮想メモリファイルの方も確認してみよう。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.mem
image: /var/lib/libvirt/images/pisces-1.mem
file format: raw
virtual size: 175M (183579136 bytes)
disk size: 175M

ん?今、piscesにはメモリ128MByteしか割り当てて無いはずだから、175Mってのはちょっと大きいな…。何でやろ?

続いて、仮想マシンの定義を見てみよう。
(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

仮想ディスクが、pisces-1.vda.qcow2になって、そのbackingStoreとして、pisces.qcow2と定義されている。

pisces-1.vda.qcow2が更新され、今まで使ってたpisces.qcow2は更新されずに参照のみ、ということになるんだろう。

ファイルの状態を見てみる。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu 3525 f.... (libvirt-qemu)qemu-system-x86

(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3525 F.... (libvirt-qemu)qemu-system-x86

pisces.qcow2の方は、ACCESSフラグが"f"で、pisces-1.vda.qcow2の方のACCESSフラグは"F"だ。

man fuserによると、
f open file. f is omitted in default display mode.
F open file for writing. F is omitted in default display mode.
とのことで、やはりpisces.qcow2の方はread onlyなのだろう。

さて、では作ったスナップショットを消してみよう。
(aquarius) $ virsh snapshot-delete pisces pisces-1
エラー: スナップショット pisces-1 の削除に失敗しました
エラー: サポートされない設定: 1 個の外部ディスクスナップショットの削除はまだサポートされていません

おや?削除できない。
ディスクを外部に持たせたタイプのスナップショットは削除できないのか?それじゃスナップショットのメリットが無いなぁ。

だったら、スナップショットに戻すのは?
(aquarius) $ virsh snapshot-revert pisces pisces-1
エラー: サポートされない設定: revert to external snapshot not supported yet

あらま、これもサポートされないって…。

どうやら、外部ディスクにスナップショットを取得していた場合は、スナップショットを削除するには--metadataというオプションが必要らしい。
(aquarius) $ virsh snapshot-delete pisces pisces-1 --metadata
ドメインのスナップショット pisces-1 が削除されました

本当に削除されたのだろうか?
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------

何もリストに出てこない。無事に削除されたようだ。

スナップショットが削除されたのなら、外部スナップショットファイルとメモリファイルはどうなった?
(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.mem
-rw------- 1 root root 183578840 12月 4 18:51 /var/lib/libvirt/images/pisces-1.mem

(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 198144 12月 4 18:51 /var/lib/libvirt/images/pisces-1.vda.qcow2

どちらも存在している。削除はされないようだ。

ファイルの定義も確認しておくが…変わってないようだ。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.mem
/var/lib/libvirt/images/pisces-1.mem: Libvirt QEMU Suspend Image, version 2, XML length 3980, running

(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.vda.qcow2
/var/lib/libvirt/images/pisces-1.vda.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/libvirt/images/pisces.qcow2), 77309411328 bytes

ファイルのオープン状態は?
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3525 F.... (libvirt-qemu)qemu-system-x86

Read/WriteモードでOpenしているようだ…な。

(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu 3525 f.... (libvirt-qemu)qemu-system-x86

ベースファイルの方は、Read Onlyか…。この辺りも変わってないな。

(aquarius) $ sudo fuser -fv /var/lib/libvirt/images/pisces-1.mem
あれ?こちらは誰もOpenしていない。

(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

相変わらず、外部スナップショットファイルを使用しているように見えるぞ。
う~ん。ちょっと期待した動作と違うなぁ…。

一応、qemuコマンドで確認してみる。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.vda.qcow2
image: /var/lib/libvirt/images/pisces-1.vda.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/pisces.qcow2
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.mem
image: /var/lib/libvirt/images/pisces-1.mem
file format: raw
virtual size: 175M (183579136 bytes)
disk size: 175M

変わったようには見えないなぁ。

ちょっとpiscesにダミーファイルを作って、先に作ったダミーファイルを削除してみるか。
(pisces) $ touch hogefuga
(pisces) $ rm snap-1

仮想ディスクファイルのタイムスタンプはどうなった?
(aquarius) $ date; sudo ls -l /var/lib/libvirt/images/pisces.qcow2 /var/lib/libvirt/images/pisces-1.vda.qcow2
2016年 12月 4日 日曜日 19:04:31 JST
-rw------- 1 libvirt-qemu kvm 458752 12月 4 19:04 /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 2917203968 12月 4 18:51 /var/lib/libvirt/images/pisces.qcow2

外部スナップショットファイルの方が更新されたな。

じゃぁこの状態でpiscesを停止してみる。
(pisces) $ sudo shutdown -h now

停止したら、仮想ディスクのタイムスタンプをもう一度確認してみる。
(aquarius) $ date; sudo ls -l /var/lib/libvirt/images/pisces.qcow2 /var/lib/libvirt/images/pisces-1.vda.qcow2
2016年 12月 4日 日曜日 19:05:45 JST
-rw------- 1 root root 3276800 12月 4 19:05 /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 2917203968 12月 4 18:51 /var/lib/libvirt/images/pisces.qcow2

やっぱり、外部スナップショットの方が更新された。
どうやら、一度外部スナップショットファイルを作成すると、基本的にはソレが更新対象になるようだ。
スナップショットを削除しても、ベースの方にI/Oが行われるようになるわけではないようだ。

念のため、piscesの定義も確認してみる。
(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

piscesが停止していると、<backingStore>定義が見えなくなるのか…。

う~ん。再びpiscesを起動してみるか…。
(aquarius) $ virsh start pisces

さっき作成したダミーファイルは残っているんかいな?
(pisces) $ ls hogefuga
存在しているねぇ。

もう一度、ディスク定義を見てみる。
(pisces) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/home/uramoto/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

やっぱり、pisces.qcow2とpisces-1.vda.qcow2の両方を使っているように見えるなぁ。

もう一度、ディスクの使用状況を…。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3820 F.... (libvirt-qemu)qemu-system-x86
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu   3820 f.... (libvirt-qemu)qemu-system-x86

変わってない…。う~ん…。

piscesを停止させてから考えよう…。
(pisces) $ sudo shutdown -h now

なんか、virsh restoreってのがあるみたいだけど、これ使うとどうなるんやろ?
(aquarius) $ virsh restore /var/lib/libvirt/images/pisces-1.mem
ドメインが /var/lib/libvirt/images/pisces-1.mem から復元されました

ちょっ、マジか…。
普通に起動してスナップショットを取得した瞬間の状態になった!

ちょっとログインして、ダミーファイルを確認してみよう…。
(pisces) $ ls hogefuga snap-1
スナップショットを取得する前に作成したファイル(snap-1)は残ってて、スナップショット作成後に作ったファイル(hogefuga)は存在していない!
スナップショットを取った瞬間に戻った…のか?

例によって、ファイルのオープン状態を確認してみよう。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
オープンされていない。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu   3915 F.... (libvirt-qemu)qemu-system-x86

オープンされてる。しかもR/Wモードだ。

メモリファイルの方は…
(aquarius) $ sudo fuser -fv /var/lib/libvirt/images/pisces-1.mem

オープンされてない。

仮想マシンの構成情報は?
(aquarius) $ virsh dumpxml pisces
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

元に戻ってる!!!

piscesを一回停止させて、もう一度起動したら、どの状態になるんだろう?
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh dumpxml pisces
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

あ…あれ?…???どういうことだ???
外部スナップショットファイルが指定されてる…ぞ?
ベースのファイルが更新されているから、これだと起動しないんじゃないか?

(aquarius) $ virsh start pisces
立ち上がってくるなぁ…。
普通に立ち上がってくるし、ダミーファイル(hogefuga)も存在している。
良く分からんぞ…。
(これ、たまたま起動したんだと思う。ベースファイルが大きく書き換わっていた場合、差分ファイルとの整合性が合わなくなる。ベースファイルの更新が少なかったから、なんとかなったのではないだろうか?)

さっきの流れ的には、多分メモリファイルから復帰させた後、構成ファイルを書き換えれば完全に元に(スナップショット前に)戻せるだろう。
とりあえずそれをやってみよう。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh restore /var/lib/libvirt/images/pisces-1.mem
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh edit pisces
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>

<source file='/var/lib/libvirt/images/pisces.qcow2'/>
(aquarius) $ virsh start pisces
(aquarius) $ virsh dumpxml pisces
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh dumpxml pisces
(aquarius) $ sudo rm /var/lib/libvirt/images/pisces-1.mem /var/lib/libvirt/images/pisces-1.vda.qcow2

これで、元に戻ったかな?

今回の実験は、色々な情報がモリモリになっていて、自分でもちょっと理解し切れていない。
一旦はここで切って、次回、情報を整理したい。

というわけで今回は以上。