Skip navigation
1 2 3 Previous Next

virtual hive-jp

76 posts

vRealize Operations(vROps)はご存知の通り、vSphere環境をモニターリングして将来のリソース枯渇の予測やインフラの集約率を分析できる製品です。またvRealize Log Insight(vLI)はvSphere環境から発生する各種ログを集中管理できる製品です この2つの製品を統合することによって仮想インフラのモニターリングとログ分析をより効果的に行うことができます。 ということで、簡単な手順ではありますがvROpsにvLIを統合してみます。 まず、vROpsとvLIを導入します。両方ともに仮想アプライアンス導入し、初期セットアップまでは実施済みです。



<vLIからvROpsへ接続> 

vli01.png

vLIのダッシュボードより[管理]を選択します。

 

vli02.png

左メニュの[統合]より、”vRealize Operations”を選択、vROpsのホスト名、接続アカウント名、パスワードを入力し、保存するとvLI側からvROpsを登録することになります。



<vROpsからvLI用管理パックをインストール>

 

vLIで正常にvROpsが登録されましたら、今度はvROpsからvLIの管理パックをインストールします。 

 

vli03.png

VMware Solution Exchangeより”Management pack for vRealize Logsight”をダウンロードします。  

 

vli04.png

ダウンロードしたvLI用管理@アックをvROpsのソリューションとしてインストールします。  

 

vli05.png

vLI用管理パックを追加した画面です。vLI用管理パックの場合、接続に必要なアダプターの作成は必要ないため、これでvROpsの作業は完了です。  

 

vli06.png

ソリューションの追加後は、vROpsの[アクション]メニューにvLI用リンクが追加されます。このリンクをクリックするとvLIのウイが表示され、オブジェクトで発生したログをより詳しく管理することができます。 


もちろん、vLIだけでも十分ログを分析、管理することが可能です。が、vROpsと統合することによって単なるログ管理だけではなく異常状況の傾向や将来予測などvSphereインフラ全般の運用管理をより効率的にできます。 


2つの製品を導入している場合は、是非統合して運用することをオススメします。     

12月7日、VSANアップグレードに関して気になるKBが公開されました。 VSANを構成しているESXiノードを5.5から6.0にアップグレードの際に、VSANデータがロストする恐れがあるとのことです。具体的には以下のような条件が揃った場合、発生するとのことです。

 

  • ESXi 5.5、6.0が混在してるVSANクラスタの場合
  • ESXi 5.5、6.0が混在してるVSANクラスタでオブジェクトの再構成された場合
  • 再構成されたオブジェクトのコンポーネントが格納されている複数のESXi 5.5が6.0にアップグレードされる前に再起動した場合

 

今のところ、事象の解決策はないため、VMware社では有効な解決方法が公開されるまでVSANノードのESXi 5.5から6.0へのアップグレードは行わないよう強く推奨しています。

が、どうしてもVSANのアップグレードが必要な場合のワークアラウンドも提示されています。

 

  • 仮想マシンをVSAN以外のストレージにStorage vMotionしてから実施
  • VSANクラスタ内のすべてのESXiノードのディスク空き容量を20%(ディスク使用率が80%を超えると自動的にオブジェクトの再構成が実施されるため)以上確保
  • ESXiノードアップグレード時、Storage Policyなどのオブジェクト再構成が必要な操作を行わない
  • ESXiノードアップグレード時、アップグレードプロセスで必要な再起動以外のESXi 5.5の再起動はしない(障害発生時でも含む)

 

  詳細な内容はここをご確認ください。 まあ、VSANをアップグレードはマッテ!ということですな。。。    

vSphere Replicationを導入し、アプライアンス管理ページより初期構成を行うと次のエラーが発生することがあります。

 

  "Server returned 'request expired' less than 0 seconds after request was issued but is shouldn't have expired for at least 600 seconds "

vSphereReplication_error01.png

上記のエラーが発生するとvSphere Replicationサービス(VRM)が開始しません。

 

 

