2013/05/06

btrfsって遅い・・・。USB3のHDD増設だ!

Fedora 18を再インストした時に、ファイルシステムをext4からbtrfs(これ、b-tree filesystemの略称なんだが、「バターfs」と呼ぶ人がいるらしい。普通に「びーちーあーる、えふえす」でいいと思うのだが)に変更したのだが、このファイルシステム、体感的に、すこぶる遅い

最もストレスを感じていたのが、KVM上でVistaを動かしていた時で、目に見えて遅くなってしまった。

そんな折、外付けHDDの容量が、そろそろ心配になってきた。なにせ、Vistaの仮想ディスク・ファイルだけで、現状90GBあるので、複数バックアップすると、1TBでも、あっという間に一杯になる。しかも、USB2で接続しているのでファイルのコピーも酷く時間がかかる。

そこで、外付けHDDを買いに行くついでに、USB-3のIFボードも買ってくることにした。

ところが・・・、

Linux対応しているIFボードがほとんど無い!!

ものは試しにと、手元にあったLogitecのボードを差してみたが、ボード自体は認識したものの、外付けHDDは電源ランプすら点灯せず。まぁ、そらそうか。

そんな中、ありました、RAOTOCのREX-PEU3XというPCI Expressに挿すタイプのボードです。さっそく、外付けHDDと共に買いつけてきました。

IFボードを差し込んで、USB3対応のHDDを繋ぎ、PCの電源をON。外付けHDDはNTFSでフォーマットされていたので、Fedora18で、何事もなく認識。すばらしぃ!

さっそく、ext4に再フォーマットして、Vistaの仮想ディスク・ファイルを移してみることにした。

PC本体のbtrfsから、外付けHDD(USB3接続)のext4へファイルを転送すると、なんと外付けHDDのアクセスランプが点滅→停止を繰り返す(要するに外付けHDDが暇になっている)という、笑えない状態になり、無事転送を完了。

仮想マシンの仮想ディスクを外付けHDDに切り替えてVistaを起動・・・。

うわぁ、速いじゃん!

外付けHDDは音も静かで、なかなか良い感じ。

さて、次世代のファイルシステム候補の一つであるbtrfsですが、現状で主流となるには、まだ厳しいですな。まぁ、開発途中との事ですし・・・(とは言え、開発途中と言い続けて、早数年)

| | コメント (0) | トラックバック (0)

2013/03/20

KVMでブリッジ。ああ、そうか。

さて、KVMの引き戻しをしていて、

「ああ、そうだ、virbr0を外すんだった。」

と、本ブログの【Fedora17にアップしたので】を見ていて、ふと思った。

「ん? これってブリッジを用意してくれてるって事だよね。」

ググってみると、Fedoraでブリッジ設定をしようとすると、NetworkManagerが悪さをするのでサービスを停止させ、古いnetworkサービスを開始する必要があるとの記述が散見される。これが、原因かなぁと思って、諦めていたのだが、ifconfigで表示される、このvirbr0は、間違いなくブリッジじゃないのか?

macvtapを使用するから必要ないと削除していたのだが、ブリッジにしないと使い辛い問題があった。

macvtapではホストとゲストで通信できない。ホストとゲストは、別のIPアドレスが割り振られているが、ゲスト上で、ホストのIPアドレスを指定しても、ルーティングしてくれないのだ。

この問題は仮想ブリッジを使えば解決する。その為に、NetworkManager下で、わざわざブリッジを作っているのがvirbr0という訳か。

試しに、仮想マシンのNIC設定を変更してみる。

以前の設定は、

ソースデバイス: ホストデバイス em1 : macvtap
デバイスモデル: ハイパーバイザーのデフォルト
Source code: Bridge

であったのを

ソースデバイス: 共有デバイスを指定
  ブリッジ名: virbr0
デバイスモデル: ハイパーバイザーのデフォルト

に変更して、仮想マシンを起動。Windowsが立ち上がったら、ホストのIPアドレスにpingをうってみる。

「あっ、届いた!」

ならばと、ホスト側でSambaをセットアップ。ほう、Fedora18からSamba4なんだ。
あら? Sambaが吸い込めない。また依存関係エラーか。とりあえず、引っ掛ったモジュールをyumで見てみると、@anacondaから?
yumで削除とインストールしてやると、fedoraリポジトリから正常に吸い込んだので、再度、Sambaをインストール。正常にインストール出来たのでサービスを登録した。

# yum -y install samba samba-client
# systemctl start smb.service
# systemctl start nmb.service
# systemctl enable smb.service
# systemctl enable nmb.service 

