前回は、軽くスナップショットを作ってみるところを試してみた。
今回は、スナップショットの情報、特に親との差分情報がドコに格納されているのか？を探してみる。
まずはざっと、スナップショットを作ってみよう。
(あえて、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月18日金曜日
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を削除する手順だ。
登録:
投稿 (Atom)