Xen 4.5がリリースされたことが紹介されています。

コードの全面的なリフレッシュを行ったハイパーバイザー「Xen 4.5」

Xenが開発されてきた歴史が、詳しくまとめられています。
PVHという準仮想化の新しいモードが採用されています。
Cache Monitoring TechnologyとかSupervisor Mode Access PreventionといったCPUの新しい機能も使えるようになっているそうです。

ちょっと見ない間にだいぶ変わってきているようです。

OpenStackの日本HPでの活用事例が紹介されています。

従来型企業こそOpenStackを使うべき理由～導入・移行パターンと活用の勘所～ (1/2)

クラウドを使うメリットがスピードと生産性であることが述べられています。
最初に取り組んだのがAWSで、その問題点を解決するためにOpenStackを使い始めたそうです。
過去に作った仮想基盤も継続的に使用しているそうです。
サービスとして提供するものは、自らも使っているそうです。

大きな組織で、過去の資産があればあるほど使い分けが重要になってくるようです。

NTTコム、GMO、楽天がOpenStackを使う理由を挙げています。

NTTコム、GMO、楽天が語る「僕らがOpenStackを使う理由」 (1/3)

NTTコムでは、OpenStackの今後に期待しているそうです。
GMOではうまく使えているそうですが、障害には自力で対応するしかないそうです。
楽天ではお試し環境として使っているそうです。ITのエンジニアでも、開発系とインフラ系の垣根がなくなってきているそうです。

障害を自力で対応しないといけないことに、どれくらい対応できるか問題ですよね。

Google Cloud DebuggerがGoogle Compute Engineに対応されたそうです。

クラウドに分散して実行中のJavaコードをデバッグできる「Google Cloud Debugger」が、Compute Engineに対応

条件は、Java 7か8で64bit Debianイメージを用い、Google Cloud repository、GitHub、BitBucketにコードを保存していることだそうです。

ウォッチポイントを設定することで、状態を把握できるとの事です。ブレークで止めるわけではないみたいですね。

止めてしまうと状態が変わってしまうところなどは、マルチスレッドのプログラムのデバッグと似ているわけですね。

OpenStack Days Tokyo 2015のミラクルリナックスのセッションが報告されています。

第2回　運用フェーズに入ったOpenStack─「OpenStack Days Tokyo 2015」セッションから

OpenStackの運用上の問題が述べられています。

それに対して、ZabbixとHatoholで解決するのだそうです。

自動的に、障害検知をするには複数の要素を総合的に判断しなければいけないことが述べられています。

けっこう難しそうですね。