VDAアップグレード (プレビュー)

最終公開日 : Nov 13, 2026
Related information
管理

はじめに

以前は、VDAのアップグレードには完全な手動介入が必要でした。バージョン2503では、VDAアップグレードエージェントを導入することで、DaaS展開におけるVDAアップグレードが簡素化されます。バージョン2503以降のアップグレードは、共有またはローカルのファイルパスから直接実行できるようになります。
VDAアップグレードエージェント ctxvua は、VDAアップグレードサービスとの通信を担当し、以下の機能を実行します。
  • スケジュールされたチェック: VDAアップグレードエージェントは、15分ごとにVDAアップグレードサービスにスケジュールされたアップグレード情報を照会します。
  • 自動アップグレード: アップグレード指示を受信すると、VDAアップグレードエージェントはVDAを自動的にアップグレードします。
  • ステータスレポート: VDAアップグレードエージェントは、アップグレード結果（成功または失敗）をVDAアップグレードサービスに報告します。
VDAアップグレードサービスの詳細については、「Tech Brief: Citrix VDA Upgrade service」を参照してください。そこでは、サービスの概要、動作の詳細、その他の役立つリソースを見つけることができます。

考慮事項

  • Linux VDAは、基盤となるパッケージ管理コマンド（rpmやaptなど）を使用してアップグレードされ、手動アップグレードプロセスを反映しています。コマンドラインアップグレード中に構成ファイルは自動的に処理されます。
  • Windowsとは異なり、Linux VDAには組み込みのVDAアップグレードエージェントが含まれています。エージェントがすでに存在するため、これによりアップグレードプロセスが簡素化されます。VDAアップグレードエージェントのバージョンは、VDAのバージョンに紐付けられています。
  • デフォルトでは、VDAアップグレードエージェントは無効になっています。エージェントを有効にするには、次のコマンドを実行します。
    /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\UpdateServices\UpdateAgent" -t "REG_DWORD" -v "fEnabled" -d "0x00000001" --force

    systemctl start ctxvua.service
  • VDAアップグレードエージェントサービス (ctxvua) はデフォルトで無効になっています。systemctl を使用してこのサービスを有効にして開始できます。
  • ベストプラクティスとして、本番環境に移行する前にVDAアップグレードを徹底的にテストすることをお勧めします。
  • Windowsとは異なり、Linux VDAのアップグレードはファイルパスからのみサポートされます。つまり、Azure CDN URLやその他のオンラインリポジトリを直接使用することはできません。VDAパッケージは自分で管理する必要があります。これは、メジャーバージョンアップグレードとマイナーバージョンアップグレードの両方に適用されます。
  • VDAアップグレードサービスでは、「Latest VDA Version」と「Upgrade State」は無視してください。「VDA Upgrade State」のみがLinuxに関連します。
  • VDAパッケージのファイルパスは、VDAマシンにローカルなパスでも、共有場所（たとえば、VDAにマウントされたネットワーク共有）でも構いません。システムはパッケージを自動的にダウンロードするようには設計されていません。完全なパッケージファイルを提供する必要があります。
  • StudioまたはCitrix DaaS Remote PowerShell SDKを使用する際にパス検証を通過させるには、Windows UNCパス形式（\\\&ast;*で始まる）でパスを指定します。たとえば、/mnt/pkg\/\&lt;package-name>** は \\\mnt\pkg\\<package-name\> と入力する必要があります。
  • 「サーバー」VDAと「ワークステーション」VDAの区別はLinuxには適用されません。StudioまたはPowerShellでどちらのオプションを使用しても、アップグレードに影響はありません。
  • VDAのダウングレードはサポートされていません。

