Mar 30, 2007

セ・リーグ開幕

「すいません、涙もろいんで。」(落合博満)
「なんか、だんだん年をとっていくごとに涙もろくなっちゃって……。」(浅田真央)

今年の落合監督は何を言ってくれるだろうか。

Yahoo!プロ野球 - 2007年3月30日 中日vs.ヤクルト 結果

「中村紀洋、なんて恐ろしい選手!」(姫川亜弓)

中日ドラゴンズはとんでもない選手を手に入れてしまった。

率直に言って開幕ゲームのこの活躍だけで600万円分の価値があった。「イラナイなんて言ってゴメンナサイ。もうずっとドラゴンズにいてください。」と言うほかない、この活躍を観せられては。特に2本目の流し打ちは見事としか言いようがない。素晴らしい打者だ。この調子を維持してくれるなら、福留から左・右・左・右と強打者が続くドラゴンズのラインアップが相手ピッチャーにとって脅威になるのは間違いなさそうだ。

川上憲伸は…まあいつも通り。本塁打一本で済んだわけだから御の字か。桑田がいなくなったので現役単独の最多本塁打投手。今年は8本目が観たい。

余談だが、今年から日本野球機構承認のオンライン野球ゲーム、ドリームベースボール(DBB)に参加し始めた。

DBB d-bb.com ドリームベースボール プロ野球をもっと楽しむオンラインゲーム

プロ野球ネタはこのブログじゃなくてDBBのサービスするブログに記そうと思っていたのだが、他のサイトへのリンクの禁止やアフィリエイトの禁止など禁止事項が多過ぎて断念した。

禁止事項が多いのもアレなのだが、その日のスコアカードを簡単にインクルードできるようにするとか、選手名を書くだけで自動的に選手のプロフィールページにリンクするとか、NPB BISを利用したオンラインサービスならではの可能性がいろいろありそうなのにもったいないな、という感じ。

先生、Snapとか HeartRails Glanceとかが鬱陶しいんです!

何やらリンク先のサムネイルやらブックマークリンクをポップアップ表示してくれるサービスがあり、なぜだか知らないが人気があるようである。サービス提供者の方々には本当に本当に申し訳ないのだが、私の感覚に従えばこれらのサービスは十分閲覧者の妨げになっている。

Snap
HeartRails Glance | リンク先 「チラ見」 サービス
Browster - Fastest Way to Browse
Cooliris Previews - Discover More...

多分一番利用者が多いと思われるSnapは表示・非表示などの閲覧者のプリファレンスをクッキーとして保存できるので限りなく存在を消してくれるのに対して、(上記中唯一の)国産サービスであるHeartRails Glanceはそうはなっていない。改善を期待したいところ。他のはわかんないけど。

さていきなり議論をフットバスと、結局閲覧者のプリファレンスや利便を優先すべきか、コンテンツ提供者のプリファレンスや利便を優先すべきか、あるいは両方を優先すべきか、という話に収斂しそうである。

思えば、ブログシステムのような統一的なWebページ作成ツールやモダンなWebブラウザ、YouTubeをはじめ利便性の高い外部サービスなどなどが流行ったおかげで、「文字がブリンクしたり、スクロールしたりして読ませてくれない」、「ブラウザのStatus Lineにどうでもいいメッセージがスクロール表示され、リンク先のURLすら確認できない」、「なぜか右クリックが禁止されている」、「やたらポップアップする」、「いきなり悪趣味なMIDIのオルゴールが鳴り始める」、「どうやって作ったのか逆に尋ねたくなるバナー画像を伴う」コンテンツというのはかなり排除された。コンテンツ提供者のプリファレンス(のようなエゴのようなもの)は捨象されるか閲覧者のプリファレンスにもマッチするような穏当で上品な代替品に置き換えられた。結果として、閲覧者にとっての利便性は格段に向上した(が、もちろん今でもブログシステムの改造記事はそれなりの読者を集める)。

かたや、「リンク先のサムネイルやらブックマークリンクをポップアップ表示してくれる」サービスである。歴史が繰り返されているだけのような気がしてならない。

それを便利だと思うプリファレンスを共有しているコミュニティにとっては(そこそこの規模はあるようだ)、確かにエコシステムとして機能しているのだろうが、それ以外の閲覧者にとってはそうではない。こと私に限って言えば、「あれこれポップアップ」ですら許せない狭量さを持ち合わせている。また、コミュニティツールならコミュニティツールとして、ブラウザのイクステンションなり外部サービスなりとして実現することもあり得たはずだろう。

