8.17. 仮想化

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]

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]

ネットワークインターフェイスのリセット後に 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.

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

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

# 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

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

# 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

# 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

# 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

AMD SEV-SNP を搭載した仮想マシンで Kdump が失敗する

現在、Secure Nested Paging (SNP) 機能を備えた AMD Secure Encrypted Virtualization (SEV) を使用する RHEL 9 仮想マシン (VM) では kdump が失敗します。現在、この問題に対する回避策はありません。

Jira:RHEL-10019^[1]

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>

<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]

--migrate-disks-detect-zeroes オプションは仮想マシン移行では機能しない可能性がある

現在、RHEL 9 で仮想マシン (VM) を移行する場合、--migrate-disks-detect-zeroes オプションが機能せず、指定されたディスク上のゼロブロックが検出されずに移行が続行される可能性があります。この問題は、ミラーリングジョブがホールパンチに依存していたため、結果として宛先ファイルがスパースファイルになる QEMU のバグによって発生します。

Jira:RHEL-82906

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

大量の起動可能なデータディスクを持つ仮想マシン (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>

<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

破棄 I/O 要求を送信する仮想マシンは、discard_granularity が設定されていない場合に一時停止する可能性があります。

ホストカーネルは不整合の破棄 I/O 要求を失敗し、QEMU は werror= policy パラメーターを使用してこのような失敗に応答します。werror が stop: werror=stop に設定されている場合、破棄要求が失敗すると仮想マシン (VM) が一時停止します。この状況を修正して仮想マシンを再開する方法がないため、この状況は通常、望ましくありません。

回避策: virtio-blk ディスクおよび virtio-scsi ディスクの discard_granularity パラメーターが設定され、ホストの /sys/block/<blkdev>/queue/discard_granularity の値と一致していることを確認します。これにより、仮想マシンはアライメント制約を認識するようになり、破棄要求が適切にアライメントされて失敗しなくなります。

Jira:RHEL-86032^[1]

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

Red Hat Enterprise Linux ホスト上で、32 個以上の仮想 CPU を割り当てると、Windows Server 2025 の仮想マシン (VM) の動作が遅くなります。その結果、仮想マシンに多数の仮想 CPU が設定されている場合、Windows 仮想マシンの起動が遅くなったり、起動中に停止したりすることがあります。

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

bcdedit /set useplatformclock no

bcdedit /set useplatformclock no

Copy to Clipboard

Toggle word wrap

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

Jira:RHEL-62742^[1]

virtiofs 共有ディレクトリーで開いているファイルが多すぎると、vrtiofsd プロセスがクラッシュする可能性があります。

仮想マシン (VM) から、開いているファイルが大量にある virtiofs 共有ディレクトリーにアクセスすると、Too many open files エラーが発生して操作が失敗し、virtiofsd プロセスがクラッシュする可能性があります。

回避策: 次のいずれかの手順を試してください。

virtiofsd を root として実行し、--inode-file-handles=mandatory コマンドラインオプションを使用します。
--cache=never コマンドラインオプションを使用します。
--rlimit-nofile コマンドラインオプションを使用して、virtiofsd が使用できるファイル記述子の数を増やします。

Jira:RHEL-87161^[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

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

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

Jira:RHEL-66229、Jira:RHELDOCS-19066

IBM Z 上の仮想マシンを移行すると、ネットワーク設定が削除されることがある

現在、IBM Z ホスト間で仮想マシン (VM) を移行すると、仮想マシンのネットワーク設定がリセットされ、仮想マシン上でネットワークが利用できなくなる場合があります。この問題を回避するには、仮想マシンの移行を開始する前に vhost-net サービスを無効にします。

Jira:RHEL-43214^[1]

8.17. 仮想化

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links