カテゴリー「virt-manager」の14件の記事

2019年10月 6日 (日)

Debian 10 で Nested KVM ♪

仮想化の仮想化、つまり入れ子の構成での仮想化です。

Ne001_

Ne000

(出典:redhat:Device Assignment with Nested Guests and DPDK

Ne002

ただ単純にゲストの上にゲストをインストールすればいいやん、と思いっていましたが、そう単純ではありませんでした。

場合によっては「L0 ベアメタルホスト」にて、nestedのための設定が必要な場合があります。

ということで、Nested 構成のための手順書です。ただし、実ハードウェアはKVM使用が可能な環境、L0,L1は構築済みとして話を進めています。(L0構築は「Linux のインストール 基礎知識と実践(2018年度)」を、L1構築は「virt-manager 超入門! in 2018」を参考に。)

なお、作業環境はDebian10でやっています。

 

【(1) kvm_intel / kvm_amd モジュールでnestedが有効になっているか確認】

L0のベアメタルホスト、つまり、実ハードに直接インストールしたLinuxの端末にて以下を入力。

Intel系CPUの場合
$ cat /sys/module/kvm_intel/parameters/nested

AMD系CPUの場合
$ cat /sys/module/kvm_amd/parameters/nested 

 

返り値が「Y」または「1」の場合は有効、「N」または「0」になっているならば無効になっています。

Ne102_c_1

(返り値が「Y / 1」の場合)

 

Ne101_1

(返り値が「N / 0」の場合。この場合は、おそらくL1ゲストで「KVMを利用できません。これは、KVMパッケージがインストールされていない、もしくは、KVM のカーネルモジュール (kvm.ko) が読み込まれていないことを意味します。QEMU が使われるので動作が遅くなるでしょう。」とエラーが出てきて、KVMが利用できないハズ・・・)

 


これが有効になっている場合は(3)に、無効になっていれば(2)に進みます。

【(2) kvm_intel / kvm_amd モジュールのnestedを有効化 】

まずは、起動しているL1ゲストをすべて停止させます。

L0ホストにて、次のモジュールをアンロードします。

(Intel系の場合)# modprobe -r kvm_intel
(AMD系の場合) # modprobe -r kvm_amd

 

L0ホストにて以下、設定を追加します。

# vi /etc/modprobe.d/kvm-nested.conf

とし、エディタで以下の行を記述し、保存。

(Intel系の場合)options kvm_intel nested=1
(AMD系の場合) options kvm_amd nested=1

Ne105_

 

続けてL0ホストにて、以下のモジュールをロードしなおします。

(Intel系の場合)# modprobe kvm_intel
(AMD系の場合) # modprobe kvm_amd

 

再度、

(Intel系の場合)$ cat /sys/module/kvm_intel/parameters/nested
(AMD系の場合) $ cat /sys/module/kvm_amd/parameters/nested 

と打ち、返り値が「Y」または「1」になっていればOKです。

 

 

【(3) L1仮想マシンに vmx / svm機能を追加】  

L1ゲストのCPUモードを編集します。
対象のL1ゲストが起動していたら、停止させてから作業を行います。

L0ホスト上で、

# virsh edit L1ゲスト名

とし、<CPU>の項目のところに以下の行を追記します。

(Intel系の場合)<feature policy='require' name='vmx'/>
(AMD系の場合) <feature policy='require' name='svm'/>

Ne201_c_1

※ Nested KVM の設定において、

<cpu mode='host-passthrough'/>

の追記の方の話が多くのサイトでありますが、CPUパススルーの場合は、マイグレーションを考慮したときによろしく無いようです。
これについて、「Harukaの雑記」さんによる「ホストCPUをパススルーせずにNested KVM を動かす」に説明がありました。ここでは上記サイトに習い、仮想マシンに vmx / svm機能をもたせる手法で行っています。

 

以上で Nested KVM の設定は終了です。

問題がなければ、L1ゲストの「/proc/cpuinfo」に「vmx」または「svm」が出てくるはずです。

Ne102_c2_1

(「/proc/cpuinfo の svm」とかって何やねんな人は「virt-manager 超入門! in 2018」を参考に。)

ここから先はL1を構築したようにL2を構築すれば良いです。(終)

 

 

【おまけ】  

※1
virt-managerでL2ゲストをインストールしようとすると、

仮想ネットワーク 'default' の開始時にエラーが発生しました: internal error: Network is already in use by interface enp1s0

というエラーがでることがある。

Ne401_c_1

これは、新たに構築しようとしているゲストの「defaultのネットワークセグメント」が、すでに存在しているネットワーク(L0上に構築した「defaultのネットワークセグメント」)と重複している可能性が大です。ということで、セグメントのかぶらないものを新規作成すれば良いです。

ということで、以下、virt-managerによる手順。

とりあえず、対象の「QEMU / KVM」をクリックしてから「編集 > 接続の詳細」と進みます。

Ne402_c_1

 

すると、以下の画面が出るので、「緑色の十字アイコン」をクリックして、ネットワークを新規に作成。

Ne403_c_1

 

次に、ネットワーク名を決定する。今回は適当に「net1」とした。

Ne404_c_1

 

ネットワークアドレスを指定する。

Ne405_c_1

ネットワークアドレスを任意に選択。ただし、標準で virbr0 に割り当てられる「192.168.122.0/24」は避ける。そもそもこれが重複している可能性が大なので。あと、一般的に使用率が高そうな「192.168.0.0/24」や「192.168.1.0/24」や「192.168.11.0/24」なども避ける。まぁ、virt-manager が「192.168.100.0/24」などはどうですか〜と、問題なさそうなアドレスを提示してくれるので、それを選択するのもよし。

 

Ne406_c_

IPv6 はどうしますか? と聞いてきます。必要な人は追加してください。

 

Ne408_c_1

ネットワークの接続に関する設定です。隔離ネットワークなどの設定がここでできます。

とりあえず、今回は標準的なNAT接続にしました。

 

以上でネットワーク作成は完了です。

Ne411_c_1

 

あとは、仮想マシン作成時に、今作成したネットワーク(net1)を選択すればOKです。

Ne421_c_1

(終)

 

※2
ゲストOSに、最近の新しいOSをインストールする場合は、UEFI設定でインストールをしたほうが良い場合があるかもしれません。
その場合は、仮想マシン作成時に、下図のように「OVMF(UEFI)」を選択すると良いです。

Ne431_c_1

Ne501_

(終)

 

 

 

 

 

【参考サイト】
 ・「仮想マシン」と「ゲストOS」の言葉と意味の違い 
 ・Nested Guests - KVM 
 ・クラウド時代のオープンソース実践活用:Nested KVMでOpenStack構築三昧 
 ・ArchWiki:KVM 仮想化のネスト 
 ・RedHat:仮想化の導入および管理ガイド 
 ・KVM - Debian Wiki 
 ・ホストCPUをパススルーせずにNested KVM を動かす 
   <cpu mode='host-passthrough'>ではなく、
   <feature policy='require' name='vmx'/>で動かす話が述べられてた。
   マイグレーションにおけるCPUパススルーでの問題点が指摘されている。
 ・Nested Virtualization with Intel (VMX) 
 ・redhat:Device Assignment with Nested Guests and DPDK 
 ・Multi-Hypervisor Virtual Machines - Usenix 
 ・Unsafe Nested Virtualization on Intel CPU   
 ・Linux ハイパーバイザーの徹底調査 
 ・役割を終えた XEN , Citrix と XenServer が過去形となる日  
 ・コードログ:仮想マシン-ハイパーバイザーとしてのQEMUの動作 
 ・Introduction to Linux Virtualization using KVM 
 ・tkokamoの日記:virtio(vhost)の概要 
 ・BHyVeってなんや  
 ・FreeBSD 10.0-RELEASE公開記念 10.0-RELEASEで学ぶbhyveの使い方 

 

 

〔関連ページ〕
 ・virt-manager 超入門! in 2018 
 ・virt-manager でリモートアクセス(SSH-一般ユーザ接続:公開鍵認証) 

 

 

 

 

 

2019年8月27日 (火)

virt-manager:VirtFS でホスト・ゲスト間のファイル共有

V007_cr

VirtFSを利用してホスト・ゲスト間でファイル共有、読み書きができたのでメモ。厳密にはファイルの共有というよりは、ディレクトリ(フォルダ)の共有により、同一ファイルを扱うことができる、といった方が正しいかもしれませんが。どちらにせよ、共有できるのと、できないのでは利便性が断然変わりますね。

ということで今回はその手順を整理したのですが、とりあえず作業環境は

ホストOS: Debian GNU/Linux 10 KDE
 ホスト側ユーザ名:ruser10
 仮想環境: QEMU/KVM 3.1.0:virt-manager 2.0.0:libvirt 5.0.0
ゲストOS: Debian GNU/Linux 7 KDE
 ゲスト側ユーザ名:vuser7

となります。

なお、virt-manager は通常「root権限での使用」となりますが、「一般ユーザ権限」でやった方がオススメ。というかすべき。
理由は後述。一般ユーザ権限での使用に関しては、「virt-manager を一般ユーザ権限で使用できたの巻」をどうぞ。


大まかな手順は以下になります。

(1)ホストOSにて、「ファイル共有のためのディレクトリ」を作成(メインのディレクトリ)
(2)対象のゲストOSにて「ファイルシステムを作成」(ターゲットパス等の設定)
(3)ゲストOSにて、マウント用のディレクトリを作成
(4)共有用のディレクトリをマウント(これ以後、共有開始可♪)
(*)/etc/fstabによるマウント自動化

ではいきます。

 

【(1)ホストOSにて、「ファイル共有のためのディレクトリ」を作成  

まず、「ファイル共有のためのディレクトリ」をホストOS上に作成します。(このディレクトリがメインのディレクトリとなります。ゲストOS側はこのディレクトリの中身を共有することになります。)

V001_

今回はホームディレクトリ下に共有用の「shareF」というディレクトリを作成しました。

 

 

【(2)対象のゲストOSにて「ファイルシステムを作成  

下図のように、対象のゲストOSの詳細の画面から「ハードウェアを追加」を選択。

V002_

 

次に、「ファイルシステム」を選択し、「ドライバー」と「モード」は「Default」、「ソースパス」は「ホストOS上にてファイル共有用に作ったディレクトリのパス」を入力。「ターゲットパス」は任意に自分でテキトーに指定。この「ターゲットパス」はゲストOSからマウントする際に後で使用します。

V003_

  ↓

V004_r

(ファイルシステム作成完了の図♪)

 

*おまけ

V031_r

(virsh でいじるならば「# virsh edit ゲストOS」で。上図は一例。確認だけなら、「# cat /etc/libvirt/qemu/ゲストOS.xml」でも良い。)

 

 

【(3)ゲストOSにて、マウント用のディレクトリを作成  

対象のゲストOSを起動。

今度は「ゲスト側でマウントするためのディレクトリ」をゲストOS内に作成します。

V005_

ゲストOSにて、今回は「shareP」というマウント用のディレクトリを作成しました。

以上で、下準備は終わりです。

今回の事例の設定値を整理をすると、

ホストOSの共有用のディレクトリのパス
 「/home/ruser10/shareF/」
ターゲットパス名
 「SharePoint
ゲストOSの共有用のディレクトリのパス
 「/home/vuser7/shareP/

です。

 

【(4)共有用のディレクトリをマウント  

V006_

ゲストOSの端末にて、

# mount -t 9p -o trans=virtio (ターゲットパス)(ゲストOSの共有用ディレクトリのパス)
(今回は、「# mount -t 9p -o trans=virtio SharePoint /home/vuser7/shareP/」)

とすればマウントが完了する。

以後、ファイルの共有が可となる。

V007_cr2

ちなみに、ファイルが保存されている実際の場所は、ホスト側の方になります。(終)

 

※ virt-manager の「一般ユーザ権限」化をしなかった場合、下図のようにゲストOS側からは書き込みができない。

V011_cr2

ということで「一般ユーザ権限」化をば。

 

 

 

 

【(※)おまけ 〜 /etc/fstab によるマウントの自動化  

(4)までの手順で設定を終わらせた場合、ゲストOSを終了するとマウントは解除されるため、ゲストOSを起動するごとに、(4)のマウント作業が必要となってしまう。

そこで、ゲストOSの /etc/fstab を編集し、このマウント作業を自動化させる。

ゲストOSの「/etc/fstab」に

(ターゲットパス)(ゲストOSの共有用ディレクトリのパス)9p trans=virtio,version=9p2000.L,nobootwait,rw,_netdev 0 0

を追記する。

(今回は、

SharePoint /home/vuser7/shareP/ 9p trans=virtio,version=9p2000.L,nobootwait,rw,_netdev 0 0」

V008_cr2

以上で終了。

次回の起動からは自動でマウントされます。以後、(4)の手動によるマウント作業は不要です。(終)

 

 

 

【外部サイト】
 ・KVM:VirtFS 
 ・Documentation/9psetup - QEMU 
 ・Seesaa wiki:VirtFS 
 ・Arch:fstab  
 ・9p, ubuntu 14 and fstab 
   /etc/fstab の書式を参考に。
 ・VirshコマンドによるKVMゲストOSの管理 
 ・FreeBSD:VirtFS  

 ・Virtio-fs 
  

 

 

〔関連ページ〕
 ・virt-manager 超入門! in 2018 
 ・virt-manager:USBリダイレクトの無効化・制限 
 ・virt-manager でリモートアクセス(SSH-一般ユーザ接続:公開鍵認証) 
 ・Linuxでファイル暗号化(1)〜 USBメモリをgocryptfsで守る♪   
 ・ネットワーク切断設定時限定 〜 VirtFS の自動マウント設定こぼれ話  

 

 

 

 

 

 

2018年9月 1日 (土)

virt-manager でリモートアクセス(SSH-一般ユーザ接続:公開鍵認証)

この手法は、リモートホスト側の virt-manager の調整がされていることが前提になってきます。
これについては、
virt-manager を一般ユーザ権限で使用できたの巻
にて。

上記の設定はなされているものとして、以下ではSSHの設定を行います。


SSHの基本的な設定とかよくわからんな方は
SSH でリモートアクセス! in 2018
をどうぞ。

ちなみに今回の解説でのネットワークは以下のようなローカルな環境でやってます。

001

【ローカルホスト実行環境】

 ホストOS: Debian GNU/Linux 9
 仮想環境
  QEMU/KVM 2.8
  libvirt 3.0
  virt-manager 1.4
 ホスト名:LocalPC9 
 IP:192.168.11.2 
 ゲストOS
  ・debian7

 

【リモートホスト実行環境】

 ホストOS: Debian GNU/Linux 9
 仮想環境
  QEMU/KVM 2.8
  libvirt 3.0
  virt-manager 1.4
 SSHサーバopenssh-server 
 ホスト名:RemotePC9 
 IP:192.168.11.71 
 ゲストOS
  ・android8.1
  ・debian5
  ・debian9
  ・Raspbian
  ・winxp

 

〔大まかな流れ:SSH設定手順〕  

【ローカルホスト側】
 ・公開鍵/秘密鍵ペア生成
 (他の環境で作成してもよい。その場合は、秘密鍵の設置を自身で。) 

【リモートホスト側】
 ・上記で作成された公開鍵を「/home/一般ユーザ/.ssh/authorized_keys」に。

で、終了。

 

002_b

root接続の時と同様、自分の環境では、1回、通常のSSH接続してからでないと、virt-managerからリモートアクセスできなかった。
 

 

〔実践例〕 

(ローカルホストでの作業)

$ ssh-keygen -t rsa

で鍵を生成。ecdsaで行きたい人は「$ ssh-keygen -t ecdsa」。

012_1_2

(リモートホストでの作業)

(事前に上記で作成した「公開鍵」をruser2ユーザのホームディレクトリにコピーしたと仮定して)
$ mkdir ./.ssh (←「~/.ssh」 ディレクトリが存在しない場合)
$ chmod 700 ./.ssh/(←「~/.ssh」 ディレクトリを自分で作成した場合)
$ cat /home/ruser2/公開鍵(*.pub) >> ./.ssh/authorized_keys
$ chmod 600 ./.ssh/authorized_keys

で終了。 

011_1

 

(ローカルホストにて1回SSH接続しておく)
020_1_2


上記は「ssh リモートホストユーザ名@ipアドレス」としているが、今回のようなローカルエリアネットな場合は、「ssh リモートホストユーザ名@リモートホスト名.local(今回の例で言えば、 ssh ruser2@RemotePC9.local で行ける)」(mDNS:Multicast DNS の使用。)

以上で設定は終了です。

 

〔virt-manager でリモート接続〕 
ローカルホスト側の virt-manager を起動し、「ファイル > 接続を追加」を選択。
031_1_2

021_2

052_1

042_
 
(リモートで稼働してみたの図。)
 
 
 
〔おまけ〕 
Debian 9.5 の場合は、一般ユーザに関してはデフォルトでパスワード認証が可となっているので、パスワード認証を不可としたい場合は、

【リモートホスト側にて】
 ① /etc/ssh/sshd_config ファイルにて
  「PasswordAuthentication yes」を
  「PasswordAuthentication no」と編集後、
 ② # systemctl restart sshd でsshd を再起動。 

とすれば「パスワード認証」はできなくなります。
B071_081_1

B073_082_1

公開鍵認証only(パスワード認証不可)なので、セキュリティ的にはこちらの方が良いかと。

 

 
 
以上で終了です。
 
「virt-manager でリモートアクセス(SSH-root接続:公開鍵認証)」よりも、こちらの方がroot接続によるSSH接続は必要としないので、この点についてはセキュリティ的に安心かも。(素人判断でありますが) 

 

 

〔おまけ その2〕 (2019.9.1 追記)

ローカルホスト側のvirt-managerから、リモートホスト側のゲストOSを起動したとき、何故か画面が真っ黒のままで、何も表示されないことがある。(リモートホスト側のvirt-managerでは表示される。)

この場合、そのゲストOSの「ディスプレイSpice」のアドレスの所が「localhostのみ」になっているかもしれない。

Vr_301_r

その場合は、これを「すべてのインターフェース」に直せば、たぶん表示されるようになるかと。

Vr_302_r

(終)

 


 
 
〔関連ページ〕
 ・SSH でリモートアクセス! in 2018(その2)【公開鍵認証】  
 ・SSH:rootでログインする場合 
 ・virt-manager 超入門! in 2018  
 ・virt-manager でリモートアクセス(SSH-root接続:公開鍵認証) 
 ・virt-manager:VirtFS でホスト・ゲスト間のファイル共有     
 

 

 
 
 
 
 
 

2018年8月31日 (金)

virt-manager を一般ユーザ権限で使用できたの巻

通常、virt-manager はrootユーザ権限で使用する設定になっている。
 
そのため、virt-manager を SSH でリモートアクセスする際、そのままでは、rootでSSH接続しなければならない。
 
root で SSH 接続することはあまり好ましくないと思われるので、何とかならないかと調べていたところ、 virt-manager は 非root ユーザ権限の「一般ユーザ権限」で使用することができることがわかった。
 
普段使いのArch Linux さんの
virt-managerをroot以外の一般ユーザーで使う
が非常にまとまっていて素晴らしい。
 
上記のサイトを参考に、一般ユーザ権限で使用することができた。
 
ちなみに、自分の場合は、
 ・QEMUの設定 
 ・libvirtの設定 
までで十分だった。
 
いやぁ感謝。
 
 
 
 








 


2018年8月24日 (金)

virt-manager でリモートアクセス(SSH-root接続:公開鍵認証)

 

※1
SSHのroot接続によるセキュリティ設定に不安がある方は
virt-manager でリモートアクセス(SSH-一般ユーザ接続:公開鍵認証)
の方が良いかと思います。
ちなみに手順的にはこちらの方が早いです。
 
※2
SSHの基本的な設定とかよくわからんな方は
SSH でリモートアクセス! in 2018
をどうぞ。

virt-manager でリモートアクセスです。 

とりあえずやり方は以下。
 
ちなみに今回の解説でのネットワークは以下のようなローカルな環境でやってます。
 
 
001

 
【ローカルホスト実行環境】

 ホストOS: Debian GNU/Linux 9
 仮想環境
  QEMU/KVM 2.8
  libvirt 3.0
  virt-manager 1.4
 ホスト名:LocalPC9 
 IP:192.168.11.2 
 ゲストOS
  ・debian7

 

【リモートホスト実行環境】

 ホストOS: Debian GNU/Linux 9
 仮想環境
  QEMU/KVM 2.8
  libvirt 3.0
  virt-manager 1.4
 SSHサーバopenssh-server 
 ホスト名:RemotePC9 
 IP:192.168.11.71 
 ゲストOS
  ・android8.1
  ・debian5
  ・debian9
  ・Raspbian
  ・winxp 

 

〔大まかな流れ:SSH設定手順〕 

【ローカルホスト側】
 ・公開鍵/秘密鍵ペア生成
 (他の環境で作成してもよい。その場合は、秘密鍵の設置を自身で。) 

【リモートホスト側】
 ・上記で作成された公開鍵を「/root/.ssh/authorized_keys」に。

で、終了。
 
002_3

 
ただし、自分の環境では、1回、通常のSSH接続してからでないと、virt-managerからリモートアクセスできなかった。
 

 

〔実践例〕 
 
(ローカルホストでの作業)

$ ssh-keygen -t rsa

で鍵を生成。ecdsaで行きたい人は「$ ssh-keygen -t ecdsa」。

 

012_1
 
(リモートホストでの作業)

(事前に上記で作成した「公開鍵」をruser2ユーザのホームディレクトリにコピーしたと仮定して)
# mkdir ./.ssh
# chmod 700 ./.ssh/
# cat /home/ruser2/公開鍵(*.pub)>> ./.ssh/authorized_keys
# chmod 600 ./.ssh/authorized_keys

で終了。 

 

021_1

(ローカルホストにて1回SSH接続しておく)
024_1

 


上記は「ssh root@ipアドレス」としているが、今回のようなローカルエリアネットな場合は、「ssh root@リモートホスト名.local(今回の例で言えば、 ssh root@RemotePC9.local で行ける)」(mDNS:Multicast DNS の使用。)

  

〔virt-manager でリモート接続〕 
ローカルホスト側の virt-manager を起動し、「ファイル > 接続を追加」を選択。
031_1

 
051_2

 
052_1

053_1

 (リモートで稼働してみたの図。)
 
 
さて、以上で終了ですが、冒頭で述べたとおり、「root接続」なので、個人的にはセキュリティ上心配があります。
 
この設定の場合、通常のSSH接続でも「root接続」が可なので、ローカルホストがセキュリティ的に陥落した場合リモートホストも無条件で落とされます
024_2

なので、このやり方でやる場合は、SSH接続に「何らかの制限」をかけた方が良いと思われます。
制限をかけないのであれば、このやり方で接続は「できる」けれども「やるべきではない」かも。
 
SSHの制限についてはいろいろと調べたんですが、素人な自分には良いやり方を見つけることができませんでした。う〜ん、残念。よい制限方法はないものか・・・。
 
  
  
ちなみに話変わって、virsh ならば、公開鍵内に

command="/usr/bin/virsh"

を追記すれば、SSH-root接続virsh に限定することは可能です。
 
(リモートホスト側)
061_1

(ローカルホスト側)
062_3

たぶんセキュリティ的にはマシかと。

 
 
 
 

〔関連ページ〕
 ・virt-manager でリモートアクセス(SSH-一般ユーザ接続:公開鍵認証)(非root接続) 
 ・SSH でリモートアクセス! in 2018(その2)【公開鍵認証】 
 ・virt-manager 超入門! in 2018   

 
 

【外部サイト】
 ・【 ssh 】コマンド――リモートマシンにログインしてコマンドを実行する 
 ・virt-managerでKVMホストにリモート接続する(VNCに関する情報が) 
 ・virshがroot以外で使えない理由 
 
 【TLS接続関係】
  ・libvirt:TLSSetup  
  ・KVMのリモート管理 
  ・libvirtでTLS接続 

 
 
 
 
 
  
 
 

2018年8月18日 (土)

virt-manager 超入門! in 2018

最近は右も左も「仮想化」な時代になった感じですね。
8年前、コマンド打ちながらやっとこさ動作させていたのが、いつのまにかボタンひとつで操作するのが当たり前のようになっていて、時代を感じる今日この頃です。
 
さて、今回扱う仮想化ソフトは「virt-manager」です。
 
064__1

非常に使いやすい仮想化ソフトの一種なんですが、この「virt-manager」とセットでよくでてくる基本的なキーワードがあるので、まずそこの確認から。
 
 
01_qemu_3

★ 仮想化の大黒柱「QEMU」  
ハードのエミュレータです。
PS/2 マウスやキーボード、HDD、CD-ROM、FDD、VGA、サウンドカードなどの周辺機器、NICやシリアルポート、PCI、USB等をエミュレート(模倣)します。
 
もちろん、CPUのエミュレートもサポートされています・・・が、ソフトのみでCPUをエミュレートしようとすると、どうしても遅くなってしまうんですね。
 
で、実行速度を少しでも上げるためにkqemuっていうカーネルモジュールが開発されていたんですが、KVMなるものが現れて、「kqemuよりもこっちの方がいいよね」ってことで、kqemuは途中で終了し、ここらへんの部分はKVMへ移行しました。
 
 
02_kvm_2

★ 高速化のキモ「KVM」  
アナウンス後、わずか2ヶ月で Linux のカーネルにマージされたと噂されるハイパーバイザ。立ち位置的に、Xenと近い模様。
 
実CPUの仮想化支援機能である Intel VT(vmx)AMD-V(svm) を利用する、というか、これが無いと使用できない。
 
ようは、CPU等の仮想化をソフトだけでやるんでは無くて、実のCPUの力(仮想化支援機能)も借りて、実行速度をあげましょう、というシロモノ。
 
QEMU単体でやるのと、KVMとセットでやるのでは実行速度が全然違います。
セットで使うようなもんなので、よく「QEMU / KVM」みたいな感じで表記されているのだと思います。
 
ということで、KVMは高速化のキモとなるんですが、何度も言うとおりCPUの「仮想化支援機能」が必須です。これが無いCPUでは利用できません。
 
10年前以上のCPUであれば、利用はまず無理でしょう。CPUに仮想化支援機能が入ってません。
まぁ、それくらい昔のPCであれば、全体的なスペックから考えて仮想化は厳しいとは思いますが。
 
 
 
03_virtm_3

★ 仮想化を身近な存在に〜「virt-manager」  
ようは「QEMU/KVM」のフロントエンドです。
素で「QEMU/KVM」を使う場合、扱いにくいんですが、「virt-manager」はGUIで直感的に管理・運用ができるようなってます。
 
051__2

(素でQEMUを使ってみた場合の図:コマンド打ちで大変だった・・・)
 
 
さて、当然のことながら「virt-manager」単体では何もできません。
「QEMU」や「KVM」などの仮想化ソフトの存在があって、初めて機能します。
 
 
  
04_libvirt

★「KVM」と「virt-manager」の橋渡し〜「libvirt」 
libvirtは、仮想化管理用の共通APIを提供するもの。
 
元々はXenを制御するために作られたライブラリらしいのですが、それが発展してKVMやVMwareなども制御できるようになったとのこと。
 
で、「KVM」と「virt-manager」の間を橋渡ししています。
 
Wikipedia にある図がそれを端的に示していると思います。
(出典:https://ja.wikipedia.org/wiki/Libvirt)
 
05_libvirt_support_2

仮想マシンソフトごとに異なる制御プロトコルを使った場合、それぞれのソフトの流用性は低くなりますが、libvirtが抽象化された制御方法を提供することで、それぞれの機能追加を容易に行うことができるようになったりします。
 
かつて Debian 7 で virt-manager がうまく動かなかったとき、libvirt のバージョンが古すぎたのが原因だったようで、libvirt の重要性を意識するようになりました。
 
大げさかもしれませんが、libvirt の存在のおかげで、virt-managerが成り立っているようなものかもしれません。
 
 
おまけ
★ コマンドで操作するで〜「virsh」 
virsh は仮想マシンソフトを扱う上で利用することの出来る対話型のシェルプログラム。「virt-manager」はGUIで仮想マシンを管理・運用するのに対し、「virsh」はCUIで操作します。
さらなるレベルアップを考えているなら、「virsh」にも手を付けてよいかと思います。
 
 
 
【〜実践準備編〜】 
 
さて、話が長くなりましたが、とりあえず実践準備編です。
 
virt-manager(QEMU/KVM)を使用するにあたって、いろいろと条件があるので、まずそこの確認をば。
要件、というか、必要なもの一覧です。

・virt-manager を利用するためのOS(ホストOS)
  解説では「Debian9 KDE」を使ってます。
仮想化支援機能をサポートするCPU 
マザーボード上でCPUの仮想化支援機能有効化されていること

繰り返しになりますが、ハード的な制約として仮想化支援機能をサポートしないCPUは不可です。
仮想化支援機能の名称は、
Intel系のCPUの場合は、「Intel VT(vmx)」、
AMD系のCPUの場合は、「AMD-V(svm)」になるかと思います。
調べ方としては、CPUの型番でネットで検索して、調べる、もしくはLinuxが動いている場合は、「/proc/cpuinfo」を調べればわかります。
  

$ cat /proc/cpuinfo

001_1_3

この中に「vmx」または「svm」のキーワードがあればOK。
ただ、素で探すのはウォーリーを探せな感じで大変なので、grep使って楽に探しましょう。
 
Intel系のCPUなら、

$ cat /proc/cpuinfo | grep vmx --color=auto

AMD系のCPUなら、

$ cat /proc/cpuinfo | grep svm --color=auto

どっちかわからん。めんどくせぇから両方で検索! な人なら、

$ cat /proc/cpuinfo | grep -E "(vmx|svm)" --color=auto

と打つと良いです。
002_1_2

対応していれば、色付きで「vmx」または「svm」が含まれる行が出てきます。
もし未対応ならば、何の行も出力されません。
 
さて、CPUはこれに対応しているとして、今度はマザーボードです。
マザーボードによってはこれが無効化されている場合があるので、「Bios/UEFI」上でこれを確認します。
 
011

(上記はAMD系:svm のケース)
 
「無効(Disabled)」になっている場合は、「有効(Enabled)」にすれば良いです。
 

「Bios/UEFI」って何やねん、という方は
Linux のインストール(その3)」の
そもそも「Bios/UEFI」って何やねん? 
を参考に。

この条件が揃って、やっとvirt-manager(QEMU/KVM)を利用できます。
 

※ カーネルのKVMモジュールが有効になっているかの確認も必要なケースがあるようですが、近年のデストリではそんなに心配しなくても良さげです。

 

さて、上記の条件が揃ったと仮定して、話を続けます。

では、virt-managerのインストールに進みましょう。
 
 
 
【実践編:仮想化ソフトの導入】  
  ★ virt-manager のインストール 

作業環境は「Debian9 KDE」になります。

コンソールの場合は、

# apt install virt-manager

で終了。

001_1

Apper でのインストールは下図。
(Apper って何な方は「KDE パッケージ管理ソフト Apper」をどうぞ。)

003_1

以上で終了です。

Debian9 KDE の場合、これで QEMU、KVM、libvirt 等、必要なパッケージがすべて入ります。

ちなみに、このインストールが終わったら、一度PCを再起動させた方が良いです。

再起動せずに、Virt-manager を使おうとすると、使用中に次のようなエラーに出くわすかと思います。

006_e_

ということで、再起動を忘れずに。
 
以上、インストール編でした。
なんか、あっけないですね。
 
次は virt-manager の仮想マシン作成・ゲストOSのインストールの準備編です。 
 
virt-manager 超入門! in 2018(その2)」に続きます。
 
 
 
 
 
 
【外部サイト】
 ・(FreeBSD) KQEMUは終了ってことらしい 
 ・第4のハイパーバイザー「KVM」開発者が語る、Xenとの大きな違い 
 ・エンジニアなら知っておきたい仮想マシンのしくみ  
 ・Linux標準の仮想化技術「KVM」の仕組み (1/2)  
 ・スクリプトで仮想化管理・Virsh 
 ・libvirt探訪(基礎編) 
 ・libvirtを忘れずに 
 ・今知っておきたい仮想化時代のCPU技術  
 
 ・Kernel Virtual Machine(kvm)のセットアップ 
 ・Arch Linux:KVM カーネルのサポート  
 
 ・QEMUのなかみ(QEMU internals) part1 
 ・KVMのなかみ(KVM internals) 
  ・カーネルエクスプロイト入門 - Linuxカーネル解析の基礎 -  
 
 ・virtioによる準仮想化デバイス その1「virtioの概要とVirtio PCI」 
 ・Virtioについてのまとめ 



 
 
 

2018年6月30日 (土)

virt-manager:USBリダイレクトの無効化・制限

015_d
 
 
実行環境は以下。

仮想環境: QEMU/KVM 2.8:virt-manager 1.4
ホストOS: Debian GNU/Linux 9
libvirt 3.0

 

現況、以下な感じ。
002

で、「/etc/libvirt/qemu/」以下に、インストール済みのゲストOSの定義ファイルがあるので、それを書き換える。
ただし、viで直接書き換えるのは推奨されないようで、

# virsh edit ゲスト名

という形で書き換えを行う。
003_

 

ちなみに、初回時には書き換え用のエディタをnanoにするかviにするか聞かれたりする。

 
 

〔USBリダイレクトの無効化〕

対象のゲストOSのxmlファイルに以下を追記して、上書き保存すればOK。
ゲストOSを起動すると設定が反映されてる。

<redirfilter>
    <usbdev allow='no'/>
</redirfilter>

 

004_
012_d

 


〔USBリダイレクトの制限〕

USBメモリなどのマスストレージクラスのみ、リダイレクトの対象とし、それ以外は無効化する場合は、以下の記述とすればよい。

<redirfilter>
    <usbdev class='0x08' allow='yes'/>
    <usbdev allow='no'/>
</redirfilter>

 

005_  
015_d2  
「allow='yes'」は許可の意味。
また、「0x08」はUSBマスストレージクラスを意味する。

ちなみに、

<usbdev class='0x08' vendor='(ベンダーID:0x1234など)' allow='yes'/>

とすると、限られたベンダーのみ許可することができたり、

<usbdev class='0x08' vendor='(ベンダーID:0x1234など)' product='(プロダクトID:0xbeefなど)' allow='yes'/>

として、デバイスのモデルまで限定できたりもする。
 
055_

この制限、USBマウスやキーボードを、USBリダイレクトの選択から排除するには良いかと。
(終) 

 
 

※ おまけ
USBデバイスのベンダーIDやプロダクトIDは、「lsusb」コマンドで調べることができる。

 
 
 

<外部サイト>
 ・Domain XML format:Redirected devices 
 ・USBデバイスクラス 
 ・ベンダーIDとプロダクトIDについて 
 ・ 2進数と16進数を覚えよう!(0x と十六進数) 

 
 
  
 

〔関連ページ〕
 ・virt-manager with QEMU/KVM ゲストOSからUSBメモリへアクセス  
 ・virt-manager で USBリダイレクターの追加 
 ・virt-manager でGestOS起動時に自動でUSB接続プリンタ認識 

 
 
 
  

 
 
 

2018年6月23日 (土)

virt-manager でGestOS起動時に自動でUSB接続プリンタ認識

【実行環境】

仮想環境: QEMU/KVM 2.8:virt-manager 1.4
ホストOS: Debian GNU/Linux 9
libvirt 3.0

 

ホストOSに接続されたUSBプリンタを、ゲストOSで認識させる場合、「USBデバイスのリダイレクト」を行えばできるのだが、ゲストOSを再起動するごとに毎回これをやらなければならないのは面倒。

プリンタのように常に接続させておくようなデバイスの場合は、ゲストOS起動時に自動で認識してくれるとありがたい。

ということで、今回のテーマは
「virt-manager でUSBプリンタ自動認識」
であります。

手順としては、

[1] USBプリンタをホストに接続
[2] virt-manager にて「ハードウェア(USBプリンタ)を追加」設定
[3] ゲストOSでプリンタ認識(終)

のような流れ。

001_2
③は自分でUSBプリンタであろうものを探す。
ホストにプリンタを接続しておかないと出てこない。

上図の流れで「完了」とすると、USBプリンタが追加される。
002__3

あとは、ゲストOSを起動すればOK。
今後は「USBデバイスのリダイレクト」をしなくても、このプリンタは認識してくれる。(終)

 
 
 

※ 注
この設定後、USBプリンタを物理的に外してゲストOSを再起動させようとすると、「internal error:Did not find USB device 〜」なるエラーでゲストOSは起動しなくなる。
003_2_2

この場合、USBプリンタをホストに接続しなおした状態でゲストOSを起動すれば解決する。ちなみに、刺すべきUSBポートは元々刺してあったUSBポートが良いと思う。
というのも、USBメモリで自動接続の実験していた際、違うポートに刺し直してゲストOSを起動させたとき、動きが不安定になったことがあるからだ。
もともとと違うUSBポートに刺した場合、プリンタが不安定、もしくは動かない、はたまた、プリンタが壊れる可能性もあるかもしれない。

「ハードウェアを追加」で設定したときのUSBポートは、固定で使用した方が良さげ。

 

ちなみに、USBプリンタの使用を停止するなど、接続をやめる場合は、プリンタ設定のところを削除をすればよい。
021

 
 
 
  

〔関連ページ〕
 ・virt-manager with QEMU/KVM ゲストOSからUSBメモリへアクセス  
 ・virt-manager で USBリダイレクターの追加 
 ・QEMU/KVM ホスト・ゲスト間の文字コピペ設定  

 
 
 
 
 
 
 

virt-manager で USBリダイレクターの追加

【実行環境】

仮想環境: QEMU/KVM 2.8:virt-manager 1.4
ホストOS: Debian GNU/Linux 9
libvirt 3.0

 

ゲストOSでUSBデバイスを3つ以上接続しようとしても、「There are no free USB channels」状態で3つ目は接続できなかったりする。

001__2

 (3つ目のUSBメモリにアクセスできなかった例)

 

これは、USBリダイレクタがデフォルトで2つしかないことからきている。

002__2

ということで、これを追加すればよい。

 

003_2

③ はデフォルトで「Spice チャンネル」となっているハズ。

上記の手順で「完了」とすれば、リダイレクタが追加される。

004__2

 

あとは、ゲストOSを起動している場合は、再起動。
無事、3つ目のUSBデバイスにアクセスできる。 

011__2


 
 
 

〔関連ページ〕
 ・virt-manager with QEMU/KVM ゲストOSからUSBメモリへアクセス  
 ・virt-manager:USBリダイレクトの無効化・制限  
 ・virt-manager でGestOS起動時に自動でUSB接続プリンタ認識 

 
 
 
 
 
 
 

2017年12月28日 (木)

ゲストOS - Windows10 〜 QXLドライバー や SPICE agent とか

ゲストOSとしての Windows10 用の QXLドライバーや  SPICE agent について。

まず、
 https://www.spice-space.org/download.html
にアクセス。

001  

 
 

032_r

「spice-guest-tools-latest.exe」をダウンロード。

Windows上でこの実行ファイルをクリックすれば、QXLドライバー や SPICE agent がインストールされます。

インストール時にウィンドウが出ますので、指示の通りに進めればOKです。

 
 
 
 

〔関連ページ〕
 ・wheezy on QEMU/KVM ディスプレイ解像度の変更作業記録 
 ・QEMU/KVM ホスト・ゲスト間の文字コピペ設定  

 
 
 
 
 
 
 
 
 
 
 
2021年5月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
無料ブログはココログ