Tag: Slackware

高解像 (KVM 16)

その後も，KVMはいじっていまして，ほぼ実用的に使える領域に達した感じがします．

最後の問題が，Xorgの起動でした．サーバーとして使うには必要ありませんが，既存のWSを，いつでも動かせるような形で保存しておくためには必要です．

その既存の実マシンから移行した仮想マシン(VM)では，Xが起動してくれない，起動してもシステムがクラッシュしてしまう，解像度が1280×720より上げられない，等の問題がありました．

Slackwareのxとxapを全部削除して，全部最新版をインストールし直すという手荒なupgradeを実行して，あとは，xorg.conf, xorg.conf.dの中身を見直すことで，どのVMも起動するようになりました．

起動したVMのxorgでは，最大の解像度が1280×768ですが，実際には，1280×720の中で仮想的に縦の解像度が768となるという，使いにくい状況で，実質的に1280×720が最高の解像度でした．

解像度をもっと上げる方法をネット検索してみましたが，QXLを使用せよというのが一番多い情報でした．しかし，どれも2010から2011年くらいの情報です．virt-managerでは，デフォルトでQXLが選択されていて，その結果最大1280×720なので，話になりません．

あとは，自分で試すしかないので，ビデオをVMVGAにしたところ，最大2368×1770までの多彩な解像度が選べるようになりました．

ネット検索は万能な様な気がしますが，こういう旬な技術には，賞味期限切れ情報のほうが多くヒットしてしまって困ります^^;

ホストの解像度との兼ね合いもあるので，1440×900にしてみました．20150114-hirez

この解像度については，新規作成のVMでも同じ限界がありました．
結果的には，/etc/X11/xorg.conf.d/90-keyboard-layout.confで，keyboard layoutをjp106にoverrideするのみです．
1台だけ，glibcも古すぎて，新しいxorgが起動しなかったので，gccとglibcをSlackBuildしてupgradeしました．

GUI復活 (KVM 15)

いくつかの実マシンを仮想化する作業をしています．いずれも，確立した手順で^^; CUIとして起動するところまで行きますが，X (Xorg)が起動してくれません．startxをすると，nVidiaや，AMDのfglrxのドライバーが何だかんだとログに残して，致命的なエラーでおしまいです^^;

nVidiaのドライバーについては，ドライバーのインストーラーを使って，

./NVIDIA_Linux-x86-xxx.xx.run --uninstall

とすれば，削除できるとあり，試してみました．上記はちゃんと動きますが，依然として，Xは起動してくれません．

結局，Slackwareのxシリーズを全部removepkgして，/usr/lib/xorgと/etc/X11の残骸をどこぞに移して，もういちどSlackwareのxシリーズをinstallpkgする，という手順で，動くようになりました．

作業の要所では，snapshotを残すようにしています．

後の注釈: 残念ながら，その後１台では失敗して，１勝１敗です．snapshotを取ってからやっているので，トラブってぐしゃぐしゃになっても安心です.

実HDDを仮想マシン化 (KVM 13)

前の話のまとめです．

まえがき

これまで，実マシンとして動いていたLinux Work Station （以下WS1）を，実体として残しておく訳にはいかないけど，まったく捨ててしまうのももったいない．きっと，何か，二度と再現できないノウハウ的なものがあるかもしれない^^;

ディスクをイメージ化して保存し，しかも仮想マシンとして稼働できるようにしておけば，すばらしいです．

で，いろいろ試したところ，次の手順が一番よいと思います．

仮想マシン内でコピー

まず，どこのご家庭にもある，KVM内の既に稼働している仮想マシンを用意します．この仮想マシンに新たなディスクイメージを追加します．容量は，WS1のディスクサイズでもいいですし，実際に動作させるのに必要十分で最小容量でもいいです．形式は何でもいいですが，保存することを第一に考えれば，qcow2のsparse形式でしょうね．

次に，仮想マシンの第３ディスクとして，ホストマシンに接続した，WS1のHDDの実態を追加します．

そして，仮想マシンを起動して，/dev/sdbとなったディスクイメージをパーティショニングして，formatします．

さらに，formatしたイメージのメインの部分をどこかにマウントし，/dev/sdcとなった実ディスクのメインの部分もどこかにread onlyでマウントして，内容をまるまるコピーします．

コピーの方法はいろいろあるけど，最近はrsyncのみ使用してます．

一旦保存

コピーが終了したら，仮想マシンを停止して，その仮想マシンから，先ほど追加した，新しいディスクイメージと，実HDDを削除します．この際，間違っても，せっかく作成したディスクイメージを削除しないことです．”ディバイスリストから削除”するだけで，ディスクイメージは残します．

この新しく作成して実HDDからコピーしたディスクイメージで新たな仮想WSを作って起動させるわけですが，Kernelその他いろいろいじることもあるので，原型を止めたいということであれば，このイメージをどこか別に保存しておいたほうがいいでしょうね．

起動可能とする

これは，いろいろやり方があると思います．私は100%，SlackwareのインストールDVDを使っています．

コピーの時点で，boot loaderを適切にインストールしていないので，多少の工夫が必要ですが，そのくらいのことは，Linuxをいじっている人には朝飯前でしょう．

Good luck & good-by!

これで，滅多に動かすことのなくなったWSの実体を心置きなく捨てることができます．

あとで，いろいろやって分かって来ましたが，２番目に追加したドライブが必ずしもBIOS的に２番目になるとは限りません．これは困ったことです．どうすればBIOS的に順番を変えられるか．調査中です．

KVMの使い道 (8)

今まで知らなかった，KVMについて，実際にインストールして，無線クラブの会員向けサーバーとなる予定の仮想マシンのディスクイメージを作成しました．

そもそも，Slackwareは，KVMをサポートしていませんので，必要なソフトをいろいろかき集めてインストールして，最終的にはvirt-managerで，仮想マシンの作成，稼働，停止までできるようになりました．

無線クラブのサーバーの作成の他には，自宅サーバーのクローンを作成して，懸案だった，httpd 2.2→2.4の試行に利用して，その手順によって，実サーバーのhttpdを短いダウンタイムでupgradeすることができました．

というわけで，興味もポテンシャルも上がったのですが，では，次に何をするかとなると，思いつきません．

攻撃を受けやすい外部向けサービスを仮想マシンに移転するというのは，実利的かもしれません．実サーバーから仮想マシンへは入れるけど，仮想マシンから実マシンには入れないようにしておけば，仮に仮想マシンがクラックされても，実マシンへ侵入されにくくなります．

デメリットとしては，仮想マシンとはいえ，ちゃんと管理すべきで，お守りをするマシンが１台増えるということになります．

それから，GUIも動きますが，どうしてもモニターの表示領域をフルには使えませんから，GUIがメインの用途には今ひとつです．

ということで，いまひとつおもしろくないです^^; どうしたものか．