Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

10.18. 仮想化

https または ssh 経由での仮想マシンのインストールに失敗する場合がある

現在、virt-install ユーティリティーは、https または ssh 接続を介して ISO ソースからゲストオペレーティングシステム (OS) をインストールしようとすると失敗します。たとえば、virt-install --cdrom https://example/path/to/image.iso を使用します。仮想マシンを作成する代わりに、上述の操作は internal error: process exited while connecting to monitor というメッセージが表示されて予期せず終了します。

同様に、https または ssh URL、あるいは Download OS 機能を使用した場合、RHEL 9 Web コンソールを使用したゲストオペレーティングシステムのインストールが失敗し、Unknown driver 'https' エラーが表示されます。

回避策: qemu-kvm-block-curl および qemu-kvm-block-ssh をホストにインストールして、https および ssh プロトコルのサポートを有効にします。別の接続プロトコルまたは別のインストールソースを使用することもできます。

Jira:RHELPLAN-99854[1]

仮想マシンで NVIDIA ドライバーを使用すると Wayland が無効になる

現在、NVIDIA ドライバーは Wayland グラフィカルセッションと互換性がありません。これにより、NVIDIA ドライバーを使用する RHEL ゲストオペレーティングシステムは、Wayland を自動的に無効にし、代わりに Xorg セッションを読み込みます。これは主に以下のシナリオで生じます。

  • NVIDIA GPU デバイスを RHEL 仮想マシンに渡す場合
  • NVIDIA vGPU 仲介デバイスを RHEL 仮想マシンに割り当てる場合

現在、この問題に対する回避策はありません。

Jira:RHELPLAN-117234[1]

Nutanix AHV で LVM を使用する RHEL 9 仮想マシンのクローンを作成または復元すると、ルート以外のパーティションが表示されなくなる

Nutanix AHV ハイパーバイザーをホストとする仮想マシン (VM) で RHEL 9 ゲストオペレーティングシステムを実行する場合、スナップショットから VM を復元するか VM をクローンすると、ゲストが論理ボリューム管理 (LVM) を使用している場合は VM 内の非ルートパーティションを消失させることがあります。これにより、以下の問題が発生します。

  • スナップショットから仮想マシンを復元すると、仮想マシンは起動できず、緊急モードに入ります。
  • クローンを作成して作成した仮想マシンは起動できず、緊急モードに入ります。

これらの問題を回避するには、仮想マシンの緊急モードで以下を行います。

  1. LVM システムデバイスファイルを削除します。 

    # rm /etc/lvm/devices/system.devices
    Copy to Clipboard Toggle word wrap

  2. LVM デバイス設定を再作成します。 

    # vgimportdevices -a
    Copy to Clipboard Toggle word wrap
  3. 仮想マシンを再起動します。

これにより、クローン化または復元された VM を正しく起動できます。

または、問題が発生しないようにするには、VM のクローンを作成する前、または VM のスナップショットを作成する前に、次の手順を実行します。

  1. /etc/lvm/lvm.conf ファイル内の use_devicesfile = 0 行のコメントを解除します。

  2. initramfs を再生成します。これを行うには、仮想マシンで次の手順を実行します。<kernelVersion> は、再構築するカーネルの完全なバージョンに置き換えます。

    1. 現在の initramfs 設定をバックアップします。 

      # cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bak
      Copy to Clipboard Toggle word wrap

    2. initramfs をビルドします。 

      # dracut -f /boot/initramfs-<kernelVersion>.img  <kernelVersion>
      Copy to Clipboard Toggle word wrap
  3. 仮想マシンを再起動して、正常に起動したことを確認します。

Jira:RHELPLAN-114103[1]

Milan 仮想マシンの CPU タイプは、AMD Milan システムで利用できないことがある

一部の AMD Milan システムでは、Enhanced REP MOVSB (erms) および Fast Short REP MOVSB (fsrm) 機能フラグがデフォルトで BIOS で無効になっています。したがって、Milan CPU タイプは、これらのシステムで利用できない可能性があります。さらに、機能フラグ設定が異なる Milan ホスト間の仮想マシンのライブマイグレーションが失敗する可能性があります。

回避策: ホストの BIOS で erms と fsrm を手動でオンにします。

Jira:RHELPLAN-119655[1]

