Hatena::Group::Virtualization::takaochan RSSフィード

日記はこちら
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 11 |

2006/08/29 (火)

[]統合型からモジュール型に? 統合型からモジュール型に? - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - 統合型からモジュール型に? - Hatena::Group::Virtualization::takaochan

Windows VistaおよびLonghornの開発におけるMicrosoftの苦戦を見ていると、たしかに現行のままの形でWindowsを進化させていくことは非常に難しいだろう。

ガートナーでは、Windowsアーキテクチャは将来、ハードウェアによる仮想化と組み合わせたモジュールアーキテクチャへの移行を余儀なくされると予測している。ガートナーのアナリストである、ブライアン・ガメッジ氏、マイケルシルバー氏、デビッドミッチェルスミス氏の3氏は、「現在Windowsの統合型アーキテクチャのままでは、企業ユーザーにとってもマイクロソフトにとっても将来にわたって維持し続けることは難しい」と口をそろえる。

http://www.computerworld.jp/topics/Vtl/47490.html

CPUOSが共に仮想化をサポートするようになっていっている状況で、どこまでMicrosoftが自社でフォローし、どこの部分をCPUやその他の仮想化技術などにまかせてしまうのか。VMware ESX Serverに対抗していくためにWindows無駄な贅肉をそぎ落とした仮想化ファームとしての仕組みもWindowsベースに考えていくのであれば、Windowsモジュール化は必要な工程だろう。

Vista-Longhornに続く次世代Windowsの構想をMicrosoftがどう描いているのか。

それはVista-Longhorn以上にMicrosoft未来を大きく左右する問題だ。

[]Live migration Live migration - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - Live migration - Hatena::Group::Virtualization::takaochan

XenLive migration機能があるというのはあまりよく理解していなかった。これってXenEnterpriseだけじゃなくてXen標準の機能なのだろうか?

他のプラットフォームの仮想化ソリューションがあまり備えていないXenの機能には,このほか,Live migrationがある。これはシステムを稼働させたま仮想マシンを別の物理マシンに移動する機能だ。VMwareのVMotionに相当する機能だが,オープンソース技術を使って,安価に構築できる。移動元と移動先のマシンSANストレージエリアネットワーク)やiSCSIなどの共有ディスクで接続しておき実現する。

http://itpro.nikkeibp.co.jp/article/NEWS/20060828/246505/?ST=oss

もちろん、SANなどの共有ストレージを必要とするのでおいそれと簡単安価には実現できないだろうが。

まず近い将来にXen 3.0をより安定化する必要がある。その次にEnterprise市場向けに,レポーティングや統計といった機能を追加したいと考えている。長期的には,本当に動的に仮想環境を作成したり移行したりできるようにしつつ,より高度な自動化ができるようにしていきたい。

VMwareXenWindowsLinuxのような戦いになるのだろうか?

いずれにしろ、Xenの行方は注視していきたい。

2006/08/26 (土)

[]XenEnterprise 1.0 XenEnterprise 1.0 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - XenEnterprise 1.0 - Hatena::Group::Virtualization::takaochan

XenSourceがXenEnterprise 1.0がリリースされた。

最大16way/32コアのIntel x86プロセッサに対応、ライセンスも2/4/8/16/32単位で発行される。2ソケット/サポートなしの最小構成価格は、同社オンライン価格で488米ドル

http://journal.mycom.co.jp/news/2006/08/25/341.html

まずはRHEL4(Update1/3 Update6)以降およびSLES9 SP2以降のみだが、順次拡大されていくだろう。Guest OSとしてWindowsサポートされている。

XenEnterprise 1.0は、オープンソースの「Xen 3.0」をベースに開発された企業向け仮想化ソフトXen 3.0の基本機能のほか、既存の物理システム仮想マシン化する「P2V tools」、ゲストOSホスティングを可能にする「Xen Hypervisor」、ゲスト仮想サーバを統括管理する「Multi-Host Xen Management」など、企業向けの管理ツールが収録されている。