ページに埋め込むというのは最悪の界面/実現方法に思えてしかたないのだ...。

Mar 29, 2007

KML / GeoRSS Overlays機能がGoogle Maps APIに追加されていた

しばらくウォッチしていなかったが、Google Maps API にKML/GeoRSS Overlays機能が追加されていた(2.76)。

Google Maps API Documentation
Google Maps API Official Blog: KML and GeoRSS Support Added to the Google Maps API

私がむかーしやっていた↓の話が、

Ogawa::Buzz: Ajaxを使ってKMLをGoogle Maps上にマップする
Ogawa::Buzz: georss2kml.cgi: GeoRSSをGoogle Earthにマップするスクリプト

ずっとお手軽に、単にKML/GeoRSS URLを指定するだけで、勝手に読み込んでマップ上にオーバーレイしてくれるようになった(↓)。

    var map = new GMap2(document.getElementById("map"));
    map.addControl(new GLargeMapControl());
    map.addControl(new GMapTypeControl());
    
    var point = new GLatLng(35.7054825793624, 139.751811367593);
    map.setCenter(point, 13);
    
    var url = 'http://as-is.net/maps/sample.kml';
    var gx = new GGeoXml(url);
    map.addOverlay(gx);

動作サンプル: kml2gmaps-ggeoxml.html: Maps KML file onto Google Maps

とは言うものの、GGeoXmlで取得したKML/GeoRSSのデータは単にGMap2.addOverlay, GMap2.removeOverlayできるだけで、データ構造を操作するためのインタフェースは用意されていない。だから、MarkerやInfo Windowの表示方法を変更したり、Ogawa::Buzz: Ajaxを使ってKMLをGoogle Maps上にマップするみたいにナビゲーション用のメニューを表示したりすることはできない。残念ながら。

まだ機能としてはimmature。今後の充実を期待しているところ。


そう言えば、GGeoXML - Are markers accessible? - Google Maps API | Google グループのスレで気がついたんだけど、私のコードがまんまリユースされていてちょっと愉快ではない感じ(?)

KML Points onto Google Maps API

SUICAとパスネットの残高が減らない問題

PASMOのサービスが開始された翌日(19日)に通勤定期をPASMO定期に切り替えたのだが、地下鉄ユーザの私は悩んでいる。というのも、SUICAにもチャージが残っているし、パスネットの残高もあるからだ。

通勤定期が磁気カードだったときは、通勤定期かパスネットで入場して、通勤定期か通勤定期+パスネットで出場すれば良かった。注意不足がちな私も間違えないくらい単純だった。溜池山王駅の改札に磁気カードを一枚しか受け付けない自動改札機ばかり並んでいるのを見て舌打ちするくらい二枚受け付けできる自動改札機を愛用していた。

だが、PASMO定期ホルダーになってみると厄介だ。確かに定期の区間内ならタッチ&ゴーできる。自宅からオフィスまでのコースレコードを塗り替えることも可能だ。だが、定期で入場して定期+パスネット(またはSUICAイオカード)で出場、パスネットで入場して定期+パスネットで出場することができない。多分、自動清算機では清算できると思うのだが、三軒茶屋のようにほぼ常時清算機前に行列ができる駅のユーザにとっては面倒すぎる。

このような面倒を避けたければ、PASMO定期にチャージすればよいだけなのだが、そうするとSUICAとパスネットの残高が一向に減らないということになる。

SUICAの方はスイッピグッズの懸賞のために買い物にせっせと使うからいいんだけどね。

Mar 25, 2007

Re: Desktop virtualization tools vie for position (@InfoWorld)

Desktop virtualization tools vie for position | InfoWorld | Review | 2007-03-22 | By Randall C. Kennedy

WindowsをホストOSとして利用する仮想化ソフトウェア群の比較をしている記事。InnoTek VirtualBox 1.3、Microsoft Virtual PC 2007、Parallels Workstation for Windows 2.2、VMware Workstation 6.0 Beta 3が比較してある。

デスクトップ仮想化製品の性能比較という、消費者にとって関心が高い話題を取り上げているという点で良記事ではあるのだが、問題点が2つある。一つはVMware Workstation 6.0 Beta 3のベンチマークスコアが掲載されているということ。デバッグコードを含むベンチマークスコアはまったく当てにならないし、他と比較する意味もない。というか、EULAではベンチマーク結果をパブリッシュすることはVMware社のapproveなしに行えないはずなのに、VMwareはこのベンチマーク結果をapproveしたのだろうか。とてもそうは思えない。

