えんでぃの技術ブログ

えんでぃの技術ブログ

ネットワークエンジニアの視点で、IT系のお役立ち情報を提供する技術ブログです。

トップ > Linux > QEMU、KVM、libvirtの基礎知識まとめ

QEMU、KVM、libvirtの基礎知識まとめ

Linux KVM

linux-kvm-logo
引用元: linux-kvm.org

はじめに

LinuxでVMを作るにあたり、KVM (Kernel-based Virtual Machine) を使うことにしました。
※使い始めた理由については、#(参考) KVMを使い始めた理由に書きました

KVMを使ってみると、初期設定時に以下のようなもやもやに当たりました。

  • 導入すべきパッケージがよくわからない (必須のもの、任意のもの、いくつかの選択肢から選ぶものが混在している)
  • KVMの動作要件であるVT-x/AMD-Vが何なのかわからずもやもやする
  • KVM周りのコンポーネントが色々あるが、それぞれ何をしているのかわからずもやもやする

本記事は、KVMの導入や使い方紹介に先立って上記の理解を深め、多少なりとももやもやを晴らすことを目的としています。
他記事と比較して、わかりやすさと網羅性を重視して書きましたので、ぜひご覧いただけると嬉しいです。

具体的には、以下を紹介します。

  • KVM仮想化の全体像 (ハードウェア,KVM,QEMU,UI)
  • KVMとQEMUの役割の違い
  • KVM、QEMUを操作する主なUI (libvirt, Virtual Machine Manager, Cockpit, 他)

KVMの具体的な導入手順、VMの作り方などについては、後続の記事で紹介します。

記事の信頼性について

本記事でまとめた内容は、大半が他のブログや連載記事、Wikipediaを情報ソースとしています。
KVM、QEMUを含む各種OSSの公式ドキュメントももちろん確認したのですが、情報が足りない部分が多かったので非公式の記事で補完しました。
従って、情報の正確性については100%ではありません。

本来であれば500ページを超える専門書やソースコードを読み込んで正確に理解することが理想ですが、残念ながらスキルと時間が足りません。
限られた時間の中でKVMを動かすのに必要な理解を得るために、今回はこのような形とさせていただきました。

最後に、本記事に記載した内容は可能な範囲で実機検証済みであり、他の記事やブログでも同様な内容で多く取り上げられていることは申し添えておきます。

広義のKVMと狭義のKVM

広義では、仮想化ソフトウェア (Emulator) を指してKVMと呼ぶことがあります。
内部的には仮想CPU、仮想メモリ、仮想I/Oデバイスを構成し、ホストとは別のOSを起動することで仮想マシンを実現しています。
言い換えると、仮想マシンにおけるCPU処理、メモリ読み書き、ディスク/ネットワークIOは仮想化ソフトウェアの働きによって、物理CPUへの命令、物理メモリ読み書き、物理ディスク/ネットワークI/Oに変換されています。

ただ厳密に言うと、上記のような仮想化はQEMU (アプリケーション) とKVM (カーネルモジュール) の組み合わせによって実現しています。
狭義のKVMは、kvm.ko と呼ばれるLinuxカーネルモジュールを指し、QEMUを含みません。

以降、本ブログではカーネルモジュールとしての狭義のKVMをKVMと呼び、QEMUとは明確に区別することにします。

KVM + QEMU 仮想化の全体像

図は、Wikipediaの画像を元にしています。

kvm-diagram_modified

上図の (1)〜(3) について、それらの機能や連携内容を順に紹介していきます。

(1) QEMU (エミュレータ)

QEMUの機能

QEMUは、仮想マシンのエミュレーションを行います。
エミュレーションの対象は、 CPU、メモリ、I/Oデバイスに大別されます。
更に、I/Oデバイスについてはより細かく細分化されます。

