「Linux」カテゴリーアーカイブ

VMのCPU使用率

ホストOSがUbuntu 8.04.1 LTS Server x64であるVMware Server 2.0にて、ゲストOSにWinXPのVMとUbuntu 8.04.1 LTS Desktop x64のVMが作成されている。

WinXPのVMを起動させておくとホストOSのCPU周波数が1GHzになることはあまりないんだけど、UbuntuのVMでは放っておけば大体1GHzに落ち着く。VMにのせるゲストOSによってホストの負荷が変わるんだ。まあ、Windowsは元々ハードウェアリソースには厳しいからね。

WordPress MU 2.6.3のインストール

WordPress.comのようなマルチユーザのサイトを作ってみたいな。。。 と思ってググるとWordpress MUなるものがあるそうな。Wordpressは1.x時代から使ってるけど、真剣に調べたのは初めてだったりする。

WordPress.comはAkismetのAPIキーをゲットするために登録して少し使ったことがあるけど、なかなかいい。WordPress MUを使っているとのことだから、これは試してみないといけませんね。

テスト用にVMを用意して、ゲストOSはUbuntu 8.04.1 LTS Server x64を入れてある。tar.gz版を /home/user/puglic_html にダウンロードして、解凍する。そうすると wordpress-mu-2.6.3 というディレクトリができるので、wordpress-muとリネームしてどうせテスト環境なので http://127.0.0.1/wordpress-mu としてアクセスすることにする。ちなみに、http://localhost/wordpress-muでアクセスするとlocalhostではインストールできないと怒られる。なぜだろ。。。

http://127.0.0.1/wordpress-muにアクセスするといろいろと指示が英語で書かれているんだけど、ようするに

  • 空のデータベースを作ってね
  • /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentのアクセス権を 777 にしてね
  • Apacheのmod_rewriteが有効にしてね

ということを言っている。

順に作業すると、ます空のデータベースは、
$ mysql -u user -p
パスワードを入力
> create database wordpress_mu;
> quit
で作る。ちなみに、データベース名に “-” は使えないらしい。アクセス権は$ chmod 777 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentを実行すればOK。Apacheのモジュール有効化は$ sudo a2enmod rewriteのコマンドを実行する。

ちなみに、Wordpress MUの複数のブログをサブドメイン別(blog1.domain.com, blog2.domain.com …)にするのか、サブディレクトリ別(www.domain.com/blog1, www.domain.com/blog2 …)にするのか決める必要がある。サブドメイン別にするとDNSの設定とか必要だから、面倒だからサブディレクトリ別にする。フォーラムによるとサブドメイン型が推奨されているけど。。。

そのあと再び http://127.0.0.1/wordpress-mu にアクセスするとSub-domains/Sub-directories, Database Name, User Name, Password, Database Host, Server Address, Site Title, Emailを聞かれるので正しく設定するとadminのパスワードとログインページへのボタンが表示される。あと、アクセス権は755に戻してとも言われる。$ chmod 755 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentとアクセス権を元に戻す。

パスワードをコピーしてボタンを押すと、見慣れたwordpressログインページが現れる。すべて英語でメニュー構成もwordpressとちょっと違う。まずはusersのadminのパスワードを変更しよう。

次に、日本語化を行おう。ここはwpmu-jaに2.6.2用の日本語化情報および言語ファイルがあるので、書いてあるままに作業する。ちなみに、日本語を選択する箇所は2つあって、settingsのlanguageとsite admin→optionのlanguage。あと、日付のフォーマットも「Y/n/j l」に変更。これは普通のWordpressと同じ。

この後はテストサイト/ユーザの作成、プラグインの導入とテーマの設定かな。とりあえず、今回はここまで。

ゲストOSでの音途切れ

VMware Server 2.0のゲストOSであるWinXPにおいて音楽を再生していると途中に途切れることがあることについて前に書いたけど、あれからちょろちょろと調べてみた。