もう一つは、Parallels Workstation for Windowsに関して、

Employing a lightweight hypervisor — a feature unique in this market segment — Parallels Workstation boasts impressive performance numbers for virtualized Windows and Linux desktops.

と書いてあること。Parallels Workstationが実現しているのは、VMware WorkstationやMicrosoft Virtual PCと同様にホストOS上で動作するVMMであって、一般的にHypervisorと呼ばれているベアメタル上で動作するVMMではない。

こういう誤解が生じるのには実はParallels社自体に原因がある。Parallels Workstationの製品ページ(Virtual pc, virtual machine and multiple operating system solutions by Parallels, Inc.)に行くと、

The World's First Hypervisor-powered Virtual PC Solution

とか

Parallels Workstation is the first desktop virtualization solution to include a lightweight hypervisor that directly controls some of the host computer's hardware resources.

とか謳い文句が書いてあり、これを文字面どおり解釈すればInfoWorldの記事にあるような誤解が生じても仕方がない(実際にParallelsが成し遂げたのは「VT-x/AMD-Vを使った、ホストOS上で動作するVMMを、世界で始めて製品化した」ということだと思われる)。しかし、Parallelsは巧妙に「Hypervisor-powered」や「include a lightweight hypervisor」という表現を採っていて「(Bare-metal) Hypervisor-based」という表現は避けている。よく読めば嘘はついていないけど明らかに紛らわしい。Parallels社は、意図的に顧客と記者を誤解させることで製品の優位性を主張する一方で、まともに技術が分かる人には胡散臭い会社だと断定されかねない愚を冒している。実際InfoWorldの記者は誤解したし、私は十分胡散臭いと感じている。

このようなつまらない誤解が生じるのなら、もうHypervisorという言葉は使うべきではない、あるいは定義していから使うべきだ。間違いなくテクニカルなドキュメントにおいては。

とか書いていたら、VMwareの中の人が噛み付いていた。

VMTN Blog

あとこれもおんなじ。

笠原一輝のユビキタス情報局

ある意味良記事ではあるのだが、ベータ版でベンチマークをとっている。しかも、記事中でベータ版であることにまったく言及していない(直前の記事で言及しているというのは言い訳にならない)。BIOSでVT-xのOn/Offを切り替えているだけで、VMMがVT-xを使っているかどうかをどのように観測あるいは制御しているのかについて言及していないので、何を測定して比較しているのかまったく分からない。ベンチマークは再現性のある方法で行わなければ意味がない。

こうした結果について仮想化技術に詳しいエンジニアなどに取材したところ、一様に「現在の仮想化ソフトウェアでの新命令セットのサポートは始まったばかりで、最適化が進んでいないのが現状。今後最初から仮想化命令をサポートした仮想化ソフトウェアが登場すれば、性能でも大きな差がでるはず」と指摘している。つまり、今のところ初期段階で、AMD-VなりVT-xを生かすところまでいっていないというのだ。実際、VMware Workstationの結果からもわかるように、優秀な仮想化ソフトウェアはAMD-V/VT-xがなくてもホストOSにかなり近い処理能力を実現しており、ONにすることでそれらとの整合性がうまくとれないということなのかもしれない。
ゲストOSがCPU命令を実行する際のオーバーヘッドを軽減するという仮想化命令のコンセプトを考えれば、ソフトウェア側のサポートが進めばメリットが出てくるのは明らかだが、今の段階ではまだまだ初期段階で、なかなかメリットを見いだしにくい、そういうことだろう。もっとも、こうした例は、新しい命令セットなどが登場したときにはよくあることで、今後ソフトウェア側のサポートがより進めば徐々に解決されていくのではないだろうか。

もう何が言いたいのかさっぱり分からない。よく分からないなら「分からない」と書くべき。確証もない仄めかしを読まされて真に受けてしまう読者への配慮が足りない(そういうものはチラシの裏にでも書いておくべきだ)。また、パブリッシュされているもの、VMTN Blogくらいは読んでほしいね。

Mar 22, 2007

Cybozu2iCal 0.12公開

サイボウズオフィス6のカレンダーアイテムを取得して、iCalendar形式に変換するスクリプト、Cybozu2iCalを久々に更新しました。

