Vagrantで、ansible_localを使ってみる

VagrantでゲストOSをセットアップするには、次の3通りがあります。

  1. Vagrantfileの中ではプロビジョニングを使わず、ゲストOSを立ち上げるだけにして、ansible単独でゲストOSを操作する方法
  2. Vagrantfileの中でconfig.vm.provision 'ansible_local'として、Vagrantのansible_localというプロビジョニングを使う方法
  3. Vagrantfileの中でconfig.vm.provision 'ansible'として、Vagrantのプロビジョニングを使う方法

このうち、今回はansible_localを使う方法を試してみます。

Vagrantのプロビジョニングでansible_localを使う場合には、ホストOSにはansibleをインストールしてある必要はありません。

ゲストOSにansibleが自動的にインストールされ、そこでansible-playbookが実行されます。

ポイントは2つあります。1つは、Vagrantfileでprovisionにansible_localを設定します。2つめは、Playbookでconnection: localを使うことです。

ansible_localを指定すると、ゲストOSにansibleが自動的にインストールされます。

実際の例は以下の通りです。

Vagrantfileは次の通りです。プライベートアドレスに192.168.33.10を指定して、provisionにansible_localを指定します。Playbookにsite.ymlを指定し、インベントリファイルにhostsを指定しています。

Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.network "private_network", ip: "192.168.33.10"
  
  config.vm.provision "ansible_local" do |ansible|
    ansible.playbook = "site.yml"
    ansible.inventory_path = "hosts"
    ansible.limit = 'all'
  end
end

インベントリファイルは次の通りです。vagrantsというグループにubuntu01というホスト名のサーバーがあり、アドレスは192.168.33.10としています。

hosts

[vagrants]
ubuntu01 ansible_host=192.168.33.10

Playbookは次の通りです。vagrantsというグループに、connection: localという設定で、ubuntuというユーザーにログインします。そこで、Apache2をインストールしています。

site.yml

---
- hosts: vagrants
  connection: local
  user: ubuntu
  tasks:
    - name: install packages Apache2
      apt: name=apache2 update_cache=yes
      become: yes

connection: localがないと、次のようなエラーになります。

TASK [Gathering Facts] *********************************************************
fatal: [ubuntu01]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Host key verification failed.\r\n", "unreachable": true}
        to retry, use: --limit @/vagrant/site.retry

connection: localを使わないと、ゲストOSにansibleをインストールしてあるのに、わざわざ自分自身にsshでログインしてplaybookを実行しようとします。そのとき、SSHのエラーになります。

ansible_localを使うと、ansibleは自動的にインストールしてくれますので簡単ですね。

AnsibleにはGitによる管理が必須です

Ansibleを使って構成管理をしだすと、少し設定を変更しては試してみることが増えます。特に、AnsibleやDockerを学ぶ際には繰り返すことが多いです。Vagrantを使っていると特に設定して試してみてという試行錯誤が簡単なので、変更が多くなります。

そうすると、ここを変更したいけど、後でまた必要になるからコメントアウトしておこうとかしたくなります。

また、少しづつ変えると何のために変更したのか後で見直すとよくわからないということになります。

そこで有効になるのがGitです。

Gitで設定ファイルを管理すると、とりあえず今の状態を保存しておこうということが簡単にできます。また、動かなくなった時でも簡単に元に戻せます。

あれ、このプログラム以前は動いたはずだけど、なんで動かないのだろうとよくあるのではないでしょうか。また、Gitでとりあえず保存はしておいて、過去のコードが役に立ったというような経験がありませんか。そのとき初めてGitの良さがわかるようになります。

Git無しではなんか不安、になれば十分使いこなしているといえましょう。

別に、Git中毒になれと言っているわけではないです。時々でもいいからコメント付きで保存しておくと、いざという時役に立ちます。

サーバーの構成管理がファイルでできるようになっていることが大きいです。ファイルを保存してきさえすれば、以前の状態のサーバーを簡単に作り出すことができます。

幸いにして、Git使っているけどなんでいいのかわからない、なんて場合もあると思います。そういう場合は、作業記録を残しておくことに意義を見出しましょう。

Ansibleで開発しようと思ったらとりあえずgit init。できた!、動いた!と思ったらとりあえずgit comit。これを習慣にしておくといいです。

AnsibleのインベントリファイルはLinuxのhostsファイルとは違う

インベントリファイルはhostsという名前になっていることが多いです。