■ 原因

本エラーは主にvSphere ReplicationアプライアンスのNTPとESXi、vCenterのNTPにズレがある場合発生します。アプライアンスインポートの際にtime zoneも設定したにもかからわず、時刻同期の動的ポリシーがうまく動作しない場合があるようです。

 

 

■ 解決方法

vSphere Replicationアプライアンスのコンソールに接続、手動でNTPを構成します。

  sntp -P no -r NTPサーバアドレス

 

 

NTP設定後、ntpサービスを再起動します。

vSphere 6リリースと同時に、VSANバージョンも6がリリースされました。

 

バージョン5.5よりスケーラビリティが2倍に拡張されたことはもちろん、All Flash Arrayサポート、フォルトドメイン概念の導入、そしてユーザビリティが大きく改善されました。

個人的にはVSANを検討しているのであればバージョン6を推奨しますし、すでに5.5を導入している場合はバージョン6にアップグレードすることをオススメします。

 

VSANのアップグレードはローリングアップグレードです。ESXiホスト1台ずつ行われます。

例えば、ESXi-01、02、03、04 計4台で構成されているVSANクラスタのアップグレードの流れは以下のとおりです。

 

① アップグレードを実行するとESXi-01のデータが他のESXiホストへ再同期されます。FTTによる可用性を維持するためです。

② データの同期が完了した時点で、ESXi-01のディスクグループを削除、新しいVSAN FS フォーマットされたディスクグループを作成します。

③ 正常にディスクグループが作成されたら、順次ESXi-02→03→04順に①、②が繰り返されます。

④ すべてのESXiホストのディスクグループ作成が終わったら、VSANのアップグレードも完了です。

 

簡単です。w

 

ただし、1点注意することがあります。

 

VSANクラスタが3台のESXiホストで構成されていて、FTT=1の場合はデータが2台のESXiで保持され、ウィットネスは2台とは別のESXiのホストに生成されます。

そのためアップグレードの場合は、仮想マシンの稼働に確保できるホスト2台しかないため、アップグレード時の可用性チェックをスキップする必要があります。(仮想マシンの稼働には問題ありません)

可用性チェックのスキップは、アップグレードコマンドに”--allow-reduced-redundancy”を追加します。

 

VSAN 6へのアップグレードについて、簡単に紹介します。

 

VSAN 6へのアップグレード作業にはいくつか前提条件があります。

 

■ 前提条件

  • vCenter 6へのアップグレード
  • ESXi 6へのアップグレード
  • vSphere HA アドミッションコントロールの無効化

 

アップグレードはrvc(Ruby vSphere Console)を利用します。

 

VSANクラスタのESXiを6にアップグレードすると、次の画像のようなアラートが表示されます。”VSANクラスタだよー。アップグレードが必要だよー”ってね。w

vsan6 upgrade01.png

 

① まず、rvcを起動します。vCenter 6のrvcは以下のフォルダにあります。

C:\Program Files\VMware\vCenter Server\rvc\rvc.bat

 

② rvc.batを実行、次のコマンドで既存VSANの情報を確認します。

vsan.disks_stats /localhost/データセンター名/computers/VSANクラスタ名

vsan6 upgrade02.png

 

vsan.disk_statsを実行するとVSANのヘルス状態が”正常”であることとバージョンが”v1”であることが確認できます。

 

 

③ 次のコマンドを実行し、現在VSANにてデータの同期などが実行されていなことを確認します。

vsan.check_state /localhost/データセンター名/computers/VSANクラスタ名

vsan6 upgrade03.png

 

上の画像のとおり、再同期やアクセス不可のデータがないことを確認します。

 

④ 次のコマンドを実行し、VSANのアップグレードを実行します。

※本環境は3台のESXiで構成されているため、可用性チェックをスキップする”--allow-reduced-redundancy”を追加しました。4台以上のESXiで構成されている場合、FTTを考慮しても問題がなければ”--allow-reduced-redundancy”オプションは必要ありません。