Cybozu2ICal - ogawa - Google Code

0.10でサイボウズカレンダーの反復イベントに対応したつもりだったのですが、どうも不十分だったようでいくつかフィードバックをいただきました。遅くなりましたが、0.12ではそれらの対策をしたつもりなのでご確認いただければと思います。

RFC2445: Internet Calendaring and Scheduling Core Object Specification (iCalendar)を読むと、反復条件(RRULE)では、終了日時UNTILは「日付」または「UTC時刻」で指定することになっています。0.11までは、すべての反復イベントに対してUNTILに「日付」のみを指定していましたが、0.12ではなるべく標準に即すべく、時刻指定のある反復イベントのUNTILはUTC時刻で指定し、時刻指定のない反復イベントのUNTILは日付で指定するようにしました。

また、この修正をしてもGoogle Calendarには時刻指定のない反復イベントの終了日時が一日早まってしまうバグがある様子です。私の勘違いなのかもしれませんが。

2007年3月21日から25日までの終日イベントは以下のように指定できるはずです。

DTSTART;VALUE=DATE:20070321
DTEND;VALUE=DATE:20070322
RRULE:FREQ=DAILY;UNTIL=20070325

しかし、Google Calendarでは24日までのイベントとして認識されていまいます。なんとなく、UNTILの日付(20070325)を時刻(20070325T000000)として解釈しているような気がします。

ところが、こんな具合に、

DTSTART;VALUE=DATE:20070321
DTEND;VALUE=DATE:20070322
RRULE:FREQ=DAILY;UNTIL=20070325;WKST=SU

RRULEにWKST=SUオプション(週の開始を「日曜」とするオプション)を指定すると、Google Calendarの問題が回避できることを発見したので、cybozu2ical 0.12はこの回避策を採用しています。

関連:
Ogawa::Buzz: Cybozu2iCal 0.10公開
Ogawa::Buzz: Cybozu Office 6のカレンダーを Google Calendarで表示する

Mar 16, 2007

水に流してもらいたい

声に出して読みたい戯言。

中日新聞ホームページへようこそ

<東京カフェ>水に流せない
農林水産省が、海外の“正統”な日本料理店の認証制度を検討しているという。独自に解釈されたおかしな料理を、和食と名乗られては困るということなのだろうが、外交上の相互主義の立場から考えると、大きな問題をはらんでいる。
レバニラいためや、野菜いため、ギョーザが定番の大衆中華料理店。もし、これに中国政府がクレームをつけたら、外食産業はパニックとなるに違いない。スパゲティ・ナポリタンは論を待たず。独特の食文化で知られる名古屋に行ってみれば、スパゲティ・「イタリアン」とか「台湾ラーメン」だとか、もう、突っ込みどころは満載。
つまり、海外の食文化を換骨奪胎して、オリジナルと離れたメニューを作ってきたのは日本だ。自国の料理にだけ注文をつけるのは、少し身勝手な気がする。
しかも、認証制度の旗を振る松岡利勝農相は「水道水を飲んでいる人は、ほとんどいない」と発言。水道水をおいしく飲めるのが日本の自慢だし、そもそも、きれいな水を生む森林を涵養(かんよう)するのは、農相の役目だ。食文化を論じながら、食の基本となる水を軽視する態度は、いかがなものか。不透明な事務所費問題とあわせ、水に流せない。 (浅田晃弘)

ちょっと声に出して人に聞かせてあげたい(笑)。私が強いて言うとすれば、「名古屋をバカにするな、バカ飯文化は名古屋だけのものじゃないぞ」ということくらいである(笑)。

ついでに野暮は承知で言わせてもらうと(このエントリーはその野暮が目的なのだが)、私はその認証制度だか認定制度だかにはまったく反対である。

明らかに不要である。この認定制度がすぐに打ち切りになって忘れられてしまうことはあまりにも目に見えている。なぜならそれはこの制度に費用対効果がほとんど、あるいはまったく期待できないからだ。

この制度の対象となるレストランは、調査予算の制約上、高級な部類に入るものに限られる。制度によって損害を被るものもまた高級な部類に入る店であって、非認定であることが死活問題となり得る店である。制度に実際に「効果(らしきもの)」を求めるなら調査対象にこのようなクラスのインスタンスを選ばなくてはならない。言うまでもなく制度の信頼性を損なうには「日本食と称してろくでもない料理を出している」超有名店が一例あれば十分だからである。