XenEnterpriseのリリースによって、VMwareとの争いはより激しくなるだろう。"P2V tools"や"Xen Hypervisor"、"Multi-Host Xen Management"などの管理ツールがどれだけ企業ニーズに答える製品になっていくか次第では、VMwareにとっても強敵になるかもしれない。

2006/08/25 (金) このエントリーを含むブックマーク

[Microsoft][Xen]MicrosoftとXenSourceの連携強化

MicrosoftはどうやらXenとの連携にかなり本気なようだ。

Linux向けの仮想化ソリューションプロバイダーXenSourceとMicrosoftは、パートナーシップを拡大し、提供が予定されているハイパーバイザーベースWindows仮想化テクノロジーを利用して、Xen対応LinuxゲストOSとして実行した場合に、このゲストOSパフォーマンスを高めることができるソフトウェアの開発を協力して進めていくことで合意した(このWindows仮想化テクノロジーは、2007年中に提供が予定されているWindows Longhorn Serverのリリース日から6カ月以内にリリースされる予定である)。

http://www.itmedia.co.jp/enterprise/articles/0608/24/news007.html

XenMicrosoftからVM用のファイルフォーマットライセンスを受け、MicrosoftXen向けのVMを動作させることが出来るAPI変換レイヤーを手に入れる。

MicrosoftとしてはLinuxベースになってしまっている環境ではXenを使われることは仕方がないことと考え、Xenと連携することによってXen用のVMをそのままWindows Longhorn Serverに持ってきても動作させることが出来るようにすることでLinuxからWindowsに乗り換える敷居を低くしようという戦略なのだろう。

…というか、対VMware陣営といったところだろうか。

カーネル側の対応が必要なためにCPUの仮想化機能を使用しないとWindowsの仮想化に対応できなかったXenWindows呪縛があるがためにLinuxに対応できなかったMicrosoftが相互の欠点を補い合う形で連携する。うまくいけばそれなりにVMwareの対抗馬になるかもしれない。

2006/08/24 (木)

[][]container container - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - container - Hatena::Group::Virtualization::takaochan

"仮想化"というアプローチがどれだけ浸透していくのか、まだ見えていない部分は多いが、少なくとも使おうとすれば使える環境は次第に整いつつある。そして現時点では、1つのOSを複数のOSであるかのように見せかけるcontainerにまで仮想化を広げつつあり、OpenVZ[VirtuozzoのOpen版]やVserverといったcontainerを実現するアプリケーション日進月歩進歩している。

OSレベルの仮想化を行うVMwareやVirtual Server, Xenのアプローチはいわゆるhypervisor型だが、container型は単一のOSを複数OSであるかのように動作させるため、オーバヘッドやリソースの消費量が少なく、よりハイパフォーマンスが期待できる点が利点だ。

Red Hatの最高技術責任者CTO)であるBrian Stevens氏も、LinuxWorld Conference and Expoでの取材に答え、containerについて「われわれも実現する日が来ることを望んでいる」と述べている。Red Hatでは、OpenVZとVserverのどちらを使用するかについて、まだ決定に至っていないという。

NovellSUSEにはLinuxの高度な新機能がいち早く搭載されるとの定評がある。この評判を維持したいと考える同社はcontainerの導入にとりわけ積極的で、OpenVZの「SLES 10 Service Pack 1(SLES 10 SP1)」への搭載を検討している。「今は、OpenVZをSLES 10 SP1に搭載可能か、評価をしている段階だ」と、NovellLinux製品管理担当バイスプレジデント、Holger Dyroff氏は述べている。

http://japan.zdnet.com/news/software/story/0,2000056195,20210128,00.htm

Xenが搭載されたからといって誰もが使い始めるわけではないだろうが、誰もが使おうと思えば使える環境を持つようになることの意味は大きい。containerについても同様のことがいえるだろう。

デファクトスタンダードの仮想化管理ツールが出てくれば、オープンソースとしてVMwareに匹敵するツールが生み出される可能性もある(少なくとも大多数のユーザが必要十分と感じるレベルのツール)。