ホストOSであるUbuntu 8.04.1 LTS Serverのサウンド設定において、デフォルトで選択されるpulseaudioの動作が重い、とどこかに書いてあった。で、それをalsaに変えてみたけど音途切れは相変わらず発生する。それよりか、いろいろと弄っていたらホスト側で音が出ていないことに気付いた。あわててサウンド設定を自動検出に戻してみたけどだめ。

どうやら、VMware Remote ConsoleでゲストOSを起動していると音声はそちらにとられてしまうらしい。ゲストOSをシャットダウンしたらホストOSの音が戻った。ここら辺が微妙で、ホストOSでCDなんかを再生しちゃうとなぜかゲストOSをそれから起動させても音が鳴らない。UbuntuというかLinuxのマルチメディアはまだまだツメが甘いかな。

あと、音途切れの原因を探るべくゲストOSにてリソースを「パフォーマンス」でチェックしてみたら、CPU、メモリ使用率、HDD転送量が頭打ちするときに起こることが分かった。要するに、リソース不足である、と。テスト機であるからそもそも省リソースの方針で、リソース増強はなんか違う。限られたリソースの中で音楽再生の優先度を上げられればいいのだけど。。。

hdaがsdbになった

先日HDDをSSDに換装して大いに快適になったテスト機。だけど、気がついたらVMが立ち上がらなくなっていた。原因はVMを入れていたドライブがマウントされていなかった。では、なぜマウントされなかったのか? その原因は、HDDを取り外したときに今までhdaと認識されていたドライブがsdbと認識されるようになったためだと分かった。ドライブはIDEのSSDなのでhd*として認識されていいのに。。。

なぜsd*と認識されているのか? を探索するより、こういうことがあるからUUIDが導入されたわけだからUUIDを使ってみよう、と思いたったのであった。

ドライブのUUIDをを調べるためには、コンソールにてsudo vol_id /dev/sdb1を実行すれば、ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_UUID_ENC=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=
と表示される。ID_FS_UUIDが求めるUUIDで、これを/etc/fstabに設定する。# /dev/hda1 /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0
UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0
上の行が今までの設定でコメントアウトされている。

これでPCを再起動するとちゃんとドライブもマウントされ、VMもちゃんとVMware Serverに認識されVMが起動するようになった。

HDDからSSDへ

最近の高速SSDがどうしても試したくて。。。 といっても、いろいろと調べると安い高速SSDにはJMicronのJMF602というコントローラが使われてて、ある特定のディスクアクセスを行うと数十秒から数分OSがフリーズするらしい。プチフリーズ(プチフリ)と呼ばれるらしいが、どうも起きる人は気が狂うくらい起きて、起きない人は全く起きないのだとか。

まあ、これは試してみないといけないということで、TS32GSSD25S-Mを買ってみた。いわゆるハイスピード版と言われるもので、箱が黒と赤なのが目印(前のバージョンのものは青と緑)。

そして、試すならテスト機で、ということでUbuntu 8.04.1 LTS Server x64が乗っているHDDと交換することにした。面倒だし、最近はそこら中がベンチマークだらけなので性能比較は省略。

まずはSSDを追加してUbuntuのLiveCDを起動する。最初は面倒だったからHDDのパーティションをまっさらなSSDにGParted(パーティション・エディタ)でコピーしてbootフラグをonにしたけど、なぜかこの方法ではSSDからブートしない。LiveCDでマウントすれば中はちゃんと見えるし、ためしに/etc/fstabのUUIDの部分を/dev/sda1とかに変えてみたけど、そもそもgrubすら立ち上がっていないので効果なし。

でやっぱり定番のddでディスク全体をコピーすることにした。LiveCDで起動して、コンソールにて# dd if=/dev/sda of=/dev/sdb conv=sync,noerror bs=65536を実行する。ifが読み込みファイル/パーティション/ディスク、ofが書き出しファイル/パーティション/ディスクで、/dev/sda(こちらがHDD)
とsdb(こちらがSSD)と指定したのでディスク全体がコピーされる。convとbsパラメータの説明はdd –helpに表示されるので省略。