しかし、そう選択したとしてそのような(認定・非認定の)高級店は海外の日本食レストランのいったい何パーセントを占めるだろうか。1%にも満たないのではないか。白いベニハナか黒いペニパナか区別できるだけで残りのほとんどのレストランは調査対象にもならないのでは、制度による効果など何もないに等しい。あるいは調査の信頼度を下げて調査結果を濫造・捏造すれば(この店はオーナーが日系3世だからオッケーとか、10年前の地球の歩き方に出てたからオッケーとか)パーセンテージを上げることはできる。その場合も全体として得られる情報量はほとんど変わらない。

こんなことは明らかである。なのに、制度に支持や理解を示す人がネット上にあまりに多いのには正直クラクラしてくる。Reputation Systemは、近頃かますびしいCGM (Consumer Generated Media)とやらの得意分野なのではなかったのか。

食のナショナリズムだという海外からの指摘が的外れなのは分かっている。記者の功名心や部数・視聴率競争が事実を捻じ曲げるのはよくあることで、正直なところ海外での受け止め方がどうなのかは分からない(というよりあるメディアであまりに極端な意見が述べられた場合、その話題は多数には普通にスルーされているのだと考えるのが正着打に思える)。むしろ重要なのは、国内で政策として国民に理解できるように説明することと、全世界の日本食レストランの経営者・従業員・利用客に誤解なく理解できるように説明することとはまったく異なるということ。陳腐な言い方をすれば相互理解が必要なのだが、とりわけcultureかracismか峻別し難い事柄については、ほとんど不可能と言ってよいほど難しい。

そうでなくても日本人はracismに鈍感過ぎる。つい先日も全日空の不時着陸の映像をアップロードしたYouTubeのページで事故の多いボンバルディア機を揶揄するつもりでCanadian Qualityだと発言してカナダ人全体を馬鹿したために叩かれていた人がいたと記憶しているが、そういう迂闊さは政治家や新聞記者だけの専売特許ではなく一握りのネット上の日本人にも共有されているようだ、とこれは蛇足。まあなんだ、大型機体より中小型機体の方が故障率・事故率が高いのは当たり前なわけで、そういう前提を無視してボンバルさんだけ頭ごなしに叱ってもね、という話もある。いやこれも蛇足。

まあ私は不可能だと思っているわけだけど。

昨年の時点で海外日本食レストラン認証有識者会議の設置についてとか言っているのでもうすでに今年度と来年度の会議費分くらいは予算がついていて引き返せないのは分かっている。だからすぐに止めろとは言わない。なるべく早くひっそりと水に流してほしいと思う。

また、日本人がアメリカ料理を何となく理解した気になっているのはマクドナルドやKFCやミスドのおかげなのだから、正しい日本食を手っ取り早く広めたければ外食チェーンをテコ入れすればいいだけだという別の考え方もできる。私はそれでいいんじゃないかと思う。そういう保護主義的な施策の受けがどうしても悪いようだったら、海外展開する外食チェーンに益体もない認定シールでも配ればいい。野暮の極みと言われようとも。

Mar 12, 2007

VMwareのFC6ゲストのCPU負荷が高い件について。

VMware Server 1.0.xを使っていて気がついたのだが、ゲストとして走らせるOSによってえらくホストのCPU Usageが違うようだ。ユーザープロセスをなるべく動作させない状態でホスト上のtopコマンドで観察していると、Ubuntu 6.10 ServerのCPU Usageは1%未満、Fedora Core 6は5%程度になる。ラフに見積もってFedora Coreの方が5倍以上負荷が高いことになる。ちょっと気になったので調べてみた。

結論から言うと、Ubuntu 6.10 Serverではカーネルコンパイル時のCONFIG_HZの値が100、Fedora Core 6では1000になっている。さらに、kernel.orgからダウンロードしてきたカーネルソースを読んでみると、デフォルトは250になっていて100, 250, 1000の3種類から選べるようになっていた。ざらっとソースを眺めてみたところによると、結局この値はタイマー割り込みの頻度の多寡を制御する結果をもたらすことになるようだ(OleのTalkでトラップが50kHz以上の頻度で発生する、と言っていた理由が今更ながら分かった)。この値が大きいほど割り込み頻度が高まるのでデスクトップシステムに適合するし、小さいほどユーザコードを効率良く実行してくれるのでサーバシステムに適合する。だから、デスクトップパッケージであるFedora Coreには1000、サーバパッケージであるUbuntu Serverには100が設定されているのだろう。