フェイルオーバー設定のある hostdev インターフェイスは、ホットアンプラグされた後にホットプラグすることはできません

フェイルオーバー設定の hostdev ネットワークインターフェイスを実行中の仮想マシン (VM) から削除した後、現在、インターフェイスを同じ実行中の VM に再接続することはできません。現在、この問題に対する回避策はありません。

Jira:RHEL-7337

フェイルオーバー VF を使用した仮想マシンのポストコピーライブマイグレーションが失敗する

現在、仮想マシンが、仮想機能 (VF) フェイルオーバー機能が有効になっているデバイスを使用している場合、実行中の仮想マシン (VM) のポストコピー移行の試行は失敗します。

回避策: ポストコピー移行ではなく、標準の移行タイプを使用します。

Jira:RHEL-7335

ライブマイグレーション中にホストネットワークが VF と VM に ping できない

設定済みの仮想機能 (VF) で仮想マシン (仮想 SR-IOV ソフトウェアを使用する仮想マシンなど) のライブマイグレーションを行う場合、仮想マシンのネットワークは他のデバイスに表示されず、ping などのコマンドで仮想マシンに到達できません。ただし、移行が終了すると、問題は発生しなくなります。

Jira:RHEL-7336

AVX を無効にすると、仮想マシンが起動できなくなる

Advanced Vector Extensions (AVX) をサポートする CPU を使用するホストマシンで、現在、AVX を明示的に無効にして VM を起動しようとすると失敗し、代わりに VM でカーネルパニックが発生します。現在、この問題に対する回避策はありません。

Jira:RHELPLAN-97394[1]

ドメイン SID の不一致により、移行した IdM ユーザーがログインできない可能性がある

ipa migrate-ds スクリプトを使用して IdM デプロイメントから別のデプロイメントにユーザーを移行する場合、そのユーザーの以前のセキュリティー識別子 (SID) には現在の IdM 環境のドメイン SID がないため、ユーザーが IdM サービスを使用する際に問題が発生する可能性があります。たとえば、これらのユーザーは kinit ユーティリティーを使用して Kerberos チケットを取得できますが、ログインできません。

回避策: ナレッジベースのソリューション記事 Migrated IdM users unable to log in due to mismatching domain SIDs を参照してください。

Jira:RHELPLAN-109613[1]

ネットワークインターフェイスのリセット後に Windows VM が IP アドレスの取得に失敗する

ネットワークインターフェイスの自動リセット後に、Windows 仮想マシンが IP アドレスの取得に失敗することがあります。その結果、VM はネットワークに接続できません。

回避策: Windows Device Manager でネットワークアダプタードライバーを無効にしてから再度有効にします。

Jira:RHEL-11366

仮想 CPU をホットプラグした後、Windows Server 2016 VM が動作を停止することがある

現在、Windows Server 2016 ゲストオペレーティングシステムで実行中の仮想マシン (VM) に仮想 CPU を割り当てると、仮想マシンが予期せず終了したり、応答しなくなったり、再起動したりするなど、さまざまな問題が発生する可能性があります。現在、この問題に対する回避策はありません。

Jira:RHELPLAN-63771[1]

NVIDIA パススルーデバイスを備えた VM での冗長エラーメッセージ。

RHEL 9.2 以降のオペレーティングシステムを搭載した Intel ホストマシンを使用している場合、パススルー NVDIA GPU デバイスを備えた仮想マシン (VM) で、次のエラーメッセージが頻繁に記録されます。 

Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
Copy to Clipboard Toggle word wrap

ただし、このエラーメッセージは VM の機能には影響しないため、無視してかまいません。詳細は、Red Hat ナレッジベース を参照してください。

Jira:RHELPLAN-141042[1]

ホストで OVS サービスを再起動すると、実行中の VM でネットワーク接続がブロックされることがある

ホストで Open vSwitch (OVS) サービスが再起動またはクラッシュすると、このホストで実行されている仮想マシン (VM) はネットワークデバイスの状態を回復できません。その結果、仮想マシンがパケットを完全に受信できなくなる可能性があります。

この問題は、virtio ネットワークスタックで圧縮された virtqueue 形式を使用するシステムのみに影響します。

回避策: virtio ネットワークデバイス定義で packed=off パラメーターを使用して、packed virtqueue を無効にします。圧縮された virtqueue を無効にすると、状況によっては、ネットワークデバイスの状態を RAM から回復できます。

