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

最終公開日 : Nov 13, 2026

はじめに

以前は、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」を無視してください。Linuxでは、「VDA Upgrade State」のみが関連します。
  • 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アップグレードを有効にする。
    • カタログを作成する際に(/ja-jp/citrix-daas/install-configure/machine-catalogs-create#vda-upgrade-optional)、VDAアップグレードを有効にできます。
    • カタログを編集する際に(/ja-jp/citrix-daas/install-configure/machine-catalogs-manage#configure-vda-upgrade-settings-by-editing-a-catalog)、VDAアップグレードを有効にできます。
  2. VDAはカタログ単位でアップグレードします。マシンごとのVDAアップグレードは現在利用できません。詳細については、(/ja-jp/citrix-daas/install-configure/machine-catalogs-manage#configure-auto-upgrade-for-vdas)を参照してください。
    注:
    カタログのVDAアップグレードをスケジュールすると、カタログ内のすべてのマシンがアップグレードの対象に含まれます。そのため、アップグレードを開始する前にこれらのマシンをバックアップすることをお勧めします。
  3. VDAアップグレードプロセスは、追加コンポーネントのアップグレードや、復元などの機能の使用をサポートしていません。これら2つの手順はスキップしてください。
  4. アップグレード時間やアップグレード失敗しきい値など、スケジューリングオプションを設定します。失敗しきい値は、プロセスが停止されるかアラートがトリガーされるまでに許容される失敗したアップグレードの数を決定する可能性があります。
  5. VDAインストーラーの場所として「Use local file share」を選択します。Windows UNC形式でパスを指定します(例: \\\\server\share\path)。
  6. 「Force logoff sessions」オプションは、VDAアップグレード中にユーザーセッションがどのように処理されるかを制御します。Studio UIでは切断されたセッションのみログオフできますが、PowerShellではすべてのセッション(接続済みおよび切断済み)をログオフできます。ログオフは即座には行われません。VDAアップグレードエージェントがアップグレードスケジュールを照会しようとして切断されたセッションを見つけた後、VDAアップグレードサービスがログオフを開始します。その後、エージェントは照会を再試行する前に15分間待機します。

PowerShellを使用してVDAをアップグレードする

Windows上のRemote PowerShell SDKを使用してVDAアップグレードを構成できます。Remote PowerShell SDKの詳細については、(/ja-jp/citrix-daas/sdk-api#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がコンポーネントバージョンを報告したかどうかを確認します。VDAをフィルタリングするには、MachineIdを使用します。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アップグレードエージェントサービス(ctxvua)を中心に展開されます。これは仲介役として機能し、VDAアップグレードサービスと通信し、OS関連の操作のために**/opt/Citrix/VDA/sbin/update_helper.sh**スクリプトを実行します。アップグレード中、プロセスに関する情報はレジストリに保存されます。

レジストリ

コマンド /opt/Citrix/VDA/bin/ctxreg dump |grep -i UpdateAgent を使用して、VDAアップグレードエージェントに関連するレジストリ設定を調べます。これにより、構成の問題やアップグレードプロセス自体の問題が明らかになる可能性があります。
  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アップグレードサービスが同期するまでしばらく時間を置きます。その後、「アップグレードタイプ」が設定されていることを確認します。

参照