さすがはdd。今度はちゃんとSSDからブートすることができ、無事Ubuntuもその上のVMware Serverもその上のWinXPも起動した。なんといってもUbuntuがこれほど速く起動するのを見るのは初めてで驚き。VMware Remote Consoleなんて起動時のプログレスバーが20%のときに一瞬しか見えない。その上のゲストOSのWinXPは遅いSSDにVMが置かれているからこちらは変化なし。

HDDが20GBでSSDが32GBだったので、10GB程度が未使用になっている。これはもったいないので、またまたLiveCDで起動してGPartedにて(使ってない)swapパーティション(/dev/sda5)およびそれが格納されている論理パーティション(/dev/sda2)をSSDの後ろに移動して、HDDからコピーした基本パーティション(/dev/sda1)を開いたスペースに拡張する。ちなみにswapパーティションの移動は一発ではできなくて、

  1. swapパーティションを「swapをオフにする」で解除する
  2. 論理パーティションを後方に最大に拡大する
  3. swapパーティションを後方に最大に拡大する
  4. swapパーティションの開始位置を元の容量と同じになるように後方にスライドさせる
  5. 論理パーティションの開始位置をできる限り後方にスライドさせる
  6. 基本パーティションの終了位置を後方に最大に拡大する
  7. swap、論理パーティションにわずかな「隙間」ができるので、それらを微調整して埋める

これらの操作をまとめて実行する。swapおよび論理パーティションは元の容量ピッタリではないけど、元々スワップは使っていないので問題なし。

恐れていたfstabのUUIDの設定は全く心配に及ばなかった。プチフリも今のところは問題なし。って、まだ2時間程度しか使ってないけど。。。

/tmpをRamdiskにする

引き続き、VMware Server 2.0のチューニング。

ゲストOS(Win XP)で音楽を再生していると時々途切れる。大抵の場合はホストOS側のディスクアクセス時に発生していることから、ゲスト側ではなくホスト側にチューニングが必要であろうと思われる。もうすでに/etc/sysctl.confは弄ってあるから、あとは/tmpをramdiskに移動する荒業が残っている。

まあ、テスト機だからあまり深く考えずに、さくっと/etc/fstabに以下の行を追加する。tmpfs /tmp tmpfs defaults,noatime 0 0
tmpfs /var/tmp defaults,noatime 0 0
Ubuntu Forumには/var/logもramdisk化に含まれていたけど、logはまだディスクにとっておくことにしよう。

さて、再起動してみたけどいつもと同じように起動してくる(こないと困るんだけど)。今のところちょろちょろと作業は行っているけど、音楽が途切れることは少なくなっていると思う。ただ、ゼロではないのが悔しいところ。ホストOSの動作にまだちょくちょくホストのディスクを使っている節がある。あと、ホスト、ゲストOSともにそれほど軽くなったって印象は残念ながらあまりない。これまでいろいろとチューニングしてきているからかな。残る手段はホストOSのスワップ停止とゲストOSの一時ファイルのramdiskへの移動。

とりあえず、しばらくこれで様子を見よう。

VMware Remote Consoleの画面切り替え(3)

VMware Remote Consoleのウィンドウ切り替えでやっぱりUbuntu上では違和感がある。そこで、VMRCを起動するUbuntuにおいて、~/.vmware/preferences に以下の設定を追加した。pref.motionGrab = "FALSE"
pref.motionUngrab = "TRUE"
pref.grabOnMouseClick = "TRUE"
この設定を行うと、VMRCを操作していてUbuntuに戻るときはVMRCの外側のどっか(大抵は下のパネル。Windowsで言うところのタスクバー)をクリックする。で、VMRCに戻るときはVMRCの画面のどこかをクリックする。自分的にはこれが一番しっくりくる。

この設定の難点は、UbuntuからVMRCにタスクを切り替えてもVMRC画面をクリックしないとVMの操作ができないこと。あと、VMRC画面の外に僅かでもポインタが外れるとVMRCからUbuntuにタスクが切り替わるので、再度VMRC画面をクリックしないとVMの操作を続行することができない。

一番いい解決方法は、Linux上のVMRC Plug-inがWindowsのそれと同じ動きをしてくれるようになることなんだけど。。。

fstabにスペースを含むマウントポイントを指定する