「container式の仮想化は、個々のアプリケーションに異なるOSイメージを必要としない場合には素晴らしく機能する」と、Crosby氏は言う。このような状況は良くあることで、例えば、SWsoftのVirtuozzo--OpenVZの兄的存在--が広く使われているウェブサイトホスティング企業などがそのケースに該当する。

仮想化はあくまでも選択肢の1つだ。containerが非常に有用な環境もあれば、そうではない環境もある。

hypervisorよりもcontainerは制約が多い分、ターゲットとなりうるパイは小さいだろうが、それでも十分な市場が生み出される可能性はある。パフォーマンスリソース、そしてなによりも使い方を考えた上で仮想化の方式も選択する時代がすぐにやってきそうな気がする。

2006/08/22 (火)

[]Xen Enterprise Xen Enterprise - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - Xen Enterprise - Hatena::Group::Virtualization::takaochan

XenSourceの最高経営責任者CEO)Peter Levine氏は米国時間8月17日、来週から同社の「XenEnterprise」を販売することを明らかにした。

http://japan.zdnet.com/news/software/story/0,2000056195,20204987,00.htm

VMwareシェアを広げているのは仮想化製品のなかで比較的扱いやす管理ツールを備えているからだと思うわけで、そういった面でXenがどこまで迫れるのか、興味がある。

XenEnterpriseでは、Windowsを稼働させることも可能になるという。変更が加えられていないOSを動作させられるのは、これまで VMwareソフトウェア専売特許だったが、IntelおよびAMDの新たなサーバ用プロセッサには、そうしたOSXen上でも同様に稼働させる機能が搭載されている。

結局CPUの仮想化技術を踏まえたWindowsなどへの対応となるが、Xenの準仮想化による実行スピードの優位点がどの程度あるのか、注目していきたい。

[]HP-UXにおける仮想化技術 HP-UXにおける仮想化技術 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - HP-UXにおける仮想化技術 - Hatena::Group::Virtualization::takaochan

IBMAIXHPHP-UXなど、UNIXの世界の仮想化技術はIAサーバの一歩も二歩も先に進んでおり、今後、IAサーバにおける仮想化技術がどう進化していくのかの指標として重要だと思う。もちろん、ハードソフトを全て単一ベンダーで提供するUNIXシステムだからこそ実現できている部分もあるのだが、x86 CPUでもCPUが仮想化技術サポートするなど、だんだん近づいてきているとは思うので、いずれUNIXで実現されている仮想化技術をIAサーバにおける仮想化でも取り込んでいくことになるのではないだろうか。

<ハードウェアレベル>

<ソフトウェアレベル>

<OS内>

http://www.atmarkit.co.jp/ad/hp/hpux0607/02.html

[]2006/8 Update 2006/8 Update - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - 2006/8 Update - Hatena::Group::Virtualization::takaochan

[]仮想化に対する取り組み例 仮想化に対する取り組み例 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - 仮想化に対する取り組み例 - Hatena::Group::Virtualization::takaochan

ESX Serverは非常に有用な製品だが、それは正しい使い方をしてこそだ。そこを理解したうえで、それでもVMにするメリットがあると判断したのであれば、x86サーバVM化に踏み出すべきだと思う。

ネットの判断は正しかったと言える。現在、同社は数十台の物理サーバ上で400以上もの仮想マシン運用しているからだ。

http://www.computerworld.jp/news/trd/46809.html

「われわれは、新しい技術だといって決して安易に飛びついたわけではない。きちんとした手順を踏んで導入の検討を進め、どのようなワークロードが適しているか、あるいは適していないかについて継続的に検討した」

そもそもVMにまでしてそのサーバを残す必要があるのか、そしてそのサーバVMとして稼動させることは可能か…焦ってVM移行してもあまりいいことはない。じっくりとプランニングし、ある程度のゆとりを持たせながらVM移行していくことがよいだろう。

ネットは2台の物理マシン上で6つ程度の仮想マシン運用することから取り組みを開始したが、これらの4プロセッサ・サーバ上の仮想ワークロードの数は数カ月で約40にまで増加したという。

