KVMゲストにWindowsを突っ込んで色々試してたんだけど、Windows側の電源管理で休止状態やスリープ状態が使えなかった。
これ使えないとちょっと不便だなーと思ってたんだけど、すげー単純なことだった。
対象のゲストマシンを停止させた後、ゲストの設定を編集する。
(sagittarius) $ virsh edit pegasus
<features>～</features>の間に、<acpi/>があるか確認。無ければ追記。
<pm>～</pm>の間に、<suspend-to-mem enabled='yes'/>と<suspend-to-disk enabled='yes'/>のエントリを確認。無ければ追記、あっても宣言がnoならyesに書き換える。
これで保存して、対象のゲストを起動すれば…。
あら不思議、ちゃんとちゃんと「休止状態」や「スリープ」が選べるようになりました、よ、と。
https://libvirt.org/formatdomain.html#elementsPowerManagement
2017年1月30日月曜日
2017年1月22日日曜日
ゲストにUSBリダイレクト
SPICEプロトコルは、ゲストのモニタ・キーボード・マウスやサウンドをつなぐだけでなく、端末側のUSBポートをリダイレクトすることが出来るらしい。
ゲストの端末のUSBポートを、ゲストOS側につなぐことで、手元のPCのUSBに繋いだデバイスを、あたかもゲストOSに繋いだかのように振る舞うことが出来るようだ。
で、実はこれ、簡単に実現できる。
手元の端末がWindowsなら、spice-spaceのダウンロードサイトからUsbDkというツールをダウンロード、インストールするだけだ。
インストールする先はゲストOSではなく、端末側(Virt Viewer/Remote Viewerを動かす方)だから間違えないように。
ゲスト側は、仮想マシン上にUSB Redirectorというデバイスが用意されている必要がある。
ただ、Libvirtのデフォルトで用意されるはずだから、特に弄る必要は無いぞ。
端末側にUsbDkの導入が終わったら、Remote ViewerでゲストOSに接続しよう。
今までは、Remote Viewerのメニューバー「File」の、「USB device selection」が選択不可の状態だったのが、選択出来るようになっているはずだ。
これを選択すると、手元のPCのUSBポートに接続されたデバイスを選択するダイアログが表示される。
ノートPCの内蔵デバイスの場合、内部的にUSB接続のものもあるので、ここに一覧化されるぞ。
例えば自分のノートの場合、モニタの上に接続されているカメラや、SDカードリーダーが表示された。
この中の一つにチェックを入れて「Close」ボタンを押せば、該当のデバイスがゲストOSに接続される。
ただ、ネットワーク的に遠いところ(屋外から、ケータイやWiMAX等の通信回線を通して、SSHトンネルをからのSPICE接続等)では、めっちゃ遅いし途中で切断される可能性も高い。
実際、USBカメラは機能しなかったし、SDカードを開いて中身を書き換えようとすると、ものすごく我慢を強いられるぞ。(実は、この機能を使えば、デジイチで外で撮影したあと、喫茶店とかですぐにデータを家のPCに格納できるかも、とちょっと期待していたのだが…。この速度ではかなり厳しいな。)
とは言え、これが存在する/しないで意外と使い勝手が変わりそうだ。覚えておいて損は無いだろう。
とりあえず、今日はここまで。
ゲストの端末のUSBポートを、ゲストOS側につなぐことで、手元のPCのUSBに繋いだデバイスを、あたかもゲストOSに繋いだかのように振る舞うことが出来るようだ。
で、実はこれ、簡単に実現できる。
手元の端末がWindowsなら、spice-spaceのダウンロードサイトからUsbDkというツールをダウンロード、インストールするだけだ。
インストールする先はゲストOSではなく、端末側(Virt Viewer/Remote Viewerを動かす方)だから間違えないように。
ゲスト側は、仮想マシン上にUSB Redirectorというデバイスが用意されている必要がある。
ただ、Libvirtのデフォルトで用意されるはずだから、特に弄る必要は無いぞ。
端末側にUsbDkの導入が終わったら、Remote ViewerでゲストOSに接続しよう。
今までは、Remote Viewerのメニューバー「File」の、「USB device selection」が選択不可の状態だったのが、選択出来るようになっているはずだ。
これを選択すると、手元のPCのUSBポートに接続されたデバイスを選択するダイアログが表示される。
ノートPCの内蔵デバイスの場合、内部的にUSB接続のものもあるので、ここに一覧化されるぞ。
例えば自分のノートの場合、モニタの上に接続されているカメラや、SDカードリーダーが表示された。
この中の一つにチェックを入れて「Close」ボタンを押せば、該当のデバイスがゲストOSに接続される。
ただ、ネットワーク的に遠いところ(屋外から、ケータイやWiMAX等の通信回線を通して、SSHトンネルをからのSPICE接続等)では、めっちゃ遅いし途中で切断される可能性も高い。
実際、USBカメラは機能しなかったし、SDカードを開いて中身を書き換えようとすると、ものすごく我慢を強いられるぞ。(実は、この機能を使えば、デジイチで外で撮影したあと、喫茶店とかですぐにデータを家のPCに格納できるかも、とちょっと期待していたのだが…。この速度ではかなり厳しいな。)
とは言え、これが存在する/しないで意外と使い勝手が変わりそうだ。覚えておいて損は無いだろう。
とりあえず、今日はここまで。
2017年1月19日木曜日
WindowsをKVMゲストにコンバート(virt-convert)
前回は、VMware Workstationの仮想ディスク(.vmdk)を、qemu-img convertによって、qcow2形式に変換し、仮想マシンそのものは別途新規作成、という手順を踏んだ。
これらの作業を一括で行ってくれる、virt-convert というコマンドも存在する。
ヘルプ(virt-convert --help)を見れば使い方は分かるだろう。詳細はmanページにも記載がある。
ただ、内部的には qemu-img convert を使っているので、前回の手順と大きな違いは無い。
好きな方を使えばいいだろう。
１つだけ試しに変換してみたが、手間に大きな違いはなかった。
これらの作業を一括で行ってくれる、virt-convert というコマンドも存在する。
ヘルプ(virt-convert --help)を見れば使い方は分かるだろう。詳細はmanページにも記載がある。
ただ、内部的には qemu-img convert を使っているので、前回の手順と大きな違いは無い。
好きな方を使えばいいだろう。
１つだけ試しに変換してみたが、手間に大きな違いはなかった。
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ゲスト化していく。
WindowsをKVMゲストにコンバート(ホストWin)
というわけで、コンバート作業を行う。
今回のコンバート対象は、もともと物理環境で動いていたWindows7 Entだ。
こちら、搭載されていたSSDは既にツブしてあって、そもそもコンバート元が存在しない。
実は、環境をツブす前に、Windows Backupでバックアップを作成していて、そのバックアップデータからKVM仮想マシンにリストアする、という形をとる。
やり方はそんなに難しくないので、簡単に流れだけ書いておく。
次は、VMware workstationのゲストで動かしていた環境だな。
今回のコンバート対象は、もともと物理環境で動いていたWindows7 Entだ。
こちら、搭載されていたSSDは既にツブしてあって、そもそもコンバート元が存在しない。
実は、環境をツブす前に、Windows Backupでバックアップを作成していて、そのバックアップデータからKVM仮想マシンにリストアする、という形をとる。
やり方はそんなに難しくないので、簡単に流れだけ書いておく。
- virt-managerから仮想ディスクを作成。
ここでは、元々使っていたディスクサイズと同程度か、それ以上のサイズにしよう。 - virt-managerから仮想マシンを作成。
1で作成した仮想ディスクを使用する。また接続I/F(IDEとかSATAとか)は、元々使っていた構成と同じにしよう。 - virt-managerのcd-romデバイスに、Windowsのインストールメディアか、バックアップ時に作成しておいたシステム修復ディスクを指定。
- 仮想マシンを起動。(CD-ROMブートさせる)
- 後はメニューに従ってシステムリストアさせる。
- 構成に併せてOSをカスタマイズする。
- 再アクティベートする。
- 不要なアプリケーションの削除
まずは以前導入済みで、仮想環境として不要となるアプリケーションの削除をしよう。
以前、物理マシン上で動かしていた頃、Intel Rapid Strage TechnologyやSSD用のツールキットを使っていたが、これらは不要となるだけでなく、なぜかCPU使用率が上がってしまうので削除する。
また、KVM仮想マシン上のWindowsでは、VMware Workstationも動かせないようなので、こちらも削除してしまう。
自分の場合、VMware Workstationの仮想マシン領域にiSCSI領域を使用していたため、こちらも不要だ。仮想マシンの必要なファイルを取得したら、iSCSIも停止してしまおう。 - 不要なデバイスの削除
管理者権限でコマンドプロンプトを起動し、以下のコマンドを実行しよう。
set devmgr_show_nonpresent_devices=1
Start DEVMGMT.MSC
デバイスマネージャーが起動してくると思うので、メニューバー「表示」から「非表示のデバイスの表示」を選択しよう。
メインウィンドウのツリーに、薄いアイコンがたくさん出てくると思う。これは、過去に接続したことのあるデバイスで、今は接続されていないもの、だ。
これらは、再度接続すれば認識されるが、もう二度と接続しないものもあるだろう。レジストリ領域を無駄に消費してしまうので、これらを削除してしまおう。
この中で正常に動作していないデバイスとして「PCIシンプル通信コントローラー」と「PCIデバイス」が見つかるかもしれないが、その二つは今は放置しておいて構わない。
この手順は、次の「VirtI/Oドライバの追加とデバイス切り替え」の後にも実施しておこう。 - VirtI/Oドライバの追加とデバイス切り替え
こちらは、HDD用とそれ以外で手順が異なる。
個別に対応する。- ドライバディスクの入手
ドライバディスクは、Fedoraプロジェクトのサイトからダウンロードできる。
ホストOS上でダウンロードしておこう。 - NetworkデバイスのVirtI/Oへの切り替えとドライバインストール
- ゲストOSを停止
- Networkデバイスを、VirtI/Oへ変更
- ゲストOSを起動
先ほどダウンロードしたドライバディスクを、ゲストOSのCD-ROMデバイスへマウント - デバイスマネージャーで、ネットワークデバイスが「不明なデバイス」になっていると思うので、右クリックから「ドライバの更新」を行い、ドライバの場所としてCD-ROMを選ぶ
- ドライバがインストールされる
同じように「PCIシンプル通信コントローラー」と「PCIデバイス」もドライバインストールする
ドライバディスクの中にQXLドライバもあるが、これをインストールしたら再起動でハングするようになった。spice-projectの方でドライバを配布しているため、そちらを使用しよう。
「標準VGAグラフィックアダプター」のドライバ更新だ。
そこまで出来たら、一度再起動して動作を確認してみよう。 - 仮のHDD追加とドライバインストール、OSディスクのデバイス切り替え
こちらはちょっと面倒だ。以下の流れで実施する。- ゲストOS停止
- 新しい仮想ディスクをゲストに追加
(このとき、インターフェースをVirtIOにすること) - ゲストOS起動
- ゲストOSのデバイスマネージャにドライバが無いSCSIコントローラーが表示されるので、他のドライバと同じように更新
- ゲストOS停止
- 先ほど追加した仮想ディスクを削除
- もともと使っていた仮想ディスク(仮想マシンのOSが入っているディスク)のインターフェースをVirtIOに変更する
- ゲストOS起動
- ドライバディスクの入手
- Guest-Agentの導入
仮想ドライバのメディアの中に、guest-agentというフォルダがある。
ゲストにコイツも入れておこう。ホストからの制御が出来るようになるっぽい。
(vmware-toolsとかその類)
Windows Installer形式なので、デバイスドライバの導入ほど手間はかからないはずだ。 - そのほか
後は、IPアドレスの固定化など、自分の環境に合わせて実施すればいい。
次は、VMware workstationのゲストで動かしていた環境だな。
2017年1月12日木曜日
WindowsをKVMゲストにコンバート(コンバート対象)
ある程度KVM環境は整った。
今度は、今まで使っていたWindowsをKVMゲストに持ってくる、という作業だ。
今まで使っていたWindows環境というのが意外と多く、整理してみると以下の通りになる。
Win7 Enterpriseで作成されている環境は、VMware Workstationホストとしての機能と、Blu-rayディスクの視聴にのみ使っていた。
どちらの機能も不要になるため、移行対象かどうか、という点に関しては△にしている。
(一旦移行しておいて、後で削除、となると思う。)
また、後ろの2つに関しては、環境を作り直すのはそんなに難しくないため、移行対象から外している。
Win7 Homeで作成されている環境もあるが、KVM環境にコンバートするに当たってリモートデスクトップが使いたくなるかもしれない。その時は、Win7 Home→Win7 Proへのエディション更新をすることになるが、それはまだ考えないことにする。
というわけで、次回は物理マシンのWin7 Entのコンバートだ。
今度は、今まで使っていたWindowsをKVMゲストに持ってくる、という作業だ。
今まで使っていたWindows環境というのが意外と多く、整理してみると以下の通りになる。
| OS | ハコ | 目的 | 移行対象 |
|---|---|---|---|
| Win7 Ent | 物理マシン | Blu-rayディスク視聴、VMware Workstationホスト | △ |
| Win7 Home | VMware Workstation | Web、カメラデータ取り込み、音楽再生等 | ○ |
| Win7 Pro | VMware Workstation | 仕事が出来る環境(ほぼ未使用) | ○ |
| Win7 Home | VMware Workstation | Win7用ゲーム | ○ |
| WinXP Pro | VMware Workstation | Win7非対応ゲーム | ○ |
| Win7 Home | VMware Workstation | Blu-ray作成用環境 | × |
| Win7 Home | VMware Workstation | ビデオ編集用環境 | × |
Win7 Enterpriseで作成されている環境は、VMware Workstationホストとしての機能と、Blu-rayディスクの視聴にのみ使っていた。
どちらの機能も不要になるため、移行対象かどうか、という点に関しては△にしている。
(一旦移行しておいて、後で削除、となると思う。)
また、後ろの2つに関しては、環境を作り直すのはそんなに難しくないため、移行対象から外している。
Win7 Homeで作成されている環境もあるが、KVM環境にコンバートするに当たってリモートデスクトップが使いたくなるかもしれない。その時は、Win7 Home→Win7 Proへのエディション更新をすることになるが、それはまだ考えないことにする。
というわけで、次回は物理マシンのWin7 Entのコンバートだ。
ゲストに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デバイスのグループ確認かな？
2017年1月1日日曜日
相互にWoL
前回の記載の通り、今回はaquariusからsagittarius、sagittariusからaquariusに相互にWoLが出来るように設定してみる。
基本的には、aqauriusは起動しっぱなし、sagittariusは適宜停止させることを考えているため、sagittariusからaquariusを起動させることはまず無いのだが、せっかくなので両方設定しておく。
いずれのPCも、オンボードetherからブート出来るようにUEFIを設定しておいて欲しい。
このあたりは、UEFIの実装によって異なるので、各自実機を確認しておくこと。
設定は簡単。
まずは、aquariusからsagittariusを起動させるための設定だ。
sagittariusのOSレベルでWoLが受け入れられるかの確認。(enp0s31f6は、sagittariusのLANの名前だ)
(sagittarius) $ sudo ethtool enp0s31f6
以下の出力があるかを確認してほしい。
Wake-on: g
この Wake-on が g になっていない場合、WoLは出来ない。ethertoolコマンドで変更してほしい。
変更は、各自ググってみてくれ。簡単に見つかるはずだ。
自分の場合、初めから g になっていたため、特に変更することは無かった。
続いて、sagittariusのMACアドレスの確認だ。
(sagittarius) $ ip link show enp0s31f6
以下のような出力があるはずだ。
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
この、XX:XX:XX:XX:XX:XX がsagittariusのMACアドレスになる。
ここまで出来たら、sagittariusをシャットダウンさせよう。
(sagittarius) $ sudo shutdown -h now
停止したら、aquariusからsagittariusが起動できるか確認だ。
既に、wakeonlanコマンドは導入済みのはずなので、supernovaを起動させる時と同様の手順を踏もう。
(aquarius) $ cd ~/wol
(aquarius) $ vi sagittarius
先程確認したMACアドレス(XX:XX:XX:XX:XX:XXの部分)を記載する。(それ以外は記載しない。)
では実際に起動を仕掛けてみる。
(aquarius) $ wakeonlan -f sagittarius
無事に起動してきただろうか？
無事に起動が確認できたら、aquariusからsagittariusの起動確認は終了だ。
今度は逆に、sagittariusからaquariusの起動確認だ。
sagittariusの時と同様に、aquariusのMACアドレスを確認しておこう。
(aquarius) $ ip link show enp0s25
また、ethtoolでWoLが有効かも確認しておく。
(aquarius) $ sudo ethtool enp0s25
確認できたら、aquariusはシャットダウンしておこう。
(aquarius) $ sudo shutdown -h now
続いて、sagittariusの方で準備だ。
多分、sagittariusの方はwakeonlanコマンドが導入されていないと思うので、導入しておこう。
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get --simulate install wakeonlan
(sagittarius) $ sudo apt-get install wakeonlan
wakeonlan用にMACアドレスを記載したファイルを用意しておく。
(sagittarius) $ mkdir ~/wol
(sagittarius) $ cd ~/wol
(sagittarius) $ vi aquarius
先程確認した、aquariusのMACアドレスを記載しておく。
では実際に実行だ。
(sagittarius) $ wakeonlan -f aquarius
どうだろう、無事にaquariusが起動してきただろうか？
無事に起動してきたら成功だ。
いずれも、起動が上手くいかない場合は、UEFIの設定を再確認してみるといい。
今回は以上。
基本的には、aqauriusは起動しっぱなし、sagittariusは適宜停止させることを考えているため、sagittariusからaquariusを起動させることはまず無いのだが、せっかくなので両方設定しておく。
いずれのPCも、オンボードetherからブート出来るようにUEFIを設定しておいて欲しい。
このあたりは、UEFIの実装によって異なるので、各自実機を確認しておくこと。
設定は簡単。
まずは、aquariusからsagittariusを起動させるための設定だ。
sagittariusのOSレベルでWoLが受け入れられるかの確認。(enp0s31f6は、sagittariusのLANの名前だ)
(sagittarius) $ sudo ethtool enp0s31f6
以下の出力があるかを確認してほしい。
Wake-on: g
この Wake-on が g になっていない場合、WoLは出来ない。ethertoolコマンドで変更してほしい。
変更は、各自ググってみてくれ。簡単に見つかるはずだ。
自分の場合、初めから g になっていたため、特に変更することは無かった。
続いて、sagittariusのMACアドレスの確認だ。
(sagittarius) $ ip link show enp0s31f6
以下のような出力があるはずだ。
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
この、XX:XX:XX:XX:XX:XX がsagittariusのMACアドレスになる。
ここまで出来たら、sagittariusをシャットダウンさせよう。
(sagittarius) $ sudo shutdown -h now
停止したら、aquariusからsagittariusが起動できるか確認だ。
既に、wakeonlanコマンドは導入済みのはずなので、supernovaを起動させる時と同様の手順を踏もう。
(aquarius) $ cd ~/wol
(aquarius) $ vi sagittarius
先程確認したMACアドレス(XX:XX:XX:XX:XX:XXの部分)を記載する。(それ以外は記載しない。)
では実際に起動を仕掛けてみる。
(aquarius) $ wakeonlan -f sagittarius
無事に起動してきただろうか？
無事に起動が確認できたら、aquariusからsagittariusの起動確認は終了だ。
今度は逆に、sagittariusからaquariusの起動確認だ。
sagittariusの時と同様に、aquariusのMACアドレスを確認しておこう。
(aquarius) $ ip link show enp0s25
また、ethtoolでWoLが有効かも確認しておく。
(aquarius) $ sudo ethtool enp0s25
確認できたら、aquariusはシャットダウンしておこう。
(aquarius) $ sudo shutdown -h now
続いて、sagittariusの方で準備だ。
多分、sagittariusの方はwakeonlanコマンドが導入されていないと思うので、導入しておこう。
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get --simulate install wakeonlan
(sagittarius) $ sudo apt-get install wakeonlan
wakeonlan用にMACアドレスを記載したファイルを用意しておく。
(sagittarius) $ mkdir ~/wol
(sagittarius) $ cd ~/wol
(sagittarius) $ vi aquarius
先程確認した、aquariusのMACアドレスを記載しておく。
では実際に実行だ。
(sagittarius) $ wakeonlan -f aquarius
どうだろう、無事にaquariusが起動してきただろうか？
無事に起動してきたら成功だ。
いずれも、起動が上手くいかない場合は、UEFIの設定を再確認してみるといい。
今回は以上。
登録:
投稿 (Atom)