Jira:RHEL-333

中断されたポストコピー仮想マシン移行の回復が失敗することがある

仮想マシン (VM) のポストコピー移行が中断された後、同じ受信ポートですぐに再開されると、移行は Address already in use のエラーで失敗する可能性があります。

回避策: ポストコピー移行を再開する前に少なくとも 10 秒待つか、移行の復旧には別のポートに切り替えてください。

Jira:RHEL-7096

AMD EPYC CPU で NUMA ノードマッピングが正しく機能しない

QEMU は、AMD EPYC CPU の NUMA ノードマッピングを正しく処理しません。これにより、NUMA ノード設定を使用する場合、これらの CPU を持つ仮想マシン (VM) のパフォーマンスに悪影響が及ぶ可能性があります。さらに、VM は起動時に以下のような警告を表示します。 

sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency.
WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80
Copy to Clipboard Toggle word wrap

回避策: NUMA ノード設定に AMD EPYC CPU を使用しないでください。

Jira:RHELPLAN-150884[1]

PCIe ATS デバイスが Windows 仮想マシンで動作しない

Windows ゲストオペレーティングシステムを使用して仮想マシン (VM) の XML 設定で PCIe アドレス変換サービス (ATS) デバイスを設定しても、ゲストが仮想マシンの起動後に ATS デバイスを有効にしません。これは、Windows が現在 virtio デバイス上の ATS をサポートしていないためです。

詳細は、Red Hat ナレッジベース を参照してください。

Jira:RHELPLAN-118495[1]

virsh blkiotune --weight コマンドが正しい cgroup I/O コントローラー値を設定できない

現在、virsh blkiotune --weight コマンドを使用して VM weight を設定しても、期待どおりに機能しません。このコマンドは、cgroup I/O コントローラーインターフェイスファイルに正しい io.bfq.weight 値を設定できません。現時点では回避策はありません。

Jira:RHELPLAN-83423[1]

NVIDIA A16 GPU を使用して仮想マシンを起動すると、ホスト GPU が動作を停止する場合がある

現在、NVIDIA A16 GPU パススルーデバイスを使用する仮想マシンを起動すると、ホストシステム上の NVIDIA A16 GPU 物理デバイスが動作を停止する場合があります。

この問題を回避するには、ハイパーバイザーを再起動し、GPU デバイスの reset_method を bus に設定します。 

# echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
# cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
bus
Copy to Clipboard Toggle word wrap

詳細は、Red Hat ナレッジベースの記事 を参照してください。

Jira:RHEL-7212[1]

ストレージエラーが原因で Windows 仮想マシンが応答しなくなる可能性がある

Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) では、I/O 負荷が高いときにシステムが応答しなくなることがあります。このような場合、システムは viostor Reset to device, \Device\RaidPort3, was issued エラーをログに記録します。現在、この問題に対する回避策はありません。

Jira:RHEL-1609[1]

特定の PCI デバイスを搭載した Windows 10 仮想マシンが起動時に応答しなくなることがある

現在、Windows 10 ゲストオペレーティングシステムを使用する仮想マシン (VM) は、ローカルディスクバックエンドを備えた virtio-win-scsi PCI デバイスが仮想マシンにアタッチされている場合、起動中に応答しなくなる可能性があります。

回避策: multi_queue オプションを有効にして仮想マシンを起動します。

Jira:RHEL-1084[1]

メモリーバルーンデバイスセットが設定された Windows 11 仮想マシンが再起動中に予期せず終了することがある

現在、Windows 11 ゲストオペレーティングシステムとメモリーバルーンデバイスを使用する仮想マシン (VM) の再起動が、DRIVER POWER STAT FAILURE ブルースクリーンエラーで失敗する場合があります。

Jira:RHEL-935[1]

virtio バルーンドライバーは、Windows 10 および Windows 11 仮想マシンでは動作しないことがある

特定の状況下では、Windows 10 または Windows 11 ゲストオペレーティングシステムを使用する仮想マシン (VM) 上で virtio-balloon ドライバーが正しく動作しません。その結果、そのような仮想マシンは割り当てられたメモリーを効率的に使用できない可能性があります。

Jira:RHEL-12118

Windows 仮想マシンの virtio ファイルシステムのパフォーマンスは最適ではない

