2020 年 7 月 28 日更新

vRealize Automation 8.1 | 

  • vRA Easy Installer (ISO) ビルド 15996863
  • vRA 製品(アプライアンス)ビルド 15986821

各リリース ノートで、追加または更新された情報をご確認ください。

リリース ノートの概要

New:vRealize Automation 8.1 Patch 2

vRealize Automation 8.1 Patch 2 が利用可能になりました。さまざまな領域におけるバグの修正が含まれています。これは累積アップデートです。 

詳細とインストール方法については、ナレッジベースの記事 KB79170 を参照してください。  

vRealize Automation 8.1 について

vRealize Automation 8.1 では、vRealize Automation 8.0 の機能が強化され、機能面では vRA 7.x リリースに近くなりました。XaaS などの主要な機能を再度導入し、AWS GovCloud のサポート、ABX での PowerShell のサポート、vRO での Python、Node.js、PowerShell のサポートを追加しました。

新機能

vRealize Automation 8.1 には次のような多くのメリットがあります。 

VMware vRealize Automation 8.1 には、製品内ユーザー サポートが含まれています。

  • 設定について調べるには、Signpost のヘルプを使用します。
  • 機能または設定プロセスの詳細を調べるには、ヘルプ パネルを使用します。

[重要] 機能およびサポートに関する注意事項

  • ワークフローが Service Broker にインポートされ、プロパティと複合タイプを有効にする前にカスタム フォームが有効になっており、対応するアレイが実装されている場合は、カスタム フォームを削除し、ワークフローを Service Broker に再度インポートすることでフォームの要素を修正する必要があります。

New vRealize Automation 8.1 へのアップグレード

vRealize Automation 8.0/8.0.1 を 8.1 にアップグレードするには、vRealize Automation 8.x のアップグレードに関するドキュメントを参照してください。vRealize Suite Lifecycle Manager のアップグレード後、ナレッジベースの記事 KB75185 を参照して vRealize Automation 8.1 OVA バイナリを vRealize Suite Lifecycle Manager にマッピングします。 

vRealize Automation 8.1 での移行評価

移行評価サービスを使用する前に、そのサービスを有効にする必要があります。

  1. 新しい vRealize Automation 8 インスタンスをアップグレードして展開した後、[ID およびアクセス権の管理] に移動します。
  2. ユーザーを選択し、ロールを編集して、クラウド管理者および移行サービスの管理者または閲覧者にします。移行評価サービスを追加します。
  3. vRealize Automation 8 からユーザーをログアウトします。
  4. ユーザーを vRealize Automation 8 にログインすると、移行評価タイルが表示されます。

注:以前にバージョン 8.0 または 8.0.1 で移行評価を実行した場合は、8.1 の移行元の環境で評価を再実行する必要があります。バージョン 8.1 の移行元の環境で評価を再実行するには、移行元のインスタンス画面に移動し、[編集] をクリックしてパスワードを入力し、必要なテナントを選択して、[次: 評価] をクリックします。

はじめに

サポート ドキュメントで製品について理解しておく必要があります。

vRealize Automation をインストールしてユーザーを設定した後、含まれている各サービスについて、スタート ガイド使用と管理ガイドを参照できます。スタート ガイドでは、エンドツーエンドの事前検証について説明しています。使用と管理ガイドでは、使用可能な機能の検証をサポートする詳細な情報を提供しています。vRealize Automation 8.1 の製品ドキュメントには、その他の情報も記載されています。

vRealize Orchestrator 8.1 の機能と制限事項については、「vRealize Orchestrator 8.0 リリース ノート」を参照してください。