具体的なエミュレーション対象のデバイスとしては、主に以下が挙げられます。

  • CPU
  • メモリ
  • I/Oデバイス
    • ハードディスク
    • CD / ISOイメージ
    • ネットワーク
    • ディスプレイ
    • サウンド
    • キーボード
    • マウス
    • 他

上記リストは、QEMU System Emulation User's Guide、またはman qemu-system-x86_64 でキーワード検索することで洗い出しました。

QEMU = プロセス

QEMUは、Linux上でqemu-system-x86_64 というコマンドで起動され、通常のプロセスとして動作します。
コマンドの x86_64 の部分は、エミュレーションしたいCPUのアーキテクチャによって変わりますが、KVMを使いたい場合は基本的に x86_64 になります。
後述するように、KVMの動作要件である仮想化支援機能は、現時点では x86 アーキテクチャのCPUのみに対応する技術であるためです。

QEMU のインストール方法

Fedoraの場合、以下のコマンドでKVMと連携可能なQEMUをインストールできます。

sudo dnf install qemu-kvm

参考までに、dnf info qemu-kvmの出力を抜粋しました。
qemu-kvmはメタパッケージと呼ばれ、インストールしたシステムがKVMを実行するために必要なQEMUパッケージをインストールしてくれるものです。
多くの場合は、qemu-system-x86がインストールされます。

This is a meta-package that provides a qemu-system-<arch> package 
for native architectures where kvm can be enabled. 
For example, in an x86 system, this will install qemu-system-x86

KVM = QEMUのアクセラレータ

QEMUは、単体で仮想マシンの作成・起動・管理を一通り対応できます。
しかしQEMU単体で使うと、仮想マシンの動作は非常に遅くなってしまいます。
QEMUはKVMと組み合わせて使うことで、高速に動作するようになります。

KVMで仮想マシンを立てると、裏では qemu-system-x86_64 -accel kvm ... というコマンドが実行されます。
つまり、QEMUがKVMをアクセラレータに指定して実行します。
言い換えると、KVMはQEMUのバックエンドと連携して動作し、QEMUが効率的に動作するために一部のバックエンド機能を支援したり代替している と私は理解しています。
KVMが具体的にどのように動くかについては、#(2) KVM (仮想化支援機能との連携) にて概要のみ紹介します。

(参考) QEMU単体とQEMU+KVMの速度比較

2012年の情報ですが、QEMU単体構成とQEMU+KVM構成でパフォーマンスを比較した動画が上がっています。
動画の左側に表示されている「KVM」がQEMU+KVM構成、右側に表示されている「TCG」がQEMU単体構成を表しています。
この動画の環境では、アプリケーションの起動時間が6倍、アニメーションのFPS (1秒あたりのコマ数) にも大きな開きが出ていました 。
※TCG という用語については、#TCG (Tiny Code Generator)で補足します

参考URL (QEMUとKVMの関係)

下記サイトがよく整理されていて、非常に参考になりました。

TCG (Tiny Code Generator)

TCG (Tiny Code Generator) はQEMUのコンポーネントの一つで、CPU仮想化を実現するためのものです。
アクセラレータを指定せずにQEMUを実行すると、デフォルトで qemu-system-x86_64 コマンドに -accel tcg がセットされます。

TCGは Binary Translation (BT) と呼ばれる技術を使っています。
Binary Translation とは、仮想CPUで処理される命令をハイパーバイザーのソフトウェア処理によって一部書き換えてから物理CPUに渡す機能です。

基本的には高速なKVMを利用するので、TCGの出番はありません。
ただ、KVMを利用するにも条件があります (CPUが仮想化支援機能をサポートしていることと、ホストマシンでKVMカーネルモジュールがロードされていること)。
これらの条件を満たさなかった場合、 qemu-system-x86_64 -accel kvm ... コマンドを発行しても、デフォルトのTCGにフォールバックされます。
このフォールバックの挙動は、 man qemu-system-x86_64 の -accel オプションの説明からもわかります。