vsan.v2_ondisk_upgrade --allow-reduced-redundancy /localhost/データセンター名/computers/VSANクラスタ名

vsan6 upgrade04.png

 

1台ずつアップグレードされます。(アップグレードにかかる時間は各ESXiホストのデータ量によって異なります)

ちなみに再同期のステータスは[クラスタ]→[監視]→[仮想SAN]→[コンポーネントの再同期]から確認できます。

vsan6 upgrade05.png

 

⑤ すべてのアップグレードが完了したら、次のコマンドでVSAN情報を確認します。

vsan.disks_stats /localhost/データセンター名/computers/VSANクラスタ名

vsan6 upgrade06.png

 

vsan.disk_statsを実行するとVSANのヘルス状態が”正常”であることとバージョンが”v2”に上がっていることが確認できます。

(vSphere Web Clientからも[クラスタ]→[監視]→[仮想SAN]→[ディスクの管理]の”ディスクフォーマットバージョン”にて確認できます)

vsan6 upgrade07.png

 

⑥ rvcを終了します。

 

 

これでVSANアップグレードは終了です。アップグレードの過程で保護中のデータが”旧バージョン”や”コンプライアンスに非準拠”になることがありますが、自動的に”準拠”に変わります。反映されない場合は、 "仮想マシンのストレージポリシーのコンプライアンス確認"を実行し、手動で反映させます。

vsan6 upgrade08.png

vSphere 6(ESXi 6)環境でHorizon Viewを導入する場合、注意が必要なKBが公開されました。

 

Windows 7 virtual machines running on ESXi 6.0 hosts restart unexpectedly

※KBには明確にHorizon Viewとは明記されていませんし、影響のあるプロダクトにもHorizon Viewはありませんが、vSphere環境でWindows 7を利用するケースは主にHorizon Viewだと思われるので敢えてHorizon Viewと書きました。

 

内容は、vSphere 6(ESXi 6)環境でWindows 7を利用する場合、Windows 7 VMが予期せぬ再起動が行われるとのことです。

条件としましてはWindows 7 VMが高解像度に設定されているか、マルチモニターを利用する場合で、KBが公開された時点では根本的解決方法はなさそうです。

 

その代わり、以下のワークアラウンドが提示されています。

  • Windows 7 VMの解像度を下げる
  • マルチモニターではなくシングルモニターで利用する

 

詳細な内容はここをご参照ください。

2年前でしょうかね。VMware社のエンジニアやコミュニティ/ブログで精力的に活動しているブロガーでvSphereデザインガイド作ろうとしたことがありました。

いわゆる専門家による経験をベースにしたティップス集のようなものだったと思います。ツイーターにて様々なティップスを募集しましたが、条件は140文字程度の短い文で構成することだったと思います。(集まったティップスはエディション1.0で公開されたようです)

 

去年はエディション2.0が新たに公開されました。ツイートのように短い文章で構成されてたエディション1.0とは違い、2013年から2014年の間で様々なブログから書かれた記事の中から厳選されたブログ記事で構成されています。内容は以下のとおり。

 

vSphere Design Pocketbook 2.0

1. Host Configuration

2. Cluster and vCenter Design

3. Storage Configuration

4. Network and Security Design

5. VM Configuration

6. Application Landscape

7. その他のティップス

 

英語ですが、タダですので、ダウンロードしてスマホやタブレットに入れといて電車の中で読むには最高かもしれません。笑

ダウンロードはこちらから。

 

PS> Thanks to PernixData and Frank Denneman who published the document.

まさかと思いましたが、こんなツールが公開されました。


VMware Labsに"VCS to VCVA Converter"というツールが公開されました。2013年Flingsコンテストで優勝したアイディアから産まれたとのことです。

で、このツールが何かというと、Windows ServerにインストールしたvCenterをLinuxベースの仮想アプライアンスにマイグレーションしてくれるツールです。!!!

 

vcs-to-vcsa-converter.png