で、GUIのSamba設定もインストールしたのだが、今度は、ユーザ追加が動かない。またですか、Fedoraさん!
仕方がないので、smbpasswdコマンドでユーザを追加する。

# smbpasswd -a 追加するSambaユーザ名
Sambaパスワードの入力

その他は、GUIのSamba設定が使えたので設定して、ゲストのWindows側からアクセスしてみると、ちゃんと、共有ディレクトリが見れるではないか!。

という事で、ブリッジの問題は片付いた。

それにしても、何かと手間がかかるんだよなぁ。(^-^;

| | コメント (0) | トラックバック (0)

引き戻したんだけど

前に書いたように、Fedora18へのアップグレードが、結局、再インストールになったので、qemu/KVM上で使っていたWindowsも引き戻しになった。

当初、仮想マシンマネージャーが見つからず、yumでインストールしようとすると、依存関係で引っ掛かって取り込めなかった。

こうなると大事(おおごと)で、依存関係で引っ掛っているモジュールを確かめ、そのモジュールを必要としているモジュールのバージョンを確認して適正なものに合わせるという作業になる。

とりあえず、エラーが出ているモジュールをyumで削除し、再インストールする。最後に、glibc関連のバージョンが合わないというエラーが残った。glibc関連は当然保護されているので削除できない。このため、これを使っているモジュールを見付て削除→再インストール。無事に仮想マシンマネージャーを取り込んだ。

仮想マシンマネージャーが使えるようになったので、新しい仮想マシンを定義。バックアップしてあったHDDイメージを設定して、仮想マシンを復活。上手く起動したのだが、立ち上がってきたWindowsに、PCI関連のドライバがないと言われた。

とりあえず、Windowsのデバイスマネージャで、PCIのドライバを無効化してみたのだが、今度は、ハードウェアで追加した、USBメモリが読めなくなった。今、原因を探っている。

そんな中、仮想マシンのハードウェアを眺めていると、タブレットが入っている。特に使っていないので削除してみたのだが、こうすると、とても不便な状況になってしまう。

仮想マシンのグラフィックコンソール(要するに、仮想マシン上で動作するOSの画面)上でマウスをクリックすると、マウスが捕捉され、マウス・カーソルがグラフィックコンソールの外に出れなくなる。

具体的に言うと、グラフィックコンソールが表示されている、ホスト(Linux)のウインドウのクライアント領域内から出れなくなるのだ。これが曲者で、Windowsをフルスクリーン表示した時に画面サイズと合うように解像度設定をしてあったので、フルスクリーン表示でない場合は、グラフィックコンソールの一部しか表示されず、ウインドウの右下端にスクロールバーが出てくる(表示の自動調整はフルスクリーン時のみに設定してある)。
だが、マウスを補足されてしまうと、このスクロールバーにすら、マウスを持っていけない。マウス補足の解除は、CTRL(左)とALT(左)の同時押しで出きるのだが、クリックする度に、これをやるのは、非常に不便なのだ。

で、ググってみると、

マウスで VM ゲスト のコンソールを押すと、カーソルはコンソールウインドウ内に 捕捉され、明示的に解放 されるまで外側に移動できなくなります。ホストとゲストの間を自由に移動できるようにするには、 VM ゲスト にタブレットを追加してください。

なのだそうだ。ふむ、タブレットにも意味があるってことか。

さて、改めてUSBが繋がらない原因を探らないと。

| | コメント (0) | トラックバック (0)

2012/11/24

ブリッジが出来ないなぁ

KVM上でWindowsを使っているのは前の記事に書いたが、一時使えなくなっていたのは、ブリッジが上手くできなかったから。このためmacvtapを使用したのだが、この場合、ホストとゲスト間の通信が出来ない。よって、Samba経由のファイル受け渡しが出来ないのだ。

で、調べてみたのだが、どうやら元凶は、NetworkManagerらしい。
このNetworkManagerは、随分と「俺様」なサービスらしく、Fedoraではブリッジ設定出来ないらしい。

ググってみると、各所で「NetworkManagerを切ってください」との記述が・・・。
めんどくせぇ・・・。

NetworkManagerのサービス止めて、networkサービス起動しようとしたら・・・、
あら? start出来ないじゃん!!

「macvlan使えばできるよん!」とかいう記述もあったが、NetworkManagerはem1デバイスを頑として譲らず、切り替えられない。

どうも、NetworkManagerをシステムから削除しないといけないんじゃないかと、思う今日この頃。

思えば、NetworkManagerがデフォルトになってから、「あれが動かん、これが動かん」が続いている気がする。Fedoraも、何考えてんだか・・・。

そろそろ、気力も失せたので、この件は、一旦、持ち越しにします。。。


| | コメント (0) | トラックバック (0)

2012/07/31

再アクティベーションに陥る

記事でも書いてきたように、現在、Fedora17+KVM環境で、Windows Vista(パッケージ版)を仮想環境にインストールして使っている。

当初、仮想ディスクの不足やら、サービスパック適用に伴う起動不良やらで、オンラインのライセンス認証が上手く行かず、電話問い合わせによるライセンス認証を行い、Vistaは無事にアクティベーションされていたのだが・・・。

前の記事でも書いたように、Fedora 16で、インストール不良からアップデートが上手くいかず、クリーンインストールする羽目になった。またWindowsのネットワーク接続が上手くできなかったので、そのままになっていたものを、Fedora 17(こちらはアップデート成功)にした所で、macvtapを使用してネットワーク接続をクリアした。

Vistaの仮想イメージは、バックアップしてあったものを、そのまま使用しているので、Vistaの再インストール等は行っていないのだが、仮想マシンのハードウェア設定が変わってしまったのか(KVM環境もアップデートされたので、それによる仮想ハードウェアの設定が変わったのかもしれない)、Vistaのライセンス認証を再び要求される事になった。

しかも、前回のライセンス認証があるので、プロダクトキーが重複するため、オンラインのライセンス認証が使えず、結局、また、電話でMSのライセンス窓口に電話し、事情を説明して、ライセンス認証(アクティベーション)を行う羽目になった。

確かに、Vistaが出た頃は、仮想環境は一般的ではなく、ハードウェア情報は変わらなかったのかもしれないが、仮想環境ではハードウェア情報が頻繁に変わることが予想される。ライセンス認証を保持するために、変更してはいけないハードウェア情報が何か明確でない以上、この方法は、かなり使い難いと言ってよいと思う。

MSには、もう少し、(サイトのリンクを何度も辿らないと見つからないとかではなく、明確に)情報を出してもらいたいものである。

また、Vistaのサポートが打ち切られた後、新しいマシンへインストールした場合、ライセンス認証はどうなるのだろうか? 「サポートが切れたので、もう使えません。」というのでは話にならないが、ずっと電話対応する事も出来ないだろう(もし、そうなれば、その維持費用が新製品に転嫁される事になり、あまり現実的とは思えない)。

| | コメント (0) | トラックバック (0)

2012/07/11

Fedora17にアップしたので

Fedora16でアップデートに失敗し、再インストとなりましたが、Fedora17は、何事もなくアップデート出来ました。やはり奇数バージョンはしっかりしています。

で、KVMも新しくなったようなので、Fedora16時にネットワークが上手く繋がらず、永らく止まっていたKVMを動かしてみました。というのも今回、macvtapが出来るようになり、以前のようにホスト側でブリッジを設定する必要がなくなったようなので、これは簡単じゃわと考えたからです。

■ネットワークの設定
仮想マシンマネージャーを立ち上げ、仮想マシンを作成(既存のインポート)し、各種設定をを行いました。問題のネットワークですが、メニューからNICを選択して、

ソースデバイス: ホストデバイス em1 : macvtap
デバイスモデル: ハイパーバイザーのデフォルト
Source code: Bridge

を設定して起動させてみました。

おっ、Vistaが立ち上がってくるじゃないの!

ネットワークも繋がってるようです。で、ホスト側(Linux)のネットワークをifconfigで見てみると、macvtap0が出来てますな。「いいんじゃない。」と思っていると、あれ? virbr0ブリッジがあるぞ? なんで、ブリッジが残ってんだ??

早速、ググってみると、

『KVMをインストールすると、漏れなくvirbr0が作成されます。』

との事。いや、要らないんだけどなぁ(苦笑)。

で、回避方法が書いてあったので、それを実行してみました。

KVMが管理しているネットワークをまず確かめる。

# virsh net-list
名前 状態 自動起動
-----------------------------------------
default active yes

このdefaultが起動してしまうため、virbr0が作られるらしい。defaultの内容は、

virsh net-dumpxml default

で確認できる。出力されたXMLを見ると、確かに定義されとりました。

で、このdefaultを削除すればvirbr0も削除出来るとの事だったので、

virsh net-destroy default

で、defaultを削除する。
が、これだけでは、再起動時に、また自動起動してしまうので、

virsh net-autostart default --disable

として自動起動をOFF設定してやります。

これで、virbr0は無くなり、macvtap0だけになるようです。

さて、後は、アップデートの山を消化しないと・・・。

| | コメント (0) | トラックバック (1)

2011/09/01

キャッシュモデル

どうやら上手くアップデート出来た模様。。。

何で、こんな遅いんだろうと、HDBENCHを入れて計測してみた。すると、キャッシュモデルの設定で、速度が大きく変化することが判明。

起動用の仮想ストレージ(40GB)
Disk Bus: IDE
Strage format: raw

当初設定していた「キャッシュモデル」はdefaultでした。

キャッシュモデル: default
Read: 234324
Write: 6323
Random Read: 123671
Random Write: 4115

と、HDBENCHの結果でも、書き込みが極端に遅いことが解ります。そこで、「キャッシュモデル」をwritebackにして仮想マシンを再起動してみました。

キャッシュモデル: writeback
Read: 192843(211354)
Write: 159750(177162)
Random Read: 97803(97896)
Random Write: 29689(29425)
※括弧内はベンチマーク再実行時の結果

という訳で、これが、インストールに時間がかかっていた要因の一つのようです。

ちなみに、virtioの仮想ディスクでも試してみました。

Disk Bus: virtio
Strage format: raw
キャッシュモデル: writeback

Read: 172390(172681)
Write: 142420(197202)
Random Read: 133856(136533)
Random Write: 30806(32809)
※括弧内は再実行結果

あまり差が無いどころか、IDEより遅かったりします。

いずれにしても、キャッシュモデルをwritebackにするのは必須のようです。

| | コメント (0) | トラックバック (0)

2011/08/29

Vista SP2適用完了

やっと、ここまで辿り着きました。

SP2適用後のFirst bootは、表示が速くなった印象があります。Cドライブの使用量は21GB弱で、いま、仮想ストレージのバックアップ中です。

やはり、HDD容量は40GBが最低ラインのようですね。

後は、HDD容量の削減と、よく使うファイルのvirtio仮想ディスクへの移動(有力候補はProgramData?)といったところでしょうか。これで、やっとVisual Studioが使えそうです。

長かった。。。

| | コメント (0) | トラックバック (0)

Vista再び!

結局、週末を使ってVistaインストールに再チャレンジ。

現在、Vista SP1のアップデート作業中で数時間経過。。。
遅い!遅すぎる!!

ただ、このSP1のインストールまでに、Windows updateで大量のアップデータを処理しないといけませんでした。結局、SP1インストール直前の起動ディスク(Cドライブ)使用量は20GB以上でした。やはり起動ディスク用の仮想ストレージの容量の最低ラインは40GBのようです(SP1適用の為に10GB程空きが必要らしい。なお、この容量は、ページング用のファイルとハイパネート用のファイルを含んでいません。この2つで5〜6GBあったようなので、40GBでもギリギリ)

それと、もう一つ不思議だったのは、CTRL+ALT+DELで起動するタスクマネージャでパフォーマンスのCPU表示表示が1個しか出ませんでした。これは、仮想マシンマネージャー(virt-manager。Gnome3の場合、「アクティビティ」で「アプリケーション」を選択し、右メニューの「システムツール」で出てきます)で2CPUを指定し、かつConfigurationでCore2Duoを指定してもこうなります。
実は、その下のtopologyのcore数が1のままの為で、これを変更すれば、ちゃんと2CPU表示になります。とはいえ、Vista Home Premiumは2CPU対応してないようですが(苦笑)

さて、HDBenchを入れて、IDE仮想ディスクとvirtioの仮想ディスクのスピードを見てみたのですが、倍速までは行かないまでも、やはりvirtioの方が高速です。この辺からも、起動ディスクとしてvirtioが使えないVistaとQEMU-KVMの相性はよろしくないようです。

さて、さて、やっとこさSP1の更新が完了。リブートしてきました。Cドライブのの容量は、17.4GBになっています。インストール関連の情報を整理したのでしょうか? SP1適用前より減っています。

後は、このインストール済みの仮想ストレージのファイルを、外付けの大容量ディスクにバックアップすれば完了です。これは、ホストOS(Linux)側で単にファイルをコピーするだけですので、簡単。しかも、上手くいくかどうかわからない「システムの復元」に頼ること無く、確実にシステムを復元出来る点では、仮想化のメリットなのかもしれません。

| | コメント (0) | トラックバック (0)

2011/08/17

それはないよRedHat

永らく、御無沙汰してしまった。自宅サーバのBlogに移行していたのだが、サーバPCが、あえなく御陀仏・・・。という訳で、こちらに避難してきました。ただいまです。

さて、Fedora Linuxも気が付けば、15まで番号が上がり、インストールすると、デスクトップがGnome3に変更されたりして、そりゃ大騒ぎな状態になっています。個人的には、Gnome3はイマイチ(というか、「不出来」と言った方が近い)と思いながら、使っております。

で、Fedora15には、QEMU-KVMを使った仮想化機能があります。Linuxを使っていると、Windowsが必要となる事は、あまり無いのですが、緊急でVisual Studioを使いたい場合があるので、余っていたWindows VistaをゲストOSとして導入してみることにしました。

ちなみに、ホストになるFedora15はx86_64(64Bit版)を使っています。PCのCPUはCore2Duoで、ちょっと古いとは言え、そこそこのパフォーマンスは出るだろうと考えました。ただメモリが3GBしかないので、この辺は、ちょっと心配な所です。Vistaは32Bit版(しか手元にない)です。

とりあえず、セットアップしてみました。仮想マシンのCPUは2個(Core2Duoですので)、メモリは半分より、ちょっと多めの1.8GBを設定しました。問題は、仮想マシンのストレージ(要するにパーティション)なんですが、デフォルトが8GBになっており、そのまま使うと、インストール後、Window Updateした時点で容量不足に見舞われます。少なくとも20GB程度は欲しい所です。

それと、QEMU-KVMの仮想マシンの場合、グラフィック・コンソール(Vista用の画面ですな)はリモート接続を使うのが前提のようで、そのままセットアップするとVNCになります。ただ、この場合、マウスの反応などが遅くて、大変、使い辛いです。このため、RedHatのSPICEを使う事にしました。こちらの方が、かなり軽いです。(SPICEを使う場合、ディスプレイのモデルはqxlを使用するとパフォーマンスが上がるそうなので、そちらもセットアップしました)

さて、これで使い始めたのですが、やっぱり「重い」。

KVMをネットをググってみると、ストレージとネットワークにvirtioドライバが使えるらしい。このドライバをVistaにインストールすると、高速なI/Oが実現できるらしい。

ネットワークドライバは、ブリッジを使うようなのでFedora側にブリッジを作成して、仮想マシンにハードウェアとして登録すれば、あとはVistaが自動検出するので、提供されているドライバをインストールすれば使えるようになります。情報を見てみるとギガ・イーサで接続された事になっているようです。物理ネットワークは100Mなんだけどね(笑)。

ストレージの方も、高速化しようと、RedHatのページをググってみたのですが・・・、

> ゲストOSとしては、Red Hat Enterprise Linux 3、4、5の他に、
> Microsoft Windows Server 2003 R2と、
> Microsoft Windows Server 2003 SP2、
> Microsoft Windows Server 2008、
> Microsoft Windows XP (32bitのみ), Vista もサポート対象となっています。

あれ? Vistaはオマケのような扱いだな。ちなみにダウンロードしたドライバには、Vista用のディレクトリが・・・、無い!!

RedHatの補足事項ページには、

> Windows Vista/Server 2008 32 ビット版
> メモリバルーン: balloon\install\Vista_Win2008\x86\balloon.inf
> ネットワーク: NetKVM\install\Vista_Win2008\x86\netkvm.inf
> ストレージ: viostor\install\Vista_Win2008\x86\viostor.inf

となっているので、とりあえずWindows Server 2008用のドライバを使うことにしたのですが、このページには続きがあって、

> [警告マーク] Windows Vista に対する擬似仮想化ストレージドライバ
>
>現時点では、 Windows Vista 向けの擬似仮想化ストレージドライバは、
> 擬似仮想化ディスクから起動する機能に対応していません。擬似仮想化
> ディスクは、 起動ディスク以外での使用のみをサポートしています。

ええええっ!! 機動ディスクが作成出来ない!!。そりゃないよRedHatさん。

仕方がないので、ストレージは、最初に作成したIDEディスク(20GB)を、そのまま使うことにし、ページングファイルやTempフォルダ等をvirtioのストレージに移して高速化する事にした。


やっぱり、この御時世、Vistaなんてサポートの切れそうなものは使わず、Windows7に乗り換えろと言う話なんでしょうか。でも、高いパッケージを、わざわざ買ったのに使えないのは、ちょっとなぁ。

| | コメント (0) | トラックバック (0)