Ansibleを使い始めた時、Linuxの/etc/hostsファイルと一緒なのかと思っていました。

よく紹介されている例でも、IPアドレスが直書きされています。

それでも動くのですが、調べていくうち/etc/hostsファイルとは違うことがわかってきました。

インベントリファイルは、ホストの名前とその設定を書く場所です。

よくある例では、

[default]
192.168.33.10

と書かれています。これは、defaultグループに192,168.33.10でアクセスできるホストがあるという設定です。

でも、次のような書き方もあります。

host01 ansible_host=192.168.33.10

[webservers]
host02 ansible_host=192.168.33.20

このインベントリファイルの意味は、host01はグループに属していません。IPアドレスは、192.168.33.10です。webserversというグループにhost02という名前のマシンがあって、そのIPアドレスが192.168.33.20という意味です。

どうもインベントリファイルは、/etc/hostsファイルとは違って名前を設定するファイルのようです。

Ansibleのtutorialを見てみると、Getting Startedでは、

192.0.2.50
aserver.example.org
bserver.example.org

このように直書きしたものもありますが、Inventoryの説明では、

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

このようにすべて、名前で設定されています。

また、IPアドレスだけでなくいろいろな設定を書くことができます。

ansible_connectionで接続方法が設定できたり、ansible_userで接続時のユーザー名を設定できたりします。

foo.example.com ansible_host=192.168.33.10 ansible_connection=local ansible_user=foo

:varsという拡張子をつけることでグループを一括して設定を書くことができます。

[webservers]
foo.example.com
bar.examble.com

[webservers:vars]
ansible_connection=local
ansible_ssh_private_key_file=/home/example/.ssh/aws.pem

AnsibleのインベントリファイルはLinuxのhostsファイルとは違うという話でした。

AnsibleでゲストOSをセットアップする

前々回でAnsibleをインストールし、前回でVagrantで作ったゲストOSにSSHで接続できることがわかりました。Ansibleを使う環境は整ったので、Ansible単独でゲストOSをセットアップします。

手順はまず、Vagrantでサーバーを用意します。次に、Ansibleの設定をansible.cfgにして、扱うサーバーの設定を書いたhostsという名前のインベントリファイルを用意して動作確認をします。それが出来たら、Playbookを作成して実行してみます。

なお、Windows上のAnsibleの設定ではこちらのCygwinの情報を参考にしました。

Vagrantfileファイル

用意したサーバーは、次のようなVagrantfileで作りました。

Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.define 'ubuntu01' do |host|
    host.vm.hostname = 'ubuntu01'
    host.vm.network "private_network", ip: "192.168.33.10"
  end

  config.vm.provision 'shell', inline: <<-SCRIPT
    # aptのソースファイルを書き換え
    sed -i s%archive.ubuntu.com/ubuntu%ftp.jaist.ac.jp/pub/Linux/ubuntu/%g /etc/apt/sources.list
    apt-get update
    apt-get -y install python aptitude
  SCRIPT

end

ゲストOSには、ubuntu/xenial64を選びました。ubuntu01という名前にして、IPアドレスは、192.168.33.10にしました。

ubuntu/xenial64にはPythonがインストールされていません。Ansibleは、PythonのコードをゲストOSに送り込んで実行します。そのため、あらかじめPythonをインストールしていおきます。ダウウンロードの時間を短縮するために、aptのソースファイルを編集してあります。

ansible.cfgファイル

次に、Ansibleの設定をするansible.cfgを作ります。vagrant ssh-configの結果をもとに次のようなファイルを作りました。

ansible.cfg

[defaults]
inventory = hosts
remote_user = ubuntu
host_key_checking = False
private_key_file = C:/msys32/home/kazu/ansible/intro/.vagrant/machines/ubuntu01/virtualbox/private_key

[ssh_connection]
# for Cygwin, MSYS2
control_path = /tmp

インベントリファイル名は、hostsにします。remote_userとprivate_key_fileは、vagrant ssh-configで表示されるユーザー名UserとプライベートキーIdentityFileの場所を設定します。

host_key_checking = Falseは、ゲストOSを作ったり壊したりしたときに公開鍵が変わってしまうのですが、それをチェックしないという意味です。

MSYS2やCygwinでansibleを動かすときのポイントは、control_path = /tmpをansible.cfgに設定することです。これがないとエラーになります。
こんなエラーが出ます。