# -accel name[,prop=value[,...]]
This is used to enable an accelerator. 
Depending on the target architecture, 
kvm, xen, hax, hvf, whpx or tcg can be available. 
By default, tcg is used. 
If there is more than one accelerator specified, 
the next one is used
if the previous one fails to initialize.

稀なことですが、KVM利用に失敗してフォールバックされていた場合、「意図せずTCGを利用している」といった状況になる可能性もあります。

(2) KVM (仮想化支援機能との連携)

KVMの機能

KVMは、Linuxカーネルがハイパーバイザとして動作するために必要な機能を提供します。

ただし、KVM自身はエミュレーションを行いません。
QEMUが仮想マシンのエミュレーションを行い、KVMは仮想ハードウェアの処理と物理ハードウェアの処理の仲介を行います。

KVMの主な機能は以下です。

KVMの最も重要な機能は、CPUがサポートする仮想化支援機能 (Intel VT-x、またはAMD AMD-V)をQEMUに対して提供することです。
上記の仮想化支援機能はKVMの基本機能でもあり、動作要件でもあります (※)。
(※) 例外として、IBM POWER と IBM Z 上でもKVMを動作させることは可能ですが、本記事の解説の対象外としています

KVM = カーネルモジュール

KVMは kvm.ko というカーネルモジュールとしてLinux に組み込まれています。

このことはコマンドでも確認できます。
kvmで始まる行がkvmカーネルモジュールをロードしていることを表しています。
同じ行の右側にkvm_intelと書かれているのは、kvmカーネルモジュールがkvm_intelカーネルモジュールに利用されていることを表しています。

lsmod | grep kvm

# kvm_intel             319488  0
# kvm                   823296  1 kvm_intel
# irqbypass              16384  1 kvm

インストール方法

KVMはLinuxに組み込まれているので、追加のインストールは不要です。

ただし、LinuxホストのCPUがVT-x、またはAMD-VをサポートしていることがKVMの動作要件となります。

(3) 仮想マシンのドライバ

仮想マシンのドライバには、私の知る限り2パターンあります。

  1. 通常のベアメタルサーバと同様、OSやカーネルに付属する汎用的なドライバを利用するパターン
  2. 準仮想化ドライバ (virtio) を使うパターン

ここで主に触れたいのは、2つ目のvirtioです。

(参考) 準仮想化

準仮想化 (Paravirtualization) とは、仮想化用にチューニングしたOSを仮想マシンとして起動することで、仮想化に特化した機能を仮想マシンに実装する手法です。
具体的にはHypercall (仮想マシンカーネルからホストマシンハイパーバイザーへ直接出す命令) の実装が挙げられます。
準仮想化によって性能や機能性の面でメリットが得られることもありますが、OSに手を入れることで互換性の問題が発生したり、実装が複雑になりうるのが弱点です。

対義語は完全仮想化 (Full Virtualization) であり、ベアメタルと全く同じOSで仮想化を実現する手法です。
少なくともvirtioの存在を無視すれば、QEMU単体やQEMU+KVMは完全仮想化に該当します。

virtio

virtioは、仮想I/Oデバイス (ディスク、ネットワーク、サウンド、ディスプレイ、キーボード、マウスなど) の準仮想化ドライバ機能を提供するAPI群です。

virtioは仕様と ソースコードが公開されています。
様々な仮想化製品やハードウェアがある中で、virtioのように統一されたインターフェースを提供することで、仮想化アプリケーション開発者の負担を減らすことができます。

また準仮想化のメリットとして、特にvirtioの場合は性能の向上も挙げられます。
細かいアーキテクチャは理解できていないのですが、実際に汎用的なネットワークインターフェースカードのドライバとvirtioで性能比較し、virtioの方が良い性能を得られたという報告があります (参考1) (参考2)。

Hybrid Virtualization

