ゲストにWindows10を導入し、ホストにPCI-Eで接続しているグラボ(nVidia GeForce GTX 1060)をPCIブリッジでゲストに渡し、ゲストのWindows10で3Dゲームとか楽しもうと思ってる。
で、色々試してたんだけど、結局NGだった。
とりあえず、
https://uramocha02.blogspot.jp/2017/01/pciiommu.html
https://uramocha02.blogspot.jp/2017/01/pcigpu.html
https://uramocha02.blogspot.jp/2017/01/pci.html
この辺りの作業の後、以下の作業を実施。
---------------------------------------
/etc/modules に以下の行を追加
--内容
#PCI pass through
pci_stub
vfio-pci
--ココまで
/etc/modprobe.d/vfio.conf を新規作成
--内容
options vfio-pci ids=10de:1c03,10de:10f1,1912:0014
--ココまで
lsmod | grep -i vfio
dmesg | grep -i vfio
lspci -nnk -d 10de:1c03
lspci -nnk -d 10de:10f1
vi /etc/initramfs-tools/modules
--
pci_stub ids=10de:1c03,10de:10f1,1912:0014
--
lspci -nnk -d 1912:0014
---------------------------------------
それでも、上手くゲストにブリッジ出来ずに悩んでた。
で、どうやら、nVidiaのグラボをPCIパススルーするためには、libvirtのバージョンが1.3.3以上でないとダメのようだ。(AMDのグラボなら可能っぽい)
Ubuntu 16.04 の libvirt は 1.3.1 のようなので、微妙に機能が足りない。
新しい libvirt をビルドするという手もあるし、Ubuntu 18.04 を待たずに、17.10 にアップグレードするという手もあるにはあるけど、18.04 はあと3ヶ月弱でリリースなので、それまで待つことにしよう…。
ちなみに、参考にしてた URL は以下。
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
ハイパーバイザの作り方~ちゃんと理解する仮想化技術~ 第15回 PCIパススルーその1「PCIパススルーとIOMMU」
Libvirt: Domain XML format
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
GPU passthrough: gaming on Windows on Linux
HOW-TO make dual-boot obsolete using kvm VGA passthrough
Linux and Windows running simultaneously with GPU passthrough
PCI passthrough via OVMF
Ubuntu日本語フォーラム / ubuntu14.04上にlibvirt1.3.3 以上をインストールしたい。
Ubuntu 18.04 がリリースされたら、もう一度見直して挑戦しよう。
主にUbuntuで実験した内容を書くかもしれない。 もしかしたら、つまらない時事ネタかも。 いつか、紙媒体の書籍にしたいので、このブログの内容の転載はお控え願います。引用は可。 まずは、「目指せ!電子書籍化!」です。
2018年2月8日木曜日
2017年1月16日月曜日
WindowsをKVMゲストにコンバート(ゲストWin)
今度は、過去にVMware Workstationの仮想マシンとして稼動していた環境を、KVMゲストに移行する。
とはいえ、仮想マシンごと移行するのではなく、仮想ディスク(.vmdk)をQEMU用(.qcow2)にコンバートして、その仮想ディスクを使う新しい仮想マシンを作成する、という形だ。
適当に仮想ディスクを取り出して、そのファイルがあるディレクトリで以下のコマンドを実行だ。
(sagittarius) $ sudo qemu-img convert \
-c \
-p \
-O qcow2 \
Windows\ 7_x64_Home-cl2.vmdk \
/var/lib/libvirt/images/pegasus.qcow2
ここでは、元の仮想ディスクのファイル名がWindows 7_x64_Home-cl2.vmdk、コンバート後の仮想ディスクファイル名をpegasus.qcow2、コンバート後の形式をqcow2で指定している。
他にもオプションがあるが、とりあえずこれだけ抑えておけばいいだろう。
変換には時間がかかるが、-pオプションで経過が表示されるので、気長に待とう。
(仮想ディスクサイズ128GB、実質使用サイズ36GBで、大体1時間ぐらい?)
変換が終わったら、念のために書式を確認しておく。
(sagittarius) $ sudo qemu-img info /var/lib/libvirt/images/pegasus.qcow2
確認が出来たら、今まで通りに仮想マシンを作ってみよう。
仮想ディスクのI/Fは、VMwareで使っていた時と同じにしておいた方が無難だ。
無事に起動できたら、WindowsをKVMゲストにコンバート(ホストWin)の後半と同様に、OSカスタマイズしておこう。
また、このWindowsは、Home Editionだ。したがって、リモートデスクトップ接続することが出来ない。
今までのVMware Workstation上のゲストOSの場合は、これでも問題は無かった。
ホストOS側にリモートデスクトップ接続し、このゲストをフルスクリーンで起動すれば良かったからだ。
今回、KVM環境に移行したため、グラフィック関連が弱くなってしまい、操作性が悪い。ゲストOSが正常起動するのであれば、ソレに対してリモートデスクトップ接続して操作したい。
そのため、Windows7のHome EditionからProfessional Edition以上にアップグレードさせようと思う。
通常であれば、Any time Upgradeを使うことになると思う。
必要に応じて実施しよう。
エディション変更が出来たら、ユーザパスワードを設定したり、IPアドレスを固定化して、リモートデスクトップ接続が出来るか確認だ。
また、この仮想マシンには、USBデバイス(デジタルカメラ)を接続したい。
そのため、PCI-Eに挿入したUSB拡張カードをゲストにアサインしておく。
(PCIパススルーだ。GPU以外はすんなりパススルー出来る。)
ざっとココまで。後は色々動かしてみて、期待した処理が出来るか確認すればいい。
残りも必要に応じて、KVMゲスト化していく。
とはいえ、仮想マシンごと移行するのではなく、仮想ディスク(.vmdk)をQEMU用(.qcow2)にコンバートして、その仮想ディスクを使う新しい仮想マシンを作成する、という形だ。
適当に仮想ディスクを取り出して、そのファイルがあるディレクトリで以下のコマンドを実行だ。
(sagittarius) $ sudo qemu-img convert \
-c \
-p \
-O qcow2 \
Windows\ 7_x64_Home-cl2.vmdk \
/var/lib/libvirt/images/pegasus.qcow2
ここでは、元の仮想ディスクのファイル名がWindows 7_x64_Home-cl2.vmdk、コンバート後の仮想ディスクファイル名をpegasus.qcow2、コンバート後の形式をqcow2で指定している。
他にもオプションがあるが、とりあえずこれだけ抑えておけばいいだろう。
変換には時間がかかるが、-pオプションで経過が表示されるので、気長に待とう。
(仮想ディスクサイズ128GB、実質使用サイズ36GBで、大体1時間ぐらい?)
変換が終わったら、念のために書式を確認しておく。
(sagittarius) $ sudo qemu-img info /var/lib/libvirt/images/pegasus.qcow2
確認が出来たら、今まで通りに仮想マシンを作ってみよう。
仮想ディスクのI/Fは、VMwareで使っていた時と同じにしておいた方が無難だ。
無事に起動できたら、WindowsをKVMゲストにコンバート(ホストWin)の後半と同様に、OSカスタマイズしておこう。
また、このWindowsは、Home Editionだ。したがって、リモートデスクトップ接続することが出来ない。
今までのVMware Workstation上のゲストOSの場合は、これでも問題は無かった。
ホストOS側にリモートデスクトップ接続し、このゲストをフルスクリーンで起動すれば良かったからだ。
今回、KVM環境に移行したため、グラフィック関連が弱くなってしまい、操作性が悪い。ゲストOSが正常起動するのであれば、ソレに対してリモートデスクトップ接続して操作したい。
そのため、Windows7のHome EditionからProfessional Edition以上にアップグレードさせようと思う。
通常であれば、Any time Upgradeを使うことになると思う。
必要に応じて実施しよう。
エディション変更が出来たら、ユーザパスワードを設定したり、IPアドレスを固定化して、リモートデスクトップ接続が出来るか確認だ。
また、この仮想マシンには、USBデバイス(デジタルカメラ)を接続したい。
そのため、PCI-Eに挿入したUSB拡張カードをゲストにアサインしておく。
(PCIパススルーだ。GPU以外はすんなりパススルー出来る。)
ざっとココまで。後は色々動かしてみて、期待した処理が出来るか確認すればいい。
残りも必要に応じて、KVMゲスト化していく。
2017年1月12日木曜日
ゲストにPCIパススルー(キーボード、マウス)
というわけで、GPUのパススルーは出来た。
ただ、それだけだとキーボード・マウスによる入力が出来ない。
当初は、ゲストにUSB Host Deviceからキーボード・マウスを引き渡せばいいかと思ったのだが、どうやらそれでは上手くいかないようだ。
そこで、PCI-Eに挿すUSB拡張カードを買ってきて(今回は、4ポートのUSB3.0カードを買ってみた)、それをPCに挿入、そのPCI-Eカードごとゲストに引き渡す形にした。
ただし、PCI-EカードスロットによってはPCIパススルー出来ないようなので、駄目だったらスロットを変えてみよう。
USB拡張カードを挿入、ホストOS(sagittarius)から認識できたら、GPUのパススルーと同じように、USBカードのパススルーも実施しよう。
ここでは、併せてデバイスの削除も実施しておく。
削除するデバイス
タブレット、spiceチャンネルの削除は、今回の仮想マシン上では不要になるため。
USBリダイレクターに関しては、ちょっと使い方が分からなかったので、一旦削除している。
多分、spiceクライアントからUSBデバイスを接続するためのものかと。
これで起動すると、拡張USBカードに接続しておいたキーボード・マウスがゲストOSで使えるようになる。
駆け足だったけど今日はココまで。
現在は、ubuntuをゲストにしてPCIパススルー(GPUパススルー含む)を検証していたんだけど、この後ゲストOSをWindows7にすれば…と考えていた。
実はWindows7では、GPUパススルーを実現することが出来ないことが発覚した。
そのため、過去使っていたWindows7(物理ホスト、VMware Workstation上のゲスト複数)は、GPUパススルーしないKVMゲストに移植することにする。
次は、その辺りが書けるといいな。
ただ、それだけだとキーボード・マウスによる入力が出来ない。
当初は、ゲストにUSB Host Deviceからキーボード・マウスを引き渡せばいいかと思ったのだが、どうやらそれでは上手くいかないようだ。
そこで、PCI-Eに挿すUSB拡張カードを買ってきて(今回は、4ポートのUSB3.0カードを買ってみた)、それをPCに挿入、そのPCI-Eカードごとゲストに引き渡す形にした。
ただし、PCI-EカードスロットによってはPCIパススルー出来ないようなので、駄目だったらスロットを変えてみよう。
USB拡張カードを挿入、ホストOS(sagittarius)から認識できたら、GPUのパススルーと同じように、USBカードのパススルーも実施しよう。
ここでは、併せてデバイスの削除も実施しておく。
削除するデバイス
- サウンド:ich6
- タブレット
- チャンネル:spice
- USBリダイレクター1
- USBリダイレクター2
- Intel USB 3.0
タブレット、spiceチャンネルの削除は、今回の仮想マシン上では不要になるため。
USBリダイレクターに関しては、ちょっと使い方が分からなかったので、一旦削除している。
多分、spiceクライアントからUSBデバイスを接続するためのものかと。
これで起動すると、拡張USBカードに接続しておいたキーボード・マウスがゲストOSで使えるようになる。
駆け足だったけど今日はココまで。
現在は、ubuntuをゲストにしてPCIパススルー(GPUパススルー含む)を検証していたんだけど、この後ゲストOSをWindows7にすれば…と考えていた。
実はWindows7では、GPUパススルーを実現することが出来ないことが発覚した。
そのため、過去使っていたWindows7(物理ホスト、VMware Workstation上のゲスト複数)は、GPUパススルーしないKVMゲストに移植することにする。
次は、その辺りが書けるといいな。
2017年1月3日火曜日
ゲストにPCIパススルー(GPU割当)
続いて、PCIデバイスのグループ確認だ。
どうも、PCIデバイスはコントローラでグルーピング化され、そのグループ単位でしかゲストにブリッジ出来ないらしい。(同一のグループに属するPCIデバイスのうち、一つだけゲストにブリッジする、ということは出来ないらしい。)
と思ったんだけど、グループ確認しなくてもグラボとグラボに搭載されているサウンド、どうやらゲストにブリッジ出来たようだ。
ゲストOS側もUEFIにすることで、目的が達成できるみたいだ。
一度、以下の条件で仮想マシンを作ってみよう。
これだけでは、おそらく普通にインストールされて、従来通りにvirt-managerやvirt-viewer等で操作出来る仮想マシンに仕上がるはずだ。
一旦、そのゲストマシンのIPアドレスを固定化して、sagittariusやaquariusからログイン出来るようにしておこう。
また、GUI(X Window)を確認しておきたいので、適当に導入しておく。今回は、ubuntu-gnome-desktopを入れておくことにする。
virt-manager/virt-viewerでX Windowが確認できたら、一度そのOSは停止しておく。
停止したら、virt-managerから、ハードウェアの追加をしよう。
PCI Host Deviceからグラボ(自分の場合はNVIDIA Corporationデバイスだ)をゲストに割り当てる。
グラフィック機能とサウンド機能、それぞれデバイスとして認識しているので、2つある。2つとも割り当てよう。
このままでは、まだGPUが利用出来ない。
既に割り当てられているデバイスのうち、以下のものを削除しよう。
削除が終わったら、この仮想マシンを起動してみよう。
virt-managerやvirt-viewerの画面には表示がなく、物理マシンのVGA(PCIスロットに挿入したVGA)が繋がっているモニタに表示されたのではないだろうか?
おそらくこれで、GPUをパススルーは成功だ…が、このままではキーボード/マウス入力が出来ない。
キーボード/マウスも渡す必要があるんだが、現時点ではやり方が不明だ。
もう少し調査する。
取り急ぎ、仮想マシンには、別途ネットワーク経由でログインして、シャットダウンしておこう。
キーボード/マウスのパススルーが分かったら、また記載することにする。
今回はここまで。
どうも、PCIデバイスはコントローラでグルーピング化され、そのグループ単位でしかゲストにブリッジ出来ないらしい。(同一のグループに属するPCIデバイスのうち、一つだけゲストにブリッジする、ということは出来ないらしい。)
と思ったんだけど、グループ確認しなくてもグラボとグラボに搭載されているサウンド、どうやらゲストにブリッジ出来たようだ。
ゲストOS側もUEFIにすることで、目的が達成できるみたいだ。
一度、以下の条件で仮想マシンを作ってみよう。
- ネットワーク:openvswitchで作成したブリッジ
- ファームウェア:UEFI x86_64(「インストール前に設定をカスタマイズする」にチェックを入れておくこと。)
- OS:とりあえず暫定的にubuntuを
これだけでは、おそらく普通にインストールされて、従来通りにvirt-managerやvirt-viewer等で操作出来る仮想マシンに仕上がるはずだ。
一旦、そのゲストマシンのIPアドレスを固定化して、sagittariusやaquariusからログイン出来るようにしておこう。
また、GUI(X Window)を確認しておきたいので、適当に導入しておく。今回は、ubuntu-gnome-desktopを入れておくことにする。
virt-manager/virt-viewerでX Windowが確認できたら、一度そのOSは停止しておく。
停止したら、virt-managerから、ハードウェアの追加をしよう。
PCI Host Deviceからグラボ(自分の場合はNVIDIA Corporationデバイスだ)をゲストに割り当てる。
グラフィック機能とサウンド機能、それぞれデバイスとして認識しているので、2つある。2つとも割り当てよう。
このままでは、まだGPUが利用出来ない。
既に割り当てられているデバイスのうち、以下のものを削除しよう。
- ディスプレイSpice
- ビデオQXL
削除が終わったら、この仮想マシンを起動してみよう。
virt-managerやvirt-viewerの画面には表示がなく、物理マシンのVGA(PCIスロットに挿入したVGA)が繋がっているモニタに表示されたのではないだろうか?
おそらくこれで、GPUをパススルーは成功だ…が、このままではキーボード/マウス入力が出来ない。
キーボード/マウスも渡す必要があるんだが、現時点ではやり方が不明だ。
もう少し調査する。
取り急ぎ、仮想マシンには、別途ネットワーク経由でログインして、シャットダウンしておこう。
キーボード/マウスのパススルーが分かったら、また記載することにする。
今回はここまで。
2017年1月2日月曜日
ゲストにPCIパススルー(IOMMU有効化)
Ubuntuメインの環境にしようと思っても、やっぱりWindowsの便利なツールは手放せない。
更に、自分が使っているデジイチ等、Windows用のアプリしか無いものも多い。
Windowsゲームもやりたい。
そのため、KVMのゲストOSにWindowsを入れるが、KVMのグラフィック機能ではゲームが楽しめない。多分、Blu-Rayディスクも再生させるのが難しいだろう。
そこで出て来るのがPCIパススルーだ。
その名の通り、PCIデバイスをゲストOSにそのまま渡す、という仕組みだ。
実は今回のPCリフレッシュで、PCI Expressのグラフィックボードも搭載している。GeForceの1060を搭載したグラボだ。
(実はこのために、今はCPU搭載GPUのみを使用している。)
lspciコマンドで一応確認してみよう。
(sagittarius) $ sudo lspci
以下の出力が確認できる。
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1c03 (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 10f1 (rev a1)
グラボはPCIEスロットの1番に挿しているが、もしかしたら1番ではPCIパススルーは出来ないかもしれない。その場合は付け直しすることにする。
で、グラボを含めたPCIパススルーは…、実は良く分かってない。
ただ、調べてみたら幾らか情報はある。
このあたりの情報を参考に、色々試してみる。
OVMF による PCI パススルー
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
KVM PCIパススルー (PCI PassThrough)
CentOS7 KVMでPCIパススルー(GPU含む)
Ubuntu 12.04LTS + kvmでPCIパススルー
Linux - PCI-PassThrough
どうやら、UEFIでvt-dを有効にするだけじゃなく、カーネルブートオプションでIOMMUなるものを有効にする必要があるらしい。
ブートオプションなので、カーネルの再ビルド等は不要だ。
念のため、事前の情報を取得しておこう。
(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.before
(sagittarius) $ cat iommu.before
[ 0.057006] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1
自分の環境だと、この1行だけしか出力されなかった。
これに対して、IOMMUを有効にしたらどうなるのだろうか?
どうやら、/etc/default/grubをいじるらしい。
(sagittarius) $ sudo vi /etc/default/grub
12行目あたり、GRUB_CMDLINE_LINUX=""になっていると思う。
これを、GRUB_CMDLINE_LINUX="intel_iommu=on"に書き換えて保存する。
反映させるためには、update-grub2を実行するようだ。
(sagittarius) $ sudo update-grub2
ブートパラメータなので、OS再起動させないと反映されないはず。
(sagittarius) $ sudo shutdown -r now
再起動してきたら、ログインして念のためにdmesgにエラーが無いか確認しておこう。
(sagittarius) $ dmesg | less
で、先程と同様に、iommu関連のログを取得してみる。
(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.after
(sagittarius) $ cat iommu.after
先程は1行だったのが、今度は大量に出た。
そのうち1行、以下の行が出ているのを確認する。
[ 0.000000] DMAR: IOMMU enabled
これが出ていれば、IOMMUは有効になっているはずだ。
とりあえずIOMMU有効化は終わり。
次はPCIデバイスのグループ確認かな?
更に、自分が使っているデジイチ等、Windows用のアプリしか無いものも多い。
Windowsゲームもやりたい。
そのため、KVMのゲストOSにWindowsを入れるが、KVMのグラフィック機能ではゲームが楽しめない。多分、Blu-Rayディスクも再生させるのが難しいだろう。
そこで出て来るのがPCIパススルーだ。
その名の通り、PCIデバイスをゲストOSにそのまま渡す、という仕組みだ。
実は今回のPCリフレッシュで、PCI Expressのグラフィックボードも搭載している。GeForceの1060を搭載したグラボだ。
(実はこのために、今はCPU搭載GPUのみを使用している。)
lspciコマンドで一応確認してみよう。
(sagittarius) $ sudo lspci
以下の出力が確認できる。
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1c03 (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 10f1 (rev a1)
グラボはPCIEスロットの1番に挿しているが、もしかしたら1番ではPCIパススルーは出来ないかもしれない。その場合は付け直しすることにする。
で、グラボを含めたPCIパススルーは…、実は良く分かってない。
ただ、調べてみたら幾らか情報はある。
このあたりの情報を参考に、色々試してみる。
OVMF による PCI パススルー
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
KVM PCIパススルー (PCI PassThrough)
CentOS7 KVMでPCIパススルー(GPU含む)
Ubuntu 12.04LTS + kvmでPCIパススルー
Linux - PCI-PassThrough
どうやら、UEFIでvt-dを有効にするだけじゃなく、カーネルブートオプションでIOMMUなるものを有効にする必要があるらしい。
ブートオプションなので、カーネルの再ビルド等は不要だ。
念のため、事前の情報を取得しておこう。
(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.before
(sagittarius) $ cat iommu.before
[ 0.057006] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1
自分の環境だと、この1行だけしか出力されなかった。
これに対して、IOMMUを有効にしたらどうなるのだろうか?
どうやら、/etc/default/grubをいじるらしい。
(sagittarius) $ sudo vi /etc/default/grub
12行目あたり、GRUB_CMDLINE_LINUX=""になっていると思う。
これを、GRUB_CMDLINE_LINUX="intel_iommu=on"に書き換えて保存する。
反映させるためには、update-grub2を実行するようだ。
(sagittarius) $ sudo update-grub2
ブートパラメータなので、OS再起動させないと反映されないはず。
(sagittarius) $ sudo shutdown -r now
再起動してきたら、ログインして念のためにdmesgにエラーが無いか確認しておこう。
(sagittarius) $ dmesg | less
で、先程と同様に、iommu関連のログを取得してみる。
(sagittarius) $ cd
(sagittarius) $ dmesg | grep -i iommu > iommu.after
(sagittarius) $ cat iommu.after
先程は1行だったのが、今度は大量に出た。
そのうち1行、以下の行が出ているのを確認する。
[ 0.000000] DMAR: IOMMU enabled
これが出ていれば、IOMMUは有効になっているはずだ。
とりあえずIOMMU有効化は終わり。
次はPCIデバイスのグループ確認かな?
登録:
投稿 (Atom)