リリース 6.0(1) では、次のサポートが追加されています。

• Cisco UCS サーバーのインターネットプロトコル バージョン 6（IPv6）を使用した IPv6 iSCSI UEFI ブートのサポート。これにより、IPv6 対応 IP ネットワークへのシームレスな統合が可能になります。IPv4 による制限に対応し、次世代のインフラストラクチャ展開の拡張性と管理を向上させます。

• Windowsの NDIS Poll モード機能のサポート：Cisco UCS VICドライバは、 Windows Server 2025 以降で NDIS Poll モード機能をサポートしています。この機能を使用すると、ドライバ自体にスケジューリングを行わせるのではなく、オペレーティング システム（OS）が着信および発信トラフィックのサービス プロセスをスケジュールできます。

  さらに、OS は低い実行レベルでドライバの処理サービスを実行するため、システムの外部イベントに対する応答性が高まります。

  この機能は、 Windows Server 2025 でデフォルトで有効になっており、Cisco UCS VIC 15000 シリーズ アダプタでサポートされています。

  （注）	Windowsドライバを使用した NDIS Poll モードの詳細については、 [Microsoft] > [Windows ドライバ（Windows Driver）] の順に選択し、[ネットワーク（Network）] の資料を参照してください。 また、 Cisco UCS Manager VICコンフィギュレーション ガイド の Windows 向け NDIS Poll モードのサポートのセクションを参照してください。

• RSS を使用したマルチ TX キュー：この構成では、Cisco UCS Manager のイーサネットアダプタ ポリシーを使用することにより、Receive Side Scaling（RSS）と複数の送信（Tx）および受信（Rx）キューが有効になり、 VMware ESXi 8.0 U3 以降のバージョンでネットワーク パフォーマンスを向上できます。

  この構成は、Cisco UCS VIC 1400、14000、および 15000 シリーズ アダプタの eNIC ドライバ 2.0.17.0 でサポートされています。

  詳細については、Cisco UCS Manager Networkd Management Guide の Configuring an Ethernet Adapter Policy to Support RSS and Multiple Transmit Queues on VMware ESXi の項を参照してください。

ESX ENIC ドライバの更新

NENIC/NENIC(RDMA) バージョン 2.0.17.0 は、ESX 7.0 U1、ESX 7.0 U2、ESX 7.0 U3、ESX 8.0 以降でサポートされています。

ESX NENIC_ENS バージョン 1.0.9.0

NENIC_ENS バージョン 1.0.9.0 は、ESX 7.0 U1、ESX 7.0 U2、ESX 7.0 U3、ESX 8.0 以降でサポートされています。

ESX FNIC ドライバの更新

ネイティブ FNIC バージョン 5.0.0.45

ネイティブ FNIC ドライバ バージョン 5.0.0.45 は、ESX 8.0、ESX 8.0U1、および ESX 8.0U2 でサポートされています。

ネイティブ FNIC バージョン 5.0.0.46

ネイティブ FNIC ドライバ バージョン 5.0.0.46 は、ESX 7.0 U1、ESX 7.0 U2、ESX 7.0 U3、ESX 8.0 U3、および ESX 9.0 でサポートされています。

（注）

ドライバ バージョン 5.0.0.x は、ネイティブ FCとFC NVME の両方の機能をサポートしています。 ESX FC NVME は、 VIC 1400 と 15000 シリーズ アダプタでサポートされています。 FDMI は、VIC 1400 および 15000 シリーズ アダプタでネイティブ FNIC ドライバ バージョン 5.0.0.x を使用してサポートされています。 INT-x 割り込みモードは、ESX nfnic ドライバおよび Windows nenic ドライバではサポートされていません。 FPIN 機能はESXi 8.0U3 および ESX 9.0 でサポートされています。

Linux ENIC ドライバ更新

ENIC バージョン 1160.x

このドライバは、次の Linux オペレーティング システムのバージョンをサポートしています。

• Red Hat Enterprise Linux 8.8、8.10、9.2、9.4、9.6、10.0

• SUSE Linux Enterprise Server 12 SP5、15 SP4、15 SP5、15 SP6

• Ubuntu Server 22.04、22.04.1、22.04.2、22.04.3、22.04.4、22.04.5、24.04、24.04.1（6.8.0-51カーネル）、24.04.2

ENIC バージョン 939.x

このドライバは、次の Linux オペレーティング システムのバージョンをサポートしています。

• -Citrix ハイパーバイザ 8.4 LTSR

Linux FNIC ドライバ更新

ユニファイド FNIC ドライバ更新 2.0.0.10x

このドライバは、次の Linux オペレーティング システムのバージョンをサポートしています。

• Red Hat Enterprise Linux 8.8、8.10、9.2、9.4、9.6、10.0

• SUSE Linux Enterprise Server 12 SP5、15 SP4、15 SP5、15 SP6

ユニファイド FNIC ドライバ更新 2.0.0.9x

このドライバは、次の Linux オペレーティング システムのバージョンをサポートしています。

• Citrix ハイパーバイザ 8.4 LTSR

（注）

RDMA および ENS 機能は、 リリース 4.3(4a) 以降のリリースで、VIC 13xx アダプタではサポートされていません。 RDMA および ENS 機能は、 VIC 14xx アダプタ以降でサポートされています。 fnic マルチキューは、RHEL 8.4+, 9.0+ , SLES 12SP5+ でサポートされています。 FC-NVME は、RHEL 8.4+、RHEL 9.0+、SLES 15SP12+ の Cisco UCS VIC 14xx およびVIC 15xxx アダプタでサポートされています。 FDMI は、RHEL 8.4+、9.0+、SLES 12 SP5、SLES 15 SP4 および SLES 15 SP5 のVIC 14xx アダプタとVIC 15xxx アダプタでサポートされています。 SLES 15 FC NVMe は DM マルチパスでサポートされ、ネイティブ マルチパスはサポートされていません。 ソフトウェアおよびハードウェアの最新のセットについては、サポートマトリックス https://www.cisco.com/c/en/us/products/servers-unified-computing/interoperability.htmlを確認してください。

Windows 2025、2022 および 2019 の NENIC/ENIC ドライバの更新

Windows Server 2025 および 2022 の NENIC バージョン 5.16.18.8

• このドライバの更新は、VIC 1400、14000 および 15000 シリーズ アダプタとサポート対象の QoS 変更に対して、VMMQ と RDMA ドライバを提供します。

• NDIS Poll Mode 機能は、Cisco UCS VIC 15000 シリーズ アダプタを搭載した Windows Server 2025 でのみサポートされています。

Windows Server 2022 および 2019 ENIC バージョン 4.4.0.15

• このドライバの更新は、VIC 1300 シリーズ アダプタ用の Spectre 準拠ドライバを提供します。

Windows 2025、2022 および 2019 の FNIC ドライバの更新

Windows Server 2025、2022 および 2019 FNIC バージョン 3.3.0.24

• このドライバの更新は、VIC 15000、1400、14000、および VIC 1300 アダプタ用に、Spectre 準拠の fNIC ドライバを提供します。

Windows 2025、2022 および 2019 用のスタンドアロン ラック サーバー PCIe インターフェイスによるサポートのための VIC 管理ドライバ

Windows Server 2025、2022 および 2019 VIC管理ドライバ バージョン 1.0.0.1

このドライバの更新は、VIC 1400 および 15000 シリーズ アダプタ用に提供されています。

次の表は、リリース 4.3 で解決済みの不具合のリストです。

次の表は、リリース 4.2 で解決済みの不具合のリストです。

リリース 4.2(1d) では解決済みの問題はありません。

次の表に、解決されていない不具合を示します。

仮想マシン マルチ キュー（14xx および 15xxx vNIC）

vport の VMMQ 状態の無効化が有効になっていません。

回避策

キューを無効にして 1 に割り当てるには、power シェルコマンドを使用します。

#Get-VMNetworkAdapter -vmname * | Set-VMNetworkAdapter -VmmqEnabled $false -VmmqQueuePairs 1

Cisco UCS VICファームウェアバージョン 4.1(2b) 以降の Cisco UCS VIC アダプタは、サードパーティのトランシーバをサポートしていません。

Cisco UCS VICファームウェアバージョン 4.1(2b) 以降の Cisco UCS VIC アダプタは、サードパーティのトランシーバをサポートしません。

4.1(2b) 以降の物理リンクには、シスコ認定のトランシーバまたはケーブル接続を使用してください。

vHBA のFCアダプタ ポリシーでターゲットあたりの LUN が 1024 よりも大きく設定されているが、 FC vNIC に展開される実際の値は 1024 に制限されている場合。

Cisco UCS Manager 4.2(3c) リリース以降では、サービス プロファイルの vHBA のFC アダプタ ポリシーで [ターゲットあたりの LUN（LUNs Per Target）] フィールドが 1024 よりも大きく設定されている場合、 FC vNIC で展開される実際の値は 1024 に制限されます。

この問題は、 VIC アダプタのファームウェアバージョンが古く、 ターゲットあたりの LUN の値が 1024 を超える値をサポートしていないために発生します。

ターゲットあたりの LUN を 1024 よりも大きく設定した場合、RHEL 8.7 が緊急シェルで起動します

ターゲットあたりの LUN が 1024 よりも大きい値に設定され、RHEL 8.7 を実行している複数のパスがある場合、 OS はすべてのパスをスキャンするのに時間がかかります。最終的に、スキャンは失敗し、 OS は緊急シェルで起動します。

OS によってスキャンされる ターゲットあたりの LUN（パス）の数を減らします。

Q-in-Q 転送（14xx および 15xxx VNIC）

ホストによって生成される二重タグ付きフレーム（1Q + 1Q）が VIC によって送信される場合は、 Linux ホストで次のコマンドを設定する必要があります。

1. 二重タグ付き（1Q + 1Q）フレームを送信する必要がある 14xx または 15xxx VNIC で、 VLAN TX オフロードを無効にします。

   ホストからこれを実行し、次の ethtool コマンドを入力します。

   ethtool -K <interface_name> txvlan off

2. VLAN TX オフロード機能がオフになっていることを確認するには、次のコマンドを入力します。

   ethtool -k <interface_name> | grep tx-vlan-offload

Windows ：デフォルトのアダプタポリシー win-HPN-SMBd を、大規模な論理的なプロセッサの値の場合 512+ に変更します

割り込み値を 514 に変更し、更新された設定を再展開します。

物理 NIC モードのサポート

リリース 4.2(3b)以降、物理 NIC モードは完全にサポートされたため、Cisco UCS C シリーズ ラック サーバーの物理 NIC モードから実験的という用語が削除されました。

トランク モードでは 物理 NIC はサポートされていません。

リンクのダウン/アップ後の実行時に ESXCLI のリンク速度が更新されません

この問題は、VMware API がドライバへのリンク ステータスを更新していない場合に発生します。

これを回避するには、FI またはアップ リンク スイッチで次のコマンドを実行します。

sh interface port-channel (uplink Po)

vNIC MTU の設定

Windows の VIC 1400 シリーズ アダプタの MTU は、UCS 設定からではなく、ジャンボ パケットのアドバンスト プロパティから導出されるようになりました。

VIC 14xx アダプタについては、ホスト インターフェイス設定から、vNIC の MTU サイズを変更できます。新しい値は関連付けられた QoS システム クラスで指定された MTU と同等以下でなければなりません。この MTU 値が QoS システム クラスの MTU 値を超えている場合、データ転送中にパケットがドロップされる可能性があります。

RDMA の制限

• ブレードおよびラック サーバ上の VIC 1400 シリーズ Windows ドライバは、アダプタごとに2つ以上の RDMA エンジンをサポートしていません。現在、Windows cは各 RDMA エンジン上にある 4 VPorts の RDMA のみをサポートできます。

• RoCE バージョン 1 は、第 4 世代 Cisco UCS VIC 1400 シリーズ アダプタではサポートされていません。

• UCS Manager は、RoCEv2 対応の vNIC に対してファブリック フェールオーバーをサポートしません。

• RoCEv2 は、NVGRE、NetFlow、および VMQ 機能と同じ vNIC インターフェイスでは使用できません。

• RoCEv2 は usNIC では使用できません。

• RoCEv2 は、GENEVE オフロードでは使用できません。

• RoCEv2 は、ESX とLinux の両方で、SR-IOV と一緒に使用できません。

16 個の vHBAs が最大 I/O キューで設定されている場合設定が失敗する

Cisco UCS Manager では、vHBA ごとに最大 64 個の I/O キューがサポートされています。ただし、16 個の vHBAs を設定すると、各 Vhbas でサポートされる I/O キューの最大数は 59 個になります。Cisco UCS Manager リリース 4.0 (2) では、Vhbas ごとに 59 個の I/O キューを使用して 16 個の vHBAs を設定しようとすると、設定が失敗します。

VM-FEX

ESX VM-FEX および Windows VM FEX はサポートされなくなりました。

INTx 割り込みモード

INTx 割り込みモードは、ESX nenic および nfnic ドライバではサポートされていません。

INTx 割り込みモードは、Windows nenic および fnic ドライバではサポートされていません。

INTx 割り込みモードは、 Linux enic および fnic ドライバではサポートされていません。

FC-NVMe フェイルオーバー

ホストとネットワークの障害から保護するには、複数のイニシエータのゾーン分割を両方のアクティブなコントローラポートで行う必要があります。パッシブ パスは、コントローラに障害が発生した場合にのみアクティブになり、ポート フラップを開始しません。ANA をサポートしていない古いカーネルに基づくオペレーティング システムでは、DM マルチパスでパッシブ パスが正しく処理されず、IO がパッシブ パスに送信される可能性があります。これらの IO 操作は失敗します。

FC-NVMe 名前空間

RHEL 8.5 nvme-cli バージョン 1.14 以降、 nvme list コマンドは fc-nvme 名前空間を表示しません。fc-nvme 名前空間を表示するには、RHEL 8.4 の nvme-cli または 1.15 以降の nvme-cli バージョンを使用してください。

FC-NVMe ESX の構成

ESXiを実行するVIC 15000 および 1400 シリーズ アダプタは現在、 FC-NVMe 名前空間のブロック サイズとして最大 512B のみをサポートしていますが、一部のベンダーは ESXi 7.0 にデフォルトの 4KB ブロック サイズを使用しています。したがって、ターゲットの FC-NVMe 名前空間ブロックは、明示的に 512B として構成する必要があります。[ストレージ（Storage）] で NVMe に移動し、NVMe のブロック サイズを 4KB から 512B に変更します。

また、 FC-NVMe ターゲット コントローラのキューの深さと VM デバイスのキューの深さの間の不一致が原因で発生する I/Oスループットの低下や BUS BUSY エラーの発生を回避するためにも、設定を変更する必要があります。これを回避するには、次のコマンドを実行して、 ESXi ホストから検出されたすべてのコントローラを表示します。

# Esxcli nvme controller list

コントローラのコントローラ キューとキュー サイズのリストを確認します。

# vsish -e get /vmkModules/vmknvme/controllers/controller number/info

同じターゲット上のすべてのコントローラは、同じキュー サイズをサポートします。次に例を示します。

Number of Queues:4
Queue Size:32

VMを調整するには、コントローラのキューサイズと一致するようにVM 上のすべての NVMe デバイスの queue_depth を変更します。たとえば、RHE VM を実行している場合は、次のコマンドを入力します。

# Echo 32 > /sys/block/sdb/ device/queue_depth

次のコマンドを実行して、queue_depth が 32 に設定されていることを確認します。

# cat /sys/block/sdb/ device/queue_depth

（注）	この変更は再起動後は維持されません。

（注）

追加のドライバ構成では、FC- NVMe アダプタを作成するために、アダプタ ポリシーを FCNVMeInitiator に設定することが必要な場合があります。 アダプタ ポリシーは、 [サーバー（Server）] > [サービス プロファイル（Service Profile）] >[ポリシー（Policies）] > [アダプタ ポリシー（Adapter Policies）] [FCアダプタ ポリシーの作成（Create FC Adapter Policy）] の下にあります。 アダプタ ポリシーは、 [サーバー（Server）]、 [サービス プロファイル（Service Profile）]、 [ストレージ（Storage）]、[vHBA の変更 （Modify vHBAs）]の下にあります。

ESXi 7.0 での ANA によるFC -NVMe の有効化

ESXi 7.0 では、ANA はFC- NVMe に対して有効になっていません。これにより、ターゲット側のパス フェールオーバーの障害が発生する可能性があります。

ANA を有効にする手順については、https://docs.netapp.com/us-en/ontap-sanhost/nvme_esxi_7.html#validating-nvmefc のURLを参照してください。