KVMの仮想化支援機能が提供する動作モードの切り替え (VM Entry, VM Exit)は、CPUリソースを多く消費します。
ここにvirtioを組み合わせると、動作モードの切り替わり回数が抑制されて、処理効率が向上するとのことです。

このように、QEMU+KVMの完全仮想化の仕組みに、virtioの準仮想化ドライバを組み合わせた仮想化をHybrid Virtualization と呼び、仮想化支援機能を更に高速化させる手段として紹介されています。

QEMU+KVMの仮想化は、Hybrid Virtualization の定義に該当します。

virtio のインストール方法

virtioは、Linuxカーネルに同梱されているようです。

ただWindowsゲスト用のvirtio については同梱されない場合があるようなので、個別にホスト側にインストールが必要なようです。
参考情報として、Fedoraにおけるインストール手順を載せておきます。

sudo wget https://fedorapeople.org/groups/virt/virtio-win/virtio-win.repo \
-O /etc/yum.repos.d/virtio-win.repo

sudo dnf install virtio-win

余談ですが、Windowsゲスト用のvirtioは、ホスト側にインストールして終わりではありません。
上記コマンドは、virtioドライバのインストーラを含むisoファイルをホストに配置するのみです。
実際にvirtioドライバをWindowsゲストにインストールして使用するには、isoファイルをWindowsゲストにマウントして、ゲスト上でインストール操作を行う必要があります。
詳細な手順は、10 Easy Steps To Install Windows Server in Linux KVMというブログに記載があります。
こちらのブログの手順は、私も手元のWindows10評価版で試して動作確認しました。
Windows10評価版は、Microsoft社公式ページよりWindowsのリンクを選択した先からダウンロードできます。

他のディストリビューションでのインストール方法も探せば見つかると思いますが、パッケージが配布されていない場合はFedoraで配布しているISOファイルを直接ディレクトリに配置しても良いようです。

参考サイト (virtio)

virtioの概要としては、以下がわかりやすかったです。

参考サイト (仮想化技術全般)

QEMU の操作方法

これまでの解説からすると、QEMUがフロントエンドとしてコマンドラインインターフェース (qemu-system-x86_64) とエミュレーション機能を提供し、裏でKVMがアクセラレータとして動作する という理解になります。
上記で間違いはないのですが、実際のユースケースではqemuコマンドをユーザーが直接実行することはほぼありません。

QEMUはlibvirt経由で操作することが多い

実際には、 libvirtベースのアプリケーションを介して仮想マシンの作成、変更、監視、停止、削除、移行などを行うことがほとんどです。
例えば、Virtual Machine Manager (virt-manager) はQEMU+KVM を操作できるGUIプログラムですが、裏ではlibvirtが提供するAPIを介してQEMUコマンドを発行しています。

具体例として、Virtual Machine Manager でVMを起動した時の ps コマンドの出力は、以下のようになっています。

/usr/bin/qemu-system-x86_64 \
-name guest=fedora_cinnamon,debug-threads=on \
-S \
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-fedora_cinnamon/master-key.aes \
-blockdev {"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} \
-blockdev {"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"} \
-blockdev {"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/fedora_cinnamon_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"} \
-blockdev {"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"} \
-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \
-cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,hle=off,rtm=off \
-m 6144 \
-overcommit mem-lock=off \
-smp 7,sockets=7,cores=1,threads=1 \
-uuid ef88cdc5-8105-448f-b249-97adbe58206a \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=37,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev {"driver":"file","filename":"/home/shared/kvm_volumes/fedora_cinnamon.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} \
-blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} \
-device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=1 \
-device ide-cd,bus=ide.0,id=sata0-0-0 \
-netdev tap,fd=39,id=hostnet0,vhost=on,vhostfd=40 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:00:83:41,bus=pci.1,addr=0x0 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=41,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-chardev spicevmc,id=charchannel1,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \
-device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object rng-random,id=objrng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on

