[脱vmware]kvmってこんなに速いのか

これみて、もうKVMがやりたくてやりたくて。

これでもう遅いLinuxデスクトップとはおさらばできますか？

…..nic性能とかあるけど

[vmware]firefox 3を使って分かるvmwareの遅さ

くどいんだけど、vmiを使ってもvmwareはやっぱ遅い。

firefox 3のメニューの[履歴]とか[ブックマーク]をクリックしてメニューアイテムをだし、その上でマウスを行き来させると、実機上ではさくさくフォーカスが移るのに、vmware上ではかな〜り大変しているって感じにフォーカスが移動するんだよね。

で恐らく、この問題というのは実害があまりないとしても、もっと深い部分で大きな問題があるのでは。

swingアプリが使える速度で動作しないとか

airアプリが使える速度で動作しないとか

snapshotとかも切ったし、メモリもスワップさせないしとか、初歩のチューニングはしたけど、こんなもんか？

このままだとwindows xp or windows 2000専用仮想環境になりさがるな

[覚書]fedora 10上で動作するvmware workstation上のubuntu 8.10ゲストのキーマップがおかしい

安心していると忘れそうな不具合なので覚書

fedora 10上でvmware workstationを動作させ、ubuntu 8.10をゲストとして稼動させたところ

• workstationのコンソール上でubuntu 8.10にログインしたところ特定のキーが機能しない
• 方向キーというかカーソルキーやPageUp PageDownといった英数字以外のキーがおかしい
• ホストOS上でXephyrでリモートログインと方向キーがおかしくなる

対応方法

vmware workstation上でのキーマップの不具合は、~/.vmware/configを作るとか、編集したりする。

Xephyrの方の対策はまだ

vmware workstationの対策用~/.vmware/configのサンプル
元ネタ

xkeymap.keycode.108 = 0×138 # Alt_R
xkeymap.keycode.106 = 0×135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0×148 # Up
xkeymap.keycode.116 = 0×150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0×152 # Insert
xkeymap.keycode.119 = 0×153 # Delete
xkeymap.keycode.110 = 0×147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0×149 # Prior
xkeymap.keycode.117 = 0×151 # Next
xkeymap.keycode.78 = 0×46 # Scroll_Lock
xkeymap.keycode.127 = 0×100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

原因

調査中

赤っ恥。firefoxのメニュー速度が遅いのはリモートログインが原因なんかんじゃない

「fedora 10でxdmcpが使えないのは、性能が出難いからじゃないの？」とかで、gdmがリモートログインをできなくしているのは、リモートログインでまともな性能がでないのだとか書いた。でも真実は、拙者みたいな適当な知識しか持たないLinuxタコを遠ざけるのが目的なのかも(w

最近HDDがお釈迦になったノートPCにXPの代わりにubuntu 8.04を入れて半放置していた。

ここ最近わりと徹底的というか真剣にLinux環境からcifs(windows共有)を使ってみて、ubuntuをもってしてもとてもwindows xp並の機動力(即時対応できるか？)に難があるのだと痛感。それにOpenOffice calcの計算ミスというか心震えるバグ？に信用↓。それでノートのubuntuをXPにそろそろ戻そうかと思っていました。

でもその前にと試しに実機同士のリモートログインの性能を調査してみた。・・・・・ていうかリモートログインしてみただけだけど。firefox3のメニュー展開とかopenofficeのレスポンスとか。

えと、自分的にはvmware上のゲストにリモートで入った場合のちょいましを想像していた。

そしたら・・・・全然動くじゃんorz

真剣に反省しました。

しかもレスポンスのよさは、ホストOS上で動作させたvmware workstation 6.5のコンソール上よりいいかもorz

自身とvmwareに対する過信が大きく揺らいだ瞬間でした(支持率13%くらいか)。麻生化現象

ホストとゲスト ubuntu 8.04(host os) <-(not bridge)– fedora 8(guest os) vmware workstation 6.5

Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s
l 8388608 0.16 0.14 419.3780 482.8705 2048 12798.40 14736.0
1 8388608 0.16 0.03 416.6751 2097.0209 3696 22948.25 115492.8


実機同士 ubuntu 8.04(desktop) <–(100mbps)– ubuntu 8.04(note pc)

Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s
l 8388608 0.47 0.02 143.6590 4194.0419 2048 4384.12 127992.0
1 8388608 0.71 0.06 94.0754 1198.3084 3462 4853.14 61818.1


（続くかも）

[覚書]VMware workstationがXと一緒に死んでしまって、ゲストOSも道連れ

VMware workstation 6.5はGUIが頻繁に落ちる(ubuntu 8.04上4GBメモリ)。しかしゲストOSはGUIとは別の他のプロセス上で稼働しているから割り切れば大したことはないです？

致命的な問題はVMware workstationを動作させているXが死んだ場合ですか？。ゲストOSも綺麗さっぱり殺されてしまいます。当然かつ早急な対処が必要。compizが動作するXに安定を期待するのは愚か者というものですね？

対策としてはゲストOSをバックグランドで動作させること？なわけですが・・・いやすでにバックグラウンドで動作してるし

真の対策としては、ゲストOSのプロセスに各種殺しのシグナルを送らないようにすることッスね？

かなり適当にやると以下の感じか？これをスクリプトにするなり、端末から実行すればよいと

trap ‘ ‘ 0 1 2 3 4 5 6 7 8 9 10 11 12 <–シグナルリストはいい加減注意
trap -p
vmrun start $HOME/Virtual Machines/usurabaka/usurabaka.vmx nogui

このようにやればXが真でもゲストOSは稼働し続けるから、安定稼働＆安心利用できるでしょ