現在、Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) 上で virtio ファイルシステム (virtiofs) が設定されている場合、仮想マシン内の virtiofs のパフォーマンスは、Linux ゲストを使用する仮想マシンよりも大幅に低下します。現在、この問題に対する回避策はありません。

Jira:RHEL-1212[1]

Windows 仮想マシンのストレージデバイスのホットアンプラグが失敗する可能性がある

Windows ゲストオペレーティングシステムを使用する仮想マシン (VM) で、仮想マシンの実行中にストレージデバイスを削除すると (デバイスのホットアンプラグとも呼ばれる)、失敗する場合があります。その結果、ストレージデバイスは仮想マシンにアタッチされたままになり、ディスクマネージャーサービスが応答しなくなる可能性があります。現在、この問題に対する回避策はありません。

Jira:RHEL-869

CPU を Windows 仮想マシンにホットプラグするとシステム障害が発生する可能性がある

Huge Page が有効になっている Windows 仮想マシンに最大数の CPU をホットプラグすると、ゲストオペレーティングシステムが次の Stop エラー でクラッシュする場合があります。 

PROCESSOR_START_TIMEOUT
Copy to Clipboard Toggle word wrap

現在、この問題に対する回避策はありません。

Jira:RHEL-1220

Windows 仮想マシンの virtio ドライバーの更新が失敗する可能性がある

Windows 仮想マシン (VM) で KVM 準仮想化 (virtio) ドライバーを更新すると、更新によりマウスが動作しなくなり、新しくインストールされたドライバーが署名されない可能性があります。この問題は、virtio-win.iso ファイルの一部である virtio-win-guest-tools パッケージからインストールして、virtio ドライバーを更新する際に発生します。

回避策: Windows Device Manager を使用して virtio ドライバーを更新します。

Jira:RHEL-574[1]

vhost-kernel を使用する仮想マシンで TX キューのサイズを変更できない

現在、virtio ネットワークドライバーのバックエンドとして vhost-kernel を使用する KVM 仮想マシンでは、TX キューサイズをセットアップすることができません。したがって、TX キューにはデフォルト値の 256 しか使用できず、仮想マシンのネットワークスループットを最適化できない可能性があります。現在、この問題に対する回避策はありません。

Jira:RHEL-1138[1]

仮想マシンは、AMD EPYC モデルの spec_rstack_overflow パラメーターの vulnerable ステータスを誤って報告します。

ホストを起動すると、spec_rstack_overflow パラメーターの脆弱性は検出されません。ログのパラメーターをクエリーすると、次のメッセージが表示されます。 

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Mitigation: Safe RET
Copy to Clipboard Toggle word wrap

同じホスト上で仮想マシンを起動した後、仮想マシンは spec_rstack_overflow パラメーターの脆弱性を検出します。ログのパラメーターをクエリーすると、次のメッセージが表示されます。 

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Vulnerable: Safe RET, no microcode
Copy to Clipboard Toggle word wrap

ただし、これは誤った警告メッセージであり、仮想マシン内の /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow ファイルのステータスは無視できます。

Jira:RHEL-17614[1]

e1000e または igb モデルインターフェイスのステータスが down の場合でも、リンクステータスは仮想マシン上に up と表示されます。

仮想マシンを起動する前に、e1000 または igb モデルのネットワークインターフェイスのイーサネットリンクのステータスを down に設定します。設定したにもかかわらず、仮想マシンの起動後、ネットワークインターフェイスは up ステータスを維持します。これは、イーサネットリンクのステータスを down に設定し、仮想マシンを停止して再起動すると、自動的に up に設定されるためです。その結果、ネットワークインターフェイスの正しい状態が維持されません。

回避策: コマンドを使用して、仮想マシン内でネットワークインターフェイスのステータスを down に設定します。 

# ip link set dev eth0 down
Copy to Clipboard Toggle word wrap

または、仮想マシンの実行中にこのネットワークインターフェイスを削除して再度追加してみることもできます。

Jira:RHEL-21867

SeaBIOS が 4096 バイトのセクターサイズのディスクから起動できない

SeaBIOS を使用して、論理または物理セクターサイズが 4096 バイトのディスクから仮想マシン (VM) を起動すると、起動ディスクが使用可能として表示されず、仮想マシンの起動が失敗します。このようなディスクから仮想マシンを起動するには、SeaBIOS ではなく UEFI を使用します。