この圧倒的なオプションの長さからも察しがつくように、実際の場面ではQEMUコマンドの直接実行をすることはそうそうありません。
多くの場合はもっと使いやすい別のツールを使うことになります。

libvirt とは

libvirtは、仮想化アプリケーションやハイパーバイザを操作するための抽象化レイヤーを提供するソフトウェア群です。

主に、以下の3つの機能を持ちます。

機能名 詳細
ライブラリ
デーモン
  • libvirtd デーモン
  • socketを開き、APIアクセスを待ち受ける
  • 通信を受けることでデーモンが自動起動する
    (systemctl status libvirtd のTriggeredBy行より)
  • libvirtd.socketを開くために、libvirtdの自動起動は必要
CLI

XMLで構成管理する

libvirt では、仮想マシンの構成情報 (仮想マシン名や仮想CPUコア数など) をXMLファイルに保存して管理します。
CUIやGUIで設定するだけでなく、XMLを直接編集することでもVMの構成を変更することができます。

libvirt を利用している製品

libvirt を介して仮想化環境を便利に管理している製品をざっくり紹介します。
詳細な機能や使い方などは、別記事にてそのうち紹介できればと思います。

CLI管理ツール

CLI管理したい場合はvirsh, virt-install, virt-cloneを主として、お好みでvirt-top, guestfishなどを利用します。

CLIツールは、基本的にVM周りの操作をスクリプト化して効率化するときに使う印象です。
CLIツールは指定するオプションが多いこともあり、普段遣いでVMを操作する場合は、GUIの方が結果として早く操作できると思います。

インストールコマンドは以下のようになります。

sudo dnf install libvirt virt-install virt-top libguestfs-tools

virsh は、libvirtの依存関係であるlibvirt-clientに同梱されます。
virt-cloneはvirt-installに同梱されます。
guestfishは、libguestfs-toolsに含まれます。

virsh、virt-installについては、次の記事で使い方を紹介します。

GUI管理ツール (OSS)

GUIで管理したい場合は、Virtual Machine ManagerかCockpit を使います。

QEMU+KVMを実行するマシンにデスクトップ環境があればVirtual Machine Manager が利用可能ですが、無いならばWEBベースのCockpit になります。
もちろん、デスクトップ環境があってもCockpitは利用できます。

特にRHELを利用している方は、今後RedHat社としてCockpit を推奨とする動きになっているので、基本的にはCockpit 一択になると思います。
ただし2020年現在、Cockpit と Virtual Machine Manager の間には機能差があるので、利用する機能によってはVirtual Machine Manager や、CLIの出番が来る可能性もあります。

Virtual Machine Manager (virt-manager) のインストールコマンドは以下のようになります。

sudo dnf install virt-manager

Cockpit そのものはFedoraには元々同梱されていますが、CockpitでKVMを操作するために追加でcockpit-machinesのインストールが必要です。
cockpit-machinesをインストールするとcockpitに「Virtual Machine」タブが追加され、仮想マシンを管理できるようになります。

sudo dnf install cockpit-machines

(参考) Virtual Machine Viewer / Remote Viewer

Virtual Machine Viewer (virt-viewer) は、ローカルホストで動作しているVMにコンソール接続するためのツールです。
libvirtでリモートのサーバに接続 (--connect) している場合は、結果的にリモートサーバに接続することもあります。

Remote Viewer (remote-viewer) は、リモートで動作しているマシンにSPICE、VNCなどのプロトコルでコンソール接続するためのツールです。
宛先にlocalhostを指定すればローカルのVMにコンソール接続することもできますが、その用途であればVirtual Machine Viewerの方が若干便利です。
ローカルでVMを起動している場合も、Cockpitをお使いの方であれば導入推奨です。

いずれもGUIアプリケーションであるため、Linux上で利用する場合はデスクトップ環境かWindow Managerが必要です。
MacやWindowsからRemote Viewerを使う構成であれば、特に動作要件はありません。