一方でVMware ServerではネイティブOSに比べてコンテキストスイッチとカーネルモードの実行オーバーヘッドが大きい。つまりは、割り込み頻度が高ければ高いほど(ユーザモードのワークロードに関わらず)VMwareのソフトウェアオーバーヘッドはより大きくなり、CPU Usageの差となって現れるのだろう。

何となく原因にあたりが付いたところで、この値を変更できないものかと思った。ソースを斜め読みした限りではブート時のカーネルオプションでは制御できない。タイマーはごくクリティカルな処理なのでカーネル変数を取得して計算するよりはCONFIG_HZの値をインライン展開しておきたいと考えるのはカーネル設計者としては当然のことだ。マルチバージョニングする手もあるけどね。

しかたがないのでFC6のカーネルをCONFIG_HZ=250で再構築してみて確認してみることにした(Ubuntu Desktopは250だから250でいいじゃんかという発想)。Linuxのカーネルなんてかれこれ10年はmakeしていないのでいろいろ試行錯誤した結果、以下のような手順でOKらしいことが分かった。

まず、root権限でいろいろ入れておく。

# yum install yum-utils rpmdevtools unidef

次にユーザ権限でビルドするための環境を作る。

$ cd ~
$ rpmdev-setuptree
$ rpm -Uvh http://ftp.riken.jp/Linux/fedora/core/updates/6/SRPMS/kernel-2.6.19-1.2911.6.5.fc6.src.rpm
$ cd ~/rpmbuild/SPECS
$ rpmbuild -bp --target `uname -m` kernel-2.6.spec
$ cd ~/rpmbuild/BUILD/kernel-2.6.19/linux-2.6.19.x86_64
$ cp configs/kernel-2.6.19-x86_64.config .config

次に.configを編集する。make menuconfigして編集してもいいが面倒くさいのでviを使って変更すればよい。

@@ -190,9 +189,9 @@
 CONFIG_CC_STACKPROTECTOR=y
 # CONFIG_CC_STACKPROTECTOR_ALL is not set
 # CONFIG_HZ_100 is not set
-# CONFIG_HZ_250 is not set
-CONFIG_HZ_1000=y
-CONFIG_HZ=1000
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
 CONFIG_REORDER=y
 CONFIG_K8_NB=y
 CONFIG_GENERIC_HARDIRQS=y

Makefileの先頭付近のEXTRAVERSIONの定義を変更しておく。変更しておかないとuname -rが2.6.19-prepとかいう名前になってどのバージョンの何のカーネルか分からなくなる。

EXTRAVERSION = -1.2911.6.5.fc6-250hz

makeして、

$ make bzImage && make modules

root権限でインストールして再起動。

# env INSTALL_MOD_STRIP=1 make modules_install
# installkernel 2.6.19-1.2911.6.5.fc6-250hz arch/x86_64/boot/bzImage System.map
# reboot

あとはgrubのメニューで新規に追加されたカーネルをロードする。問題なければあとで/boot/grub/grub.confのdefaultの値を適当に変更しておくとよい。

結果はというと、5%くらいあったCPU Usageが1~2%くらいまで下がった。時計が遅れるとかいった問題が起きていないところを見るとおそらく問題ないのだろう。というわけで実験終了。

Mar 7, 2007

SLES 10 + OCFS 2 + Xen 3.0

たまには突っ込んでおいた方がよいと思った。

SUSE Linux 10.0でXen 3.0を用いユーティリティコンピューティング環境を実現
SUSE Linux Enterprise Server 10ライブマイグレーション環境構築ガイド

冒頭の図は、ストレージサーバがiSCSI targetになり、Xen Dom0がiSCSI initiatorになってストレージ上にXen DomUイメージを格納する、という状態を説明している。

...いるのだが、本文をどんどん読んでいくと、ストレージサーバがiSCSI target兼initiatorとなり、ストレージサーバでiSCSIデバイスとして認識したLUNにパーティションを切ってmkfsした上で、OCFS2 (Oracle Cluster File System 2)を使ってストレージサーバとXen Dom0の間で共有するという話になっている。

Xenホスト間でDomU VMのモビリティが実現できるのは事実だし、キャッシュコヒーレンスのためにばんばんメッセージを交換するNFSに比べてパフォーマンスがいいのは事実なんだろうけど、iSCSIは一ミリも関係ないのでは?

すっとぼけた話だと思った。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com