前提条件

  • コントロールプレーン: Citrix DaaS™
  • VDAバージョン: 2503以降
    注:
    最新のCR VDAを使用することをお勧めします。
  • VDAにはVDAアップグレードエージェントがインストールされており、サービスが実行されている必要があります。
  • VDAをアップグレードする権限があること。
  • VDAアップグレードがStudioで適切なCRまたはLTSRトラックで構成されていること。
  • VDAが使用中でないこと。（ユーザーはVDAからサインオフする必要があります。）
  • VDAがメンテナンスモードでないこと。（VDAは管理者によってメンテナンスモードに設定できます。また、最大許容登録試行回数を超えた場合、VDAは自動的にメンテナンスモードになることもあります。）
  • VDAはデリバリーグループに属し、DaaSに登録されている必要があります。
  • 移行先のVDAが現在のVDAのオペレーティングシステムをサポートしていること。

Studioを使用したVDAのアップグレード

一般的なワークフロー

Studioを使用してVDAをアップグレードする一般的なワークフローは次のとおりです。
  1. カタログのVDAアップグレードを有効にする。
  2. VDAはカタログごとにアップグレードします。マシンごとのVDAアップグレードは現在利用できません。詳細については、「VDAの自動アップグレードを構成する」を参照してください。
    注:
    カタログのVDAアップグレードをスケジュールすると、そのカタログ内のすべてのマシンがアップグレードの対象に含まれます。そのため、アップグレードを開始する前に、これらのマシンをバックアップすることをお勧めします。
  3. VDAアップグレードプロセスは、追加コンポーネントのアップグレードや、復元などの機能の使用をサポートしていません。これら2つの手順はスキップしてください。
  4. アップグレード時間やアップグレード失敗しきい値など、スケジューリングオプションを構成します。失敗しきい値は、プロセスが停止されるかアラートがトリガーされるまでに許容される失敗したアップグレードの数を決定する可能性があります。
  5. VDAインストーラーの場所として「ローカルファイル共有を使用」を選択します。パスをWindows UNC形式で指定します（例：\\\\server\share\path）。
  6. 「セッションの強制ログオフ」オプションは、VDAアップグレード中にユーザーセッションがどのように処理されるかを制御します。Studio UIでは切断されたセッションのみログオフできますが、PowerShellではすべてのセッション（接続済みおよび切断済み）をログオフできます。ログオフは即座には行われません。VDAアップグレードサービスは、VDAアップグレードエージェントがアップグレードスケジュールを照会しようとして切断されたセッションを見つけた後にログオフを開始します。その後、エージェントは15分間待機してから照会を再試行します。

PowerShellを使用したVDAのアップグレード

WindowsでRemote PowerShell SDKを使用してVDAアップグレードを構成できます。Remote PowerShell SDKの詳細については、「Citrix DaaS Remote PowerShell SDK」を参照してください。
PowerShellコマンドレットは次のとおりです。
  • Get-VusCatalog
    このコマンドレットを使用して、Name、Uid、Uuid、UpgradeState（Available、UpToDate、Scheduled、Unknown）、Upgrade scheduled、およびStateId（Upgrade scheduledのステータス）などのカタログの詳細を取得します。
  • Get-VusMachine
    このコマンドレットを使用して、MachineName、Uid、Uuid、UpgradeState (Available、UpToDate、Scheduled、Unknown)、および StateId (Upgrade scheduled のステータス) などのマシンの詳細を取得します。
  • Get-VusComponentVersion
    このコマンドレットを使用して、VDA がコンポーネントバージョンを報告したかどうかを確認します。MachineId を使用して VDA をフィルター処理します。MachineId は Get-BrokerMachine からの UUID です。
  • New-VusMachineUpgrade
    このコマンドレットを使用して、マシンレベルで VDA アップグレードを構成します。
  • New-VusCatalogSchedule
    このコマンドレットを使用して、マシンカタログレベルで VDA アップグレードをスケジュールします。
例:
Get-BrokerMachine -DNSName 'u22-test*'

New-VusCatalogSchedule -CatalogName "test-catalog" -UpgradeNow -DurationInHours 2 -LogoffOption ActiveAndDisconnectedSessions -VdaServerPackageUri "\\root\xendesktopvda_24.11.0.1-1.ubuntu22.04_amd64.deb"

