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」は無視してください。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でどちらのオプションを使用しても、アップグレードに影響はありません。
  • VDAsのダウングレードはサポートされていません。

前提条件

  • コントロールプレーン: 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アップグレードエージェントサービス (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アップグレードサービスが同期するまでしばらく待機します。その後、「アップグレードタイプ」が設定されていることを確認します。

参照