こちらで軽く書いたけど、デスクトップ(ミドルタワー)の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月31日土曜日
2016年12月27日火曜日
閑話休題(VMware Workstation on KVM)
う～ん…。
Linux KVMの上にWindows7を載せて、そのWindows7にVMware Workstation(11)を導入、そのVMware WorkstationでゲストOSを動かすことって出来ないのかなぁ…？
何度かやってるけど、起動しようとするとWindows7ごとハングして、暫くしたらWindows7が強制リブートされる…。
ネットで調べても見つからない…。
(逆パターンはいくらでも実績あるんだけどね…)
Linux KVMの上にWindows7を載せて、そのWindows7にVMware Workstation(11)を導入、そのVMware WorkstationでゲストOSを動かすことって出来ないのかなぁ…？
何度かやってるけど、起動しようとするとWindows7ごとハングして、暫くしたらWindows7が強制リブートされる…。
ネットで調べても見つからない…。
(逆パターンはいくらでも実績あるんだけどね…)
2016年12月26日月曜日
閑話休題(PCリフレッシュ中)
自宅では、先日購入したWin10タブレットを含めて、全部で4台のPCが動いている。
(常時稼動は1台だけだが。)
以下一覧。
で、メインのワークステーションが古すぎるため、パーツを買って現在入れ替えをしている真っ最中だ。
もう随分前のCore2Quadから、第6世代Core i7に再構成している。
そちらを優先している関係で、KVMの検証が進んでいない。誰も読んでないと思うけど、少し待ってくれぃ。
(常時稼動は1台だけだが。)
以下一覧。
- メインのワークステーション(Windows7 / デスクトップ)
- Linuxサーバ(Ubuntu Linux / NUC)
- ノートPC(Windows7 / ノート型)
- タブレット(Windows10 / ノート・タブレット型)
で、メインのワークステーションが古すぎるため、パーツを買って現在入れ替えをしている真っ最中だ。
もう随分前のCore2Quadから、第6世代Core i7に再構成している。
そちらを優先している関係で、KVMの検証が進んでいない。誰も読んでないと思うけど、少し待ってくれぃ。
2016年12月20日火曜日
スナップショットを使おう その4(仮想マシンスナップショットの目的整理)
スナップショット、色々試しているけど、ちょっと混乱してきた。
というわけで、まずはスナップショットを使う目的を整理しよう。
が主目的ではないだろうか？
1～3までは、「スナップショット作成→検証→元に戻す」を繰り返し、納得がいく状態になったらコミットする、という流れになる。
通常であれば、「バックアップ→検証→リストア」という手順になるが、バックアップおよびリストアは結構手間がかかる。それに比べ、仮想環境で取得可能なスナップショットは非常に短い時間、少ない手間で処理できるので、とても便利だ。
4は、「あるベースイメージから複数のスナップショットを作成→それぞれのスナップショットに異なるバージョンのソフトウェアを導入・検証→元に戻す」を繰り返し、問題ないバージョン(スナップショット)をベースイメージにコミットする、ということになるかと思う。
4に関しては、「ベースイメージを複数コピー→検証→破棄」という流れでも実施可能だ。このパターンなら、複数の仮想マシンに分かれるので、IPアドレス等がバッティングしなければ、同時に複数の仮想マシンを起動可能だ。
ただし、IPアドレスの変更は意外と影響範囲が大きく、思わぬところで躓く可能性があるため、十分注意する必要があるだろう。
というわけで、まずは1～3を目的としたスナップショットの操作手順をおさらいしていこう。
図にすると以下のような感じだ。
スナップショットの破棄パターン
スナップショットのコミットパターン
次回以降にそれぞれ記載していく。
今回はここまで。
というわけで、まずはスナップショットを使う目的を整理しよう。
- ソフトウェアの導入検証
- ソフトウェア・OSのバージョンアップ検証
- ソフトウェア・OSの設定変更検証
- 同一ソフトウェアの異なるバージョンの検証
が主目的ではないだろうか？
1～3までは、「スナップショット作成→検証→元に戻す」を繰り返し、納得がいく状態になったらコミットする、という流れになる。
通常であれば、「バックアップ→検証→リストア」という手順になるが、バックアップおよびリストアは結構手間がかかる。それに比べ、仮想環境で取得可能なスナップショットは非常に短い時間、少ない手間で処理できるので、とても便利だ。
4は、「あるベースイメージから複数のスナップショットを作成→それぞれのスナップショットに異なるバージョンのソフトウェアを導入・検証→元に戻す」を繰り返し、問題ないバージョン(スナップショット)をベースイメージにコミットする、ということになるかと思う。
4に関しては、「ベースイメージを複数コピー→検証→破棄」という流れでも実施可能だ。このパターンなら、複数の仮想マシンに分かれるので、IPアドレス等がバッティングしなければ、同時に複数の仮想マシンを起動可能だ。
ただし、IPアドレスの変更は意外と影響範囲が大きく、思わぬところで躓く可能性があるため、十分注意する必要があるだろう。
というわけで、まずは1～3を目的としたスナップショットの操作手順をおさらいしていこう。
図にすると以下のような感じだ。
スナップショットの破棄パターン
スナップショットのコミットパターン
次回以降にそれぞれ記載していく。
今回はここまで。
2016年12月15日木曜日
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
これで、元に戻ったかな？
今回の実験は、色々な情報がモリモリになっていて、自分でもちょっと理解し切れていない。
一旦はここで切って、次回、情報を整理したい。
というわけで今回は以上。
(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
これで、元に戻ったかな？
今回の実験は、色々な情報がモリモリになっていて、自分でもちょっと理解し切れていない。
一旦はここで切って、次回、情報を整理したい。
というわけで今回は以上。
2016年11月18日金曜日
スナップショットを使おう その2
前回は、軽くスナップショットを作ってみるところを試してみた。
今回は、スナップショットの情報、特に親との差分情報がドコに格納されているのか？を探してみる。
まずはざっと、スナップショットを作ってみよう。
(あえて、piscesが稼動している状態で作ってみるぞ。)
(aquarius) $ virsh start pisces
(aquarius) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットが作成されたら、pisces自体は停止しておこう。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all
スナップショットが出来ているか確認
(aquarius) $ virsh snapshot-list pisces
スナップショットが作られているのが確認できただろうか？
これで、スナップショット作成時はpiscesは稼働中、現在はpisces停止状態、という形になった。
というわけで、少なくともpisces-1の状態から今までの間に、システム停止に伴うログ情報の差分や、メモリ使用状況が大きく変わっているはずだ。
これらの情報はいったいドコに記録されているのだろうか？
というわけで、そのスナップショットの情報を見てみる。
(aquarius) $ virsh snapshot-info pisces pisces-1
何行か情報が出てくるがその中に
場所: 内部
という行がある。
もしかして、これが「差分情報をドコに持っているか？」ということなのだろうか？
となればまずは、ディスク情報を見てみよう。
(aquarius) $ virsh vol-info pisces.qcow2 default
う～ん…。特に変わった情報は無いなぁ…。
virshで見ることが出来なくて、qemuコマンドなら見ることが出来る、とかか…？
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(一部略)
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 543M 2016-11-11 19:01:30 51:41:26.974
(一部略)
何か出た…ぞ！？
こちらのコマンドでも出せる。
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 543M 2016-11-11 19:01:30 51:41:26.974
どうやら、スナップショットの情報は、同一仮想ディスク上に格納されているようだ。
スナップショット情報が、別の仮想ディスクとして記録されるVMware等とは異なる挙動だ。
そうすると、72GBしか割り当てていないはずの仮想ディスク、スナップショットで使い切ったらどうなるんだろう…？
調査はしていないけど、どうやらスナップショット数分、仮想ディスクの大きさは増えていくみたいだな。
さて、じゃぁスナップショット作成時のメモリの情報はドコに？
先ほどの出力結果を見てみると、VM SIZEという欄に「543M」という記載がある。
仮想マシンには、メモリを512MBしか割り当てていない。もしかしたら、スナップショットの瞬間のメモリ情報も、仮想ディスク内に格納されているのか？
これを確認するには、一旦メモリ割り当てサイズを変更して、スナップショットを取り直してみれば判るだろう。
というわけで、スナップショットの削除。
(aquarius) $ virsh snapshot-delete pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
piscesが停止していることを確認して、メモリ割り当て量を変更。
(aquarius) $ virsh list --all
(aquarius) $ virsh edit pisces
以下の2行を書き換えよう。(割り当てサイズを512MBから128MBへ減らす)
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
↓
<memory unit='KiB'>131072</memory>
<currentMemory unit='KiB'>131072</currentMemory>
そしたら、piscesを起動し、スナップショットを取得
(aquarius) $ virsh start pisces
(aquairus) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
では、仮想ディスクの状態を見てみる。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(一部略)
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 145M 2016-11-18 11:07:00 00:02:07.609
(一部略)
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 145M 2016-11-18 11:07:00 00:02:07.609
おおおおっ！？VM SIZEが145Mになっている！やはりメモリ空間もこの仮想ディスクに格納されているのか！
VMwareの製品などは、仮想マシンの稼働中のスナップショットは、メモリ内容も別ファイルに格納されるようになっているから、実装が違うということか！
これでは、仮想マシンのスナップショットからのバックアップっていうのは無理かもしれないな。
ちなみに、仮想マシンが停止している状態で取得したスナップショットはどうなのだろうか？
同じ手順で確認してみよう。
まずはスナップショットの削除だ。
(aquarius) $ virsh snapshot-delete pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
スナップショットが削除されたことが確認できたら、piscesを停止しよう。
(pisces) $ sudo shutdown -h now
piscesが停止していることを確認し、停止状態のままスナップショットの取得だ。
(aquarius) $ virsh list --all
(aquairus) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットが取れたことを確認して、仮想ディスクの状態を確認してみる。
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 0 2016-11-18 11:26:55 00:00:00.000
予想通り、VM SIZEは0だ。
なるほど、仮想マシンスナップショットのメモリ空間は、デフォルトでは仮想ディスクに格納されるっていうことか。
というわけで次回は、メモリ保存とスナップショットディスクを、外部保管に出来ないか？という観点で調査してみる。
今回は、スナップショットの情報、特に親との差分情報がドコに格納されているのか？を探してみる。
まずはざっと、スナップショットを作ってみよう。
(あえて、piscesが稼動している状態で作ってみるぞ。)
(aquarius) $ virsh start pisces
(aquarius) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットが作成されたら、pisces自体は停止しておこう。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all
スナップショットが出来ているか確認
(aquarius) $ virsh snapshot-list pisces
スナップショットが作られているのが確認できただろうか？
これで、スナップショット作成時はpiscesは稼働中、現在はpisces停止状態、という形になった。
というわけで、少なくともpisces-1の状態から今までの間に、システム停止に伴うログ情報の差分や、メモリ使用状況が大きく変わっているはずだ。
これらの情報はいったいドコに記録されているのだろうか？
というわけで、そのスナップショットの情報を見てみる。
(aquarius) $ virsh snapshot-info pisces pisces-1
何行か情報が出てくるがその中に
場所: 内部
という行がある。
もしかして、これが「差分情報をドコに持っているか？」ということなのだろうか？
となればまずは、ディスク情報を見てみよう。
(aquarius) $ virsh vol-info pisces.qcow2 default
う～ん…。特に変わった情報は無いなぁ…。
virshで見ることが出来なくて、qemuコマンドなら見ることが出来る、とかか…？
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(一部略)
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 543M 2016-11-11 19:01:30 51:41:26.974
(一部略)
何か出た…ぞ！？
こちらのコマンドでも出せる。
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 543M 2016-11-11 19:01:30 51:41:26.974
どうやら、スナップショットの情報は、同一仮想ディスク上に格納されているようだ。
スナップショット情報が、別の仮想ディスクとして記録されるVMware等とは異なる挙動だ。
そうすると、72GBしか割り当てていないはずの仮想ディスク、スナップショットで使い切ったらどうなるんだろう…？
調査はしていないけど、どうやらスナップショット数分、仮想ディスクの大きさは増えていくみたいだな。
さて、じゃぁスナップショット作成時のメモリの情報はドコに？
先ほどの出力結果を見てみると、VM SIZEという欄に「543M」という記載がある。
仮想マシンには、メモリを512MBしか割り当てていない。もしかしたら、スナップショットの瞬間のメモリ情報も、仮想ディスク内に格納されているのか？
これを確認するには、一旦メモリ割り当てサイズを変更して、スナップショットを取り直してみれば判るだろう。
というわけで、スナップショットの削除。
(aquarius) $ virsh snapshot-delete pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
piscesが停止していることを確認して、メモリ割り当て量を変更。
(aquarius) $ virsh list --all
(aquarius) $ virsh edit pisces
以下の2行を書き換えよう。(割り当てサイズを512MBから128MBへ減らす)
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
↓
<memory unit='KiB'>131072</memory>
<currentMemory unit='KiB'>131072</currentMemory>
そしたら、piscesを起動し、スナップショットを取得
(aquarius) $ virsh start pisces
(aquairus) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
では、仮想ディスクの状態を見てみる。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(一部略)
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 145M 2016-11-18 11:07:00 00:02:07.609
(一部略)
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 145M 2016-11-18 11:07:00 00:02:07.609
おおおおっ！？VM SIZEが145Mになっている！やはりメモリ空間もこの仮想ディスクに格納されているのか！
VMwareの製品などは、仮想マシンの稼働中のスナップショットは、メモリ内容も別ファイルに格納されるようになっているから、実装が違うということか！
これでは、仮想マシンのスナップショットからのバックアップっていうのは無理かもしれないな。
ちなみに、仮想マシンが停止している状態で取得したスナップショットはどうなのだろうか？
同じ手順で確認してみよう。
まずはスナップショットの削除だ。
(aquarius) $ virsh snapshot-delete pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
スナップショットが削除されたことが確認できたら、piscesを停止しよう。
(pisces) $ sudo shutdown -h now
piscesが停止していることを確認し、停止状態のままスナップショットの取得だ。
(aquarius) $ virsh list --all
(aquairus) $ virsh snapshot-create-as pisces --name pisces-1
スナップショットが取れたことを確認して、仮想ディスクの状態を確認してみる。
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 pisces-1 0 2016-11-18 11:26:55 00:00:00.000
予想通り、VM SIZEは0だ。
なるほど、仮想マシンスナップショットのメモリ空間は、デフォルトでは仮想ディスクに格納されるっていうことか。
というわけで次回は、メモリ保存とスナップショットディスクを、外部保管に出来ないか？という観点で調査してみる。
2016年11月11日金曜日
スナップショットを使おう その1
仮想マシン環境を使うメリットの一つに、スナップショット機能がある。
仮想マシンのある断面を保持し、いつでもその断面に戻せる機能だ。
フルバックアップしておいて、戻したいときにそのバックアップからリストアする、というのに似たイメージを持っているが、実際には異なる。
技術的には、スナップショットは「その瞬間と、現在との差分」のみ保持している状態だ。
つまり、現在の環境がまるっと消し飛ぶと、スナップショットから戻すことも出来なくなる。
また、差分管理のみのため、取得にかかる時間は非常に短くて済む。フルバックアップとは雲泥の差だ。
スナップショットとバックアップを組み合わせて、システム停止時間を出来る限り短くしたり、バックアップにかかるシステム負荷を小さくする、なんていうことを行っている人もいる、と思う。
また、仮想マシンのスナップショットを上手く使えば、
いずれも、作業前にスナップショットを取り、作業を行った後に、スナップショットに戻す、という流れで可能だ。
何度も繰り返し検証を行いたい場合にとても便利だ。
で、KVMではスナップショットは使えるのか？という点だけど、当然実装されている。
GUIのvirt-managerでも使えるけど、少し使い勝手が悪そうだ。
今回は、コマンドライン(virsh)で試してみよう。
とは言っても、スナップショット関連のオプションは幾つかある。
(aquarius) $ virsh help snapshot
Snapshot (ヘルプのキーワード 'snapshot'):
snapshot-create XML によるスナップショットの作成
snapshot-create-as 一組の引数からのスナップショットの作成
snapshot-current カレントスナップショットの取得・設定
snapshot-delete ドメインのスナップショットの削除
snapshot-dumpxml ドメインのスナップショットの XML 形式ダンプ
snapshot-edit スナップショットの XML の編集
snapshot-info スナップショット情報
snapshot-list ドメインのスナップショットの一覧表示
snapshot-parent スナップショットの親の名前の取得
snapshot-revert ドメインのスナップショットへの復帰
しかもなぜか、「作成」が2つもある。
それぞれ、helpを引いてみると、似たようなオプションが指定できるようだ。
(aquarius) $ virsh help snapshot-create
(aquarius) $ virsh help snapshot-create-as
(オプションの一覧は省略する。各自確認してみてほしい。)
細かいところは抜きにして、とりあえず作ってみよう。
操作はコマンドラインで実施するが、仮想マシンのコンソール画面が見えていた方が変化がわかるかもしれないので、virt-managerを使って、仮想マシンpiscesのコンソール画面を見ておこう。
(aqaurius) $ virt-manager
(仮想マシンpiscesを選んで「開く」だ)
あと、主にaqauriusから操作を行うが、動作状況の確認のために、時々piscesで操作をする。
間違えないようにしよう。
で、piscesにスナップショットが無いことを確認。
(aquarius) $ virsh snapshot-list pisces
続いて、稼働中でも取得できることを確認するために、仮想マシンを起動してしまおう。
(aquarius) $ virsh list --all
(aquarius) $ virsh start pisces
(virt-managerから表示したコンソールを見て、piscesが起動したのを確認しておくこと。)
piscesが表示されているコンソールからログインし、空ファイルを一つ作っておこう。
(pisces) $ cd
(pisces) $ touch snap-before
(pisces) $ ls -l snap-before
そうしたら、スナップショットの作成だ。現時点でのスナップショットを取る。
(aquarius) $ virsh snapshot-create-as pisces --name pisces-1
ドメインのスナップショット pisces-1 が作成されました
無事に作成されたか確認だ。
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------
pisces-1 2016-11-10 09:45:59 +0900 running
どうやら無事に作成されたようだ。
ちなみに、piscesの画面は数秒間反応が無かったと思う。スナップショットを作成する数秒間だけ、動きが止まるようだ。
(aquarius) $ virsh list --all
piscesは稼動しているステータスのはずだ。
さて、今のpiscesのコンソールを使って、少しいじってみよう。
先ほど作ったファイルを削除してみたり…
(pisces) $ cd
(pisces) $ rm snap-before
(pisces) $ ls -l snap-before
別にファイルを作ってみたり…
(pisces) $ touch snap-after
(pisces) $ ls -l snap-after
piscesを落としてみたり…
(pisces) $ sudo shutdown -h now
piscesが停止したところでステータスを確認してみよう。
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------
pisces-1 2016-11-10 09:45:59 +0900 running
こちらはステータス変わらず。
(aqaurius) $ virsh list --all
こちらは、piscesはシャットダウン状態だ。
もう一度起動してみよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
普通に起動してきたはずなので、piscesのコンソールから状態を確認。
(pisces) $ ls -l snap-*
snap-afterだけ存在する状態だ。
この状態で、スナップショット取得時点(pisces-1作成時点)に戻してみよう。
(aquarius) $ virsh snapshot-revert pisces --snapshotname pisces-1
piscesのコンソールがリフレッシュされて、snap-beforeファイルを作成した直後に戻ったはずだ。
念のために確認してみよう。
(pisces) $ ls -l snap-*
snap-beforeが出てきて、snap-afterが無い状態だ。
つまり、pisces-1を作成したタイミング(virsh snapshot-create-as pisces --name pisces-1 を実行したタイミング)に戻ってきたわけだ。
もう一回、ダミーファイルの削除・作成をしてみよう。
(pisces) $ rm snap-before
(pisces) $ touch snap-after2
(pisces) $ ls -l snap-*
snap-after2だけ存在しているはずだ。
この状態で、スナップショットpisces-1を削除したらどうなるだろうか？
やってみよう。
(aquarius) $ virsh snapshot-delete pisces --snapshotname pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh list --all
piscesのコンソールには何も変化が無く、スナップショットが消えただけだ。
pisces自身も稼働中のステータスだ。
pisces上のダミーファイルはどうなっているだろうか？
(pisces) $ ls -l snap-*
特に何も変化無く、snap-after2だけ存在している状態だ。
ざっと図にすると、以下のような流れで試してみた、ということだ。
これらをやってみると、他にも色んなことが考えられるのではないだろうか？
例えば、
次回以降、この辺りを試していく。
仮想マシンのある断面を保持し、いつでもその断面に戻せる機能だ。
フルバックアップしておいて、戻したいときにそのバックアップからリストアする、というのに似たイメージを持っているが、実際には異なる。
技術的には、スナップショットは「その瞬間と、現在との差分」のみ保持している状態だ。
つまり、現在の環境がまるっと消し飛ぶと、スナップショットから戻すことも出来なくなる。
また、差分管理のみのため、取得にかかる時間は非常に短くて済む。フルバックアップとは雲泥の差だ。
スナップショットとバックアップを組み合わせて、システム停止時間を出来る限り短くしたり、バックアップにかかるシステム負荷を小さくする、なんていうことを行っている人もいる、と思う。
また、仮想マシンのスナップショットを上手く使えば、
- パッチ適用の検証
- アプリケーション導入の手順の確認
- システム設定変更の影響調査
いずれも、作業前にスナップショットを取り、作業を行った後に、スナップショットに戻す、という流れで可能だ。
何度も繰り返し検証を行いたい場合にとても便利だ。
で、KVMではスナップショットは使えるのか？という点だけど、当然実装されている。
GUIのvirt-managerでも使えるけど、少し使い勝手が悪そうだ。
今回は、コマンドライン(virsh)で試してみよう。
とは言っても、スナップショット関連のオプションは幾つかある。
(aquarius) $ virsh help snapshot
Snapshot (ヘルプのキーワード 'snapshot'):
snapshot-create XML によるスナップショットの作成
snapshot-create-as 一組の引数からのスナップショットの作成
snapshot-current カレントスナップショットの取得・設定
snapshot-delete ドメインのスナップショットの削除
snapshot-dumpxml ドメインのスナップショットの XML 形式ダンプ
snapshot-edit スナップショットの XML の編集
snapshot-info スナップショット情報
snapshot-list ドメインのスナップショットの一覧表示
snapshot-parent スナップショットの親の名前の取得
snapshot-revert ドメインのスナップショットへの復帰
しかもなぜか、「作成」が2つもある。
それぞれ、helpを引いてみると、似たようなオプションが指定できるようだ。
(aquarius) $ virsh help snapshot-create
(aquarius) $ virsh help snapshot-create-as
(オプションの一覧は省略する。各自確認してみてほしい。)
細かいところは抜きにして、とりあえず作ってみよう。
操作はコマンドラインで実施するが、仮想マシンのコンソール画面が見えていた方が変化がわかるかもしれないので、virt-managerを使って、仮想マシンpiscesのコンソール画面を見ておこう。
(aqaurius) $ virt-manager
(仮想マシンpiscesを選んで「開く」だ)
あと、主にaqauriusから操作を行うが、動作状況の確認のために、時々piscesで操作をする。
間違えないようにしよう。
で、piscesにスナップショットが無いことを確認。
(aquarius) $ virsh snapshot-list pisces
続いて、稼働中でも取得できることを確認するために、仮想マシンを起動してしまおう。
(aquarius) $ virsh list --all
(aquarius) $ virsh start pisces
(virt-managerから表示したコンソールを見て、piscesが起動したのを確認しておくこと。)
piscesが表示されているコンソールからログインし、空ファイルを一つ作っておこう。
(pisces) $ cd
(pisces) $ touch snap-before
(pisces) $ ls -l snap-before
そうしたら、スナップショットの作成だ。現時点でのスナップショットを取る。
(aquarius) $ virsh snapshot-create-as pisces --name pisces-1
ドメインのスナップショット pisces-1 が作成されました
無事に作成されたか確認だ。
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------
pisces-1 2016-11-10 09:45:59 +0900 running
どうやら無事に作成されたようだ。
ちなみに、piscesの画面は数秒間反応が無かったと思う。スナップショットを作成する数秒間だけ、動きが止まるようだ。
(aquarius) $ virsh list --all
piscesは稼動しているステータスのはずだ。
さて、今のpiscesのコンソールを使って、少しいじってみよう。
先ほど作ったファイルを削除してみたり…
(pisces) $ cd
(pisces) $ rm snap-before
(pisces) $ ls -l snap-before
別にファイルを作ってみたり…
(pisces) $ touch snap-after
(pisces) $ ls -l snap-after
piscesを落としてみたり…
(pisces) $ sudo shutdown -h now
piscesが停止したところでステータスを確認してみよう。
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------
pisces-1 2016-11-10 09:45:59 +0900 running
こちらはステータス変わらず。
(aqaurius) $ virsh list --all
こちらは、piscesはシャットダウン状態だ。
もう一度起動してみよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all
普通に起動してきたはずなので、piscesのコンソールから状態を確認。
(pisces) $ ls -l snap-*
snap-afterだけ存在する状態だ。
この状態で、スナップショット取得時点(pisces-1作成時点)に戻してみよう。
(aquarius) $ virsh snapshot-revert pisces --snapshotname pisces-1
piscesのコンソールがリフレッシュされて、snap-beforeファイルを作成した直後に戻ったはずだ。
念のために確認してみよう。
(pisces) $ ls -l snap-*
snap-beforeが出てきて、snap-afterが無い状態だ。
つまり、pisces-1を作成したタイミング(virsh snapshot-create-as pisces --name pisces-1 を実行したタイミング)に戻ってきたわけだ。
もう一回、ダミーファイルの削除・作成をしてみよう。
(pisces) $ rm snap-before
(pisces) $ touch snap-after2
(pisces) $ ls -l snap-*
snap-after2だけ存在しているはずだ。
この状態で、スナップショットpisces-1を削除したらどうなるだろうか？
やってみよう。
(aquarius) $ virsh snapshot-delete pisces --snapshotname pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh list --all
piscesのコンソールには何も変化が無く、スナップショットが消えただけだ。
pisces自身も稼働中のステータスだ。
pisces上のダミーファイルはどうなっているだろうか？
(pisces) $ ls -l snap-*
特に何も変化無く、snap-after2だけ存在している状態だ。
ざっと図にすると、以下のような流れで試してみた、ということだ。
これらをやってみると、他にも色んなことが考えられるのではないだろうか？
例えば、
- スナップショットって差分を管理しているってことだけど、差分情報はドコにあるの？
- スナップショットのスナップショットは作れるの？
- スナップショットの分岐は可能なの？
- 子スナップショットがいるスナップショットを削除したら？
次回以降、この辺りを試していく。
2016年11月4日金曜日
Win7(64bit)のWindows Update
ちょっと今回はKVMやLinuxとは関係ない話題。
自宅には、Windowsマシンが数台いて、そのうち1台は、ミドルタワー型。
そいつがWindowsメインマシンで、それとは別に作業用のWindowsノートPCが1台いる。
(他にも、WinXPノートが2台ほど稼動可能な状態でいるけど、使ってない。)
で、使っているタワー型＆ノート型はいずれもWin7の64bitモデル。
最近、コイツらのWindows Updateが上手く動いてくれないんだ。
具体的には、何もしていない状態ではsvchost.exeがCPU1個分(4コアモデルなら25%、2コアモデルなら50%)を使い切ってしまい、さらにメモリもアホみたいに消費する。
(4コア8GBMemモデルで、1.5GB程メモリを消費する。)
更新プログラムの自動インストールをOnにして何日も放置し、更新プログラムの自動適用を繰り返させれば、ある程度収まるかと思っていたんだが、これが収まらない。
挙句、更新プログラムの適用にも失敗しまくるとうい事象が発生し、どうにもならない状態だった。
なんとなく対策が打てたと思うので、ざっと記載。
具体的には、
ただし、適用する直前に、wuauserv(Windows Update)というサービスを停止しておく。
停止しておかないと、パッチが適用できないようだ。
サービスを停止してすぐパッチを適用すれば、サクッとパッチ適用でき、OS再起動すればすぐに反映される様子。
今のところ、CPU使用率もほぼゼロ、メモリも40MB程の消費で済んでいるし、更新プログラムの自動適用も進んでいるようだ。
もう一台のWin7マシン(ノート型)でも試してみよう。
自宅には、Windowsマシンが数台いて、そのうち1台は、ミドルタワー型。
そいつがWindowsメインマシンで、それとは別に作業用のWindowsノートPCが1台いる。
(他にも、WinXPノートが2台ほど稼動可能な状態でいるけど、使ってない。)
で、使っているタワー型＆ノート型はいずれもWin7の64bitモデル。
最近、コイツらのWindows Updateが上手く動いてくれないんだ。
具体的には、何もしていない状態ではsvchost.exeがCPU1個分(4コアモデルなら25%、2コアモデルなら50%)を使い切ってしまい、さらにメモリもアホみたいに消費する。
(4コア8GBMemモデルで、1.5GB程メモリを消費する。)
更新プログラムの自動インストールをOnにして何日も放置し、更新プログラムの自動適用を繰り返させれば、ある程度収まるかと思っていたんだが、これが収まらない。
挙句、更新プログラムの適用にも失敗しまくるとうい事象が発生し、どうにもならない状態だった。
なんとなく対策が打てたと思うので、ざっと記載。
具体的には、
- KB3050265
- KB3102810
ただし、適用する直前に、wuauserv(Windows Update)というサービスを停止しておく。
停止しておかないと、パッチが適用できないようだ。
サービスを停止してすぐパッチを適用すれば、サクッとパッチ適用でき、OS再起動すればすぐに反映される様子。
今のところ、CPU使用率もほぼゼロ、メモリも40MB程の消費で済んでいるし、更新プログラムの自動適用も進んでいるようだ。
もう一台のWin7マシン(ノート型)でも試してみよう。
2016年10月26日水曜日
仮想マシンでuEFIが使えるようにしよう その2
前回、KVMにuEFIファームウェア(OVMF)を導入し、新規仮想マシンでuEFIが使えるようにした。
今回は、Ubuntuに用意されているもう一つのパッケージ、qemu-efiを使ってみようと思う。
というわけで導入だ。
(aquarius) $ sudo apt-get update
(aquarius) $ sudo apt-get --simulate install qemu-efi
(aquarius) $ sudo apt-get install qemu-efi
あっさり導入できた。
では、virt-managerで仮想マシンを作成してみよう。
(aquarius) $ virt-manager
確かに、ファームウェアに新しく「UEFI aarch46: /usr/share/AAVMF/AAVMF_CODE.fd」がエントリされた。
ただ、これを選択して「インストールの開始」を実行しても、エラーになる。
エラーメッセージを見てみると「oversized backing file, pflash segments cannot be mapped under 00000000ff800000」と表示されている。
これ、ファームウェアのサイズが大きすぎて、ファームウェア用のメモリ空間に収まらないってことじゃないか？
実際、/usr/share/AAVMF/AAVMF_CODE.fdのサイズは64MByte。
それを、ff800000のアドレスにマップしようとしている。
ff800000～ffffffffのアドレス空間は、約8MBしかない。これじゃ64MByteもあるAAVMF.fdは収まらないよな…。
対して、OVMFのファームウェア(/usr/share/ovmf/OVMF.fd)は2MByte。AAVMF.fdはサイズが大きすぎるのでは？
ただ、調べてみると「/etc/libvirt/qemu.confを一部書き換えればいいよ」という情報もある。その内容は、あくまで権限の話で、ファームウェアのメモリ空間を広げる、という話ではなさそうだ。
ファームウェアのメモリ空間の話な気がしているので、仮想マシンに割り与えるメモリサイズとは関係が無い。
さて…ちょっと調べた限りでは、本格的な対応方法が分からないや。
この件に関しては、一旦保留にして、この先必要になったら調査することにしよう。
というわけでアンインストールしてしまう。
(aquarius) $ sudo apt-get --simulate purge qemu-efi
(aquarius) $ sudo apt-get purge qemu-efi
今回はまともな結論にならなかったけど、まぁいいか。
今回は、Ubuntuに用意されているもう一つのパッケージ、qemu-efiを使ってみようと思う。
というわけで導入だ。
(aquarius) $ sudo apt-get update
(aquarius) $ sudo apt-get --simulate install qemu-efi
(aquarius) $ sudo apt-get install qemu-efi
あっさり導入できた。
では、virt-managerで仮想マシンを作成してみよう。
(aquarius) $ virt-manager
確かに、ファームウェアに新しく「UEFI aarch46: /usr/share/AAVMF/AAVMF_CODE.fd」がエントリされた。
ただ、これを選択して「インストールの開始」を実行しても、エラーになる。
エラーメッセージを見てみると「oversized backing file, pflash segments cannot be mapped under 00000000ff800000」と表示されている。
これ、ファームウェアのサイズが大きすぎて、ファームウェア用のメモリ空間に収まらないってことじゃないか？
実際、/usr/share/AAVMF/AAVMF_CODE.fdのサイズは64MByte。
それを、ff800000のアドレスにマップしようとしている。
ff800000～ffffffffのアドレス空間は、約8MBしかない。これじゃ64MByteもあるAAVMF.fdは収まらないよな…。
対して、OVMFのファームウェア(/usr/share/ovmf/OVMF.fd)は2MByte。AAVMF.fdはサイズが大きすぎるのでは？
ただ、調べてみると「/etc/libvirt/qemu.confを一部書き換えればいいよ」という情報もある。その内容は、あくまで権限の話で、ファームウェアのメモリ空間を広げる、という話ではなさそうだ。
ファームウェアのメモリ空間の話な気がしているので、仮想マシンに割り与えるメモリサイズとは関係が無い。
さて…ちょっと調べた限りでは、本格的な対応方法が分からないや。
この件に関しては、一旦保留にして、この先必要になったら調査することにしよう。
というわけでアンインストールしてしまう。
(aquarius) $ sudo apt-get --simulate purge qemu-efi
(aquarius) $ sudo apt-get purge qemu-efi
今回はまともな結論にならなかったけど、まぁいいか。
2016年10月23日日曜日
仮想マシンでuEFIが使えるようにしよう
これまでで、自由に仮想マシンを作ってゲストOSを導入、ネットワークを利用することが出来るようになった。
ただ、これらの仮想マシンは、ファームウェアとしては旧来のBIOS形式だけだ。
仮想マシン上でuEFIを利用することは出来ないだろうか？
利用出来る。ただし、現時点ではホストOS(aquarius)で、KVM用のuEFIファームウェアが用意されていないので、今のaquariusでは利用することが出来ない。
今回は、uEFIのファームウェアをインストールして、新規仮想マシンでuEFIを指定することが出来るようにする、というのが目的だ。
まぁ、仮想マシンでuEFIを利用するのに、どの程度のメリットがあるのか？という点も気にはなるが。
まだ出来るかどうか分からないが、ディスクレスクライアントに相当する環境を作ることが出来るのではないか？とちょっと期待している。
まぁ、難しいことは抜きにして、uEFI環境を作ってみよう。
まずは、どのパッケージがKVM-uEFI環境を作るのに必要か確認だ。
(aquarius) $ sudo apt-get update
(aquarius) $ apt-cache search uefi
たくさん出てくるが、それらしいパッケージ名は以下の2つだろう。
それぞれのパッケージの詳細を見てみよう。
(aquarius) $ apt-cache show ovmf
(aquarius) $ apt-cache show qemu-efi
どちらも、メンテナは同じ「Ubuntu Developers」で、オリジナルソースも同じ「edk2」のようだ。
備考としては、前者は
Description-en: UEFI firmware for virtual machines
Open Virtual Machine Firmware is a build of EDK II for virtual machines.
It includes full support for UEFI, including Secure Boot, allowing use
of UEFI in place of a traditional BIOS in your VM.
と書かれているのに対し、後者は
Description-en: UEFI firmware for virtual machines
qemu-efi is a build of EDK II for virtual machines. It allows virtual machines
to run in a UEFI environment.
だ。
前者の方が高機能に見えるのだが、インストールサイズは、前者が4130に対し、後者は133152だ。ぜんぜん違う。
どちらがいいのだろうか？
よく分からないので、まずは前者をインストールしてみよう。
(aquarius) $ sudo apt-get --simulate install ovmf
(aquarius) $ sudo apt-get install ovmf
インストールしてみたら、virt-managerから仮想マシンを作ってみよう。
内容は、virt-managerで新規仮想マシンを作ろう に従い、最後の「インストールの前に設定をカスタマイズ」にチェックを入れて、詳細確認するところの画面まで行く。
(aquarius) $ virt-manager
とりあえず、カスタマイズの画面までは同じなので、カスタマイズの画面までは飛ばす。
カスタマイズの画面、概要ページのファームウェアを見てみよう。
プルダウンで選択できそうな状態になっている。
ここで、プルダウンを選んでみよう。
今までは「BIOS」しか選べなかったが、新しく「UEFI x86_64: /usr/share/OVMF/OVMF_CODE.fd」が選べるようになった。
今回の仮想マシンは、このOVMF_CODE.fdを選んだ状態で「インストールの開始」をしてみよう。
(uEFIを確認するのが目的なので、インストール用のCDメディアは用意しなくていいぞ）
なんか失敗したように見えるが、実は仮想マシンは完成していて、起動もしているぞ。（遠隔からの操作の場合に、これが出るのかもしれない。）
とりあえず、CLOSEする。
仮想マシンの詳細設定画面からは、「インストールのキャンセル」をクリックしよう。
「インストールを中断します」のダイアログは、「Yes」でいい。
仮想マシンの一覧には、testは作成済み、実行中になっているはずだ。
testを選択した状態で、「開く」ボタンをクリックしよう。
仮想マシンのコンソールが立ち上がってきて、EFI Shellの状態になっているのが確認できるはずだ。
これは、仮想HDDにはOSが入っておらず、それ以外のブートデバイス(CD-ROM等）も存在しないため、OSのブートが出来ず、EFI Shellが起動した、という状態だ。
uEFIの起動にかかる部分を確認するために、一度電源ボタンの横の▼マークから、「強制的にリセット」を選択しよう。
警告のダイアログが出るが、特にデータもないため、恐れず「Yes」だ。
画面の流れが一瞬でキャプチャ出来ないが、uEFIが起動しようとしているのは確認できるはずだ。
またEFI Shellになってしまったが、ここでexitと実行してみよう。
EFI Shellから抜けて、ブートメニューに入るはずだ。
適当に操作して、EDK IIと呼ばれているuEFIの動きを見てみてもいい。
ある程度感触を掴んだら、電源ボタンで強制的にOffさせ、仮想マシンを削除してしまおう。
次は、もう一つのuEFIである、qemu-efi を試してみたい。
が、ちょっと長くなったので、次回にする。
ただ、これらの仮想マシンは、ファームウェアとしては旧来のBIOS形式だけだ。
仮想マシン上でuEFIを利用することは出来ないだろうか？
利用出来る。ただし、現時点ではホストOS(aquarius)で、KVM用のuEFIファームウェアが用意されていないので、今のaquariusでは利用することが出来ない。
今回は、uEFIのファームウェアをインストールして、新規仮想マシンでuEFIを指定することが出来るようにする、というのが目的だ。
まぁ、仮想マシンでuEFIを利用するのに、どの程度のメリットがあるのか？という点も気にはなるが。
まだ出来るかどうか分からないが、ディスクレスクライアントに相当する環境を作ることが出来るのではないか？とちょっと期待している。
まぁ、難しいことは抜きにして、uEFI環境を作ってみよう。
まずは、どのパッケージがKVM-uEFI環境を作るのに必要か確認だ。
(aquarius) $ sudo apt-get update
(aquarius) $ apt-cache search uefi
たくさん出てくるが、それらしいパッケージ名は以下の2つだろう。
- ovmf - UEFI firmware for virtual machines
- qemu-efi - UEFI firmware for virtual machines
それぞれのパッケージの詳細を見てみよう。
(aquarius) $ apt-cache show ovmf
(aquarius) $ apt-cache show qemu-efi
どちらも、メンテナは同じ「Ubuntu Developers」で、オリジナルソースも同じ「edk2」のようだ。
備考としては、前者は
Description-en: UEFI firmware for virtual machines
Open Virtual Machine Firmware is a build of EDK II for virtual machines.
It includes full support for UEFI, including Secure Boot, allowing use
of UEFI in place of a traditional BIOS in your VM.
と書かれているのに対し、後者は
Description-en: UEFI firmware for virtual machines
qemu-efi is a build of EDK II for virtual machines. It allows virtual machines
to run in a UEFI environment.
だ。
前者の方が高機能に見えるのだが、インストールサイズは、前者が4130に対し、後者は133152だ。ぜんぜん違う。
どちらがいいのだろうか？
よく分からないので、まずは前者をインストールしてみよう。
(aquarius) $ sudo apt-get --simulate install ovmf
(aquarius) $ sudo apt-get install ovmf
インストールしてみたら、virt-managerから仮想マシンを作ってみよう。
内容は、virt-managerで新規仮想マシンを作ろう に従い、最後の「インストールの前に設定をカスタマイズ」にチェックを入れて、詳細確認するところの画面まで行く。
(aquarius) $ virt-manager
とりあえず、カスタマイズの画面までは同じなので、カスタマイズの画面までは飛ばす。
カスタマイズの画面、概要ページのファームウェアを見てみよう。
プルダウンで選択できそうな状態になっている。
ここで、プルダウンを選んでみよう。
今までは「BIOS」しか選べなかったが、新しく「UEFI x86_64: /usr/share/OVMF/OVMF_CODE.fd」が選べるようになった。
今回の仮想マシンは、このOVMF_CODE.fdを選んだ状態で「インストールの開始」をしてみよう。
(uEFIを確認するのが目的なので、インストール用のCDメディアは用意しなくていいぞ）
なんか失敗したように見えるが、実は仮想マシンは完成していて、起動もしているぞ。（遠隔からの操作の場合に、これが出るのかもしれない。）
とりあえず、CLOSEする。
仮想マシンの詳細設定画面からは、「インストールのキャンセル」をクリックしよう。
「インストールを中断します」のダイアログは、「Yes」でいい。
仮想マシンの一覧には、testは作成済み、実行中になっているはずだ。
testを選択した状態で、「開く」ボタンをクリックしよう。
仮想マシンのコンソールが立ち上がってきて、EFI Shellの状態になっているのが確認できるはずだ。
これは、仮想HDDにはOSが入っておらず、それ以外のブートデバイス(CD-ROM等）も存在しないため、OSのブートが出来ず、EFI Shellが起動した、という状態だ。
uEFIの起動にかかる部分を確認するために、一度電源ボタンの横の▼マークから、「強制的にリセット」を選択しよう。
警告のダイアログが出るが、特にデータもないため、恐れず「Yes」だ。
画面の流れが一瞬でキャプチャ出来ないが、uEFIが起動しようとしているのは確認できるはずだ。
またEFI Shellになってしまったが、ここでexitと実行してみよう。
EFI Shellから抜けて、ブートメニューに入るはずだ。
適当に操作して、EDK IIと呼ばれているuEFIの動きを見てみてもいい。
ある程度感触を掴んだら、電源ボタンで強制的にOffさせ、仮想マシンを削除してしまおう。
次は、もう一つのuEFIである、qemu-efi を試してみたい。
が、ちょっと長くなったので、次回にする。
2016年10月22日土曜日
virt-managerで新規仮想マシンを作ろう その3
さて、前回までで、virt-managerを使用して、仮想マシンtestを作成し、その仮想マシンにゲストOSとしてUbuntu 16.10をインストールするところまで実施した。
最後に、この仮想マシンを削除するところをやってしまおう。
削除はvirshからでも出来るが、このままvirt-managerを使用して削除する。
virt-managerを落としていたら、また起動しよう。
(aquarius) $ virt-manager
virt-managerから、削除したい仮想マシンを選択し、メニューバーの「編集」から「Delete」を選択する。
対象の仮想マシンが仮想ストレージを持っている場合、その仮想ストレージごと削除するか聞いてくる。
仮想ストレージを他で流用するツモリなら、チェックを外そう。
今回は、綺麗さっぱり削除するツモリなので、チェックが入ったまま「Delete」だ。
ただ、この仮想マシンが.isoファイルをマウントしている場合も、削除するか聞いてくる。
通常、.isoイメージは流用することが多いため、当該イメージのチェックは外しておいた方がいいだろう。
もう一回、削除するか確認が入るので「Yes」を押して確定しよう。
あっさりさっくり削除されたぞ。
一応、virshからも確認しておこう。
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list default
(aquarius) $ sudo ls -l /var/lib/libvirt/images
削除されたのが確認できた。
これで、virt-managerから仮想マシンを削除する手順はおしまい。
最後に、この仮想マシンを削除するところをやってしまおう。
削除はvirshからでも出来るが、このままvirt-managerを使用して削除する。
virt-managerを落としていたら、また起動しよう。
(aquarius) $ virt-manager
virt-managerから、削除したい仮想マシンを選択し、メニューバーの「編集」から「Delete」を選択する。
対象の仮想マシンが仮想ストレージを持っている場合、その仮想ストレージごと削除するか聞いてくる。
仮想ストレージを他で流用するツモリなら、チェックを外そう。
今回は、綺麗さっぱり削除するツモリなので、チェックが入ったまま「Delete」だ。
ただ、この仮想マシンが.isoファイルをマウントしている場合も、削除するか聞いてくる。
通常、.isoイメージは流用することが多いため、当該イメージのチェックは外しておいた方がいいだろう。
もう一回、削除するか確認が入るので「Yes」を押して確定しよう。
あっさりさっくり削除されたぞ。
一応、virshからも確認しておこう。
(aquarius) $ virsh list --all
(aquarius) $ virsh vol-list default
(aquarius) $ sudo ls -l /var/lib/libvirt/images
削除されたのが確認できた。
これで、virt-managerから仮想マシンを削除する手順はおしまい。
2016年10月21日金曜日
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を削除する手順だ。
とはいえ、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を削除する手順だ。
2016年10月19日水曜日
virt-managerで新規仮想マシンを作ろう
KVMの環境がだいぶ整ってきた。とは言え、まだ仮想マシンは2つだけだ。
そこで、新しい仮想マシンを作る手順について整理しておこうと思う。
新しい仮想マシンを作成する手順は、こちらで把握している限り以下の5つだ。
2番目は同様に、pisces忘れるな で記載済み。
今回は、今後最も使うことになると思われる、3番目に触れたいと思う。
3番目を実施するうえで、いくつか注意しないといけない点がある。
まずは、aquariusでvirt-managerを起動する。
(aquairus) $ virt-manager
仮想マシンマネージャーが起動したら、新規に仮想ディスクを作成する。
メニューバーの「編集」から「接続の詳細」だ。
「接続の詳細」画面が立ち上がってくると思う。
そこの「ストレージ」をクリックしよう。
ストレージプールの一覧(今は、defaultプールしか存在しないが)と、そのストレージプールに入っている仮想ディスク(ボリューム)の一覧が表示されるはずだ。(幾つかのisoファイル等を追加しているため、少し多いが。)
defaultプールに仮想ディスクを追加したいので、このまま「ボリューム」の右横の＋ボタンをクリックしよう。
「ストレージボリュームを追加」というウィンドウが開く。
新規に作成する仮想ストレージの名前、サイズを決めたら「完了」だ。
仮想ディスクのフォーマットが幾つか選べるが、とりあえずqcow2にしておこう。
(他のフォーマットは別途調査する)
今回は名前をtest、容量を40GBにしてみたぞ。
(すぐ削除するツモリなので、仮の名前にしている)
作成されたのが確認できるはずだ。
確認できたら、「接続の詳細」画面はメニューバーの「ファイル」から「Close」でクローズしよう。
いよいよ、仮想マシンの作成だ。
「仮想マシンマネージャー」のメニューバー「ファイル」から「新しい仮想マシン」をクリック。
「新しい仮想マシン」というウィンドウが開いてくる。いわゆるウィザード形式だ。
この最初の画面に4つの選択肢が出てくるが、ここで先ほど作成した仮想ディスクを用いることになる。
そのため、「既存のディスクイメージをインポート」にチェックを入れて、「Forward」だ。
(他の手順も暇があったら試してみたいが。)
次の画面は、仮想ストレージを指定する画面だ。「参照」ボタンを使って、先ほど作成したtest.qcow2を指定しよう。
同画面で、ゲストOSの種類とバージョンを選択することができる。
この指定は、virt-managerでは後から変更が出来ない。virshからなら変更できるだろうけど。
今回は下図のように、Linux / Ubuntu 16.04 を選んでおく。
次の画面は、割り当てるメモリー量とCPU数だ。これは後からでも簡単に変更できるので、とりあえず表示されている通りの1024MB/1CPUにしておこう。
これでとりあえず最低限のことは出来たが、このタイミングでまだ手を加えておきたいところがある。
上図の「名前」欄は、仮想マシンの名前に相当する。(piscesとかariesとかのね)
今回は、すぐ削除するツモリなので、testとしておく。
また、「インストール前に設定をカスタマイズする」にチェックを入れておくと、細かい設定変更が可能だ。
一応、チェックを入れておこう。
最後の「ネットワークの選択」は、三角マークをクリックしていればわかる通り、接続するNICをdefaultにするか、先日作成したOpen vSwitchのスイッチにするかが選べる。
Open vSwitchのスイッチを選ぼう。
「完了」をクリックすると、今作った仮想マシンの詳細設定を実施する画面になる。
後から幾つか変更することになるが、今はとりあえず「概要」ページの「ファームウェア」だけチェックしておこう。
BIOSかUEFIかを選べるはずなのだが、現時点ではKVM用のUEFIをインストールしていないため、変更することが出来ない。
しかもこれ、仮想マシン作成時にしか変更することが出来ないのだ。
一旦はこのまま、「インストール」をクリックしてしまおう。
すぐにコンソール画面が出て、No bootable device.と表示されて止まったはずだ。
そんなことは当たり前で、用意した仮想ディスクは空っぽだし、ブート可能なCDメディア等も用意していない。これで起動してくるはずは無い。
とりあえずは停止させてしまおう。
メニューバーから、「強制的に電源OFF」だ。
確認ダイアログが出るので「Yes」をクリックしよう。
仮想マシンのモニタ画面は「仮想マシンが稼動していません」の状態になったはず。
こちらも、メニューバーからCloseしよう。
仮想マシンの一覧に、先ほど作成した「test」が表示されているのが確認できるはずだ。
次回は、このtestにUbuntuをインストールしてみる。
そこで、新しい仮想マシンを作る手順について整理しておこうと思う。
新しい仮想マシンを作成する手順は、こちらで把握している限り以下の5つだ。
- virt-installコマンドで作る
- 仮想ディスク等を用意し、仮想マシンの定義ファイル(xmlファイル)を作成、virshにそれを取り込む
- virt-managerを用いて作成する
- 物理マシンからKVM/QEMUにコンバートする(P2V)
- 他のハイパーバイザーで作成した仮想マシン(VMware製品で作成した仮想マシン等)から移行する
2番目は同様に、pisces忘れるな で記載済み。
今回は、今後最も使うことになると思われる、3番目に触れたいと思う。
3番目を実施するうえで、いくつか注意しないといけない点がある。
- まず、コンソールはspiceプロトコルになるのだが、これがデフォルトではTLS接続も有効化されてしまう。現時点では、spiceプロトコル用のTLS設定(証明書類)はまったく用意していないため、起動時にコケてしまう可能性がある。そのため、仮想マシン作成直後は、spice設定はいじらないようにする。
- 仮想マシン作成時は、予めOSインストールメディアを用意しておくか、予め作成済みの仮想ディスクを用意しておく必要がある。インストールメディアを用意しての導入は、最初の仮想マシン起動が上手くいかないことがあるため、予め仮想ディスクを作成しておくことにする。
まずは、aquariusでvirt-managerを起動する。
(aquairus) $ virt-manager
仮想マシンマネージャーが起動したら、新規に仮想ディスクを作成する。
メニューバーの「編集」から「接続の詳細」だ。
「接続の詳細」画面が立ち上がってくると思う。
そこの「ストレージ」をクリックしよう。
ストレージプールの一覧(今は、defaultプールしか存在しないが)と、そのストレージプールに入っている仮想ディスク(ボリューム)の一覧が表示されるはずだ。(幾つかのisoファイル等を追加しているため、少し多いが。)
defaultプールに仮想ディスクを追加したいので、このまま「ボリューム」の右横の＋ボタンをクリックしよう。
「ストレージボリュームを追加」というウィンドウが開く。
新規に作成する仮想ストレージの名前、サイズを決めたら「完了」だ。
仮想ディスクのフォーマットが幾つか選べるが、とりあえずqcow2にしておこう。
(他のフォーマットは別途調査する)
今回は名前をtest、容量を40GBにしてみたぞ。
(すぐ削除するツモリなので、仮の名前にしている)
作成されたのが確認できるはずだ。
確認できたら、「接続の詳細」画面はメニューバーの「ファイル」から「Close」でクローズしよう。
いよいよ、仮想マシンの作成だ。
「仮想マシンマネージャー」のメニューバー「ファイル」から「新しい仮想マシン」をクリック。
「新しい仮想マシン」というウィンドウが開いてくる。いわゆるウィザード形式だ。
この最初の画面に4つの選択肢が出てくるが、ここで先ほど作成した仮想ディスクを用いることになる。
そのため、「既存のディスクイメージをインポート」にチェックを入れて、「Forward」だ。
(他の手順も暇があったら試してみたいが。)
次の画面は、仮想ストレージを指定する画面だ。「参照」ボタンを使って、先ほど作成したtest.qcow2を指定しよう。
同画面で、ゲストOSの種類とバージョンを選択することができる。
この指定は、virt-managerでは後から変更が出来ない。virshからなら変更できるだろうけど。
今回は下図のように、Linux / Ubuntu 16.04 を選んでおく。
次の画面は、割り当てるメモリー量とCPU数だ。これは後からでも簡単に変更できるので、とりあえず表示されている通りの1024MB/1CPUにしておこう。
これでとりあえず最低限のことは出来たが、このタイミングでまだ手を加えておきたいところがある。
上図の「名前」欄は、仮想マシンの名前に相当する。(piscesとかariesとかのね)
今回は、すぐ削除するツモリなので、testとしておく。
また、「インストール前に設定をカスタマイズする」にチェックを入れておくと、細かい設定変更が可能だ。
一応、チェックを入れておこう。
最後の「ネットワークの選択」は、三角マークをクリックしていればわかる通り、接続するNICをdefaultにするか、先日作成したOpen vSwitchのスイッチにするかが選べる。
Open vSwitchのスイッチを選ぼう。
「完了」をクリックすると、今作った仮想マシンの詳細設定を実施する画面になる。
後から幾つか変更することになるが、今はとりあえず「概要」ページの「ファームウェア」だけチェックしておこう。
BIOSかUEFIかを選べるはずなのだが、現時点ではKVM用のUEFIをインストールしていないため、変更することが出来ない。
しかもこれ、仮想マシン作成時にしか変更することが出来ないのだ。
一旦はこのまま、「インストール」をクリックしてしまおう。
すぐにコンソール画面が出て、No bootable device.と表示されて止まったはずだ。
そんなことは当たり前で、用意した仮想ディスクは空っぽだし、ブート可能なCDメディア等も用意していない。これで起動してくるはずは無い。
とりあえずは停止させてしまおう。
メニューバーから、「強制的に電源OFF」だ。
確認ダイアログが出るので「Yes」をクリックしよう。
仮想マシンのモニタ画面は「仮想マシンが稼動していません」の状態になったはず。
こちらも、メニューバーからCloseしよう。
仮想マシンの一覧に、先ほど作成した「test」が表示されているのが確認できるはずだ。
次回は、このtestにUbuntuをインストールしてみる。
登録:
投稿 (Atom)