Jira:RHEL-7110

CPU あたり 128 を超えるコアを使用すると、起動時に Windows Server 2019 仮想マシンがクラッシュする

現在、Windows Server 2019 ゲストオペレーティングシステムを使用する仮想マシン (VM) は、単一の仮想 CPU (vCPU) に 128 を超えるコアを使用するように設定されている場合、起動に失敗します。仮想マシンは、起動する代わりに青い画面で停止エラーを表示します。

回避策: 仮想 CPU あたり 128 コア未満を使用します。

Jira:RHELDOCS-18863[1]

VBS と IOMMU デバイスを搭載した Windows 仮想マシンが起動に失敗する

Virtualization Based Security (VBS) が有効で、Input-Output Memory Management Unit (IOMMU) デバイスが qemu-kvm ユーティリティーを使用して Windows 仮想マシンを起動すると、起動シーケンスで起動画面のみが表示され、起動プロセスが不完全になります。

回避策: 仮想マシンドメイン XML が以下のように設定されていることを確認します。 

<features>
  <ioapic driver='qemu'/>
</features>
<devices>
<iommu model='intel'>
   <driver intremap='on' eim='off' aw_bits='48'/>
   <alias name='iommu0'/>
</iommu>
<memballoon model='virtio'>
   <alias name='balloon0'/>
   <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
   <driver iommu='on' ats='on'/>
</memballoon>
</devices>
Copy to Clipboard Toggle word wrap

そうしないと、Windows 仮想マシンは起動できません。

Jira:RHEL-45585[1]

5 レベルページマージングを使用し、かつ大量のメモリーを搭載した仮想マシンが起動に失敗することがある

host-phys-bits-limit パラメーターを 49 以上に設定すると、次の構成の仮想マシンが起動に失敗します。

  • 仮想マシンに割り当てられたメモリーが 1TB 以上ある
  • 仮想マシンが 5 レベルページマージング機能を使用している
  • ホストが自身のファームウェアで System Management Mode (SMM) を使用している

仮想マシンを起動しようとすると、ERROR: Out of aligned pages というエラーが表示されて失敗します。

回避策: host-phys-bits-limit パラメーターを 48 以下に設定します。

Jira:RHEL-82759

大量の起動可能なデータディスクを持つ仮想マシンは起動に失敗する可能性がある

大量の起動可能なデータディスクを持つ仮想マシン (VM) を起動しようとすると、仮想マシンは Something has gone seriously wrong: import_mok_state() failed: Volume Full エラーを表示して、起動に失敗する可能性があります。

回避策: 起動可能なデータディスクの数を減らし、システムディスクを 1 つ使用します。システムディスクがブート順序の最初になるようにするには、XML 設定でシステムディスクのデバイス定義に boot order=1 を追加します。以下に例を示します。 

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/path/to/disk.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <boot order='1'/>
</disk>
Copy to Clipboard Toggle word wrap

システムディスクのみに起動順序を設定します。

Jira:RHEL-68418

Windows 2025 仮想マシンは、多くの仮想 CPU を割り当てると動作が遅くなる

Red Hat Enterprise Linux ホスト上で、32 個以上の仮想 CPU を割り当てると、Windows Server 2025 の仮想マシン (VM) の動作が遅くなります。したがって、仮想マシンの起動に多数の仮想 CPU が設定されている場合に、Windows 仮想マシンの起動速度が遅くなるか、起動時にスタックする可能性があります。

回避策: この回避策の実行は、お客様ご自身の責任で行ってください。仮想 CPU の数が少ない仮想マシンを起動して、Windows Server の platformclock を無効にします。管理者特権を持つコマンドプロンプトで、次のコマンドを実行します。 

bcdedit /set useplatformclock no
Copy to Clipboard Toggle word wrap

次に、仮想マシンをシャットダウンし、必要な数の仮想 CPU で再設定します。また、大規模な仮想マシンを再度起動する前に、hv-time オプションが有効になっていることを確認してください。

Jira:RHEL-62742[1]

大容量メモリーを搭載した仮想マシンは、AMD Genoa CPU を搭載した SEV-SNP ホストでは起動できない