VMに対して適切なリソースを割り当てれば40VM程度をESX Server上で動作させることは問題ないだろう。多くの場合、リソースで最も問題になるのはメモリ量だろう。CPUリソースやNetworkトラフィックボトルネックになるようなパターンはあまりない。

ハードウェアの性能が進歩するペースは、アプリケーションの要求が拡大するペースをはるかに上回っている。われわれもVMwareを使っていなかったら、もっと大量の物理マシンを購入し、それらの使用率は当時よりさらに低くなってしまっていたはずだ。そこに仮想化のメリットがある。物理サーバを買わずに済んでいるため、われわれは費用を抑えることができている」

ハードウェアシステムを分離できることが仮想化の最大のメリットである。ただし、集約するということはそれだけの信頼性のあるハードウェア上に構築する必要があるわけで、そのバランスを的確に保つことが重要だ。

2006/08/20 (日)

[]ESX HCL ESX HCL - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - ESX HCL - Hatena::Group::Virtualization::takaochan

HCLを追いかけるのは大変だな…。ま、必要なとき必要なときに必ず確認するようにするしかないですな。

2006/08/10 (木)

takaochan20060810

[]VMware Workstationによる仮想化入門 VMware Workstationによる仮想化入門 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - VMware Workstationによる仮想化入門 - Hatena::Group::Virtualization::takaochan

第4回:仮想環境の設定をカスタマイズ

http://itpro.nikkeibp.co.jp/article/COLUMN/20060703/242354/?ST=newtech

前回に続き、後で書く(^_^;)。

[]Good-bye VirtualPC for Mac. Good-bye VirtualPC for Mac. - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - Good-bye VirtualPC for Mac. - Hatena::Group::Virtualization::takaochan

Microsoftが、IntelベースMac用「Virtual PC」の開発を中止する。

http://japan.cnet.com/news/ent/story/0,2000056022,20194607,00.htm

VMwareMacにおける仮想化市場に参入し、Microsoftが撤退する…。なかなか象徴的な日になった。

Windows版、Linux版に続き、Mac版のWorkStationを投入すればVMwareはかなりのアドバンテージを得られるだろう。事実上デファクトスタンダードになれるかもしれない。

きっと近い将来、多くのユーザが自分のPCで仮想化環境を"あたりまえに"使うようになる日が来る。どのベースOSを選択しても仮想化環境を引っ越せば継続してツールを使い続けることが出来る。そのメリットは意外と大きいだろう。

[]IntelMac w/VMware IntelMac w/VMware - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - IntelMac w/VMware - Hatena::Group::Virtualization::takaochan

WWDC2006にあわせ、VMwareMacVMware WorkStationの発表を行った。

http://www.vmware.com/vmtn/blog/console/2006/08/#macintosh

長らくMacサポートの動きを見せなかった同社だが、新製品では、通称「Intel Mac」と呼ばれるインテル製プロセッサを搭載したMacコンピュータ上で、Mac OS Xと並行して、WindowsLinuxNetWareSolarisなどのx86アーキテクチャ対応OS仮想マシン上で稼働させることが可能となっている。

http://www.computerworld.jp/topics/Vtl/45944.html

"動きを見せなかった"とあるが、動きたくてもPowerプロセッサを採用している以上、動けなかったというのが正直なところだろう。Powerの上でWindowsLinuxなどを動作させるためにはどうしてもCPUの"エミューれーション"が必要になる。それではエミュレータであってVMwareがめざす仮想化環境にはなり得ない。

デモ画面も公開されており、なかなかそそられる。

http://www.computerworld.jp/images/_main/200608/459441.jpg

Parallelsでもかなりグラッときたが、VMwareの仮想化環境Mac向けに正式リリースされるとなるとこれはかなり考えてしまうなぁ…。

とりあえず評価版エントリーに申し込んでみてしまったりしてみよう。IntelMacまだ持っていないけど(^_^;)。

http://vmware.rsc02.net/servlet/campaignrespondent?_ID_=vmwi.1756

2006/08/09 (水)

[]仮想化とライセンス 仮想化とライセンス - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - 仮想化とライセンス - Hatena::Group::Virtualization::takaochan