VMware Server 2.0をそのままインストールすると、VM用に /var/lib/vmware/Virtual Machines というフォルダを作ってくれる。ここに外部ディスクをマウントすればホストOSとゲストOSのスピンドルを分けることができる。

で、# mount /dev/hda1 "/var/lib/vmware/Virtual Machines/hoge_VM"は問題なく実行できる。これでVMを作って、無事ゲストOSもインストールできたのでこのマウントを永続化しようとfstabに/dev/hda1 "/var/lib/vmware/Virtual Machines/hoge_VM" ext3 auto,users,rw,relatime 0 0と設定を追加したけど再起動時にマウントは行われない。マウントポイントのスペースが怪しいのは分かっている。ダブルクォートではなく、シングルクォートにしたり、スペースをエスケープ(\)したけどだめ。

ググってみたらなんてことない、fstabのmanpageにちゃんと書いてあった。マウントポイントに含まれている空白は、`\040' のようにエスケープできる。う〜ん。Windowsあがりの私にはちょっと難しかったなぁ。ってゆか、ちゃんとマニュアル読めよ! RTFM!/dev/hda1 /var/lib/vmware/Virtual\040Machines/hoge_VM ext3 auto,users,rw,relatime 0 0って直したらちゃんとうまくいった。

VMware Remote Consoleの画面切り替え(2)

VMRC実行OSがUbuntuでも、VMのデスクトップをクリックするだけで切り替えられる「技」があることが分かった。

それは、VMウィンドウから他のウィンドウにフォーカスするときにCtrl+Altを押すこと。その後に他のウィンドウをアクティブにして、試しに裏側に行ったVMRCのウィンドウにポインタを移すと、ポインタが手のマークになる。この状態ならVMRCウィンドウのどの部分でもクリックすればVMRCウィンドウにフォーカスが当たり前面に移動してきて、アクティブになる。

少しずつ分かってきた。マウスがVMRCウィンドウから出るときに自動的にCtrl+Altが押されるように設定できればいいはず。VMware Toolsはもう入っているし、VMRC Plug-inのLinuxバージョンに問題があるはずだから、実行OSのpreferences.iniに何か秘密があるかもしれない。

VMware Remote Consoleの画面切り替え

VMware Remote Consoleで複数のVMを操作していてVMを切り替えるのに、VMのデスクトップ部分をクリックしてもVM画面が前面に切り替わらないのである。一般的なウィンドウの切り替えのように、ウィンドウのどこでも一部をクリックするのではなく、ウィンドウ枠をクリックしないと前面に切り替わらない。一応アクティブウィンドウにはなっているようなので、操作はできるけど、前のウィンドウがじゃま。。。

こういうものなのかと思っていた矢先、Windows XP ProfessionalをホストにしたVMware Server 2.0の場合はVMのデスクトップ部分をクリックすることで前面に切り替えられたのであった。まあ、Window切り替えはこうありたいものだけど、VMRCでこれができるのは新鮮。ってゆーか、今頃気付くな! って感じだけど。

気を取り直して、この操作で関係してくると思われる、ホストOS、ゲストOS、そしてVMRCを起動するOS毎の動作状況を調べてみよう。

ホストOS : ゲストOS : 実行OS
Win XP Pro : Win XP Pro : Win XP Pro
Win XP Pro : Ubuntu 6.06 LTS Server : Win XP Pro

の組み合わせはOK。でも、ゲストOSがUbuntuでログイン前だとマウスのVM間、実行OSとの行き来でプチフリーズすることがある。2,30秒くらいキーボードもマウスも反応がなくなる。Ubuntu VMを終了させるかログインしてしまえば直る。なんとも不思議な現象。これはUbuntu 6.06固有の問題っぽい。

そしてホストOS : ゲストOS : 実行OS
Win Vista Home P SP1 : Ubuntu 8.04.1 LTS Server : Win Vista Ultimate SP1
この組み合わせだと画面切り替えが正常に行える。どうも、VMRCを起動するOSに依存するようだ。まあ、早い話がLinux対応のVMRC Plug-in(=VMware Player)のバグ、ってことかな。些細なことだけど、直してほしいな。