VDAのアップグレード（プレビュー）

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

はじめに

以前は、VDAsのアップグレードには完全な手動介入が必要でした。バージョン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をアップグレードする権限があること。
  • Studioで、VDAアップグレードが適切な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インストーラーの場所として「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の詳細については、「Citrix DaaS Remote PowerShell SDK」を参照してください。
次のPowerShellコマンドレットがあります。
  • Get-VusCatalog
    このコマンドレットを使用して、Name、Uid、Uuid、UpgradeState（Available、UpToDate、Scheduled、Unknown）、Upgrade scheduled、およびStateId（Upgrade scheduledのステータス）などのカタログの詳細を取得します。
  • Get-VusMachine
    このcmdletを使用して、MachineName、Uid、Uuid、UpgradeState (Available、UpToDate、Scheduled、Unknown)、およびStateId (Upgrade scheduled のステータス) などのマシンの詳細を取得します。
  • Get-VusComponentVersion
    このcmdletを使用して、VDAがコンポーネントバージョンを報告したかどうかを確認します。MachineIdを使用してVDAをフィルター処理します。MachineIdはGet-BrokerMachineからのUUIDです。
  • New-VusMachineUpgrade
    このcmdletを使用して、マシンレベルでVDAアップグレードを構成します。
  • New-VusCatalogSchedule
    このcmdletを使用して、マシンカタログレベルで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アップグレードサービスが同期するまでしばらく時間を置きます。その後、「アップグレードタイプ」が設定されていることを確認します。

参照