Get-VusComponent -CatalogName 'test-catalog'

Get-VusCatalog -Name 'test-catalog'

トラブルシューティング

アップグレードプロセスの核となるのは、VDA Upgrade Agent サービス (ctxvua) です。これは仲介役として機能し、VDA Upgrade Service と通信し、OS 関連の操作のために /opt/Citrix/VDA/sbin/update_helper.sh スクリプトを実行します。アップグレード中、プロセスに関する情報はレジストリに保存されます。

レジストリ

コマンド /opt/Citrix/VDA/bin/ctxreg dump |grep -i UpdateAgent を使用して、VDA Upgrade Agent に関連するレジストリ設定を調べます。これにより、構成の問題やアップグレードプロセス自体の問題が明らかになる可能性があります。
  1. 構成の確認: ctxvua サービスの構成ファイルは /etc/xdl/updateagent.conf にあります。このファイルを確認することで、誤った構成を特定できます。

ログ

トラブルシューティングには、以下のログファイルが重要です。
  • /var/log/xdl/vua.log: ctxvua サービスのログファイル。これは、アップグレードエージェントの操作に関連する問題を確認するための主要なログです。ctxvua サービスの構成ファイルは /etc/xdl/updateagent.conf にあります。このファイルを確認することで、誤った構成を特定できます。
  • /var/log/xdl/update_helper.log: update_helper.sh スクリプトのログファイル。このログは、アップグレード中の OS レベルのタスクに関連する問題を診断するために不可欠です。

一般的な問題

このセクションでは、VDA アップグレード中に発生する一般的な問題について説明します。特に、Studio で無効になっているオプションと「Upgrade Unknown」の状態に焦点を当てます。

よくある問題1: 無効なアップグレードオプション

症状: 特定のカタログで、Studioの「アップグレードタイプの選択」および「VDAのアップグレード」オプションが無効（グレー表示）になっています。
解決策: 使用しているカタログタイプでVDAアップグレードサービスがサポートされているか確認してください。サポートされていない場合、これらの自動アップグレード機能を使用することはできず、アップグレードを手動で管理する必要があります。

よくある問題2: 「アップグレード不明」の状態

症状: マシンカタログでVDAアップグレードサービスを有効にした後、「アップグレード状態」が期待どおりに「利用可能」または「最新」に変わらず、「不明」のままになります。「アップグレード不明」は一時的な状態です。最終的には「利用可能」または「最新」のいずれかに更新されるはずです。
「アップグレード不明」のトラブルシューティング手順:
  1. VDAアップグレードエージェントがバージョンを報告していることを確認します。
    • 手順1a: マシンのUUIDを取得します:
      Get-BrokerMachine -DNSName '<hostname>'
    • 手順1b: エージェントによって報告されたコンポーネントバージョンを確認します:
      Get-VusComponentVersion -MachineId "<UUID>"
      Get-VusComponentVersionコマンドが空白を返す場合、VDAアップグレードエージェントがそのバージョンを報告していないことを意味します。これは、VDAが「ハード登録」されている可能性があることを示しています（マシンカタログとデリバリーグループの両方の設定を確認してください）。また、ターゲットVDAにVDAアップグレードエージェントがインストールされていないか、実行されていない可能性も示しています。
  2. VDAアップグレードサービスの同期を確認します。
    手順2a: VDAアップグレードサービスがBrokerデータベースからマシンを同期したかどうかを確認します:
    ```
    Get-VusEntityUnit -EntityUUID ""
    ```
    既知の場合は""を実際のEntityUUIDに置き換えるか、すべて取得するために指定せずに実行します。これが空白であると確認された場合、マシンがVDAアップグレードサービスサーバーと同期されていないことを示している可能性があります。
    手順2b: マシンが同期されていない場合、VDAアップグレードサービスが同期するまでしばらく時間を置きます。その後、「アップグレードタイプ」が設定されていることを確認します。

参照