libvirt

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
libvirt
Libvirt logo.svg
開発元 Red Hat
libvirt community[1]
最新版 1.2.10 / 2014年11月3日(36日前) (2014-11-03
プログラミング言語 C
プラットフォーム クロスプラットフォーム
種別 仮想化管理API
ライセンス LGPL
公式サイト libvirt.org
テンプレートを表示
libvirt supports several ハイパーバイザ, e.g. Kernel-based Virtual Machine, and is supported by several management solutions, e.g. virt-manager.

libvirtとは、仮想化管理用の共通APIを提供する、レッドハットを中心としたオープンソースプロジェクトである。

概要[編集]

libvirtは仮想機械の制御を抽象化したライブラリである。 本ライブラリの特徴は、サポート範囲が広いことである。 サポートしている仮想化は、現在XenKVMQEMULXCOpenVZUMLVirtualBoxVMware ESX・GSX・Workstation・Player、Hyper-V、そしてクラスタ管理ソフトOpenNebulaである。 更なる対象VM拡大を目指してたとえば、対応やLinux-VServerのサポートをどうするかなどが開発者メーリングリスト上で議論された。 また、さまざまな版数でのサポートも特徴である。たとえば、Xenのリリースされたさまざまな版(たとえば、Xen3.1.0やXen3.0.3など)で、動作する。また、UNIX系OSだけでなく、Windows上でもMinGWやCygwinを使えば動作する。

libvirt 自体が多くの種類の仮想化をサポートしていても、必ずしも、libvirt を利用しているアプリケーションが全ての仮想化をサポートしているというわけではなく、KVM や Xen などが libvirt を利用しているアプリケーションのサポートの中心となっている。

また、ハードウェアプラットフォームに着目すると、CPUの場合、x86, x86-64, IA64, Powerなどをサポートしており、ビット(32/64)およびエンディアンを問わない。

このような幅広いサポートを行っているため、仮想機械を制御するI/Fとしては、事実上の標準の地位を築きつつある。 たとえば、RHEL5上で、仮想マシンを管理するためのアプリケーションであるVirtual Machine Managerの実装においても利用されている[1]

また、本ソフトウェアのライセンスは、LGPLで提供されている。このため、GPLで開発されている、Xenのライブラリ(libxc)に比べて、アプリケーション開発者の視点では使い勝手が良い。

標準提供APIは、CPythonである。またその他の言語(PerlOCamlRubyJava)のAPIもオプションパッケージで提供されている。また、運用管理の標準インターフェースであるCIMへの対応もIBMを中心にCMPI CIM Providerとしてlibvirt-CIMの開発が進んでいる。なお、CMPIは、Common Manageability Programming Interfaceの略である。

また、セキュリティ拡張として、MACアクセス制御との連携を考えたsVirtが検討されている。[2]

本プロジェクトのメンテナーは、Daniel Veillard (通称Daniel)、Daniel Berrange (通称Dan)、Richard W.M.Jones (通称Rich)などRed Hatの開発者である。そのほか、Red Hat以外にもIBMやノベル、富士通の開発者にソースコードの変更権が与えられている。

ソフトウェア構成[編集]

libvirtの実装は、libvirt.cを中心としたソフトウェア構成になっている。libvirtのAPIを利用しているアプリとしては、管理コマンドvirshが提供されている。また、Python Bindingsもlibvirt.cの上位に位置する。

一方、各種仮想機械の、制御ドライバは、libvirt.cの下に位置する。 たとえば、Xenの制御層の実装では、Xen統合管理層(xen_unified.c)から、それぞれのXenのモジュールを呼び出す形になっている。ハイパーバイザー直接(xen_internal.c)、管理ツールであるXend(xend_internal.c)、管理データベースであるxenstore(xs_internal.c)を呼び出している。

また、ネットワーク越しの制御に関するコードは、以下の通りである。クライアント側では、remote_internal.cを介してリクエストを発行する。サーバ側では、libvirtd(コード的には、qemudディレクトリ以下)を介して、libvirtAPIを使って制御をおこなう。

アクセス制御[編集]

libvirtAPIを使う前にクライアント認証を必要とする接続がある。 接続で用いるクライアント認証方法は、管理者が選択できる。 この選択は、libvirtAPIを用いるアプリケーションに依存せず、統一的に適用される。

  • サーバ設定
  • UNIXドメインソケットによる伝統的権限管理
  • ポリシーキット(PolicyKit)を使ったUNIXドメインソケットの認証
  • ユーザ名とパスワードによる認証
  • Kerberosによる認証

サーバ設定[編集]

管理者は、libvirtdの認証方法を、ネットワークソケット毎に設定することが出来る。 この設定は、libvirtdの設定ファイル /etc/libvirt/libvirtd.confでおこなう。 そして、認証方法は、なし、POLKITそしてSASLの3つから選択することが出来る。 さらに、SASL機構は、将来さまざまなオプションを設定できるようになるはずである。

UNIXドメインソケットによる伝統的権限管理[編集]

libvirtがポリシーキット(PolicyKit)をサポートしていない場合、 UNIXドメインソケットに対するアクセス制御は、伝統的なユーザグループアクセス制御によりおこなわれる。

2種類のソケットがあり、ひとつは読み書き可能、もう1つは読みのみ可能となっている。 読み書きソケットは、アクセス制御が厳しく(0700)、ルートユーザのみが使うことが出来る。 読みのみソケットは、アクセス制御がオープン(0777)であり、どのユーザも使うことが出来る。 非特権ユーザにより広いアクセスを許可する場合、libvirtd.confファイルを編集しunix_sock_rw_permsに許可権限を設定し、ユーザグループを、unix_sock_groupに設定する必要がある。 例えば、前者の属性を0770にして、後者をwheelグループに設定すると、wheelグループの人全員libvirtdにアクセスできることになる。

ポリシーキット(PolicyKit)を使ったUNIXドメインソケットの認証[編集]

libvirtが、ポリシーキット(PolicyKit)認証をサポートする場合、アクセス制御は、より進んだ形態になる。 この場合、unix_sock_authパラメータは、polkitが標準になる。そして、ファイルアクセス権限は、読み書き権限を含め0777になる。クライアントアプリケーションは、PolicyKitと連携してアイデンティティを提供し、ソケットに接続する。 現デスクトップセッションのいずれのアプリケーションでも、パスワード認証を行うことが、読み書きソケットの標準ポリシーである。 この方法は、sudoコマンドによる認証と似ている。しかし、クライアントアプリケーションは、究極的に特権ユーザ(ルート)として動く必要がない。 そして、標準ポリシーでは、読み専用ソケットにどのようなアプリケーションも接続できる。

ポリシーは、/etc/PolicyKit/PolicyKit.confに置かれたマスター設定ファイルによって管理者が変更出来る。 PolicyKit.conf(5)マニュアルページに設定方法詳細の記述がある。

属性として、2つのlibvirtd操作が設定されている。1つは、読み専用のorg.libvirt.unix.monitorである。もう1つは、読み書き可能なorg.libvirt.unix.manageである。

例として、fredに読み書き権限を与え、joeには管理者パスワードを認証を要求する例を示す。このアクセス制御をするためには、以下の設定を、PolicyKit.confに追記する必要がある。

 <match action="org.libvirt.unix.manage">
   <match user="fred">
     <return result="yes"/>
   </match>
 </match>
 <match action="org.libvirt.unix.manage">
   <match user="joe">
     <return result="auth_admin"/>
   </match>
 </match>

ユーザ名とパスワードによる認証[編集]

TCPソケットを平文のまま用いたlibvirtdは、標準でSASLを認証機構として用いる。 SASL機構は、標準では、Digest-MD5を用いる。これは、基本的なユーザ名とパスワード形式の認証である。 データストリームを暗号化する方法も提供している。このため平文のTCPソケットのセキュリティもTLSソケットを使った場合と同等のセキュリティである。 このため、UNIXドメインソケット及びTLSソケットをSASL認証するように設定しておくことは望ましい。この設定は、libvirt.conf設定ファイルのauth_unix_ro, auth_unix_rw, auth_tlsでSASL認証するようにしておけばよい。

使い始めの段階では、ユーザアカウントは定義されていない。このためクライアントがTCP接続することが出来ない。 ユーザを追加し、設定を行うためには、saslpasswd2コマンドを使う。 このコマンドを実行するに当たって、アプリケーションがlibvirtであることを明示的に示す必要がある。 この例では、fredをアカウントに追加する例を示している。

 # saslpasswd2 -a libvirt fred
 Password: xxxxxx
 Again (for verification): xxxxxx


全アカウントのリストを見るためには、sasldblistuser2コマンドを使う。 このコマンドでは、libvirtのユーザデータベースを指定する必要がある。このデータベースは、/etc/libvirt/passwd.db にある。

 # sasldblistusers2 -f /etc/libvirt/passwd.db
 fred@t60wlan.home.berrange.com: userPassword

最後に、ユーザアクセスを停止する場合、saslpasswd2コマンドを再び使う。

 # saslpasswd2 -a libvirt -d fred

Kerberosによる認証[編集]

TCPソケットを平文のまま用いたlibvirtdは、標準でSASLを認証機構として用いる。 SASL機構は、標準では、Digest-MD5を用いる。これは、基本的なユーザ名とパスワード形式の認証である。 Kerberosのシングルサインオンを有効にするには、libvirt用SASL設定ファイルを変更する必要がある。 そのファイルは、/etc/sasl2/libvirt.confである。 そして、mech_listパラメータは、digest-md5の代わりにgssapiに変更する必要がある。


もし、UNIXドメインソケットやTLSソケットに対してSASLが有効になっている場合、Kerberosは、SASLを使うことが出来る。 DIGEST-MD5のように、Kerberos機構は、セッションのデータ暗号化機構を提供する。

ディストリビューションによっては、SASL-Kerberosプラグインをデフォルトでインストールしない。 この場合、cyrus-sasl-gssapiなどのパッケージをインストールすることが必要になる。 Kerberosプラグインがインストールされているかどうか調べるためには、 pluginviewerを実行して、gssapiがリストされるか確認する必要がある。

 # pluginviewer
 ...snip...
 Plugin "gssapiv2" [loaded],     API version: 4
         SASL mechanism: GSSAPI, best SSF: 56
         security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
         features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN

次に、Kerberosのレルムの管理者は、プリンシプルをlibvirtサーバ用に発行する必要がある。 プリンシプルは、ホスト毎に、libvirtdに対応して一つ割り当てる必要がある。 そして、プリンシプルは、libvirt/full.hostname@KERBEROS.REALMと名づける必要がある。

この作業は、通常kadmin.localコマンドをKerberosサーバで実行して行われる。しかしながら、Kerberosサーバによっては、サービスプリンシプルを設定するために他の方法が必要な場合もある。 一度生成されると、プリンシプルは、キータブとしてエクスポートされる。そして、libvirtd向けには、/etc/libvirt/krb5.tabに設定される。

 # kadmin.local
 kadmin.local: add_principal libvirt/foo.example.com
 Enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
 Re-enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
 Principal "libvirt/foo.example.com@EXAMPLE.COM" created.
 
 kadmin.local:  ktadd -k /root/libvirt-foo-example.tab libvirt/foo.example.com@EXAMPLE.COM
 Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type Triple DES cbc mode with HMAC/sha1     added to keytab WRFILE:/root/libvirt-foo-example.tab.
 Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
 Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES with HMAC/sha1 added to keytab WRFILE:/root/libvirt-foo-example.tab.
 Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
 
 kadmin.local: quit
 
 # scp /root/libvirt-foo-example.tab root@foo.example.com:/etc/libvirt/krb5.tab
 # rm /root/libvirt-foo-example.tab

Kerberos認証するlibvirtに接続したいアプリケーションが、ユーザプリンシプルを取得するためにkinitを実行する必要はほとんどない。 PAMがKerberos向けに設定されている場合、デスクトップセッションにログインした時点で、自動的に取得しているためである。

各種libvirtドライバー[編集]

Xenドライバー[編集]

libvirtのXenドライバーは、3.0.1以降のXenを制御することが出来る。

libvirtのXenドライバーは、複数の制御方法の組み合わせでXen仮想機械を制御する。

  • XenD: libvirt Xenドライバーを使うためには、XenDにアクセスできることが必須である。このドライバを使うためには、XenDの設定ファイル/etc/xen/xend-config.sxpで、Unixドメインソケットインターフェースを利用可能にしておく必要がある。そのためには、このファイルで、(xend-unix-server yes)と設定しておく必要がある。このソケットでのアクセスパスは、特権ユーザ(ルート)に通常限られる。その他の選択肢として、HTTPインターフェースを使うことが出来る。しかし、セキュリティを注意する必要がある。
  • XenStoreD: Xenstoredにアクセスして情報を取得することは、ドメイン情報取得の際のCPUのオーバーヘッドを減らすことが出来る。
  • Hypercalls: ハイパーコールを発行して情報を取得する。ドメイン情報を取得するには、一番効率的なアクセス方法である。
  • XM config: 3.0.4以前のXenでは、XenDにおいて不活性ドメインの制御は出来なかった。このため、これらのXenを制御する場合、libvirtでは、/etc/xenのディレクトリにXM設定ファイルを保存して不活性ドメインの制御をしている。このディレクトリに、設定ファイル以外を決しておいてはいけない。

QEMU/KVMドライバー[編集]

libvirtのQEMUドライバーは、0.8.1以降のQEMUを管理することが出来る。そして、このドライバはQEMUコマンド書式で制御できるいずれのVMにも適用できる。QEMU形式のVMには、KVMとXennerが含まれる。 利用する前に必要な条件は以下の通りである。

  • QEMU: ドライバーは、/usr/bin以下のqemu, qemu-system-x86_64, qemu-system-mips, qemu-system-mipsel, qemu-system-sparc, qemu-system-ppcの存在をチェックする。チェック結果は、XMLファイルのcapabilityの項目で見ることが出来る。
  • KVM: ドライバーは、/usr/bin/qemu-kvmコマンドと/dev/kvmのデバイスノードの存在をチェックする。もし、両方存在すれば、ハードウェア支援機構前提のゲストドメインを使うことが出来る。
  • Xenner: ドライバーは、/usr/bin/xennerコマンドと/dev/kvmのデバイスノードの存在をチェックする。もし、両方存在すれば、Xen準仮想化ドメインを、KVMを用いて使うことが出来る。

リモートドライバー[編集]

ネットワーク越しのハイパーバイザを管理することが出来る。


関連項目[編集]

脚注[編集]

  1. ^ Virtual Machine Manager

外部リンク[編集]

libvirt本体と各種言語バインディング[編集]

  • Windows Support - MinGWのコンパイラを用いてバイナリを作成することが出来る。詳細は以下のページを参照のこと[4]。また、WindowsでのAPIのglibcとの非互換はかなり大きいが、GNU Portability Library(Gnulib)をlibvirtパッケージの中に取り込むことにより、互換性の手間を回避している。

LibvirtAPIを使ったアプリケーション[編集]