現在、第 4 世代 AMD EPYC プロセッサー (Genoa とも呼ばれる) を使用し、AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) 機能が有効になっているホストでは、仮想マシン (VM) を起動できません。起動する代わりに、仮想マシンでカーネルパニックが発生します。

Jira:RHEL-32892[1]

VirtIO-Win バンドルのインストールはキャンセルできない

現在、Windows ゲストオペレーティングシステムで VirtIO-Win インストーラーバンドルから virtio-win ドライバーのインストールを開始すると、インストール中に Cancel ボタンをクリックしてもインストールが正しく停止されません。インストーラーウィザードインターフェイスに "Setup Failed" という画面が表示されますが、ドライバーはインストールされ、ゲストの IP アドレスはリセットされます。

Jira:RHEL-53962、Jira:RHEL-53965

ハイパーバイザーの起動タイプが auto に設定されている Sapphire Rapids CPU 上で実行されている Windows 仮想マシンは、再起動時に起動に失敗する可能性があります。

Sapphire Rapids CPU 上で実行されている Windows 仮想マシン (VM) でハイパーバイザーの起動タイプを auto に設定すると、仮想マシンの再起動時に起動に失敗する可能性があります。たとえば、bcdedit /set hypervisorlaunchtype Auto コマンドを使用して、ハイパーバイザーの起動タイプを auto に設定できます。

回避策: Windows 仮想マシンでハイパーバイザーの起動タイプを auto に設定しないでください。

Jira:RHEL-67699[1]

VBS を使用して Windows ゲストに仮想 CPU とメモリーをホットプラグできない

現在、Windows Virtualization-based Security (VBS) は、ホットプラグ CPU およびメモリーリソースと互換性がありません。その結果、VBS が有効になっている実行中の Windows 仮想マシン (VM) にメモリーまたは仮想 CPU をアタッチしようとしても、これらのリソースはゲストシステムを再起動した後にのみ仮想マシンに追加されます。 

Jira:RHEL-66229、Jira:RHELDOCS-19066

Accelerated Networking が有効な Azure 仮想マシンで NetworkManager-wait-online.service が起動に失敗する

Accelerated Networking 機能 (Single Root Input Output Virtualization (SR-IOV) とも呼ばれる) を使用して Azure プラットフォームの Red Hat Enterprise Linux 仮想マシンを起動すると、複数のネットワークインターフェイスカードが同じ MAC アドレスを持つ場合があります。その結果、仮想マシンが DHCP サーバーから IP アドレスを取得できず、ブート時に NetworkManager-wait-online.service の起動が失敗する場合があります。

回避策: 既存のデバイスが既存のデバイス名に名前を変更しないように、initscripts-rename-device パッケージをインストールしないでください。

Jira:RHEL-79783[1]

Extended Master Secret TLS エクステンションが FIPS 対応システムに適用されるようになりました。

RHSA-2023:3722 アドバイザリーのリリースにより、FIPS 対応 RHEL 9 システム上の TLS 1.2 接続に、TLS Extended Master Secret (EMS) エクステンション (RFC 7627) エクステンションが必須になりました。これは FIPS-140-3 要件に準拠しています。TLS 1.3 は影響を受けません。

EMS または TLS 1.3 をサポートしていないレガシークライアントは、RHEL 9 および 10 で稼働する FIPS サーバーに接続できなくなりました。同様に、FIPS モードの RHEL 9 および 10 クライアントは、EMS なしでは TLS 1.2 のみをサポートするサーバーに接続できません。これは実際には、これらのクライアントが RHEL 6、RHEL 7、および RHEL 以外のレガシーオペレーティングシステム上のサーバーに接続できないことを意味します。これは、OpenSSL のレガシー 1.0.x バージョンが EMS または TLS 1.3 をサポートしていないためです。

さらに、ハイパーバイザーが EMS なしで TLS 1.2 を使用する場合は、FIPS 対応 RHEL クライアントから VMWare ESX などのハイパーバイザーへの接続が Provider routines::ems not enabled エラーで失敗するようになりました。この問題を回避するには、EMS 拡張で TLS 1.3 または TLS 1.2 をサポートするようにハイパーバイザーを更新します。VMWare vSphere の場合、これはバージョン 8.0 以降を意味します。

詳細は、TLS Extension "Extended Master Secret" enforced with Red Hat Enterprise Linux 9.2 and later を参照してください。

Jira:RHEL-13340[1]

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat