結論：2026年7月時点では、Azureの対象となる既存VMシリーズ上で動くNVAは、停止・割り当て解除後の起動、再デプロイ、新規作成などを契機にMANA対応ハードウェアへ配置される可能性があります。ただし、LegacyVMNVAタグはすべてのNVAへ一律に付けるものではありません。Microsoftは、Accelerated Networkingを使い、MANA対応ハードウェア上で実際に性能低下を観測するワークロードに限って、一時的な回避策として使うよう案内しています。Public cloudのMANA対象Cobalt 100・Intel v5は2026年5月26日、Intel v1-v4は2026年8月1日が最も早い配置開始時期で、タグは2027年5月31日以降は効きません。まずVMシリーズ、Accelerated Networking、NVAベンダーのMANA対応、OS・ドライバー、DPDK要件を確認し、必要な場合だけ段階的にポリシーを割り当ててください。 最新の画面名や提供条件は更新で変わるため、以下の順番で確認してください。
最初に確認するポイント
| 症状・条件 | 主な原因 | 最初の確認 |
|---|---|---|
| 対象の既存VMシリーズでNVAを運用し、Accelerated Networkingが有効になっている | 新規配置、停止・割り当て解除後の起動、再デプロイなどでMANA対応ハードウェアへ配置される可能性があります。 | VMサイズがMicrosoftの対象一覧に含まれるか、各NICでAccelerated Networkingが有効か、NVAベンダーがMANAを明示的にサポートしているか確認します。 |
| Linux VMでPCIデバイス1414:00baは見えるが、MANA経由の通信が確認できない | MANAハードウェアは見えていても、mana.koがない、VFが正しくbondされていない、またはOSが必要なドライバーを備えていない可能性があります。 | lspci、mana.ko検索、ip link、ethtoolのVFカウンターを順に確認します。 |
| WindowsでGet-PnpDeviceにはMANAが出るが、Get-NetAdapterにMicrosoft Azure Network Adapterが出ない | MANA対応ハードウェアへ配置されている一方、ゲストOSにMANAドライバーがない可能性があります。 | Get-PnpDeviceとGet-NetAdapterの結果を比較し、OS更新またはMicrosoft提供ドライバーの適用可否を確認します。 |
| DPDKベースNVAで、MANA配置後に起動失敗、送受信キューエラー、低スループットが発生する | MANAではEAL引数、MACアドレスによるインターフェイス指定、カーネル、rdma-core、DPDK PMDなどの要件が従来NICと異なります。 | Linux kernel、DPDK、rdma-core、MANA PMDの最低要件と、NVAベンダーが提供する対応イメージを確認します。 |
| MANA非対応OSでもネットワークは動くが、高同時接続時に性能が落ちる | MANAを利用できない場合はNetVSCへフォールバックし、通常通信は継続できる一方、高い同時接続数で性能低下が起こる可能性があります。 | VFカウンターが増えているかを確認し、接続数、PPS、遅延、ドロップを変更前ベースラインと比較します。 |
安全な対処手順
1. 対象VMシリーズと2026年の期限を正確に判定する
最初に、NVAがMicrosoftのMANA対象となる既存VMシリーズに載っているか確認します。公式一覧にはDsv5、Dv5、Esv5、Ev5、v4、v3、Bsv2、Dv2、Fsv2、Lsなど複数の系列が含まれます。Public cloudではMANA対象Cobalt 100・Intel v5の最も早い配置開始時期は2026年5月26日で、2026年7月時点ですでに経過しています。Intel v1-v4は2026年8月1日です。日付だけで判断せず、実際のVMサイズ、NIC設定、NVA製品を台帳化します。
- VM名、リージョン、VMサイズ、NVA製品・バージョンを一覧化する
- 各NICのAccelerated Networking有効状態を確認する
- 新規作成、再デプロイ、停止・割り当て解除予定を洗い出す
- Cobalt 100・Intel v5とIntel v1-v4を分けて期限を管理する
az vm show --resource-group <resource-group> --name <vm-name> --query "{size:hardwareProfile.vmSize,tags:tags,provisioningState:provisioningState}" -o jsonaz network nic show --resource-group <resource-group> --name <nic-name> --query "{acceleratedNetworking:enableAcceleratedNetworking,vm:virtualMachine.id}" -o json注意：「2026年8月1日まで全環境が安全」とは限りません。Cobalt 100・Intel v5の最早日はすでに経過しており、停止・割り当て解除や再デプロイで配置が変わる可能性があります。
2. NVAベンダーのMANA対応と移行条件を確認する
NVAはネットワークハードウェアとドライバーへの依存が強いため、OSがMANA対応というだけでは十分ではありません。製品名、Marketplaceプラン、イメージバージョン、データプレーン方式、DPDK利用有無をベンダーへ提示し、MANA対応済みの組み合わせと必要なアップグレードを確認します。Azure Marketplace外で購入したNVAやマネージドサービス型NVAも対象になり得るため、提供元へ確認します。
- ベンダーが明示するMANA対応バージョンを確認する
- データプレーンがカーネル、SR-IOV、DPDKのどれか確認する
- Marketplace外やマネージドサービスの適用方法を提供元へ確認する
- 本番と同じVMサイズ・イメージ・NIC数で検証環境を作る
注意：一般的なLinuxやWindowsのMANA対応結果だけで、NVA製品の対応を推定しないでください。製品固有のドライバーやパケット処理方式が影響します。
3. Linux・WindowsでMANAデバイスと実通信を確認する
LinuxではPCIデバイス、mana.ko、bondされたVF、VFカウンターを確認します。WindowsではGet-PnpDeviceでハードウェア、Get-NetAdapterでドライバー、Get-NetAdapterStatisticsで実通信を確認します。デバイスが見えるだけでは利用中とは限らず、統計値が増えることまで確認します。変更前後でPPS、帯域、接続数、遅延、ドロップを同じ負荷条件で比較します。
- Linuxは1414:00baのPCIデバイスを確認する
- Linuxはmana.koとethN配下のenP*インターフェイスを確認する
- WindowsはPnpDeviceとNetAdapterの両方を確認する
- VFカウンターが0のままならMANAを利用していない可能性を調べる
lspci -d 1414:00ba:0200grep /mana*.ko /lib/modules/$(uname -r)/modules.builtin || find /lib/modules/$(uname -r)/kernel -name 'mana*.ko*'ip linkethtool -S eth0 | grep -E '^[[:space:]]+vf'Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^PCI\\VEN_1414&DEV_00BA&' }Get-NetAdapter | Where-Object InterfaceDescription -Like '*Microsoft Azure Network Adapter*'Get-NetAdapter | Where-Object InterfaceDescription -Like '*Microsoft Azure Network Adapter*' | Get-NetAdapterStatistics注意：管理用NICやSSH/RDP経路を止める検証は、帯域外アクセスとロールバック手順を用意した隔離環境で行ってください。
4. 必要な場合だけLegacyVMNVAポリシーを段階適用する
LegacyVMNVAは、Accelerated Networkingを使い、MANA対応ハードウェア上で性能低下を観測するNVAが移行を終えるまでの一時回避策です。Microsoftの組み込みAzure Policyを小さいスコープへ割り当て、safe rolloutでリージョンやリソース種別を段階的に広げます。既存デプロイにはremediation taskでタグを付けた後、reapplyを実行して有効化します。ポリシーのminor version変更を自動適用するか、1.*.*を指定します。
- 問題が再現したNVAと移行未完了のNVAだけを候補にする
- ResourceまたはResource Groupなど小さいスコープから始める
- 既存リソースはremediation taskとreapplyの両方を実施する
- Policy complianceでタグの適用状態を確認する
- 除外が必要ならPolicy exemptionを使う
az vm reapply --resource-group <resource-group-name> --name <vm-name>az rest --method post --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmss-name>/reapply?api-version=2025-11-01"注意：LegacyVMNVAは恒久対策ではなく、2027年5月31日以降は効きません。ODCRと併用すると利用可能な配置プールが減り、そのVMにODCRのSLA保証が適用されないとMicrosoftは説明しています。
5. 新しいVM世代とMANA対応構成へ移行してタグを外す
最終目標は、LegacyVMNVAへ依存せず、NVAベンダーがサポートする新しいVMシリーズ、OS、ドライバー、データプレーンへ移行することです。DPDKではMANA PMD、カーネル、rdma-core、EAL引数、MACアドレス指定を確認します。検証、カナリア、本番の順に展開し、変更前後の接続数、PPS、帯域、遅延、パケットドロップを比較します。安定後にタグとポリシー割り当てを段階的に外します。
- ベンダー推奨のNVAイメージと新しいVMサイズを選ぶ
- DPDKはkernel、DPDK、rdma-core、MANA PMD要件を満たす
- フェイルオーバーを含む負荷試験を行う
- カナリアから段階的に本番展開する
- 2027年5月31日より十分前にタグ不要の構成へ移行する
lspci -d 1414:00ba:0200uname -rdpdk-testpmd --version注意：DPDK向けのカーネル、hugepages、NICバインドを本番NVAへ直接変更すると通信断につながります。必ずベンダー手順と検証済みイメージを使用してください。
よくある質問
対象VMシリーズのNVAにはすべてLegacyVMNVAタグを付けるべきですか？
いいえ。Microsoftは、Accelerated Networkingを利用し、MANA対応ハードウェア上で性能低下を観測するワークロードにだけタグが必要だと説明しています。ベンダーがMANA対応を明示し、検証でも問題がないNVAへ一律にタグを付けると、移行を遅らせ、配置容量やODCRの扱いに不要な影響を与える可能性があります。
LegacyVMNVAタグを付ければ2027年以降もMANAを避けられますか？
避けられません。タグは移行期間の一時回避策で、2027年5月31日以降は効かなくなります。それまでにベンダー対応版、対応OS・ドライバー、新しいVMシリーズなどへ移行し、タグなしで動作する状態を確認してください。
OSがMANAに対応していないと直ちに通信断になりますか？
必ず通信断になるとは限りません。Microsoftは、MANAを利用できないOSではNetVSCへフォールバックし、通常のネットワーク通信を継続できると説明しています。ただし、高い同時接続数で性能低下が起こる可能性があり、NVAやDPDKは製品固有の依存があるため、ベンダー確認と負荷試験が必要です。
公式情報
画面や仕様が異なる場合は、利用中の製品・契約・管理ポリシーを確認したうえで公式情報を参照してください。
- Microsoft Learn: NVAのMANA対応とLegacyVMNVA一時例外
- Microsoft Learn: 既存VMサイズのMANA対象、影響、対象シリーズ
- Microsoft Learn: Linux VMでMANAを確認する
- Microsoft Learn: Windows VMでMANAを確認する
- Microsoft Learn: MANAとDPDK on Linuxの要件・確認
まとめ
原因を一つずつ切り分け、変更前の状態と結果を記録しながら進めることが重要です。操作後は同じ症状が再発しないか確認し、組織管理の端末ではポリシー変更を管理者へ確認してください。
コメント