非常にややこしいのが現状。

調査会社のガートナーのアナリストアルビン・パーク氏は、「プロセッサ単位、指定デバイス単位ユーザー単位など、ライセンス方式にはさまざまな分類が存在する。しかし、仮想化ライセンスをどうするのかという問題の答えはまだない」と指摘する。

http://techtarget.itmedia.co.jp/tt/news/0608/08/news01.html

ハードウェアソフトウェアの「完全な」結びつきを仮想化は断ち切ってしまうだけに簡単に答えは出なさそうだ。CPUライセンスの場合、数えるCPU数はホストになっているマシンCPU数なのか?それともVMで「認識する」CPU数なのか? デバイス単位の場合、「デバイス」とはどのレベルの「デバイス」を指すのか?

現状、ソフトウェアによって対応はまちまちであり、ライセンス問題は仮想化導入を「ややこしい」ものにする大きな要因になっている。

Windows Server 2003 R2」のエンタープライズバージョンリリースで、仮想化ライセンスの問題に取り組んだ。R2では、ユーザーは追加料金を支払わなくても、1台の物理サーバ上で最大4つの仮想インスタンスを実行することができる。

ライセンスをゆるくすればシェアを拡大することが出来るかもしれないが、利益は減少する。このあたりが仮想化インフラ競争を体力勝負にしている理由かもしれない。

IBMの幹部によると、同社は「IBM Tivoli Usage and Accounting Manager」という利用状況追跡ソフトウェアリリースする予定だ。この製品は、仮想化されたサーバ上で使用される処理パワーの量に基づいてソフトウェアの利用料金を算出することを可能にする。

えぐそう…。水道や電気とちがって様々なリソースから仮想インフラは成り立っているのでどう算出するかは簡単には解決することはできないだろう。

コスト削減対策として仮想化を利用しようとしているIT部門にとって、ソフトウェアコストの大幅な増加という事態を招くことになる

たしかに調子に乗って際限なしにVMを作るのは考えものだ。簡単に追加できるからこそ、慎重さが求められる。

おそらく次期仮想インフラにはリソース消費量の計算ツールもオプションとして搭載されてくるのではないかと思う。

2006/08/06 (日)

[]VMware Player用イメージ各種とりそろえております VMware Player用イメージ各種とりそろえております - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - VMware Player用イメージ各種とりそろえております - Hatena::Group::Virtualization::takaochan

気軽にVMを使ってみるには便利なVMware Playerですが、さて、インストールをした配意けど肝心のVMイメージは?という方向けに、VMwareウェブサイトで色々なOSイメージが配布(正確にはBitTorrentを使用した共有)されています。ダウンロードしてVMware Playerで起動すればすぐ使える。インスタントみたいですな。

http://www.vmware.com/vmtn/appliances/directory/

2006/08/04 (金)

[]ESX Server 2.5.3 Upgrade Patch 3 ESX Server 2.5.3 Upgrade Patch 3 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - ESX Server 2.5.3 Upgrade Patch 3 - Hatena::Group::Virtualization::takaochan

ESX Server 2.5.3 Upgrade Patch 3 enables support for Red Hat Enterprise Linux 4.0 Update 3 guest operating systems and the IBM DS4700 Fiber Channel storage array, and contains bug fixes. ESX Server 2.0.2 Upgrade Patch 1 contains bug fixes.

ESX 2.5.3 Update 3でRHEL4U3とIBM DS4700をサポート、と・・・。

[]ESX 3.0 HCL ESX 3.0 HCL - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - ESX 3.0 HCL - Hatena::Group::Virtualization::takaochan

[]Memo : Blade Networking Options Memo : Blade Networking Options - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - Memo : Blade Networking Options - Hatena::Group::Virtualization::takaochan

    • "A "best practices" installation of ESX calls for at least 3 network adapters: one for the COS and two redundant VMNICs in a virtual switch for virtual machine use."
    • "The first options is to utilize the virtual machines' virtual switch to also handle the VMotion traffic of the network."
    • "The second available option is utilizing the vmxnet_console driver of ESX to share eth0 and a VMNIC to handle COS and virtual machine traffic while utilizing a dedicated NIC for VMotion."