ubuntu01 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: mm_send_fd: sendmsg(2): Connection reset by peer\r\nmux_client_request_session: send fds failed\r\n",
    "unreachable": true
}

hostsファイル

次に、hostsという名前のインベントリファイルを作ります。

hosts

[webservers]
ubuntu01 ansible_host=192.168.33.10

webserversというグループに、ubuntu01という名前のサーバーを作り、そのIPアドレスは192.168.33.10です。これは、Vagrantと合わせます。

Ansibleで使うhostsファイルのホスト名(この場合はubuntu01)は、Vagrantで使うVagrantfileのhost.vm.nameで指定する名前とは無関係です。もっとも、同じにしておいた方が間違わなくて済むのでいいです。

動作確認

ファイルが出来たら、ansibleに続けて、すべてのマシン(all)にpingを打ってサーバーからの返事を見ます。-m pingというのはpingモジュールを使ってpingを打つという意味です。

ansible all -m ping

こういう返事が返ってくれば成功です。

ubuntu01 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Playbookの実行

あとは、Playbookを作って実行するだけです。

Playbookは、インデントが重要なのでタブが入っているとエラーになります。気をつけましょう。

ここでは、site.ymlという名前のPlaybookを作りました。

hostsに実行するサーバー名を指定して、userにログインするユーザー名を入れます。tasksとして、Apache2をインストールします。nameには、このタスクのコメントをいれ、aptというモジュールを使ってapache2をインストールされた状態にします。このとき、スーパーユーザーで行います。

site.yml

---
- hosts: ubuntu01
  user: ubuntu
  tasks:
    - name: install Apache2
      apt: name=apache2 state=installed
      become: true

ansible-playbookの次にsite.ymlを指定して実行してみます。

ansible-playbook site.yml

これで、Apache2がインストールできたら成功です。

実際に、http://192.168.33.10/ にブラウザでアクセスするとApacheの画面が見れると思います。

Ansibleの使い方は、Ansible構成管理入門を参考にさせてもらいました。ありがとうございます。

VagrantでAnsibleを使うのはSSHの理解がカギ

VagrantでAnsibleを使うのは、SSHを使ってリモートホストを操作します。なので、SSHがつながらないと話になりません。

SSHのしくみ

SSHの接続には秘密鍵と公開鍵の2つを使います。

公開鍵は、秘密鍵から作ることができます。

クライアント側とサーバー側の双方で秘密鍵と公開鍵があります。このうち公開鍵をお互いに送って保管することで通信ができます。

サーバーに接続してみて.sshディレクトリにあるauthorized_keysが保管場所。自分のホームディレクトリの.sshディレクトリの中のknown_hostsというファイルが保管場所です。

接続される側(サーバー側)で使われるのがauthorized_keysで、接続する側(クライアント側)で使われるのがknown_hostsです。

SSHクライアントで接続しようとしている場合、まずパスワードで接続してクライアント側の公開鍵をサーバー側に送ります。接続されるサーバー側は、authorized_keysという中にクライアント側の公開鍵をいれます。

そのあとで、サーバー側からサーバー側の公開鍵をクライアント側に送ります。これをクライアント側でknown_hostsに登録することで鍵認証で通信する準備が整います。これは、初めてsshで接続しようとしたときに警告が出てyesと答えると自動でやってくれます。

一度設定が済むと、

ssh -i <秘密鍵> <リモートホスト名>

で接続できます。

Vagrantの場合

Vagrantで作ったゲストOSにSSHを使ってパスワードでログイン

まずは、ゲストOSにパスワードでログインしてみます。

まず、vagrant ssh-configでVagrantが使っているsshの設定を見てみます。

$ vagrant ssh-config

Host default
  HostName 127.0.0.1
  User ubuntu
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/msys32/home/vagrant/vm/ubuntu16.04/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

HostNameが接続時に設定するホスト、Userがユーザー名、Portがポート番号です。-pでポート番号を指定して、ユーザー名とホスト名を@マークで区切って指定します。

$ ssh -p 2222 ubuntu@127.0.0.1

The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:h8pe0EpC3I5ocDrZ7PGUxjYMIs2Wh8lIsXG0R/C3S5A.
Are you sure you want to continue connecting (yes/no)?

なにやら表示が出ます。これは、サーバー側の公開鍵をホームディレクトリの.ssh/known_hostsに登録してもいいかという意味です。

yesと答えると、パスワードを聞かれます。

ubuntu@127.0.0.1's password:

Vagrantでubuntu/xenail64をゲストに使ったときは、ゲストのパスワードは、C:\ユーザー\自分の名前\.vagrant.dのなかのVagrantfileの中に書かれています。

ubuntu/xenial64の場合は以下のところです。

C:\Users\(your name)\.vagrant.d\boxes\ubuntu-VAGRANTSLASH-xenial64\20170423.0.0\virtualbox\Vagrantfile

これでログインできると思います。

公開鍵認証を使う場合

Vagrantの場合は、ホームディレクトリの.vagrant\machines\(host名)\virtualboxというフォルダの中にprivate_keyがつくられています。これを使って、ゲストOSに接続しています。
Vagrantが最初にvagrant upしたとき、ホストの公開鍵をコピーしてゲストOSのAuthorized_keysに登録しています。これで、パスワードなしでも鍵を使ってログインできるようになっています。

このauthorized_keysを確認してみます。

$ vagrant ssh

で接続して

(remote host) $ cat .ssh/authorized_keys

で、なかを見ると、

ssh-rsa AAAAB3NzaC----すごく長い------CBnRropmyAxL vagrant

みたいにssh-rsaで始まりvagrantで終わっているのがVagrantが送ったクライアント側の公開鍵です。

(remote host) $ exit

でログアウトします。

実際にsshを使って手動で接続してみようと思います。

まず、vagrant ssh-configでVagrantが使っているsshの設定を見てみます。

$ vagrant ssh-config

Host default
  HostName 127.0.0.1
  User ubuntu
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/msys32/home/vagrant/vm/ubuntu16.04/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

HostNameが接続時に設定するホスト、Userがユーザー名、Portがポート番号、IdentityFileが接続時に使う秘密鍵です。

sshで-iで秘密鍵を、-pでポート番号を、ホストの前に@マークで名前を指定して接続してみます。

$ ssh -i .vagrant/machines/default/virtualbox/private_key -p 2222 ubuntu@127.0.0.1

最初に接続したときは、ゲストOS(接続先)の公開鍵が登録されていないため、次のような警告が出ます。

The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:+lHBujro5WLFzsFfFSFTQzWS/E35OvSwdr8t8OO/AFo.
Are you sure you want to continue connecting (yes/no)? 

yesと入力しリターンキーを押すとパスワードなしでログインしたと思います。この確認は2度目から出ません。

(remote host)$ exit

でログアウトして、自分のホームディレクトリの.ssh/known_hostsを確認してみます。

$ cat ~/.ssh/known_hosts

[127.0.0.1]:2222 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE1rZpVqvH1jYQ2lEjm0zc0LORZh7aIH61qIS0msMbBvA0W1s+NTgiftffhTcnON903vw/pWt9tqNhR69wNJsI8=

ホスト127.0.0.1ポート番号2222としてリモートホストの公開鍵が登録されています。

なお、vagrant destroyしたあと、vagrant upでゲストOSを作り直し、sshで接続しようとすると、次のようなエラーになります。

$ ssh -i .vagrant/machines/default/virtualbox/private_key  -p 2222 ubuntu@127.0.0.1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:h8pe0EpC3I5ocDrZ7PGUxjYMIs2Wh8lIsXG0R/C3S5A.
Please contact your system administrator.
Add correct host key in /home/vagrant/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/vagrant/.ssh/known_hosts:3
ECDSA host key for [127.0.0.1]:2222 has changed and you have requested strict checking.
Host key verification failed.

これは、ゲストOSを作り直して公開鍵が変わってしまったために、ホームディレクトリで保存しているゲストOSの公開鍵と違っているためです。

このときは、エディタで~/.ssh/known_hostsの[127.0.0.1]:2222の行を削除すると接続することができます。

このようにvagrant ssh-configで確認した設定値を使って、sshで接続することができます。

AnsibleをMSYS2で使う

前回、VagrantとDockerで環境構築をしたので、Ansibleを使ってみることにしました。

Vagrantで作ったゲストOSに対してAnsibleで環境設定をするには、大きく分けると次の3つの方法があります。

  1. Vagrantfileの中ではプロビジョニングを使わず、ゲストOSを立ち上げるだけにして、ansible単独でゲストOSを操作する方法
  2. Vagrantfileの中でconfig.vm.provision 'ansible_local'として、Vagrantのansible_localというプロビジョニングを使う方法
  3. Vagrantfileの中でconfig.vm.provision 'ansible'として、Vagrantのプロビジョニングを使う方法

1番の方法は、WindowsホストではAnsibleからサポートされていません。

2番の方法は、AnsibleをゲストOSにインストールして、ゲストOS内でAnsibleを動かします。よって、Windowsホストでも使えます。

3番の方法は、WindowsホストではVagrantからは公式にはサポートされていません。そもそも1番の方法でansibleコマンドが動かないと、Vagrantでは動きようがありません。

このように、Windowsをホストにする場合、ansible_localしか方法はないのかと思いました。

実際、MSYS2のpipでパッケージを入れてみても、ansibleコマンドはエラーが出て動きません。

でも、Cygwinで動かしている人がいて、何とかならないかなとやってみることにしました。

最近はMSYS2をメインに使っています。そこでMSYS2で検索してみると、Ansibleを動かした人がいました。

[ansible] MSYS2 で ansible を使えるようにする手順

この通りやったらansibleが動き出しました。ありがとうございます。

ポイントは、32bitバージョンのMSYS2(msys2-i686-20161025.exe)を使うことです。64bitバージョンでは動きませんでした。

(2017/05/31)訂正
MSYS2のバージョンが問題ではなかったです。インストールするパッケージがmsysのpython2である必要がありました。

pacman -S python2

です。mingw-w64-x86_64-python2とかではだめでした。スタートメニューから起動するコンソールがMSYS2 MinGW 64bitやMSYS2 MinGW 32bitだと、MinGWのpythonがインストールしてある時はそちらが優先的に使われてしまうので気をつけてください。

インストールが終わったら、SSHでゲストOSにアクセスできることを確認して、ansibleが使えるようになります。

次回は、SSHについて書きます。

VagrantでDockerを使ってみて高速化のあれこれ

今までVirtualBoxは素のまま使っていたのですが、Vagrantを使うといいということを聞いて使ってみることにしました。

せっかくなのでDockerも使ってみようということで以下のサイトを参考にしてインストールしてみました。

VagrantとDockerについて名前しか知らなかったので試した

やってみた結果は、とてもすんなりできました。ありがとうございます。

でも、なんかインストールに時間がかかるのです。VagrantのゲストOSの元となるboxファイルは、自分のC:\Users\(your name)\.vagrant.d\boxesというフォルダに保存されます。ですので、一度ダウンロードしてしまえば2度目からはとても速くゲストOSが出来上がります。

でも、そのときにDockerをセットアップしようとprovisioningに加えると、ゲストOSを作り直すごとにインターネットからDockerが使うファイルをダウンロードします。速度が2Mbpsくらいしかでなくてプロビジョニングが終わるまで10分くらいかかります。DockerをDockerは速いということが言われていますが、Docker自身のセットアップは時間がかかるのですね。

これを解決するため、CocPxoryというプロキシサーバーをつかってみたりしました。でも、httpではなくhttpsでダウンロードしようとするのでなかなか難しいです。

結局、こちらを参考に、Ubuntuをインストールするときはaptのソースリストを変更して、日本のサーバーからダウンロードするように変更しました。

ただ、ソースのリスト先がus.archive.ubuntu.comではなく、archive.ubuntu.comでした。また、ubuntuをmirrorしているところから速いのを選びました。

また、vagrant-cachierというプラグインが少し速くしてくれました。これを使うときの注意点は、vagrant-cachierは、/var/cache/apt/archivesを/tmp/vagrant-cache/aptにシンボリックリンクすることで、ホストのフォルダC:\Users\(your name)\.vagrant.d\cache\(box名)を保存先にしています。そのため、vagrant-cachierを使ったままVagrantfileから設定を削除したり、プラグインをvagrant plugin uninstallで削除してしまうと、/var/cache/apt/archivesのリンクがそのままになってしまうため、apt-getが動かなくなってしまうことです。

Vagrantfileは、こんな感じ。

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.provision "shell", inline: <<-SHELL
    # aptのソースファイルを書き換え
    sed -i s%archive.ubuntu.com/ubuntu%ftp.jaist.ac.jp/pub/Linux/ubuntu/%g /etc/apt/sources.list
    apt-get update
  SHELL

  config.vm.provision "docker" do |d|
    # dockerに関する操作
    d.build_image "/vagrant", args: "-t kazu/my-bash"
    d.run "kazu/my-bash", args: "-d -t -v /vagrant:/tmp/shared"
  end

  if Vagrant.has_plugin?("vagrant-cachier")
    config.cache.scope = :box 
  end
end

Dockerfileは、次のようにしました。

FROM ubuntu:xenial

MAINTAINER kazu

CMD ["/bin/bash"]

これでvagrant upするとゲストOSが立ち上がります。その中で、Dockerが動いています。

一度Vagrantのboxがダウンロードされると、プロビジョニングは4分ほどで終わります。なんとか待っていられるかな。

Microsoft AzureでMySQLとPostgreSQLのサービスが始まりました

Microsoft AzureでMySQLとPostgreSQLのサービスが始まりました。

速報]マイクロソフト、Azureで「MySQL」「PostgreSQL」のデータベースサービス提供を発表、運用の手間は不要。Build 2017

早速、MySQLのサイトに行って料金を調べると、東日本のリージョンで一月2375.30円になっていました。

PostgreSQLも同じ料金でした。

これで、AzureのVirtual Machineを使ってもWordPressが手間無くできますね。

SQL Serverと比べると少し割高になっています。もちろん単純な比較はできませんけど。

他のクラウドサービスと比較してみると、少し安いくらいでしょうか。

もう1つ気になったのは、冗長構成をとるようなオプションが見当たらないことです。1台でスケールアップするしかないのかな。

最近開発されたハイパーバイザー

PhoronixというニュースサイトでBareflankというハイパーバイザーが開発されていることを知りました。

調べていくと、最近いろいろなハイパーバイザーが開発されているようです。今回はそれを紹介します。

ハイパーバイザー

Bareflank

セキュリティーなどに応用するためのプロトタイプを目的とする。C++、STLで書かれている。ユニットテストが完備されていて、Coveralls、Travis CI、Astyleが使われていて、Coverity、Clang Tidy、Google's Sanitizersといったところでコードを分析している。

サポートするのは、SandyBrdge以降のCPU。
ホストOSは、
Ubuntu 16.10
Debian Stretch
Fedora 25, 24
OpenSUSE Leap 42.2
Windows 10
Windows 8.1

少しソースコードを見ると、WindowsホストではCygwinでカーネルドライバーを作るようになっていたり、self signをできるようにしていたりと本格的です。

シンプルなハイパーバイザーを目指しているようです。機能を拡張する方法があるようで、次の2つが挙げられています。

Extended APIs

BareflankにVPIDとかMSR bitmapにアクセスするためのAPIなどを提供するもの。

Hyperkernel

他の人が自分のハイパーバイザーを開発できるように、Bareflankのサポートソフトとして開発されている。

MoRE

Windows 7 32-bit で、CPUコアは1、メモリ2GBで動作。WinDDKを使っている。3年前に開発が止まっているようです。

SimpleVisor

Intel x64/EM64T VT-xで動く、シンプルなハイパーバイザー。アセンブリコードは10行、ホストのハイパージャックとアンハイパージャックをサポート。ホストの状態を仮想化できるそうです。EPTとVPIDをサポート。WindowsとUEFI環境で動くそうです。Cのコードは500行、総コード数1700行だとか。

VisualStudio 2015 Update 3で作られる。ミニマルなハイパーバイザーを目指しているそうです。

HyperPlatform

Intel VT-x上でのハイパーバイザー。rootkitや、侵入検知システム、Windowsカーネルのリバースエンジニアリングを目的とする。

Visual Studio Community 2015 Update 3、Windows SDK、Windows Driver Kitで作られる。

ksm

Cで書かれた軽量なx64ハイパーバイザー。WindowsとLinuxホストサポート。WindowsではMinGWを使っています。

まとめ

どれもゲストOSを動かすというより、セキュリティ分野での応用を目指しているようです。CPUのVT-x機能を使う方法など、勉強したい方にはコードが簡単でいいのではないかと思います。VirtualBox、Xen、KVMといったプログラムのコードは複雑ですので。

QEMU on Windowsのサイトを移転します

QEMU on Windowsのサイトを移転します。

auのホームページ公開サービスが、2017年10月31日で終了します。

そのため、今のままで保存しておくことができなくなりました。

サイトの更新をやめてもう10年もたつのですね。時の過ぎるのは速いです。

情報も古くなっていますし、プログラムだけダウンロードできるようにしました。

新しいバージョンは、バグが入っていて公開しにくいです。

とりあえず、新しいサイトをよろしくお願いします。

QEMU on Windows