解決した問題

  • 複数のディスクを使用したコスト見積もりのドキュメントの制限/回避策(ブループリントで count プロパティを使用している場合)

    現在、ブループリントのユーザー インターフェイスが、接続されたディスクの新しい構文を yaml 形式で生成しないため、count プロパティが使用されているディスクの Day 0 プロビジョニングが中断されます。その結果、ディスクのコスト見積もりの必須プロパティ (vcUuid) のいずれかが null になり、カタログ アイテムのコスト見積もりができなくなります。

    回避策:ディスクに count プロパティを使用する場合は、yaml でブループリントの構文を以下のように手動で更新します。

    attachedDisks: ‘${map_by(resource.Cloud_Volume_1.id, id =>
    
    {“source”:id}
    )}’
    

     

  • コンピューティング インスタンスに接続されたボリュームと追加された count プロパティを使用してブループリントを展開すると、複数の disksm が作成され、一部のディスクが切断される 

    このようなブループリントを展開すると、プロビジョニング後に、作成された展開(count: 2 など)でいずれかのディスクが接続されず、常に切断されたままになります。「attachedDisks」プロパティの値に複数のディスクが設定されている場合は、最新の構文 (map_to_object(resource.disk[*].id)) のみを使用する必要があります。カタログ ユーザー インターフェイスではコスト見積もりもサポートされず、このようなブループリントがカタログとして公開されるとエラーが発生します。

    回避策:必要なディスク数の count プロパティを追加し、ブループリント キャンバスでディスクとマシン間のリンクのみを作成します。この方法により、yaml は常に attachedDisks プロパティの最新の構文を取得します。この方法を使用しない場合、ディスクがコンピューティング インスタンスに接続されたら、count プロパティを使用して複数のボリュームを追加する際に、新しい構文に手動で更新する必要があります。ブループリントで手動で更新する場合の正しい構文は、次のとおりです。attachedDisks: '${map_by(resource.Cloud_Volume_XYZ.id, id => {"source":id})}'

  • プロキシの背後でインターネットにアクセスすると ABX が動作しないことがある

     ABX アクションは、vRA アプライアンス内で実行されるオンザフライで準備されたコンテナで実行されます。

    これらのコンテナの準備には、業界標準の配信メカニズムとしてパブリック リポジトリで使用可能なアーティファクトの自動ダウンロードが必要です。

    ABX アクションの利点を活かした vRA の展開は、このようなリポジトリへのオープン アクセスを持つ仮想ネットワークに割り当てる必要があります。vRA がクラスタに展開されている場合は、3 台のノードすべてに同一のネットワーク構成が必要です。 

    直接インターネット アクセスまたはプロキシ経由でアクセスできる必要がある標準リポジトリの例:

    すべてのアクション: https://symphony-docker-external.jfrog.io https://gcr.io https://hub.docker.com/

    Python アクション:https://pypi.org/

    NodeJS アクション:https://registry.npmjs.org/

    ABX アクションの実際の依存関係に基づいて、追加のリポジトリへのオープン アクセスも必要になる場合があります。

    これらの要件は、ABX アクションによってサポートされている vRA のデフォルトの IP アドレス管理および Active Directory のプロビジョニング構成にも適用されます。

    回避策:HTTP プロキシを使用して、必要な外部サイトにトラフィックを渡します。HTTP プロキシは vracII proxy コマンド ライン拡張機能を使用して設定され、追加の指示は VMware Global Support Services (GSS) を介して取得できます。

  • 特定のドメイン名(特にパブリック サフィックスを使用していないドメイン名)にワイルドカード証明書を設定できない

    vRealize Automation 8 では、パブリック サフィックス リスト ([https://publicsuffix.org/]) の内容と一致する DNS 名のワイルドカード証明書のみを設定できます。有効なワイルドカード証明書の例として、「*.myorg.com」のような DNS 名のワイルドカード証明書を使用できます。「com」がパブリック サフィックス リストに含まれているため、この名前はサポートされます。無効なワイルドカード証明書の例として、「*.myorg.local」のような DNS 名のワイルドカード証明書を使用することはできません。「local」はパブリック サフィックス リストに記載されていないため、この名前はサポートされません。 

    回避策:パブリック サフィックス リストのドメイン名のみを使用します。

  • アクセスが Cloud.vmware.com にリダイレクトされる

    組織内のアクセス権があるログイン ユーザーに、「アクセス権がありません」というエラー画面が表示されます。このエラーは高可用性 (HA) 構成でのみ発生します。 

    回避策:ブラウザのキャッシュを消去します。 

  • 仮想アプライアンスをスナップショットに戻すと、vRA 8 クラスタの起動に失敗する

    LCM 内の 3 ノードの vRealize Automation 8 クラスタのスナップショットは現在使用できません。

    回避策:オフライン スナップショットを作成するには、まず vRA サービスをシャットダウンします。

    1.1 台の vRA ノードで「/opt/scripts/deploy.sh --onlyClean」を実行して、サービスを正常にシャットダウンします。

    2.halt コマンドを使用して各ノードをパワーオフします。

    3.仮想マシンのパワーオフ後、スナップショットを作成します。

    環境をスナップショットに戻す場合の起動手順:

    1.すべての仮想マシンをパワーオンします。

    2.vRA サービスの引数を指定せずに「deploy.sh」スクリプトを実行して、バックアップを行います。

  • プライマリ データベース ノードを停止すると、EBS トピックが登録されずにプロビジョニングが失敗する

    vRealize Automation 8 の高可用性 (HA) 環境で、プライマリ データベース ノードを削除した後にプロビジョニングを行うと、「EBS トピックが登録されていないため、イベントの発行に失敗しました (Failed to publish event as EBS topics are not registered)」というエラー メッセージが表示されて失敗します。

    回避策:詳細については、ナレッジベースの記事を参照してください。

  • 移行評価の「はじめに」ページの『移行ガイド』へのリンクが無効

    移行評価ユーザー インターフェイスの移行ガイドへのリンクは正しくないため、無効です。

    回避策:正しいリンクは『vRealize Automation 8 移行評価サービスの使用』です。

  • タイプ「properties」からの入力を使用する vRO ワークフローをトリガできない。

    タイプ「properties」からの入力を使用する vRealize Orchestrator ワークフローが catalogSteps で公開され、vRealize Automation の catalogResult からトリガされると、トリガの実行は失敗します。

既知の問題

このリリースには、次の既知の問題があります。
  • アプライアンスが 172.17.x.x ネットワークに展開されている場合、vRA 8.1 の展開またはアップグレードが失敗する

    vRA の展開が失敗します。「組み込みの vRO の登録」ステージで deploy.sh スクリプトの実行に失敗します。
    /var/log/deploy.log には次が記録されます。
    curl: (22) The requested URL returned error: 400 Bad Request
    Failed to register vRO.Will retry in 45 seconds...
    ...
    curl: (22) The requested URL returned error: 400 Bad Request
    Maximum number of retries exceeded."

    原因:アプライアンスは、172.17.x.x 空間から IP アドレスを取得しました。これは、vRO ポッドからの内部 docker0 インターフェイスと競合しています。

    https://kb.vmware.com/s/article/78783 を参照

  • vCenter Server クラウド アカウントが更新されてデータセンターが追加された場合、このデータセンターのリソースをただちに使用できない

    vCenter Server クラウド アカウントのリージョン(データセンター)に加えられた変更はただちに反映されないため、データ収集の実行が必要です。

    回避策:次のデータ収集が正常に完了するまで待機します。データ収集は約 10 分ごとに実行されます。

  • PowerShell タスクが停止しているように表示される

    アクティブなセッションがない場合、PowerShell タスクが停止しているように表示されます。この動作は、ユーザー スクリプトを実行する PowerShell プロセスが Windows システム プロセス WmiPrvSE によって保持されているために発生します。

    回避策:システムにログインし、アクティブなセッションを維持します。完全にログアウトするのではなく、画面をロックします。

  • vRO が、配列型を「type.isMultiple」が true のフィールドではなく、1 つの列のみの複合型として表す

    配列入力を含むワークフローを追加してそのフォームをカスタマイズする場合は、データ グリッドの [値] タブで列の ID を変更しないでください。デフォルト値は、_column-0_ の設定のままにしておく必要があります。一方、データグリッドに値を追加するとユーザー インターフェイスに表示される列のラベルは変更できます。

  • ライセンスの再構成がサポートされない

    Enterprise ライセンスを使用して vRealize Automation を構成した後は、Advanced ライセンスが使用されるようにシステムを再構成することはできません。

  • vRealize Automation 8 では Internet Explorer 11 がサポートされない

    Internet Explorer 11 は vRealize Automation 8 で使用できません。

    回避策:Internet Explorer 11 以外のブラウザを使用します。

  • カスタム リソースが変更または削除された後に、ブループリント キャンバスが更新されない

    カスタム リソースを削除しても、その変更はブループリント キャンバスにただちに反映されません。

    キャンバスにはキャッシュ メカニズムがあり、検索ペインの横にある [更新] ボタンを使用して更新できます。

  • vRO オブジェクト タイプが同一の異なるカスタム リソースの作成はサポートされない

    vRA 7.x では、同じタイプの異なるカスタム リソースを作成できました。これにより、ユーザーは、同じ vRO タイプで作成/削除/操作アクションの異なるセットを、異なるカスタム リソース タイプの作成で定義することができました。vRA 8.1 では、異なるカスタム リソースから同じ vRO_Type を利用できるケースはサポートされていません。 

  • リファレンス タイプへの空の入力があると、カタログを使用して vRO ワークフローが実行されない

    リファレンス タイプのワークフロー入力に対して、空の値で vRO ワークフローを申請すると、Null ポインタ例外が表示されます。

    回避策:フィールドを必須にするか、またはリファレンス タイプのデフォルト値を設定します。

  • プロビジョニングに失敗したカスタム リソースを展開から削除できない

    カスタム リソースを申請すると、リソースを作成するワークフローの実行が失敗した場合でも、展開サービス内のリソースは作成されています。これは最初の申請に「開始済み」のステータスで応答し、展開にリソースを作成しているためです。このリソースには、vRO でのリソースのプロビジョニングに成功したときに追加されるメタデータが含まれていないため、削除できません。

    回避策:カスタム リソースの削除を最初に試行した直後に、強制的に削除するかどうかを尋ねるダイアログが表示されます。[はい] を選択すると、カスタム リソースが強制的に削除されます。

  • カスタム リソース名が展開ビュー リストに正しく反映されない

    vRO_Type に基づいてカスタム リソースを作成する場合、通常は包括的な表示名を使用します。現在、この表示名は展開ビューでは使用できません。展開に表示されるリソースは、そのタイプによってのみ識別されます。

  • vCenter Server マシンのコンソール ウィンドウからタイムゾーンを設定する場合に使用可能なオプション

     vCenter Server マシンのコンソール ウィンドウからユーザーがタイムゾーンを設定したときに未定義の動作になります。

    回避策:タイムゾーンは変更しないでください。

  • テナント名で大文字と小文字が区別されない

    vmware という名前のテナントと VMware という名前の別のテナントが同じテナントとして認識されます。

    回避策:vRA 8.1 のテナントはホスト名に基づいているため、テナント名は大文字と小文字が区別されません。したがって、VMware という名前のテナントは VMWARE、vmware などの大文字と小文字の任意の組み合わせの名前のテナントと同じとみなされます。テナント名の大文字と小文字は異なる場合があるため、アプリケーション全体で保持されない場合があります。

  • バインド値を正しく解決できないため、特定のネットワーク プロパティへのプロパティ バインドを含むブループリントが展開に失敗する

    dnsdnsSearchDomains および gateway プロパティのプロパティ バインドが機能していません。これらは主に OVF ブループリントで使用されます。

    回避策:次のプロパティを使用するブループリントは、別のプロパティ セットを使用するように変更する必要があります。

    注:この問題に対する永続的な修正は、vRA 8.1 の最初の修正プログラムで提供されます。ここに記載されている回避策は一時的なものであり、修正プログラムを適用した後に元に戻す必要があります。

    dns プロパティの場合:

    dns0: '$\{resource.Cloud_NSX_Network_1.dns[0]}'
    dns1: '$\{resource.Cloud_NSX_Network_1.dns[1]}'

    を以下に変更する必要があります。

    dns0: '$\{replace(split(resource.Cloud_NSX_Network_1.dnsServerAddresses, ",")[0], "[", "")}'
    dns1: '$\{replace(split(resource.Cloud_NSX_Network_1.dnsServerAddresses, ",")[1], "]", "")}'

    dnsSearchDomain プロパティの場合:

    dnsSearchDomain0: '$\{resource.Cloud_NSX_Network_1.dnsSearchDomains[0]}'
    dnsSearchDomain1: '$\{resource.Cloud_NSX_Network_1.dnsSearchDomains[1]}'

    を以下に変更する必要があります。

    dnsSearchDomain0: '$\{replace(split(resource.Cloud_NSX_Network_1.dnsSearchDomains, ",")[0], "[", "")}'
    dnsSearchDomain1: '$\{replace(split(resource.Cloud_NSX_Network_1.dnsSearchDomains, ",")[1], "]", "")}'

    gateway プロパティの場合:

    gateway: '${resource.Cloud_NSX_Network_1.gateway}'

    を以下に変更する必要があります。

    gateway: '${resource.Cloud_NSX_Network_1.gatewayAddress}'

     

  • ノードの CPU 使用率が 100% になると、ポッドのクラッシュが始まる

    高負荷の環境でログ バンドルを生成すると、1 台以上のノードで CPU やメモリの使用率が一時的に過負荷になる可能性があります。これにより、サービスがクラッシュする場合があります。

    回避策:環境に負荷が少ないときに、ログ バンドルの収集スクリプトを実行します。外部ログ ソリューション(vRLI または Syslog サーバ)へのログの転送を設定および監視します。

  • データ収集でストレージ ポリシーの収集に失敗し、互換性のあるデータストアまたは vCenter Server 7.0 での既存のストレージ ポリシーの更新に失敗する。データ収集で vRA での WCP の可用性の更新に失敗する

    vSphere クラウド アカウントに複数のデータセンターがあり、それらが vRA のエンドポイントで選択されていない場合、データ収集の完了に失敗し、データ収集が部分的に成功して、上記の症状が発生する可能性があります。

    回避策:vSphere クラウド アカウントのすべてのデータセンター(リージョン)を選択します。そのデータセンターを管理しない場合は、クラウド ゾーンを作成する必要はありません。ただし、データセンターのアーティファクトが収集されます。

  • カスタム Day 2 アクションと組み込みタイプのバインドを手動で参照する必要がある

    vRA 7.x では、カスタム Day 2 アクションとコンテキスト内の vRA 組み込みオブジェクトのバインドの自動化がありました。vRA 8.1 では、このバインドは vRO アクションによって行う必要があります。

    公式のドキュメントでバインド プロセスに関する詳細なガイダンスを確認できます。

  • 展開にリソースが不足しているときに、ユーザーがプランの生成のブループリントを適用することによってその展開を更新しようとすると、「展開で別の要求がすでに進行中です」というエラー メッセージが表示されることがある

    さらに、展開履歴のタイムラインに別途「Day 2 アクション - 削除」が表示されます。また、ユーザーが API を介して展開を更新すると、「展開で別の要求が進行中です」と表示されます。 

    展開の更新を再試行します。

  • ドロップダウンから入力するアクションがある vRO ワークフローを XaaS カタログ アイテムとしてインポートすると、選択可能な値が静的な定数としてインポートされる

    ドロップダウンから入力するアクションがある vRO ワークフローを XaaS カタログ アイテムとしてインポートすると、選択可能な値が静的な定数としてインポートされます。

    これにより、カタログ アイテムの申請を使用する際に、フィールドに値が動的に入力されるのではなく、静的な値が表示されます。

    このようなカタログ アイテムの場合、カスタム フォームを使用して「外部ソース」と参照アクションを手動で選択することで、値が適切に入力されます。

  • NEW:OGNL 式による vRO ワークフローの表現が、vRA のカスタムの Day 2 操作で使用した際に適切にレンダリングされない

    表現に OGNL 制約を持つワークフローを含むカスタム リソース アクションが適切にレンダリングされず、一部の必須フィールドに値をポピュレートできないことがあります。

  • NEW:ロード バランサのリストを名前でフィルタリングすると、vRA で展開した同一の NSX ロード バランサが、1 つは「展開済み」、もう 1 つは「検出済み」という異なる名前で 2 つ表示される

    vRA で NSX ロード バランサを展開すると、ロード バランサは、vRA が内部データベースで使用しているものとは異なる ID および名前を使用して NSX に作成されます。結果として、vRA は最初に作成されたロード バランサ レコードを更新せず、関連付けられた NSX Cloud アカウントをデータ収集する際には重複した新しいロード バランサ レコードを作成してから更新を実行します。これにより、ロード バランサがリストされる画面では、ロード バランサが重複しているように表示されます。

    回避策:vRA で展開した NSX ロード バランサをネットワーク プロファイルに追加する際に、「検出済み」ではなく、「展開済み」のロード バランサを選択します。

check-circle-line exclamation-circle-line close-line
Scroll to top icon