[][]VMware対応シンクライアント VMware対応シンクライアント - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - VMware対応シンクライアント - Hatena::Group::Virtualization::takaochan

Wyse Technologyは、米VMwareと提携、同社の仮想デスクトップ環境へとスムーズにアクセスするシンクライアントの新ソリューションを発表した。今後のバージョンアップも予定されており、仮想デスクトップ環境を利用して、セキュアなシンクライアント端末からPCレベルのパフォーマンスを実現することを目指す。

http://journal.mycom.co.jp/news/2006/08/03/347.html

シンクライアントを用いてクライアント環境を集中管理できるようにするだけでなく、クライアント環境そのものも仮想化環境上に構築しようという試みはたしかにメリットのあるソリューションだと思う。

いくら集中管理できるようになってもクライアントの台数分のマシンマシン室にあるようではあまり意味がない(もちろんブレード化などで小型化はされて集中管理できるメリットはあるが)。クライアントにとっては自身の環境が「どのような状態で」動作しているかはあまり問題ではないわけで、そう考えればクライアント環境を仮想化してしまうことのデメリットはあまりない。

仮想化することによって可能になっていくメリットも考えられる。サーバーリソースも「同時稼動するクライアント数」をベースに用意すればいいので「必要台数」分のリソースを用意する必要はなくなる。クライアントPC上に置かれてしまっている「最新の最も重要データ」のバックアップにも仮想化クライアント環境であれば色々なバックアップ方法を柔軟に検討できる。

VMware ACEなど、ソフトウェアだけではあまりメリットを打ち出せなかったクライアント環境の仮想化だが、シンクライアントとの組み合わせはなかなか面白いと思う。

2006/08/03 (木)

[]RDM RDM - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - RDM - Hatena::Group::Virtualization::takaochan

メモ

  • Create a raw device mapping
    • <コマンドで行う場合>
    • HBA:0, Target:1, LUN:2 を対象としてRDMを作成
    • vmdkファイルは"Vmfs1"に配置
      • vmkfstools -r vmhba0:1:2 /vmfs/Vmfs1/RDM01.vmdk
    • Configuration Fileに追記する
      • scsi0:0.name = "Vmfs1:RDM01.vmdk"
      • scsi0:0.deviceType = "scsi-passthru-rdm"
    • <MUIで行う場合>
    • ログインrootもしくは管理者ユーザアカウント
    • "Status Monitor"タブにある編集対象のVMを選択
    • ドロップダウンメニューから"Configuration Hardware"を選択
    • "Add Device"を選択
    • "Hard Disk"を選択
    • "System LUN/Disk"を選択
    • "Storage Controller LUN list"から設定対象のLUNを選択
    • "Use Metadata"を選択し、配置場所を選択
    • マッピングファイル名(vmdk)を入力
    • 仮想SCSI番号を選択
    • "Compatibility Mode"で"Physical"を選択
    • "OK"をクリックしてディスク作成完了

[]ESX2.5 "vmkfstools -z"ってなんだ? ESX2.5 "vmkfstools -z"ってなんだ? - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - ESX2.5 "vmkfstools -z"ってなんだ? - Hatena::Group::Virtualization::takaochan

複数のESXサーバ上のVM間で使用する共有ディスクは"vmkfstools -z"で作成する必要があるらしい。

VMware ESX Server 2 運用ガイド』p.369の表の"クラスタ化されたディスクー複数ホストクラスタリング"の欄に「vmkfstools -zで作成される必要があります。」という記述がある。そこにだけ。それ以外なんの説明もなく…。

"z"は小文字。大文字の"Z"を用いる場合は明確で、"--extendfs"と同じ役割を果たす。"vmkfstools -Z vmhba0:1:0:1 vmhba1:1:0:1"のような形で使うと2つのVMFSボリュームをスパンして領域を拡張することが出来る。

