私が今使っているNASキット、iSCSIターゲットの機能があるのはいいのだが、イニシエータ側(PC/Linux側)で認識しているLUNと、ターゲット側(NAS側)で提供しているLUNのヒモ付が難しい。
LUNを提供するときはいいんだが、使用しなくなったLUNを返却するとき、NAS側でどのLUNなのかが判別できない。
識別する手段を探していたのだが、イマイチながらやり方が分かった。
まずはPC/Linux側でLUN番号を確認する。
$ ls -l /dev/disk/by-path
これで、デバイス名(/dev/sda等)とiSCSI LUNのヒモ付が分かる。
続いて、NASキット側にsshログインして、以下のカーネル情報に移動する
(実は、私が使っているNASキットは、ARM用の組み込みLinuxが使われている。sshでログインでき、簡単なコマンドなら実装されている）
# cd /sys/kernel/scst_tgt/targets/iscsi/(iSCSIターゲット名)/ini_groups/readwrite_ini/luns/(先ほど調べたLUN番号)
(readwriteの部分は、もしかしたらreadonlyとかかもね)
そのディレクトリに、deviceという名前のシンボリックリンクがある。
# ls -l device
こちらのリンク先を見てみると、LUNの名前になっている。
このLUNを削除すればいい。
2016年7月28日木曜日
2016年7月27日水曜日
旧pisces用iscsivol領域削除
さて前回、piscesをlibvirt配下に移すことに成功した。
まぁ、pisces自体はubuntu14.04をインストールしただけの環境なので、新たに作っても良かったんだけどね。
で、今回は最初にpiscesを作るときに用意したiSCSI領域のクリアだ。
余計なデータは持っておく必要が無いからね。
流れは以下の通り。
んじゃまぁ、想定に沿って進めていこう。
まぁ、pisces自体はubuntu14.04をインストールしただけの環境なので、新たに作っても良かったんだけどね。
で、今回は最初にpiscesを作るときに用意したiSCSI領域のクリアだ。
余計なデータは持っておく必要が無いからね。
流れは以下の通り。
- ubuntuのインストールイメージ(.isoファイル)が残っているので、それをlibvirtのストレージプールに移動
- fstabからエントリ削除
- iscsivol領域を、libvirt管理のpoolから削除
- アンマウントからOSデバイス削除まで
- NASキットから当該LUN削除
- OS再起動して確認
- マウントポイントディレクトリの削除
んじゃまぁ、想定に沿って進めていこう。
- ubuntuのインストールイメージ(.isoファイル)が残っているので、それをlibvirtのストレージプールに移動
(aquarius) $ sudo mv ~/iscsivol/ubuntu-14.04.4-server-amd64.iso /var/lib/libvirt/images/
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh pool-refresh default
(aquarius) $ virsh vol-list --pool default
- fstabからエントリ削除
(aquarius) $ sudo vi /etc/fstab
- iscsivol領域を、libvirt管理のpoolから削除
(aquarius) $ virsh pool-list --all
(aquarius) $ virsh pool-destroy iscsivol
(aquarius) $ virsh pool-list --all
(aquarius) $ virsh pool-undefine iscsivol
(aquarius) $ virsh pool-list --all
- アンマウントからOSデバイス削除まで
(aquarius) $ sudo umount ~/iscsivol
(aquarius) $ sudo vgdisplay -v vg-test
(aquarius) $ sudo lvchange -a n vg-test/lv-test1
(aquarius) $ sudo vgdisplay -v vg-test
(aquarius) $ sudo lvremove -f vg-test/lv-test1
(aquarius) $ sudo vgdisplay -v vg-test
(aquarius) $ sudo vgremove vg-test
(aquarius) $ sudo pvremove /dev/sdb1
(aquarius) $ sudo pvs
(aquarius) $ sudo parted /dev/sdb print
(aquarius) $ sudo parted /dev/sdb rm 1
(aquairus) $ sudo parted /dev/sdb print
(aquarius) $ ls -l /dev/sdb*
(aquarius) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(aquarius) $ ls -l /dev/sdb*
- NASキットから当該LUN削除
NASのマニュアルに従ってくれぃ
- OS再起動して確認
OS再起動しても影響が無いことを確認したいんだが、それと併せて確認しておきたいことがある。
今回、- 内蔵ディスク：sda
- 削除されたディスク：sdb
- libvirt用ディスク：sdc
恐らく、再起動後にデバイス名が詰められて、- 内蔵ディスク：sda
- libvirt用ディスク：sdb
それも併せて確認しておきたい。
(aquarius) $ ls -l /dev/sd*
(aquarius) $ sudo pvs
(aquarius) $ ls -l /dev/disk/by-path
(aquarius) $ sudo shutdown -r now
(aquarius) $ ls -l /dev/sd*
(aquarius) $ sudo pvs
(aquarius) $ ls -l /dev/disk/by-path
どうかな？
やっぱり、sdcだったデバイスがsdbに名前変更された。
- マウントポイントディレクトリの削除
(aquarius) $ rmdir ~/iscsivol
2016年7月25日月曜日
pisces忘れるな
以前、libvirtを使わない状態でホスト名piscesというゲストOSを作った。
その後、libvirt配下にariesというゲストOSを作っていて、そちらを使っていた。
せっかくpiscesの方も作ったので、こちらもlibvirt配下に置いて活用したい。
どうやればいいのだろうか？
手探りでやってみよう。
まずは、pisces用仮想ディスクを、ariesの仮想ディスクと同じディレクトリにコピーする。
(aquarius) $ sudo cp -pi --sparse=always ~/iscsivol/test.img /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo ls -l ~/iscsivol/test.img /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo chown root:root /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo chmod 600 /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo ls -l /var/lib/libvirt/images
続いて、ariesの構成情報を取得する。(ariesの構成情報を元に、pisces用に作りなおしてみようと思っている。)
(aquarius) $ virsh dumpxml aries > ~/pisces.xml
(aquairus) $ vi ~/pisces.xml
編集内容…
行番号がズレないように、最終行の方から…。
84行目～87行目付近
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.2'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
↓
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
<image compression='off'/>
</graphics>
66行目～71行目付近
<interface type='network'>
<mac address='52:54:00:76:db:ef'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
↓(1行削除)
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
32行目～37行目付近
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/aries.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
↓
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
2行目～3行目
<name>aries</name>
<uuid>f783e613-619a-4bf8-9e68-dd55a8d45e48</uuid>
↓(1行修正、1行削除)
<name>pisces</name>
そうしたら、このファイルをlibvirtに食わせてみる。
(aquarius) $ ls -l /etc/libvirt/qemu
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh define ~/pisces.xml --validate
(aquarius) $ ls -l /etc/libvirt/qemu
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ sudo diff /etc/libvirt/qemu/pisces.xml ~/pisces.xml
ストレージ(ボリューム)が認識されてないみたいだな…。
これで起動出来るのか？
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
起動したよ…。
(aquarius) $ virsh vol-list default
やっぱり、pisces用のボリュームは認識されてないぞ。
(aquarius) $ sudo ls -l /var/lib/libvirt/images
でも、ファイルのタイムスタンプは更新されている。
どうやら、poolをリフレッシュすれば良さそうだ。
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh pool-refresh default
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
これで、piscesをlibvirt配下に置くことが出来た。
とりあえず、piscesは起動しっぱなしのはずなので、落としておこう。
＃Remote Viewerで接続できるはず。
(pisces) $ sudo shutdown -h now
もう少し色々やりたいけど、今回はココまでにしよう。
初期にpiscesを作るために利用したiscsivolはもう使わなくなるので、次回削除する。
その後、libvirt配下にariesというゲストOSを作っていて、そちらを使っていた。
せっかくpiscesの方も作ったので、こちらもlibvirt配下に置いて活用したい。
どうやればいいのだろうか？
手探りでやってみよう。
まずは、pisces用仮想ディスクを、ariesの仮想ディスクと同じディレクトリにコピーする。
(aquarius) $ sudo cp -pi --sparse=always ~/iscsivol/test.img /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo ls -l ~/iscsivol/test.img /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo chown root:root /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo chmod 600 /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo ls -l /var/lib/libvirt/images
続いて、ariesの構成情報を取得する。(ariesの構成情報を元に、pisces用に作りなおしてみようと思っている。)
(aquarius) $ virsh dumpxml aries > ~/pisces.xml
(aquairus) $ vi ~/pisces.xml
編集内容…
行番号がズレないように、最終行の方から…。
84行目～87行目付近
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.2'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
↓
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
<image compression='off'/>
</graphics>
66行目～71行目付近
<interface type='network'>
<mac address='52:54:00:76:db:ef'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
↓(1行削除)
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
32行目～37行目付近
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/aries.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
↓
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
2行目～3行目
<name>aries</name>
<uuid>f783e613-619a-4bf8-9e68-dd55a8d45e48</uuid>
↓(1行修正、1行削除)
<name>pisces</name>
そうしたら、このファイルをlibvirtに食わせてみる。
(aquarius) $ ls -l /etc/libvirt/qemu
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh define ~/pisces.xml --validate
(aquarius) $ ls -l /etc/libvirt/qemu
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ sudo diff /etc/libvirt/qemu/pisces.xml ~/pisces.xml
ストレージ(ボリューム)が認識されてないみたいだな…。
これで起動出来るのか？
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
起動したよ…。
(aquarius) $ virsh vol-list default
やっぱり、pisces用のボリュームは認識されてないぞ。
(aquarius) $ sudo ls -l /var/lib/libvirt/images
でも、ファイルのタイムスタンプは更新されている。
どうやら、poolをリフレッシュすれば良さそうだ。
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh pool-refresh default
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
これで、piscesをlibvirt配下に置くことが出来た。
とりあえず、piscesは起動しっぱなしのはずなので、落としておこう。
＃Remote Viewerで接続できるはず。
(pisces) $ sudo shutdown -h now
もう少し色々やりたいけど、今回はココまでにしよう。
初期にpiscesを作るために利用したiscsivolはもう使わなくなるので、次回削除する。
2016年7月24日日曜日
KVM用のiSCSI領域作りなおすよ
前回書いた通り、iSCSIのKVM領域を作り直そうと思っている。
で、作り直すとして、どうやってやるか？
やり方は何種類か考えられるけど、どのやり方を実施しようか。
LVMシンプロビジョニング領域の場合、おそらくthin pool自体をpvmoveさせることになると思うけど、この場合は移動してもthin poolのままだ。
また、thin poolから作ったlvを移動させることが出来るか不明だ。
3番は、今まで作ったlv名vg名と異なる名前の領域を作り、そちらに(OSコマンドで)移動させることになる。
この場合、名前を後から変更する(vgchange / lvchange)ことになるが、その後の運用にどう影響が出るか分からない。
そのため、今回は1番を利用することにする。
流れは以下の想定だ。
また、事前準備として、NASのCIFS領域のマウントと、3つのマウントポイントのパーミッションや所有オーナー、グループも確認しておこう。
(aquarius) $ sudo mount /media/backup
(aquarius) $ df /media/backup
(aquarius) $ ls -ld /etc/libvirt /var/lib/libvirt /var/log/libvirt
では、それぞれの手順に従って進めていこう。
(aqaurius) $ sudo umount /media/backup
もし余裕があれば、aquariusを再起動して、再度マウントされるか確認しておくのもいいだろう。
(aquairus) $ sudo shutdown -r now
(aquarius) $ df
ちなみに、使っているNASキット、内部は組み込み用にカスタマイズされたLinuxのようで、iSCSIのLUNは、1つずつ大きなファイルになっている。
これを見てみると、今回用意したファイルは確かに見た目上100GBあるのだが、duで確認してみると、1.6GB程度しかない。
これは、ariesの仮想ディスクとしても実際に確保されているサイズが1.4GB程度で、その他細かいファイルが幾つか存在することと、管理上ある程度使用されている領域の合計だと考えられる。
やっと、NAS側でちゃんとシンプロビジョニングが使えるようになったよ…。
今回はここまで。
で、作り直すとして、どうやってやるか？
やり方は何種類か考えられるけど、どのやり方を実施しようか。
- 一旦バックアップを取り、vg自体を作り直す。
- 新しいLUNをvgに組み込んで、pvmoveで新しいLUNに移動させる
- 新しいLUNからlvを作り、一つずつ中身をコピー(移動)する
LVMシンプロビジョニング領域の場合、おそらくthin pool自体をpvmoveさせることになると思うけど、この場合は移動してもthin poolのままだ。
また、thin poolから作ったlvを移動させることが出来るか不明だ。
3番は、今まで作ったlv名vg名と異なる名前の領域を作り、そちらに(OSコマンドで)移動させることになる。
この場合、名前を後から変更する(vgchange / lvchange)ことになるが、その後の運用にどう影響が出るか分からない。
そのため、今回は1番を利用することにする。
流れは以下の想定だ。
- 3つのlv領域(/etc/libvirt、/var/lib/libvirt、/var/log/libvirt)をそれぞれNASのCIFS領域にバックアップ(tarを使用する想定)
- 念のため、/etc/fstab上の3つのマウント情報をコメント化
- 3つの領域をアンマウント
- 3つのlv削除→thin pool削除→vg削除→pv削除→パーティション削除→ディスク削除
- NASから、当該LUNをiSCSIターゲットから外し、領域を削除
- NAS側で新しいLUNを作成(この時、シンプロビジョニング＆スナップショット不可で作成)、iSCSIターゲットに接続
- 新しく見えてきたディスクでパーティション作成→pv作成→vg作成→lv作成→ファイルシステム作成
- /etc/fstabのコメントを元に戻す
- 3つの領域をマウント
- 3つの領域を書き戻す
- 最後に、tarで取っておいたバックアップを削除
また、事前準備として、NASのCIFS領域のマウントと、3つのマウントポイントのパーミッションや所有オーナー、グループも確認しておこう。
(aquarius) $ sudo mount /media/backup
(aquarius) $ df /media/backup
(aquarius) $ ls -ld /etc/libvirt /var/lib/libvirt /var/log/libvirt
では、それぞれの手順に従って進めていこう。
- 3つのlv領域(/etc/libvirt、/var/lib/libvirt、/var/log/libvirt)をそれぞれNASのCIFS領域にバックアップ(tarを使用する想定)
(aquarius) $ cd /etc
(aquarius) $ sudo tar cvSf /media/backup/etc_libvirt.tar libvirt
(aquarius) $ cd /var/lib
(aquarius) $ sudo tar cvSf /media/backup/lib_libvirt.tar libvirt
(aquarius) $ cd /var/log
(aquarius) $ sudo tar cvSf /media/backup/log_libvirt.tar libvirt
(aquarius) $ ls -l /media/backup/*.tar
- 念のため、/etc/fstab上の3つのマウント情報をコメント化
(aquarius) $ sudo vi /etc/fstab
- 3つの領域をアンマウント
(aquarius) $ sudo umount /etc/libvirt
(aquarius) $ sudo umount /var/lib/libvirt
(aquarius) $ sudo umount /var/log/libvirt
(aquarius) $ df
- 3つのlv削除→thin pool削除→vg削除→pv削除→パーティション削除→ディスク削除
(aquarius) $ sudo lvchange -a n vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvchange -a n vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvchange -a n vg-kvm/lv-var-log-libvirt
(aquarius) $ sudo lvremove -f vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvremove -f vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvremove -f vg-kvm/lv-var-log-libvirt
(aquarius) $ sudo vgdisplay -v vg-kvm
(aquarius) $ sudo lvchange -a n vg-kvm/lv-kvmthin
(aquarius) $ sudo lvremove -f vg-kvm/lv-kvmthin
(aquarius) $ sudo vgdisplay -v vg-kvm
(aquarius) $ sudo vgremove vg-kvm
(aquarius) $ sudo pvremove /dev/sdc1
(aquarius) $ sudo parted /dev/sdc rm 1
(aquarius) $ sudo parted /dev/sdc print
(aquarius) $ sudo bash -c "echo 1 > /sys/block/sdc/device/delete"
(aquarius) $ ls -l /dev/sd*
- NASから、当該LUNをiSCSIターゲットから外し、領域を削除
各NASのマニュアルに従ってくれい。
- NAS側で新しいLUNを作成(この時、シンプロビジョニング＆スナップショット不可で作成)、iSCSIターゲットに接続
こちらも、各NASのマニュアルに従ってくれい。
- 新しく見えてきたディスクでパーティション作成→pv作成→vg作成→lv作成→ファイルシステム作成
(aquarius) $ sudo parted /dev/sdc print
(aquarius) $ sudo parted /dev/sdc mklabel gpt
(aquarius) $ sudo parted /dev/sdc mkpart primary ext4 0% 100%
(aquarius) $ sudo parted /dev/sdc toggle 1 lvm
(aquarius) $ sudo parted /dev/sdc print
(aquarius) $ sudo pvcreate /dev/sdc1
(aquarius) $ sudo vgcreate vg-kvm /dev/sdc1
(aquarius) $ sudo vgdisplay -v vg-kvm
(aquarius) $ sudo lvcreate -L 32M -n lv-etc-libvirt vg-kvm
(aquarius) $ sudo lvcreate -L 50G -n lv-var-lib-libvirt vg-kvm
(aquarius) $ sudo lvcreate -L 2G -n lv-var-log-libvirt vg-kvm
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
- /etc/fstabのコメントを元に戻す
(aquarius) $ sudo vi /etc/fstab
- 3つの領域をマウント
(aquarius) $ sudo mount -a
(aquarius) $ df
- 3つの領域を書き戻す
(aquarius) $ cd /etc
(aquarius) $ sudo tar xvSf /media/backup/etc_libvirt.tar
(aquarius) $ cd /var/lib
(aquarius) $ sudo tar xvSf /media/backup/lib_libvirt.tar
(aquarius) $ cd /var/log
(aquarius) $ sudo tar xvSf /media/backup/log_libvirt.tar
(aquarius) $ ls /etc/libvirt
(aquarius) $ ls /var/lib/libvirt
(aquarius) $ ls /var/log/libvirt
(aquarius) $ ls -ld /etc/libvirt /var/lib/libvirt /var/log/libvirt
- 最後に、tarで取っておいたバックアップを削除
の前に、仮想マシンが動くかどうかは確認しておこう。
(aquarius) $ virsh list --all
(aquarius) $ virsh dominfo aries
(aquarius) $ virsh start aries
(aquarius) $ virsh list --all
(aquarius) $ virsh dominfo aries
(aquarius) $ virsh domdisplay aries
仮想マシンにログインして、syslog等確認したらシャットダウンをしておくこと。
(aries) $ sudo shutdown -h now
(aquarius) $ virsh list --all
では、バックアップしたものは削除しておく。
(aquarius) $ sudo rm /media/backup/etc_libvirt.tar
(aquarius) $ sudo rm /media/backup/lib_libvirt.tar
(aquarius) $ sudo rm /media/backup/log_libvirt.tar
(aqaurius) $ sudo umount /media/backup
もし余裕があれば、aquariusを再起動して、再度マウントされるか確認しておくのもいいだろう。
(aquairus) $ sudo shutdown -r now
(aquarius) $ df
ちなみに、使っているNASキット、内部は組み込み用にカスタマイズされたLinuxのようで、iSCSIのLUNは、1つずつ大きなファイルになっている。
これを見てみると、今回用意したファイルは確かに見た目上100GBあるのだが、duで確認してみると、1.6GB程度しかない。
これは、ariesの仮想ディスクとしても実際に確保されているサイズが1.4GB程度で、その他細かいファイルが幾つか存在することと、管理上ある程度使用されている領域の合計だと考えられる。
やっと、NAS側でちゃんとシンプロビジョニングが使えるようになったよ…。
今回はここまで。
2016年7月23日土曜日
iSCSIが上手く使えない理由が少しわかった
ココの記事で、NAS側のLUNをシンプロビジョニングにしたら、Ubuntu Linux(aquarius)でフォーマット等が出来ない、しょうがないからフルプロビジョニングで使う、なんてことを書いた。
また、それを踏まえてコチラの記事では、「iSCSIはフルプロビジョニング、LVM側でシンプロビジョニング」っていう形で領域を作った。
それから、少し調べてみたら、ほんの少しだけ原因が絞り込めた。
私が使っているNASキットは、iSCSI LUNを作成する時に
また、シンプロビジョニングを選んだ場合は、
つまり、
で、シンプロビジョニングを選んだらLinux側でフォーマット等が出来なかったわけだが、ふと「じゃぁスナップショット不可にしてみたらだどうだ？」というわけで、上述の2番を選んでみた。
そしたらなんと、普通にフォーマットできるし、ddで大きなファイルを書き込んでもエラーにならない。
なんだよ、そういうことか。
どうやら、スナップショット可にすると、NAS内部の管理情報が増えて、書き込み速度が低下するようだ。
そのため、書き込み量が増えた時に、エラーが発生している模様。
ちなみに、同じように「シンプロビジョニング＆スナップショット可」の領域をWindows7に見せた場合、何も問題なくI/O出来る。Windows7側は、I/Oタイムアウトが長めに設定してあるのか、I/O遅延を待ってくれているようだ。
LinuxでもiSCSIパラメータやカーネルパラメータをいじったらナントカなるのかもしれないが、そこまでガッツリチューニングするツモリは無い。
また、NAS側でスナップショットが作れなくても、LVMスナップショットが作れるので、特に致命的じゃない。
というわけで、メインは「シンプロビジョニング＆スナップショット不可」で作っていこうと思う。
というわけで、NAS側で「シンプロビジョニング＆スナップショット不可」のLUNを作成して、前回作った領域の内容を移すことにするよ。
また、LVMシンプロビジョニングを使って作ったけど、通常のLVM領域にすることにするよ。
ちょっとした手術だけど、少しはNASディスク使用効率が上がるから、今のうちに手術しておくよ。
次回乞うご期待。
また、それを踏まえてコチラの記事では、「iSCSIはフルプロビジョニング、LVM側でシンプロビジョニング」っていう形で領域を作った。
それから、少し調べてみたら、ほんの少しだけ原因が絞り込めた。
私が使っているNASキットは、iSCSI LUNを作成する時に
- フルプロビジョニング
- シンプロビジョニング
また、シンプロビジョニングを選んだ場合は、
- スナップショット不可能
- スナップショット可能
つまり、
- フルプロビジョニング
- シンプロビジョニング＆スナップショット不可
- シンプロビジョニング＆スナップショット可(デフォルト)
で、シンプロビジョニングを選んだらLinux側でフォーマット等が出来なかったわけだが、ふと「じゃぁスナップショット不可にしてみたらだどうだ？」というわけで、上述の2番を選んでみた。
そしたらなんと、普通にフォーマットできるし、ddで大きなファイルを書き込んでもエラーにならない。
なんだよ、そういうことか。
どうやら、スナップショット可にすると、NAS内部の管理情報が増えて、書き込み速度が低下するようだ。
そのため、書き込み量が増えた時に、エラーが発生している模様。
ちなみに、同じように「シンプロビジョニング＆スナップショット可」の領域をWindows7に見せた場合、何も問題なくI/O出来る。Windows7側は、I/Oタイムアウトが長めに設定してあるのか、I/O遅延を待ってくれているようだ。
LinuxでもiSCSIパラメータやカーネルパラメータをいじったらナントカなるのかもしれないが、そこまでガッツリチューニングするツモリは無い。
また、NAS側でスナップショットが作れなくても、LVMスナップショットが作れるので、特に致命的じゃない。
というわけで、メインは「シンプロビジョニング＆スナップショット不可」で作っていこうと思う。
というわけで、NAS側で「シンプロビジョニング＆スナップショット不可」のLUNを作成して、前回作った領域の内容を移すことにするよ。
また、LVMシンプロビジョニングを使って作ったけど、通常のLVM領域にすることにするよ。
ちょっとした手術だけど、少しはNASディスク使用効率が上がるから、今のうちに手術しておくよ。
次回乞うご期待。
2016年7月21日木曜日
仮想マシンをiSCSIに移すよ
さて、新しい仮想マシン(aries)をlibvirt配下で作ったのはいいけど、これらの実体はドコにあるのだろうか？
ブツとしては
(仮想HDDイメージは、これまでの調査で/var/lib/libvirt/imagesにあることが分かっているが)
ソレとは別に、
こういう場合、それっぽいファイルを探してみればだいたいの予想が出来る。
というわけで探してみよう。
(aquarius) $ sudo updatedb
(aquarius) $ sudo locate aries
検索に引っかかったファイルのウチ、関係ありそうなのは以下だ。
一つ目は、仮想マシンの定義だろう。
二つ目は、ariesが使っている仮想HDDイメージファイルで、これまでも確認済みだ。
三つ目は、.logになっていることから、稼働ログか何かだろう。
この辺りのファイル・ディレクトリを漁ってみると、他にも何かあるかもしれない。
ネットワークの定義は/etc/libvirt/qemu/networksにあった。
ストレージプールの定義は/etc/libvirt/storageにあった。
それ以外にも、/etc/libvirtや/var/lib/libvirt以下には色々ファイルがあるし、/var/log/libvirtには幾つかディレクトリがある。
ということは、以下の3つをiSCSI領域に移すようにすればいいのかな？
当然、全部で100GBもあるわけじゃない。
iSCSIストレージ側で100GBのLUNを作って、ホストマシン(aquarius)に見せよう。
(piscesを作った時に使ったiSCSIターゲットに100GBのLUNを追加するだけでいいはずだ。)
LUNを追加したら、ホストOS側(aquarius)でディスクデバイスを確認してみよう。
(aquarius) $ dmesg
自分の環境では、sdcとして認識された。
このディスクを使って領域を作成する。ざっくり以下のように。
まずはディスクパーティションの作成
(aquarius) $ sudo parted /dev/sdc print
(aquarius) $ sudo parted /dev/sdc mklabel gpt
(aquarius) $ sudo parted /dev/sdc mkpart primary 0% 100%
(aquarius) $ sudo parted /dev/sdc toggle 1 lvm
(aquarius) $ sudo parted /dev/sdc print
続いて、phisical volume(pv)の作成
(aquarius) $ sudo pvs
(aquarius) $ sudo pvcreate /dev/sdc1
(aquarius) $ sudo pvs
(aquarius) $ sudo pvdisplay /dev/sdc1
そしたら、volume group(vg)の作成
(aquarius) $ sudo vgs
(aquarius) $ sudo vgcreate vg-kvm /dev/sdc1
(aquarius) $ sudo vgs
(aquarius) $ sudo vgdisplay -v vg-kvm
続いて、LVM Thin Provisioning用にThinPoolを作成。
(aquarius) $ sudo lvcreate -l 100%FREE -T vg-kvm/lv-kvmthin
(aquarius) $ sudo lvs vg-kvm/lv-kvmthin
(aquarius) $ sudo lvdisplay -v vg-kvm/lv-kvmthin
1つずつlvを作ろう
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-etc-libvirt -V 32M
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-var-lib-libvirt -V 50G
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-var-log-libvirt -V 2G
(aquarius) $ sudo lvs vg-kvm
(aquarius) $ sudo lvdisplay vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvdisplay vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvdisplay vg-kvm/lv-var-log-libvirt
ファイルシステム作成
(aquarius) $ lsblk
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
そしたら、1つずつデータをコピーしよう。(仮想マシンは止まっていること！)
(aquarius) $ sudo mkdir /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /etc ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /etc/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /var/lib ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /var/lib/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /var/log ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /var/log/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo rmdir /mnt/libvirt
これでデータ類はコピー出来た。後はマウントするだけだ。
念の為に、前のディレクトリはリネームしておく。
(aquarius) $ sudo mv /etc/libvirt /etc/libvirt.orig
(aquairus) $ sudo mkdir /etc/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(aquarius) $ df /etc/libvirt
(aquairus) $ sudo chown root:root /etc/libvirt
(aquarius) $ sudo chmod 755 /etc/libvirt
(aquarius) $ ls -ld /etc/libvirt.orig /etc/libvirt
(aquarius) $ sudo mv /var/lib/libvirt /var/lib/libvirt.orig
(aquairus) $ sudo mkdir /var/lib/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(aquarius) $ df /var/lib/libvirt
(aquairus) $ sudo chown root:root /var/lib/libvirt
(aquarius) $ sudo chmod 755 /var/lib/libvirt
(aquarius) $ ls -ld /var/lib/libvirt.orig /var/lib/libvirt
(aquarius) $ sudo mv /var/log/libvirt /var/log/libvirt.orig
(aquairus) $ sudo mkdir /var/log/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(aquarius) $ df /var/log/libvirt
(aquairus) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ ls -ld /var/log/libvirt.orig /var/log/libvirt
この状態で一度、kvmの状態確認してみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh pool-list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh net-list --all
前回と同じように、起動停止もしてみよう。
(aquarius) $ virsh start aries
virt-viewer(Remote Viewer)で接続確認もしておく。
(aries) $ sudo shutdown -h now
更新先を確認
(aquarius) $ sudo ls -l /var/lib/libvirt/images /var/lib/libvirt.orig/images
自動マウントするように、fstabにも書いておこう。
(aquarius) $ sudo vi /etc/fstab
以下の行を追記する
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
マウントが正しく出来るか確認を。
(aquarius) $ sudo umount /var/log/libvirt
(aquarius) $ sudo umount /var/lib/libvirt
(aquarius) $ sudo umount /etc/libvirt
(aquarius) $ df
(aquarius) $ sudo mount -a
(aquarius) $ df
最後に再起動して、正しくマウントされるかを確認。
(aquarius) $ sudo shutdown -r now
(aquarius) 再ログインして
(aquarius) $ df
どうやら動いているっぽい。
まぁ、今のゲストOS(aries)は、また作り直せるから、仮に何か問題があったら作りなおそう。
というわけで、リネームしておいた3ディレクトリを削除する。
(aquarius) $ sudo rm -rf /etc/libvirt.orig
(aquarius) $ sudo rm -rf /var/lib/libvirt.orig
(aquarius) $ sudo rm -rf /var/log/libvirt.orig
今回はこれでおしまい。
ブツとしては
- 構成情報
- 仮想HDDイメージ
(仮想HDDイメージは、これまでの調査で/var/lib/libvirt/imagesにあることが分かっているが)
ソレとは別に、
- ストレージプール定義
- 仮想ネットワーク定義
こういう場合、それっぽいファイルを探してみればだいたいの予想が出来る。
というわけで探してみよう。
(aquarius) $ sudo updatedb
(aquarius) $ sudo locate aries
検索に引っかかったファイルのウチ、関係ありそうなのは以下だ。
- /etc/libvirt/qemu/aries.xml
- /var/lib/libvirt/images/aries.qcow2
- /var/log/libvirt/qemu/aries.log
一つ目は、仮想マシンの定義だろう。
二つ目は、ariesが使っている仮想HDDイメージファイルで、これまでも確認済みだ。
三つ目は、.logになっていることから、稼働ログか何かだろう。
この辺りのファイル・ディレクトリを漁ってみると、他にも何かあるかもしれない。
ネットワークの定義は/etc/libvirt/qemu/networksにあった。
ストレージプールの定義は/etc/libvirt/storageにあった。
それ以外にも、/etc/libvirtや/var/lib/libvirt以下には色々ファイルがあるし、/var/log/libvirtには幾つかディレクトリがある。
ということは、以下の3つをiSCSI領域に移すようにすればいいのかな？
- /etc/libvirt
- /var/lib/libvirt
- /var/log/libvirt
当然、全部で100GBもあるわけじゃない。
iSCSIストレージ側で100GBのLUNを作って、ホストマシン(aquarius)に見せよう。
(piscesを作った時に使ったiSCSIターゲットに100GBのLUNを追加するだけでいいはずだ。)
LUNを追加したら、ホストOS側(aquarius)でディスクデバイスを確認してみよう。
(aquarius) $ dmesg
自分の環境では、sdcとして認識された。
このディスクを使って領域を作成する。ざっくり以下のように。
| pv名 | pvサイズ | vg名 | プール名 | lv名 | lvサイズ | FS type | マウントポイント |
|---|---|---|---|---|---|---|---|
| /dev/sdc1 | 100GB(あるだけ) | vg-kvm | lv-kvmthin | lv-etc-libvirt | 32MB | ext4 | /etc/libvirt |
| lv-var-lib-libvirt | 50GB | ext4 | /var/lib/libvirt | ||||
| lv-var-log-libvirt | 2GB | ext4 | /var/log/libvirt |
まずはディスクパーティションの作成
(aquarius) $ sudo parted /dev/sdc print
(aquarius) $ sudo parted /dev/sdc mklabel gpt
(aquarius) $ sudo parted /dev/sdc mkpart primary 0% 100%
(aquarius) $ sudo parted /dev/sdc toggle 1 lvm
(aquarius) $ sudo parted /dev/sdc print
続いて、phisical volume(pv)の作成
(aquarius) $ sudo pvs
(aquarius) $ sudo pvcreate /dev/sdc1
(aquarius) $ sudo pvs
(aquarius) $ sudo pvdisplay /dev/sdc1
そしたら、volume group(vg)の作成
(aquarius) $ sudo vgs
(aquarius) $ sudo vgcreate vg-kvm /dev/sdc1
(aquarius) $ sudo vgs
(aquarius) $ sudo vgdisplay -v vg-kvm
続いて、LVM Thin Provisioning用にThinPoolを作成。
(aquarius) $ sudo lvcreate -l 100%FREE -T vg-kvm/lv-kvmthin
(aquarius) $ sudo lvs vg-kvm/lv-kvmthin
(aquarius) $ sudo lvdisplay -v vg-kvm/lv-kvmthin
1つずつlvを作ろう
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-etc-libvirt -V 32M
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-var-lib-libvirt -V 50G
(aquarius) $ sudo lvcreate -T vg-kvm/lv-kvmthin -n lv-var-log-libvirt -V 2G
(aquarius) $ sudo lvs vg-kvm
(aquarius) $ sudo lvdisplay vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvdisplay vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvdisplay vg-kvm/lv-var-log-libvirt
ファイルシステム作成
(aquarius) $ lsblk
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
そしたら、1つずつデータをコピーしよう。(仮想マシンは止まっていること！)
(aquarius) $ sudo mkdir /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /etc ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /etc/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /var/lib ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /var/lib/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /mnt/libvirt
(aquarius) $ ls /mnt/libvirt
(aquarius) $ sudo bash -c "cd /var/log ; tar cSf - libvirt | (cd /mnt ; tar xSf - )"
(aquarius) $ ls -al /var/log/libvirt /mnt/libvirt
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo rmdir /mnt/libvirt
これでデータ類はコピー出来た。後はマウントするだけだ。
念の為に、前のディレクトリはリネームしておく。
(aquarius) $ sudo mv /etc/libvirt /etc/libvirt.orig
(aquairus) $ sudo mkdir /etc/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(aquarius) $ df /etc/libvirt
(aquairus) $ sudo chown root:root /etc/libvirt
(aquarius) $ sudo chmod 755 /etc/libvirt
(aquarius) $ ls -ld /etc/libvirt.orig /etc/libvirt
(aquarius) $ sudo mv /var/lib/libvirt /var/lib/libvirt.orig
(aquairus) $ sudo mkdir /var/lib/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(aquarius) $ df /var/lib/libvirt
(aquairus) $ sudo chown root:root /var/lib/libvirt
(aquarius) $ sudo chmod 755 /var/lib/libvirt
(aquarius) $ ls -ld /var/lib/libvirt.orig /var/lib/libvirt
(aquarius) $ sudo mv /var/log/libvirt /var/log/libvirt.orig
(aquairus) $ sudo mkdir /var/log/libvirt
(aquarius) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(aquarius) $ df /var/log/libvirt
(aquairus) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ ls -ld /var/log/libvirt.orig /var/log/libvirt
この状態で一度、kvmの状態確認してみよう。
(aquarius) $ virsh list --all
(aquarius) $ virsh pool-list --all
(aquarius) $ virsh vol-list --pool default
(aquarius) $ virsh net-list --all
前回と同じように、起動停止もしてみよう。
(aquarius) $ virsh start aries
virt-viewer(Remote Viewer)で接続確認もしておく。
(aries) $ sudo shutdown -h now
更新先を確認
(aquarius) $ sudo ls -l /var/lib/libvirt/images /var/lib/libvirt.orig/images
自動マウントするように、fstabにも書いておこう。
(aquarius) $ sudo vi /etc/fstab
以下の行を追記する
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
マウントが正しく出来るか確認を。
(aquarius) $ sudo umount /var/log/libvirt
(aquarius) $ sudo umount /var/lib/libvirt
(aquarius) $ sudo umount /etc/libvirt
(aquarius) $ df
(aquarius) $ sudo mount -a
(aquarius) $ df
最後に再起動して、正しくマウントされるかを確認。
(aquarius) $ sudo shutdown -r now
(aquarius) 再ログインして
(aquarius) $ df
どうやら動いているっぽい。
まぁ、今のゲストOS(aries)は、また作り直せるから、仮に何か問題があったら作りなおそう。
というわけで、リネームしておいた3ディレクトリを削除する。
(aquarius) $ sudo rm -rf /etc/libvirt.orig
(aquarius) $ sudo rm -rf /var/lib/libvirt.orig
(aquarius) $ sudo rm -rf /var/log/libvirt.orig
今回はこれでおしまい。
LVMでThinProvisioning使えるようにしてみる
ここで「iSCSIからThinProvisioningで作ったLUNが、なんか上手く利用できない」って書いた。
原因は未だに不明だが、もしかしたらLVM側もThinProvisioningを使ったら、綺麗に利用できるのでは？なんて考えてみた。
んで、それを確認するためにiSCSIから100GBの領域をThinProvisioningで切り出したんだ。
Ubuntu側で試そうとしたら、LVM Thinを使うためのパッケージが導入されてなかった。
なのでインストールするよ。
(aquarius) $ sudo apt-get update
(aquarius) $ sudo apt-get --simulate install thin-provisioning-tools
(aquarius) $ sudo apt-get install thin-provisioning-tools
これで多分大丈夫…。
結局ダメだった。
なので、iSCSI LUNはフルプロビジョニングにして、OS側はLVM ThinProvisioningを使ってみる、という形にしよう。
(ディスク使用効率は良くないのだが…)
原因は未だに不明だが、もしかしたらLVM側もThinProvisioningを使ったら、綺麗に利用できるのでは？なんて考えてみた。
んで、それを確認するためにiSCSIから100GBの領域をThinProvisioningで切り出したんだ。
Ubuntu側で試そうとしたら、LVM Thinを使うためのパッケージが導入されてなかった。
なのでインストールするよ。
(aquarius) $ sudo apt-get update
(aquarius) $ sudo apt-get --simulate install thin-provisioning-tools
(aquarius) $ sudo apt-get install thin-provisioning-tools
これで多分大丈夫…。
結局ダメだった。
なので、iSCSI LUNはフルプロビジョニングにして、OS側はLVM ThinProvisioningを使ってみる、という形にしよう。
(ディスク使用効率は良くないのだが…)
2016年7月20日水曜日
ゲストを起動して状態を確認
前回、仮想マシンが停止している状態で、ハイパーバイザ側(ホスト側)から仮想マシンの設定を確認してみた。
今度は、仮想マシンを立ち上げて、仮想マシン側から設定内容がどのように反映されているか確認してみることにする。
仮想マシンを起動するのも、virshコマンドで実施可能だ。
(aquarius) $ virsh list --all
(aquarius) $ virsh start aries
(aquarius) $ virsh list --all
起動出来たら、端末からvirt-viewer(Remote Viewer)で接続してみよう。接続先は spice://127.0.0.2:9001 だぞ。
spiceで接続出来たら、spiceコンソールからログインして、ディスクサイズ、使用量やmacアドレス等をチェックしてみよう。
(aries) $ df -h
(aries) $ free
(aquarius) $ virsh vol-info aries.qcow2 --pool default
使用済み容量は1.3GBぐらいだった。ホスト側から見たディスク割当状態とほぼ同じだ。
(aries) $ sudo pvs
(aries) $ sudo parted /dev/vda print
ディスクのサイズも2GB程。ホスト側から見たサイズとも一致する。
(aries) $ ip a
(aquarius) $ virsh dumpxml aries
ネットワーク・インタフェースのmacアドレスも同じだった。
(aries) $ arp
(aquarius) $ virsh net-dumpxml default
う～ん。ルータに相当するIPのmacアドレスではないのかな？arpコマンドの使い方間違えているかな？
(aries) $ sudo lspci
(aries) $ sudo lshw
(aquarius) $ virsh dumpxml aries
なんとなく、同じ構成に見えるな。ヨシ。
取り敢えずは停止しておこう。
(aries) $ sudo shutdown -h now
間違えて、ホスト側(aquarius)を停止しないように。
さて、今はホスト側のOSディスク上に仮想マシンの環境が出来ている。
内蔵SSDはもったいないので、iSCSIから新たに容量を確保して、そちらに仮想マシン環境を移動させることにする。
のは次回ということで。
今度は、仮想マシンを立ち上げて、仮想マシン側から設定内容がどのように反映されているか確認してみることにする。
仮想マシンを起動するのも、virshコマンドで実施可能だ。
(aquarius) $ virsh list --all
(aquarius) $ virsh start aries
(aquarius) $ virsh list --all
起動出来たら、端末からvirt-viewer(Remote Viewer)で接続してみよう。接続先は spice://127.0.0.2:9001 だぞ。
spiceで接続出来たら、spiceコンソールからログインして、ディスクサイズ、使用量やmacアドレス等をチェックしてみよう。
(aries) $ df -h
(aries) $ free
(aquarius) $ virsh vol-info aries.qcow2 --pool default
使用済み容量は1.3GBぐらいだった。ホスト側から見たディスク割当状態とほぼ同じだ。
(aries) $ sudo pvs
(aries) $ sudo parted /dev/vda print
ディスクのサイズも2GB程。ホスト側から見たサイズとも一致する。
(aries) $ ip a
(aquarius) $ virsh dumpxml aries
ネットワーク・インタフェースのmacアドレスも同じだった。
(aries) $ arp
(aquarius) $ virsh net-dumpxml default
う～ん。ルータに相当するIPのmacアドレスではないのかな？arpコマンドの使い方間違えているかな？
(aries) $ sudo lspci
(aries) $ sudo lshw
(aquarius) $ virsh dumpxml aries
なんとなく、同じ構成に見えるな。ヨシ。
取り敢えずは停止しておこう。
(aries) $ sudo shutdown -h now
間違えて、ホスト側(aquarius)を停止しないように。
さて、今はホスト側のOSディスク上に仮想マシンの環境が出来ている。
内蔵SSDはもったいないので、iSCSIから新たに容量を確保して、そちらに仮想マシン環境を移動させることにする。
のは次回ということで。
ホスト・ゲストの構成を確認しよう
前回で、libvirt管理下のKVM仮想マシンが一つ作れた。
今回はこれの詳細(ホスト側、ゲスト側)を確認したい。
詳細確認は、主にvirshコマンドで実施可能。
なので、1つずつ確認してみる。
ちなみに、KVMやqemu、Xenでは、仮想マシンのことを「Domain」と呼んでいるらしい。従って、virshコマンドにおけるドメインは、仮想マシンのことを指すぞ。
まずは仮想マシンの基本情報を…。
$ virsh list --all
$ virsh dominfo aries
$ virsh dumpxml aries
コマンドを実行してみると分かると思うけど、2つ目は仮想マシンの簡単な概要が表示される。
3つ目は前回も実行したから分かると思うけど、仮想マシンの構成情報がXML形式で出力される。
この中で、仮想ディスクの情報を見てみると、以下のようになっている。
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/aries.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
詳細は色々と調べてみないとはっきりしたことは言えないが、一つだけ間違いないのは、ホストOS上の /var/lib/libvirt/images/aries.qcow2 というファイルが、仮想マシン上のHDDになっている、ということだ。
では、このHDDの状態を確認してみる。
$ virsh pool-list --all
libvirtでは、仮想HDDを置く領域を「プール」と表現している。また、実際の仮想HDDを「ボリューム」と表現している。
上記コマンドで、default と iscsivol という2つのプールが表示されたのではないだろうか？
iscsivol は、OSをインストールする時の.isoファイルが配置されていた場所なので、virt-install が自動的に作ったものだと想定出来る。
となると、default の中に、仮想マシンのHDDが定義されているのだろう。
$ virsh pool-info default
$ virsh pool-dumpxml default
1つ目は、そのプールの簡単な概要だ。
2つ目が、そのプール定義の詳細を表すxmlデータの出力だ。
一部を省略して記載すると、以下の内容になった。
<pool type='dir'>
<name>default</name>
<uuid>略</uuid>
<capacity unit='bytes'>略</capacity>
<allocation unit='bytes'>略</allocation>
<available unit='bytes'>略</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0711</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>
このデータで分かるのは、
つまり、このプールに仮想ディスクを作成すると、/var/lib/libvirt/images 以下に配置される、ということになる。
具体的な仮想ディスクの詳細を見てみる。
$ virsh vol-list --pool default
$ virsh vol-info aries.qcow2 --pool default
$ virsh vol-dumpxml aries.qcow2 --pool default
2つ目のコマンドを実行すると、容量と割り当てという2つの項目に気がつくはずだ。
私の環境では、
容量：2.00GiB
割当：1.37GiB
となっている。
これは、当該ファイルがスパースファイルと呼ばれる形式で作られており、見た目は2GiBあるように見えるが、実際に物理HDD上は1.37GiBしか(まだ)利用されていない、ということを意味している。
実際にファイルのサイズを見てみよう。
$ ls -lh /var/lib/libvirt/images/aries.qcow2
$ du -h /var/lib/libvirt/images/aries.qcow2
前者はサイズが約2.1G、後者は1.4Gと表示された。
ゲストOS(aries)側で使用量が増えれば、後者の出力結果が徐々に2Gに近づいていくはずだ。
また、dumpxmlでは構成が出力される。こちらは今は詳細を見ないが、軽く目を通しておいてもいいだろう。
続いて、仮想マシンのネットワーク関連を見てみる。
$ virsh dumpxml aries
出力内容のうち、ネットワークに関する部分をピックアップしてみると以下の通りだ。
<interface type='network'>
<mac address='52:54:00:76:db:ef'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
soruce networkがdefaultになっている。これが、前回確認したdefaultネットワークのことだ。
今はネットワークはdefaultしか定義されていないので、これ以外に接続することは出来ない。
別途、ネットワークを作った時に、source networkの違いが分かるようになると思う。
一応、もう一度見ておく。
$ virsh net-list --all
$ virsh net-info default
$ virsh net-dumpxml default
3つ目のコマンドで、以下の出力が確認できる。
<network>
<name>default</name>
<uuid>略</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:25:36:ed'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
これを見る限り、このdefaultネットワークに接続したゲストOSは、dhcpクライアントに設定していたら、192.168.122.2～192.168.122.254のドレかのIPアドレスが渡され、更に192.168.122.1をルータにして外部とのやり取りが行われるのではないだろうか？
そして、192.168.122.1のアドレスを持つルータは、52:54:00:25:36:edというmacアドレスを持っているのではないだろうか？
次回、実際にゲストOSを起動して確認してみることにする。
というわけで、今回はココまで。
今回はこれの詳細(ホスト側、ゲスト側)を確認したい。
詳細確認は、主にvirshコマンドで実施可能。
なので、1つずつ確認してみる。
ちなみに、KVMやqemu、Xenでは、仮想マシンのことを「Domain」と呼んでいるらしい。従って、virshコマンドにおけるドメインは、仮想マシンのことを指すぞ。
まずは仮想マシンの基本情報を…。
$ virsh list --all
$ virsh dominfo aries
$ virsh dumpxml aries
コマンドを実行してみると分かると思うけど、2つ目は仮想マシンの簡単な概要が表示される。
3つ目は前回も実行したから分かると思うけど、仮想マシンの構成情報がXML形式で出力される。
この中で、仮想ディスクの情報を見てみると、以下のようになっている。
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/aries.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
詳細は色々と調べてみないとはっきりしたことは言えないが、一つだけ間違いないのは、ホストOS上の /var/lib/libvirt/images/aries.qcow2 というファイルが、仮想マシン上のHDDになっている、ということだ。
では、このHDDの状態を確認してみる。
$ virsh pool-list --all
libvirtでは、仮想HDDを置く領域を「プール」と表現している。また、実際の仮想HDDを「ボリューム」と表現している。
上記コマンドで、default と iscsivol という2つのプールが表示されたのではないだろうか？
iscsivol は、OSをインストールする時の.isoファイルが配置されていた場所なので、virt-install が自動的に作ったものだと想定出来る。
となると、default の中に、仮想マシンのHDDが定義されているのだろう。
$ virsh pool-info default
$ virsh pool-dumpxml default
1つ目は、そのプールの簡単な概要だ。
2つ目が、そのプール定義の詳細を表すxmlデータの出力だ。
一部を省略して記載すると、以下の内容になった。
<pool type='dir'>
<name>default</name>
<uuid>略</uuid>
<capacity unit='bytes'>略</capacity>
<allocation unit='bytes'>略</allocation>
<available unit='bytes'>略</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0711</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>
このデータで分かるのは、
- プールの形式はDirectory
- パスは/var/lib/libvirt/images
つまり、このプールに仮想ディスクを作成すると、/var/lib/libvirt/images 以下に配置される、ということになる。
具体的な仮想ディスクの詳細を見てみる。
$ virsh vol-list --pool default
$ virsh vol-info aries.qcow2 --pool default
$ virsh vol-dumpxml aries.qcow2 --pool default
2つ目のコマンドを実行すると、容量と割り当てという2つの項目に気がつくはずだ。
私の環境では、
容量：2.00GiB
割当：1.37GiB
となっている。
これは、当該ファイルがスパースファイルと呼ばれる形式で作られており、見た目は2GiBあるように見えるが、実際に物理HDD上は1.37GiBしか(まだ)利用されていない、ということを意味している。
実際にファイルのサイズを見てみよう。
$ ls -lh /var/lib/libvirt/images/aries.qcow2
$ du -h /var/lib/libvirt/images/aries.qcow2
前者はサイズが約2.1G、後者は1.4Gと表示された。
ゲストOS(aries)側で使用量が増えれば、後者の出力結果が徐々に2Gに近づいていくはずだ。
また、dumpxmlでは構成が出力される。こちらは今は詳細を見ないが、軽く目を通しておいてもいいだろう。
続いて、仮想マシンのネットワーク関連を見てみる。
$ virsh dumpxml aries
出力内容のうち、ネットワークに関する部分をピックアップしてみると以下の通りだ。
<interface type='network'>
<mac address='52:54:00:76:db:ef'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
soruce networkがdefaultになっている。これが、前回確認したdefaultネットワークのことだ。
今はネットワークはdefaultしか定義されていないので、これ以外に接続することは出来ない。
別途、ネットワークを作った時に、source networkの違いが分かるようになると思う。
一応、もう一度見ておく。
$ virsh net-list --all
$ virsh net-info default
$ virsh net-dumpxml default
3つ目のコマンドで、以下の出力が確認できる。
<network>
<name>default</name>
<uuid>略</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:25:36:ed'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
これを見る限り、このdefaultネットワークに接続したゲストOSは、dhcpクライアントに設定していたら、192.168.122.2～192.168.122.254のドレかのIPアドレスが渡され、更に192.168.122.1をルータにして外部とのやり取りが行われるのではないだろうか？
そして、192.168.122.1のアドレスを持つルータは、52:54:00:25:36:edというmacアドレスを持っているのではないだろうか？
次回、実際にゲストOSを起動して確認してみることにする。
というわけで、今回はココまで。
2016年7月17日日曜日
libvirtを忘れずに
これまでのKVMの利用方法は、あくまでQEMUを通してのモノだった。
KVMは、libvirtというライブラリ(デーモン)を通して利用するのが、今のトレンドで正しいやり方のようだ。
多くのツールキットが、libvirtを通してKVMを利用するように出来ているし、libvirtはバックエンドの仮想化環境がKVMだけでなく、旧来のqemuやXen、果てはVMware ESXにも対応しているようだ。(ESXi / vSphereに対応しているかは不明。)
http://libvirt.org/
また、libvirtはC言語で書かれているため、C言語用のAPIは用意されているが、Python用のAPIも用意されているらしい。
更に、PerlやRuby等用にもAPIを準備しているとのこと。(多分、C言語APIか、Python用APIに対するラッパーを開発しているのだろう)
通常のコマンドラインで利用するための virsh コマンド、GUIで設定確認等が行える virt-manager というのも用意されている。
libvirtを使うと、Virtual Machineの管理がしやすくなる。
どういう風に管理しやすいか？っていうところだけど…あまり詳しくない。使ってみれば分かるだろう。
分かっている限りだと…
さっそく、libvirtを用いた仮想マシン操作をしてみたいところだが、その前に準備が必要だ。
明確になったところで、iSCSI領域に配置し直すことにする。
なので、virt-installをインストールしよう
$ sudo apt-get install virtinst
あと、osinfo-query というコマンドを後で使う。
なので、これもインストールしておこう。
$ sudo apt-get install libosinfo-bin
で、virt-install を使うんだけど、その前にネットワークの設定を確認しておこう。
Ubuntuの場合、仮想環境(libvirt-bin？)をインストールした段階で、仮想ネットワークvirbr0というのが出来上がる。
実際に、IPアドレスも付与されているはずだ。
$ ip address show dev virbr0
私の環境では、192.168.122.1/24 というIPアドレスが付与されていた。
(virbr0-nicというのも存在するんだけど、これは何なのか不明…。恐らく、virbr0が物理NICに接続する中間デバイスのようなものではないか？
仮想マシンNIC - virbr0(スイッチ) - virbr0-nic - 物理NIC という経路なのかと。)
また、brctlなるコマンドで一覧が見られる。
$ brctl show
virbr0 のエントリが出力されたはずだ。(virbr0-nic は出力されていない。やっぱり謎だ。)
私の環境では、出力結果の interfaces 項目が空なのだが、どういうことだろう？
予想では、virbr0-nic か、物理NIC名が入ってくるものと思ったのだが…。
もう一つ、bridge コマンドというのもある。これも良く分からないのだが…。
$ bridge vlan show
$ bridge fdb show
で、何か表示される。(何かってナンダヨ…)
前者は、ブリッジネットワークのVLAN定義が出力されるんだけど、何も設定していないので「1 PVID Egress Untagged」ってな具合に、Untaggedと表示される。(タグ付けしてないので、少なくともタグVLANじゃないね。)
後者は、Forwarding Database entry の略で、何だろう？転送先かな？Networkデバイス名とmacアドレスっぽい文字列の組み合わせが大量に出力された。
そのうちの一つ、「01:00:5e:00:00:01」というのは、レイヤ2転送用のmacアドレスらしい。
それ以外には、「33:33:ff」で始まるmacアドレスが復数存在しているが、どうやらIPv6マルチキャスト用のmacアドレスのようだ。
ってことは、とりあえず無視しても構わないだろうな。
で、じゃあKVM的には、virbr0ってどんなん？ってことなんだが、今度は virsh コマンドを用いることになる。
ちょっと見てみよう。
$ virsh net-list --all
defaultという名前のエントリ1つだけ出てきたはず。
じゃぁコレの詳細は？
$ virsh net-info default
ブリッジという項目に、virbr0 と出てきたはずだ。
ということは、defaultネットワークにつなぐことが、virbr0につなぐ、ということになるのではないだろうか？
更に、定義をxml形式で出力することも出来る
$ virsh net-dumpxml default
(このネットワーク定義を保存しておけば、リストアで使用できるっぽいぞ)
とりあえず、xml形式の方を見ると、<forward mode='nat'> という定義がある。
これを見ると、どうやらnat形式のネットワークのようだ。
＃VMware系等の仮想環境で言うところの、NATネットワークと同じようだ。
う～ん。これだけ見てみても、色々あって覚えきれねぇ。
とりあえず、virt-install のマニュアル(man virt-install)にサンプルが載っているので、これをいじって一つ仮想マシンを立ててみよう。
その前に、仮想マシンのOS定義がどの程度あって、何が使えるか確認しておこう。
$ osinfo-query os
ずらずらと出てきたエントリの中に、ubuntu14.04が見つかっただろうか？
このエントリを、次の virt-install コマンドの --os-variant 引数に適用する。
$ virt-install \
--virt-type kvm \
--name aries \
--vcpus 2 \
--memory 512 \
--disk size=2,sparse=yes \
--check disk_size=off \
--network network=default \
--cdrom ~/iscsivol/ubuntu-14.04.4-server-amd64.iso \
--graphics spice,port=9001,password=test \
--os-variant ubuntu14.04
っとコケた。
「ERROR サポートされない設定: spice TLS ポートが XML 設定において設定されていますが、TLS が qemu.conf において無効化されています」
だそうな。
どうも、--graphics spice のオプションに port オプションを付与すると、tlsによる接続環境も作ろうとしてしまうようだ。
ただ、/etc/libvirt/qemu.conf は一切いじっておらず、tls 関連の環境はまだまったく作っていない。
そもそも、サーバ証明書等の準備は一切していないから、tls は使えない状態だ。
さてどうしよう…。
なので4番を使ってみたい。
port オプションを指定しない場合、SPICEのポートはどうやら5900番を使用するようだ。
sshポート転送に以下の内容を追加して、ログインし直そう。
その後、ポートを9001に変えてみたいと思うので、併せて以下の設定も入れておこう。
$ virt-install \
--virt-type kvm \
--name aries \
--vcpus 2 \
--memory 512 \
--disk size=2,sparse=yes \
--check disk_size=off \
--network network=default \
--cdrom ~/iscsivol/ubuntu-14.04.4-server-amd64.iso \
--graphics spice,listen=127.0.0.2,password=test \
--os-variant ubuntu14.04
う～ん。
「Couldn't open libGL.so.1: libGL.so.1: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません」
というエラーが出る。
ただ、libGLが無くても動いているようなので、あまり気にしないようにしよう。
(多分、libGLをインストールすればいいんだと思う。)
念の為に、プロセスが生きているか確認してみよう。
$ ps -ef | grep qemu | grep -v grep
くっそ長い行が出てきたはずだ。これが出てくれば、実行成功だ。
実行出来たら、Remote viewer(Virtviewer)を起動して、spice://127.0.0.2:5900 へ接続してみよう。
(パスワードは、引数に指定している test だぞ)
無事に接続が出来たら、言語選択(UbuntuのOSメディアでブートした一番最初の画面)が表示されるはずだ。
ここまで出来たら、一旦この状態で設定確認をしてみよう。
コマンドプロンプトから以下のコマンドを実行することで、仮想マシンの設定が見られるぞ。
$ virsh list --all
$ virsh dumpxml aries
1つ目は、このlibvirt管理下の仮想マシン一覧だ。今はまだ1つしか作っていないから、1行しか出てこないはずだ。
2つ目は、仮想マシンariesの設定情報をxml形式で出力するコマンドだ。
ズラズラと出てくるが、xml形式なのである程度は読めるはずだ。
一旦、現状の設定を保存しておこう。
$ virsh dumpxml aries > aries.xml
そうしたら、通常通りインストールは進めてしまう。
最小構成にssh-serverを入れるだけでとりあえずはいい。
(以前、piscesを作った時と同じオプション構成だ。ホスト名はariesとする。)
インストール完了後、再起動せずに停止状態になった。
おかしいな、再起動すると思ったんだが…。
とりあえず、spiceの待受ポートだけ変更しよう。
$ virsh edit aries
viが立ち上がり、仮想マシンariesの設定情報(xml形式)が編集できる状態になったと思う。
以下の部分を変更しよう
<graphics type='spice' autoport='yes' listen='127.0.0.2' passwd='test'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
↓
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.2' passwd='test'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
書き換えたら、仮想マシンariesを起動してみる。
起動はvirshコマンドで実行出来るぞ。
$ virsh list --all
$ virsh start aries
$ virsh list --all
起動できたか確認してみよう。
virt-viewer(RemoteViewer)で、spice://127.0.0.2:9001 へアクセスしてみよう。
無事にアクセス出来たら、ログインプロンプトが出ているはずだ。
ariesをインストールした時のユーザIDでログインしてみよう。
ログインできたはずだ。
かなり長くなってしまったので、一旦ココで切って、次回以降で少しずつ内容確認していく。
ariesはシャットダウンしておこう。
(aries) $ sudo shutdown -h now
(aquarius) $ virsh list --all
KVMは、libvirtというライブラリ(デーモン)を通して利用するのが、今のトレンドで正しいやり方のようだ。
多くのツールキットが、libvirtを通してKVMを利用するように出来ているし、libvirtはバックエンドの仮想化環境がKVMだけでなく、旧来のqemuやXen、果てはVMware ESXにも対応しているようだ。(ESXi / vSphereに対応しているかは不明。)
http://libvirt.org/
また、libvirtはC言語で書かれているため、C言語用のAPIは用意されているが、Python用のAPIも用意されているらしい。
更に、PerlやRuby等用にもAPIを準備しているとのこと。(多分、C言語APIか、Python用APIに対するラッパーを開発しているのだろう)
通常のコマンドラインで利用するための virsh コマンド、GUIで設定確認等が行える virt-manager というのも用意されている。
libvirtを使うと、Virtual Machineの管理がしやすくなる。
どういう風に管理しやすいか？っていうところだけど…あまり詳しくない。使ってみれば分かるだろう。
分かっている限りだと…
- 仮想マシンの起動オプションは設定ファイルに
起動のたびに、「あれ？起動オプション何だっけ？」って悩まなくていい - 仮想マシンに対する外付けデバイス(CD-ROMやらUSB機器)を、コマンド等でオン/オフ出来る
仮想マシンにアプリケーションを導入するのに、CD-ROMイメージを交換するのが簡単になる
さっそく、libvirtを用いた仮想マシン操作をしてみたいところだが、その前に準備が必要だ。
- 仮想マシンの定義はXML形式のファイルに記載する
- Web上にサンプルはあるが、これだけでは書けない
(これだけで書けたらすごい) - 定義を作るツール(virt-install)がある
- 今はインストールされていないので、インストールする必要がある
- 仮想マシンの定義(XMLファイル)と仮想ディスクイメージを配置するディレクトリは、原則固定
(/var/lib/libvirt/images/？)
明確になったところで、iSCSI領域に配置し直すことにする。
なので、virt-installをインストールしよう
$ sudo apt-get install virtinst
あと、osinfo-query というコマンドを後で使う。
なので、これもインストールしておこう。
$ sudo apt-get install libosinfo-bin
Ubuntuの場合、仮想環境(libvirt-bin？)をインストールした段階で、仮想ネットワークvirbr0というのが出来上がる。
実際に、IPアドレスも付与されているはずだ。
$ ip address show dev virbr0
私の環境では、192.168.122.1/24 というIPアドレスが付与されていた。
(virbr0-nicというのも存在するんだけど、これは何なのか不明…。恐らく、virbr0が物理NICに接続する中間デバイスのようなものではないか？
仮想マシンNIC - virbr0(スイッチ) - virbr0-nic - 物理NIC という経路なのかと。)
また、brctlなるコマンドで一覧が見られる。
$ brctl show
virbr0 のエントリが出力されたはずだ。(virbr0-nic は出力されていない。やっぱり謎だ。)
私の環境では、出力結果の interfaces 項目が空なのだが、どういうことだろう？
予想では、virbr0-nic か、物理NIC名が入ってくるものと思ったのだが…。
もう一つ、bridge コマンドというのもある。これも良く分からないのだが…。
$ bridge vlan show
$ bridge fdb show
で、何か表示される。(何かってナンダヨ…)
前者は、ブリッジネットワークのVLAN定義が出力されるんだけど、何も設定していないので「1 PVID Egress Untagged」ってな具合に、Untaggedと表示される。(タグ付けしてないので、少なくともタグVLANじゃないね。)
後者は、Forwarding Database entry の略で、何だろう？転送先かな？Networkデバイス名とmacアドレスっぽい文字列の組み合わせが大量に出力された。
そのうちの一つ、「01:00:5e:00:00:01」というのは、レイヤ2転送用のmacアドレスらしい。
それ以外には、「33:33:ff」で始まるmacアドレスが復数存在しているが、どうやらIPv6マルチキャスト用のmacアドレスのようだ。
ってことは、とりあえず無視しても構わないだろうな。
で、じゃあKVM的には、virbr0ってどんなん？ってことなんだが、今度は virsh コマンドを用いることになる。
ちょっと見てみよう。
$ virsh net-list --all
defaultという名前のエントリ1つだけ出てきたはず。
じゃぁコレの詳細は？
$ virsh net-info default
ブリッジという項目に、virbr0 と出てきたはずだ。
ということは、defaultネットワークにつなぐことが、virbr0につなぐ、ということになるのではないだろうか？
更に、定義をxml形式で出力することも出来る
$ virsh net-dumpxml default
(このネットワーク定義を保存しておけば、リストアで使用できるっぽいぞ)
とりあえず、xml形式の方を見ると、<forward mode='nat'> という定義がある。
これを見ると、どうやらnat形式のネットワークのようだ。
＃VMware系等の仮想環境で言うところの、NATネットワークと同じようだ。
う～ん。これだけ見てみても、色々あって覚えきれねぇ。
とりあえず、virt-install のマニュアル(man virt-install)にサンプルが載っているので、これをいじって一つ仮想マシンを立ててみよう。
その前に、仮想マシンのOS定義がどの程度あって、何が使えるか確認しておこう。
$ osinfo-query os
ずらずらと出てきたエントリの中に、ubuntu14.04が見つかっただろうか？
このエントリを、次の virt-install コマンドの --os-variant 引数に適用する。
$ virt-install \
--virt-type kvm \
--name aries \
--vcpus 2 \
--memory 512 \
--disk size=2,sparse=yes \
--check disk_size=off \
--network network=default \
--cdrom ~/iscsivol/ubuntu-14.04.4-server-amd64.iso \
--graphics spice,port=9001,password=test \
--os-variant ubuntu14.04
っとコケた。
「ERROR サポートされない設定: spice TLS ポートが XML 設定において設定されていますが、TLS が qemu.conf において無効化されています」
だそうな。
どうも、--graphics spice のオプションに port オプションを付与すると、tlsによる接続環境も作ろうとしてしまうようだ。
ただ、/etc/libvirt/qemu.conf は一切いじっておらず、tls 関連の環境はまだまったく作っていない。
そもそも、サーバ証明書等の準備は一切していないから、tls は使えない状態だ。
さてどうしよう…。
- SPICEプロトコルをやめて、別プロトコル(VNCとか)を指定する
- tls の環境を整える
- GUIでインストールする virt-manager を使用する
- ポートオプションを無くして初期作成し、別途portを指定する
なので4番を使ってみたい。
port オプションを指定しない場合、SPICEのポートはどうやら5900番を使用するようだ。
sshポート転送に以下の内容を追加して、ログインし直そう。
- ローカルのポート：5900
- リッスン：127.0.0.2
- リモート側ホスト：127.0.0.2
- リモート側ポート：5900
その後、ポートを9001に変えてみたいと思うので、併せて以下の設定も入れておこう。
- ローカルのポート：9001
- リッスン：127.0.0.2
- リモート側ホスト：127.0.0.2
- リモート側ポート：9001
$ virt-install \
--virt-type kvm \
--name aries \
--vcpus 2 \
--memory 512 \
--disk size=2,sparse=yes \
--check disk_size=off \
--network network=default \
--cdrom ~/iscsivol/ubuntu-14.04.4-server-amd64.iso \
--graphics spice,listen=127.0.0.2,password=test \
--os-variant ubuntu14.04
う～ん。
「Couldn't open libGL.so.1: libGL.so.1: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません」
というエラーが出る。
ただ、libGLが無くても動いているようなので、あまり気にしないようにしよう。
(多分、libGLをインストールすればいいんだと思う。)
念の為に、プロセスが生きているか確認してみよう。
$ ps -ef | grep qemu | grep -v grep
くっそ長い行が出てきたはずだ。これが出てくれば、実行成功だ。
実行出来たら、Remote viewer(Virtviewer)を起動して、spice://127.0.0.2:5900 へ接続してみよう。
(パスワードは、引数に指定している test だぞ)
無事に接続が出来たら、言語選択(UbuntuのOSメディアでブートした一番最初の画面)が表示されるはずだ。
ここまで出来たら、一旦この状態で設定確認をしてみよう。
コマンドプロンプトから以下のコマンドを実行することで、仮想マシンの設定が見られるぞ。
$ virsh list --all
$ virsh dumpxml aries
1つ目は、このlibvirt管理下の仮想マシン一覧だ。今はまだ1つしか作っていないから、1行しか出てこないはずだ。
2つ目は、仮想マシンariesの設定情報をxml形式で出力するコマンドだ。
ズラズラと出てくるが、xml形式なのである程度は読めるはずだ。
一旦、現状の設定を保存しておこう。
$ virsh dumpxml aries > aries.xml
そうしたら、通常通りインストールは進めてしまう。
最小構成にssh-serverを入れるだけでとりあえずはいい。
(以前、piscesを作った時と同じオプション構成だ。ホスト名はariesとする。)
インストール完了後、再起動せずに停止状態になった。
おかしいな、再起動すると思ったんだが…。
とりあえず、spiceの待受ポートだけ変更しよう。
$ virsh edit aries
viが立ち上がり、仮想マシンariesの設定情報(xml形式)が編集できる状態になったと思う。
以下の部分を変更しよう
<graphics type='spice' autoport='yes' listen='127.0.0.2' passwd='test'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
↓
<graphics type='spice' port='9001' autoport='no' listen='127.0.0.2' passwd='test'>
<listen type='address' address='127.0.0.2'/>
<image compression='off'/>
</graphics>
書き換えたら、仮想マシンariesを起動してみる。
起動はvirshコマンドで実行出来るぞ。
$ virsh list --all
$ virsh start aries
$ virsh list --all
起動できたか確認してみよう。
virt-viewer(RemoteViewer)で、spice://127.0.0.2:9001 へアクセスしてみよう。
無事にアクセス出来たら、ログインプロンプトが出ているはずだ。
ariesをインストールした時のユーザIDでログインしてみよう。
ログインできたはずだ。
かなり長くなってしまったので、一旦ココで切って、次回以降で少しずつ内容確認していく。
ariesはシャットダウンしておこう。
(aries) $ sudo shutdown -h now
(aquarius) $ virsh list --all
登録:
投稿 (Atom)