VMware Labs

 

説明によると、このツールを使うことで、以下のモジュールが移行できると言ってます。

  • vCenterデータベース
  • ロール、権限
  • 証明書
  • Inventory Service

 

まさしくOSを超えるクロスプラットフォーム移行ツールです。:)

が。。。 いろんな制約もあります。

このツールを使って移行をするためには、vCenter用DBはリモート存在する必要があります。(vCenterとSQL Serverが同居してるとダメのようです) あとSQL ServerのExpressエディションもダメとのことです。

あと、当たり前ですがWindowsのローカルユーザーやグループは移行されませ~ん。あとすべてのプラグインも移行できません。


まあ、公開されたバージョンが0.9だし、まだLabsにあるので実環境での利用には無理があると思いますが、興味のある方はお試しください。

ツールの詳細はこちらをご覧ください。

VDI導入のハードルを上げている原因の一つがライセンスです。特にVDAは悩ましいものです。

元々シンクライアントやゼロクライアントのようにnon-Windows OSでバイスから仮想デスクトップに接続するために必要なものでデバイス単位でのみ購入が可能、利用可能なデバイスは最大4台といった制限があったからです。

 

 

 

この制限が次のように変更されました。

  ・VDAをユーザー単位でも購入可能となりました。

  ・VDAの接続デバイス制限数が廃止されました。

 

 

 

マイクロソフト社としては思い切った決定だと思いますが、あともう一歩、クラウド上からもクライアントOSを自由に利用できるようにボリュームライセンスポリシーが変更して欲しいですね。

 

 

 

詳しい内容はここをご参照ください。

VMware LabsにHorizon View関連の新しいツールが公開されました。

 

View Auditing PortalというツールでView Administratorの拡張ウェブポータルとして設置し利用できます。

ツールの名前から分かるように監査情報が確認できるもので具体的には、

  • View ClientのOSとバージョン
  • Linked Cloneプールの親仮想マシンとスナップショット情報
  • 仮想デスクトップとRemoteAppのセッション情報

といった情報が確認できます。

 

 

このツールの利用可能なHorizon Viewのバージョンは6.0以上で、インストール方法は。。。という程でもありません。

ここからファイルをダウンロードし、viewauditing.warというファイルを以下のフォルダに移すだけです。w

C:\Program Files\VMware\VMware View\Server\broker\webapps

ViewAuditPortal01.jpg

 

ファイルを移動後、以下のURLにアクセスするとログイン画面が表示されます。

https://View Connection Server名/viewauditing/

ViewAuditPortal02.jpg

 

リンククローンの仮想マシンとスナップショットの情報が確認できます。

ViewAuditPortal03.jpg

 

View ClientのOSとバージョンの情報が確認できるページです。

ViewAuditPortal03B.jpg

 

接続中の仮想ですクトップとRemoteAppのセッション情報が分かるページです。

ViewAuditPortal04.jpg

 

より詳しい内容はここをご参照ください。

先週サンフランシスコで開催されましたVMworld 2014でVMware発のコンバージドインフラストラクチャーEVO:RAILが公開されました。

http://blogs.vmware.com/tribalknowledge/files/2014/08/VMW-LOGO-EVO-Rail-108-300x278.png

 

このEVO:RAILはプロジェクトMARVINで知られていたものでハードウェア/ソフトウェアの統合ソリューションの新しい名称で、去年からVMwareがハードウェア市場にまで手を伸ばすという風に噂されていたものです。

 

2UのハードウェアにvSphere、Virtual SAN、LogInsightが提供されるアプライアンスで、最短パスワードを2回入力するだけで、構成が終わるとのことです。(完全自動構成時の場合)

 

紹介ビデオを見れば一目瞭然。今までハードウェアの設置から始まるvSphereの導入が劇的に短縮されます。

 

EVO:RAILアプライアンスは、4ノードで構成され、最大4アプライアンス(16ノード)まで拡張できるとのことです。

 