対して、小文字"z"を用いる場合についてはあまり情報がないが、manで以下の情報を確認できる。

     -z, --nozero
         create a file with the specified size on the VMFS file system of the
         specified SCSI device.  The size is specified in bytes by default,
         but can be specified in kilobytes, megabytes or gigabytes by adding
         a suffix of 'k', 'm', or 'g' respectively. The '-z' option disables
         a security feature with virtual disks that prevents a virtual machine
         from reading uninitialized sectors. The '-z' option should be used
         for shared virtual disks in a clustering setup.

"The '-z' option disables a security feature with virtual disks that prevents a virtual machine from reading uninitialized sectors."

"-z"オプションを用いることによって初期化されていないセクターVMが読み込むことを防止するセキュリティ機能を無効化する。

"The '-z' option should be used for shared virtual disks in a clustering setup."

"-z"オプションは共有仮想ディスクによるクラスターを構成する際に用いられる。

…この情報は[第10章 クラスタリングの構成]p.363から記述されている"Microsoft Cluster Sererを使用する、異なるESX Serverマシン上の2ノードクラスタ"の項目にもうちょっと大書きされていてもいいのではないだろうか。それともvmdkファイルを使った仮想化は基本的にはやるべきではないことで、VI3からはRDMによるクラスタしか選択できなくなったように、RDMを使う方法でやれということなのだろうか。

ちなみにこの"-z"、manでは出てくるがただ単にvmkfstools打ってリスト出しただけでは出てこない。

[root@esx2test root]# vmkfstools
vmkfstools -b --blocksize #[mMkK]
           -m --commit
           -F --config [public|shared|writable]
           -C --createfs [vmfs1|vmfs2]
           -Z --extendfs extension-SCSIDevice
           -P --querypartitions
           -c --createfile #[gGmMkK]
           -r --maprawdisk raw-SCSIDevice
           -e --exportfile dstFile
           -X --extendfile #[gGmMkK]
           -i --importfile srcFile
           -g --geometry srcFile
           -l --list
           -h --human-readable
           -M --verbosemappings
           -L --lock [reserve|release|reset|lunreset]
           -n --numfiles #
           -R --recover
           -s --scan
           -S --setfsname fsName
           -z --nozero
           -k --createswapfile #[gGmMkK]
           -w --activateswapfile
           -y --deactivateswapfile [swapFileID]
           -T --tovmfs2
        scsiDevice[:file]
[root@esx2test root]#

"VMware ESX Server Advanced Technical Design Guide"にもVMによるClusterは数ページを割いて説明している程度。ただ、押さえるべきポイントはさすがにちゃんと抑えてあり、以下の記述がある。

With the introduction of ESX 2.5, VMware now recommends that you use raw disks ( or at least a raw disk with a Device mapping, which will be explained in a second) for both Physical to Virtual, and Virtual to Virtual clusters. Prior to ESX 2.5, the recoomendation for Virtual to Virtual clusters was to maintain the shared storage a regular VMDK file and not as a raw disk.

ESX 2.5の導入において、VMware現在、Physical to Virtual環境・Virtual to Virtual環境のいずれにおいてもraw disk(もしくはRDM)を使用することを推奨している。2.5以前では、Virtual to VirtualのCluster環境ではraw diskではなく通常のVMDKファイルを用いた共有領域が推奨されていた。

raw diskを使用することの優位点が説明され、で、"Which shared storage should I use ?"。

If you are on 2.5, the answer should be simple. Use raw device, since VMware recommends it. But if you are on 2.5 and need to run 50 Virtual to Virtual clusters, you may begin to have an issue since the number of LUNs you may need to create to support each cluster, in addition to all the storage for the regular VMs themselves, may drive your local storage guy to drink.

もしあなたが2.5を使用しているのであれば、回答は簡単だ。raw deviceを用いるべきである。なぜならば、VMwareがそれを推奨しているからだ。しかし、あなたが2.5を使用しているとしても、50ものVirtual to VirtualのClusterを稼動させるのであれば、あなたは全てのClusterが必要とするだけの数のLUNを作成しなければならないという問題に直面するかもしれない。それに加えて通常のVM自身が使用する領域もあるのだから、あなたのローカルストレージはいっぱいいっぱいになってしまうかもしれない。