Linux版は以下のコマンドでインストールします。

sudo dnf install virt-viewer
sudo dnf install remote-viewer

Windows版は、https://virt-manager.org/download/からインストールできます。
ページ上にはvirt-viewerと表記されていますが、MSIでインストールするとRemote Viewerがインストールされます。

Macの場合は非公式ですが、brewコマンドでインストールできるようです (Qiita - virt-managerをMacBookにインストール)。

GUI管理ツール (基本有償)

その他のGUI管理の選択肢として、有償製品とそのアップストリームのOSSもあります。
安定版を利用するにはお金がかかりますが、可用性やセキュリティを担保する機能性は非常に高い...と思われます (まだ使ったことがないです)。

具体的な製品名を挙げるとProxmox、RedHat Virtualization (RHV。oVirtのダウンストリーム)、Oracle Linux Virtualization Manager (oVirtベース) が有償製品として挙げられます。
一方で無償の製品としては、Proxmox (無償版) と oVirt が挙げられます。

これらの製品はいずれも仮想化技術としてKVMを利用しており、バックエンドAPIとしてlibvirtを利用しています。

インストール手順は複雑になるので、本記事では割愛させていただきます。

(参考) KVMを使い始めた理由

LinuxにもVirtualBoxはあります。
検証用途でVMを立てたい場合は、VirtualBoxでも十分です。

今回、慣れているVirtualBoxではなく敢えてKVM+QEMU に挑んだ理由は、VMware vSphereの代替品としても注目されるProxmox、RHV、Oracle Linux Virtualization ManagerがKVMを利用していると知ったためです。
また、こちらのRedHat社の資料を読み、RHVの定価はvSphereよりも安く見えるといった部分にも興味を持ちました。
※上記資料にも記載されている通りあくまで定価ベースで机上で計算した値なので、導入構成や価格交渉を反映した最終的な金額はまた変わると思いますが...

仮想化製品としては最有力な vSpehereの (安価かもしれない) 代替手段を知っておきたい というのが、私にとっては KVM+QEMU を勉強する原動力になりました。

(参考) おすすめの動画 / 記事

この記事を書いた後にわかりやすい解説を見つけたので、紹介させてください。
内容は英語でArch Linuxをベースとした解説ですが、テンポ良く進むので眠くならずに見れると思います。

動画とブログはどちらも同じ作者によるものです。

ブログはこちら：Linux Hypervisor Setup (libvirt/qemu/kvm)

まとめ

本記事では、KVMのインストールやセットアップに関連する部分を中心に周辺知識を整理しました。
KVM仮想化の基本として覚えるべき要素は3つです。

要素 詳細
QEMU
  • 仮想ハードウェアのエミュレーションを行う
  • 通常プロセスとして存在する
    		•
    KVM
  • CPU仮想化支援機能などを提供する
  • virtio ドライバと相性が良く、QEMUと組み合わせることでVMがより軽快に動作できるようにする
  • カーネルモジュールとしてLinuxに同梱されている
    		•
    libvirt
  • QEMUを初めとして、いくつかの仮想化製品の操作を抽象化するAPIを提供する
  • virshやvirt-installなどのCLI、virt-managerなどのGUIのバックエンド
  • デーモンやコマンドラインとして存在する
    		•

    何も知らない状態でKVMを触り始めて、いざトラブルが発生すると (私のように) 苦労します。。
    公式の情報ソースのないカジュアルなまとめとなってしまいましたが、本記事がこれからKVMを始める方にとって少しでもお役に立てれば嬉しいです。

    Linux PC 構築関連リンク集

    endy-tech.hatenablog.jp

    次の記事

    KVMのインストール手順、libvirt CLI (virsh, virt-install) の初期設定とVM作成手順を紹介します。

    endy-tech.hatenablog.jp

    #Linux #Fedora #KVM #QEMU #libvirt

    stopendy 読者になる

    広告を非表示にする
    コメントを書く