各ノードはIvy-Bridgeプロセッサー×2、192GBメモリ、1.2TB×3 HDD、400GB×1 SDD、10GbE×ネットワークポートで構成され、アプライアンス当たり最大100台の仮想マシンまたは最大250台の仮想デスクトップを集約できることを想定しているとのことです。

 

現在EVO:RAILのパートナーとしてはDELL、Fujitsu、EMC、SuperMicro、NetOne Systems、Inspurの6社で、各パートナーは自社製x86サーバーwモデルとしてプロダクトを発表していますし、価格は$80,000~$250,000帯になると予想されています。

 

非常に魅力的なプロダクトです。

2013年公開されましたHorizon View用マスターイメージ最適化ツール、OS Optimization Toolの最新版がFlingsより公開されました。

 

 

このバージョンでは、以下のような機能が強化、追加されました。

  • Windows 7, 8用最適化テンプレートのアップデート
  • Windows Server 2008-2012用最適化テンプレートの追加
  • リモート/ローカルツールの統合
  • テンプレート管理機能の向上
  • 最適化結果のレポーティング機能追加

 

osoptimizationtool2014.jpg

 

テンプレートに”Windows Server 2008-2012”が追加されてますね。

 

 

ダウンロードはここからできます。

Virtual SANが利用できる環境でHorizon Viewを導入する際に考慮すべきサイジングとデザインのガイドがリリースされました。

このガイドはVirtual SANとHorizon Viewの特徴説明をはじめ、ホスト、ストレージ、ネットワークまで項目別に説明をしながら構成デザインについても説明しています。

guide.jpg

 

 

ご興味のある方は是非読んでみてください。

ダウンロードはここから。。。

先月リリースされましたHorizon 6 Viewで利用されるネットワークポートをまとめたダイアグラムが公開されました。

このダイアグラムは2年前、Horizon View 5.2バージョンで一度公開されたものを6.0用に更新したもので非常に分かりやすくまとまっています。

 

やはり表よりは図ですよねー。

 

http://blogs.vmware.com/consulting/files/2014/06/Horizon-6-Firewall-3.png

 

ダイアグラムのダウンロードは、ここのページから可能です。

待ちに待ったHorizon 6.0が6月19日リリースされました

メジャーバージョンらしくWindows ServerのRDSによるServer VDIやアプリケーションの利用、Virtual SANのサポート、クラウドポッドアーキテクチャーによる大規模な展開など新機能が追加されています。

詳細な内容はリリースノートをご参考ください。

 

またHorizon 6.0についてより詳しく知りたい方は以下の内容で構成されているブートキャンプをご活用ください。

    • Desktop and Applications Virtualization Best Practices
    • Image Management Architecture Guide with Mirage
    • Workspace Portal Deployment Best Practices
    • Horizon 6 Integration with Virtual SAN
    • Getting Started with Horizon vCenter Orchestrator Plug In

 

VMware Horizon 6 Bootcamp

ESXi 5.xにてWindows Server 2008 R2 x64 仮想マシンがBSODになることがあるとのことです。Solaris 10 x64の仮想マシンの場合も同様にカーネルパニックに陥ることがあるようです。

 

原因は現在調査中で、以下のCPUを搭載しているサーバの場合、発生することが確認されたとのことです。

  • Intel(R) Xeon(R) CPU E5-2670 v2
  • Intel(R) Xeon(R) CPU E5-2680 v2
  • Intel(R) Xeon(R) CPU E5-2690 v2
  • Intel(R) Xeon(R) CPU E5-2697 v2

 

修正パッチが公開されるまで、該当仮想マシンの.vmxファイルにで下記の設定を”software”に変更することで回避できるということですので、本事象を経験している方は、下記のKBを元に設定を変更してみてください。

monitor.virtual_mmu = software

 

KB 2073791 Windows 2008 R2 and Solaris 10 64-bit virtual machines blue screen or kernel panic when running on ESXi 5.x with an Intel E5 v2 series processor