If you are going to have a small number of clusters, it's not a bad idea to follow the recommendation and use a raw device mapping. But if you plan to have a number of different Virtual to Virtual clusters, and you see your storage configuration getting more and more complex, it may be a good idea just to use a shared mode VMFS partition and store shared data on it in the form ov VMDK files.

もしあなたが少ない数のClusterを使用しているのであれば、推奨にしたがってRDMを用いることは悪いことではない。しかし、もしあなたが数多くのVirtual to VirtualのClusterを計画しているのであれば、あなたはストレージ設計にかなりの負荷を強いられることなるので、shared modeのVMFS領域を用いて共有データをVMDKファイルとすることはいい考えである。

VI3ではshared modeがなくなったし、基本はやはりraw deviceってことだろう。"vmkfstools -z"なんて使う必要なし!ってことかな。どこにも説明がないのは。

Vmware Esx Server: Advanced Technical Design Guide (Advanced Technical Design Guide Series)
Ron Oglesby Scott Herold
Brianmadden.Com Pub Group (2005/08/30)
売り上げランキング: 117,016

2006/08/02 (水)

[][]Xenにたいする考え方 Xenにたいする考え方 - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - Xenにたいする考え方 - Hatena::Group::Virtualization::takaochan

オープンソースの仮想化ソフトXen」に対する顧客のニーズは「極めて」高く、Novellはすでに同ソフトウェアの出荷を開始しているにも関わらず、Red Hatのある上級幹部は、同ソフトがまだ企業で使用できる段階にはない、と慎重な姿勢を崩していない。

http://japan.cnet.com/news/ent/story/0,2000056022,20187627,00.htm

"Server"用途として使用するだけの信頼性を持っているかどうかの判断が難しい。高負荷状態になった場合や、あるVMに障害が発生した場合に完全に他のVMに対して影響を与えないといえるのかどうか等、どのラインを超えたら信頼できるといえるのかどうか、判断のわかれるところだろう。

XenEnterprise用途に使用できるようになるかは信頼性だけでなく、管理や運用のしやすさをもっと追求する必要もある。

SUSERedhatの判断がどういう結果につながるのか、しばらく注目していきたい。

2006/08/01 (火)

[]NetApp Vシリーズ NetApp Vシリーズ - Hatena::Group::Virtualization::takaochan を含むブックマーク はてなブックマーク - NetApp Vシリーズ - Hatena::Group::Virtualization::takaochan

NetApp Vシリーズは、異機種ストレージの仮想化を可能にするゲートウェイ製品で、ここに接続された他社のディスクストレージ製品をNetAppのストレージ向けOS(Data ONTAP 7G)の管理下に置き、ストレージ仮想化を行うというものだ。

http://enterprise.watch.impress.co.jp/cda/storage/2006/07/31/8350.html

ほぉ。どこまでカバーしてくれるんだろう。

Vシリーズを利用することで、NetAppのプラットフォームを他社のプラットフォームにも接続できるようになります。顧客がNetAppのテクノロジを通じて生産性やストレージの利用率を高めたいとき、これまで使ってきたディスクストレージをそのまま使い続けられるわけです。保守的な分野にも関連しますが、特にリスクを最小限に抑えたい場合には、まったく新しいストレージに置き換えるのではなく、すでにあるストレージを有効活用するほうがよいでしょう。例えば、従来型のディスクストレージをすでに大量に持っていて、さらにディスク容量を増やしたいときには、従来のように大量のディスクストレージを増設するのではなく、Vシリーズを導入して既存のディスクストレージの利用率を高めるというアプローチをとれるわけです。

たしかに目指している方向性は悪くない。すでにある程度大きくなったパイの市場で他社からシェアを奪うには何らかの形で飲み込んでいくしかない。IBMのSVC(SAN Volume Controller)と同じような発送だが、コストパフォーマンスなどを考えると十分争っていけるのではないかと思う。