VMware Workstation PlayerでOpenStack Mitakaのネットワークを設定しインスタンスを起動

***本記事にはプロモーションが含まれています。***

はじめに

VMware Workstation PlayerでOpenStack Mitakaのインストールをしています。

前回は、OpenStack MitakaをインストールしてDashboardを見るところまでをやりました。

インストールにはこちらのサイトを参考にさせていただきました。今回は、ネットワークを設定しインスタンスを起動してロードバランサを動かすところまでやります。

VMware Workstation PlayerでOpenstack Kiloを動かす手順

ネットワークの設定では、こちらも参考にさせていただきました。

OpenStack Neutronを使ってWebシステムを構築する実践的な方法 (1/3)

不具合の対処

OpenStackのホストとなるCentOSを再起動してみると、httpdサービスとneutron-serverサービスがfailedになって立ち上がりません。動くときもありますので、いつも動かないわけではないようです。

サービスの起動の状態を知るのは次のコマンドでわかります。

#systemctl list-units --type service

エラーメッセージはこんな感じです。

#systemctl status httpd

ERROR: scss.ast: Function not found: function-exists:1

#systemctl status neutron-server

neutron.service start operation timed out. Terminating.

こちらの情報によると /lib/systemd/system/httpd.service.d/openstack-dashboard.conf を実行するときに時間がかかりすぎるのが原因だとか。パッチも作られたようです。

とりあえず次のコマンドで手動で起動すると動きます。httpdが起動するまで少し待つ必要があります。

# systemctl start httpd
# systemctl start neutron-server

また、VMware Workstation PlayerのCPU2コア、メモリ4GBにすると安定して動くようになりました。CPU1コア、メモリ4GBでは、リソースが足りないようです。

ネットワークを設定

VMware Workstation PlayerでOpenstack Kiloを動かす手順に従ってネットワークを動かそうとしました。しかし、502 Bad Gatewayというエラーが出て動きません。

問題の特定にはログファイルを見るしかないようでしたが、OpenStackを始めたばかりでどのログファイルのどこを見ればいいのかよくわかりません。

そこで、OpenStack Neutronを使ってWebシステムを構築する実践的な方法 (1/3)に従ってネットワークが動作することを確かめました。そのあとに手順書に従ってネットワークを動かしました。

@ITのサイトでは、OpenStackのハンズオンを基にした手順が書かれてありわかりやすかったのですが、公開するネットワークの設定の仕方が書いてないため、手探りで設定しました。下記に書いたようにpublicのネットワークを設定しました。

また、手順書のようにtennant_idを一つ一つ手書きするのはとても大変でした。そこで、@ITの記事を参考に次のようにしてネットワークを設定しました。

ちなみに、VMware Workstation Playerの画面で作業するのはコピーペーストできません。コピーペーストできるsshクライアントを用意してVMware Workstation PlayerのCentOSにアクセスして作業するとはかどります。

まずpublicという名前の公開するネットワークを作ります。作成する時のポイントはnet-createのときに、--router:externalを使うことです。これで外部のネットワークだと指定することができます。

OpenStackのホストとなるCentOSのIPアドレスは、192.168.0.140と指定してインストールを行っています。そのIPアドレスを外して、192.168.0.141から192.168.0.199をFloationg IPという名前で使って良いアドレスと指定します。

# neutron net-create public --route:external
# neutron subnet-create --name public_subnet --disable-dhcp --allocation-pool start=192.168.0.141,end=192.168.0.199 public 192.168.0.0/24

次に非公開のネットワークを作ります。OpenStackのインスタンスはまずこのネットワーク上に接続されて作られます。そのあとに上記の公開するネットワークからFloationg IPからIPアドレスを割り当てることで外部のネットワークと通信できるようになります。

neutron net-createでprivate-net1というネットワークを作ります。プライベートネットワークのIPアドレスは 192.168.10.0/24という範囲でネットワークを設定し、101から199まで指定します。 ゲートウェイは192.168.10.1を使います。

# neutron net-create private-net1
# neutron subnet-create --name private-net_subnet1 --enable-dhcp --allocation-pool start=192.168.10.101,end=192.168.10.199 --gateway 192.168.10.1 --dns-nameserver 8.8.8.8 private-net1 192.168.10.0/24

router-createで、router1という仮想ルーターを作ります。router-gateway-setでpublicネットワークにつなげます。publicネットワークでは、Floating IPから192.168.0.141というアドレスが付与されます。router-interface-addで、プライベートなネットワークにつなげます。private-net_subnet1のIPアドレス192.168.10.0/24で最初のアドレス192.168.10.1が使われます。先にゲートウェイを指定していたのと合っている必要があります。router-port-listとsubnet-showで確認できます。

# neutron router-create router1
# neutron router-gateway-set router1 public
# neutron router-interface-add router1 private-net_subnet1
# neutron router-port-list router1
# neutron subnet-show private-net_subnet1

インスタンスを起動

VMware Workstation PlayerでOpenstack Kiloを動かす手順に従ってインスタンスを起動しようとしました。しかし、--is-public と --location というオプションはないといわれ、イメージの登録ができません。

調べてみると、glanceはOpenStack kiloからOpenStack Libertyに変わったときにバージョンが上がってるようです。--os-image-api-version 1 というオプションをつけることでコマンドを使うことができました。

# glance --os-image-api-version 1 image-create --name cirros --is-public True --container-format bare --disk-format qcow2 --location http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img

バージョン2で使うときは、--is-publicを--visibility publicにすることと、--locationは対応するものがないので、イメージをあらかじめローカルにダウンロードしておいて--fileオプションを使って指定するとよいようです。

あとは手順書に従って、インスタンスを作って起動し、ロードバランサを作って動作確認しました。OpenStack KiloとMitakaでは画面が変わっていますが、対応するところはすぐわかると思います。

OpenStackのホストであるCentOS上で次のようにルーティングを設定すると、CentOSからOpenStackのインスタンスに接続できます。動作の確認ができるのでとても助かりました。

# route add -net 192.168.10.0/24 gw 192.168.0.141 br-ex

実際にロードバランサの動作を確認すると、Curlでアクセスしたときはweb_server01とweb_server02の表示が交互に出て、ちゃんとラウンドロビンで動作していることがわかります。

しかし、ChromeでアクセスしてShift-F5でリロードしてみると時々しか変わりません。ブラウザによって動作が異なるようです。原因はわかりませんでした。

インスタンスをKVMで起動

せっかく、VMware Workstation Playerを使ってOpenStackでもCPUの仮想化機能を使えるようにしています。そこで、OpenStackのインスタンスがKVMを使っているのかどうか確かめました。

デフォルトの状態では、OpenStackはQEMUを使ってインスタンスを動かしています。設定ファイルnova.confでvirt_type=kvmとすることで、KVMを使うように設定します。

/etc/nova/nova.conf

virt_type=kvm

実際にKVMが使われているかどうか、確認します。virsh listで、インスタンスのIdを確認して、virsh qemu-monitor-commandでinfo kvmとすることで確認できます。--hmpというのは、Human Monitor Protocolの略で、通常の人間がわかるコマンドを実行するということのようです。

kvm supportがenabledになっていれば、OpenStackのインスタンスでKVMが使われています。そこそこの速度で実行されているのではないでしょうか。

# virsh list

 Id    Name                           State
----------------------------------------------------
 2     instance-00000008              running
 3     instance-00000009              running
# virsh qemu-monitor-command --hmp 2 info kvm
kvm support:enabled

おわりに

neutronのコマンドにneutron lb-*というものと、neutron lbaas-*というものがあります。調べてみると、前者はLBaaS v1で後者はLBaaS v2というようです。v1とv2ではドライバから変わって、互換性はないそうです。v1は廃止予定になっています。せっかく覚えたのになんかもったいないですね。

VMware Workstation PlayerでOpenStack Mitakaを動かしてみた

***本記事にはプロモーションが含まれています。***

はじめに

VMware Workstation Player上にOpenStack Mitakaをインストールしました。

OpenStackを気軽に試してみるには、Ubuntuを使うものとCentOSを使うものがあります。メモリーの必要量が少なかったりするので、CentOSを使うものにしました。

RDOとは、Red Hat系のOpenStackのコミュニティのこと。Packstackは、RDOで開発されているOpenStackのインストール作業や設定作業を自動化するインストーラーです。

ハードウェアの必要要件

CPUはVT-xもしくは、AMD-Vを備えたもの
メモリ4GB、6GB以上が望ましい

ここでは、VMware Workstation Playerを使って、仮想環境にOpenStackをインストールします。VMware Workstation Playerは、ホストのVT-x/AMD-Vをゲストから使えるようにする機能があります。これを使ってゲストOSをホストにしてOpenStackを動かしその上でゲストOS(インスタンス)を動かします。

開発環境

ホストOS Windows 10 Pro

VMware WorkStation Player 12.1.1

CentOS-7-x86_64-Minimal-1511.iso

インストールには、こちらのサイトを参考にさせていただきました。ほぼ、そのままでインストールしていきます。VMware Workstaion Playerの設定の仕方から始まって、OpenStackのロードバランサの設定まで細かく書かれてあります。大変参考になりました。

VMware Workstation PlayerでOpenstack Kiloを動かす手順

CentOSのインストール

CentOSは、手順書のとおりにインストールしました。

CentOSのダウンロードに1時間。インストールには20分ほどでインストールできました。Minimalインストールなので、インストール後net-toolsとntpをインストールしました。
NetworkManagerとはうまく共存できないようなので停止して代わりにnetworkサービスを使います。

ネットワークはOpenVSwitchを使います。ブリッジインターフェースを設定します。ホストのWindows 10 ProからOpenStackのホストのCentOSへアクセスするIPアドレスには、192.168.0.140を設定しました。

OpenStackのインストール

手順書を参考にインストールしました。

1つ変えたところは、次のコマンドでkiloのレポジトリをセットアップするのですが、

yum install http://rdo.fedorapeople.org/openstack-kilo/rdo-release-kilo.rpm

CentOSには、Mitakaのパッケージが用意されているので、次のコマンドでセットアップしました。

yum install -y centos-release-openstack-mitaka
yum install -y openstack-packstack

Packstackは、アンサーファイルを作って設定し、インストールします。

インストールには、OpenStackのコンポーネントをダウンロードしながらインストールするので時間がかかりました。

CentOSのインストールとOpenStackのインストールで2時間ほどで、OpenStackのDashboardを見ることができました。

自宅のネットワーク回線が遅いので、速ければもう少し早く終わると思います。

インストールの確認

インストールが正常に終了したところでhttp://192.168.0.140/dashboardにアクセスしてみました。

まだ、ネットワークの設定が終わっていないので、インスタンスを動かすことはできません。

OpenStackの設定ファイルは、/etcの下に散らばっているのですね。

詳細な手順書があったおかげでハマることなく動かすことができました。

次回、ネットワークの構成とインスタンスの起動までやってみます。

QEMUのWindows上での作り方

***本記事にはプロモーションが含まれています。***

はじめに

久しぶりにWindows上でQEMUを作ろうとしたら、ソースコードの修正が入っていて作り方が変わっていました。いろいろ試行錯誤して作り方を見つけたので紹介します。

QEMUのソースコードの現状

今年(2016年)の3月までは、GCC 4.5とGTK+ 3.6.4という組み合わせでコンパイルできていました。でも、MinGW-w64のgcc 4.8になるとwinsock関係のインクルードファイルに変更があって、それに対応するためにQEMUにも変更が入りました。

この変更で、GTK+ 3.6.4のライブラリ内でワーニングが出てしまい、QEMUをコンパイルできなくなりました。GCC 5.4に変えても無理で、GTK+のライブラリのバージョンを上げることが必要になりました。

作成環境の現状

QEMUは、GTK+に含まれるGlibというライブラリを使っています。Windows上でコンパイルしようとするときは、今まではGTK+のホームページからx86_64版をダウンロードして使ってきました。しかし、メンテナンスする人がいないようで、配布されなくなりました。GTK+のホームページでは、MSYS2という開発環境を使うよう案内があります。今後は、MSYS2を使った環境でしかQEMUを作れないことになりそうです。

Linux上のクロス開発環境では今までどおり作れると思います。

MSYS2のインストール

MSYS2はインストーラーが準備されていますので、MSYS2インストーラーのホームページからmsys2-x86_64-20160205.exeというインストーラーをダウンロードしてインストールするだけです。

SourceForgeにあるMSYS2の新しいインストーラーはなぜか起動しなかったです。

インストール後にMSYS2インストーラーのホームページに従ってアップデートするのですが、

pacman -Sy pacman

は大丈夫でした。しかし、次の

pacman -Syu

をすると、エラーで止まってしまいました。新しいプロセスをフォークできませんと言っています。調べてみると、エラーのあったパッケージは手動でインストールしなおさないといけないそうです。filesystemというパッケージがエラーになっているのをメモリました。仕方がないのでCrtl-Cでプロンプトに戻り、いったんターミナルを終了しました。ターミナルを、もう一度スタートメニューから起動しようとしましたが起動せず、コマンドプロンプトが出てしまいます。

原因は、MSYS2の起動方法が変わり、batファイルで起動していたのをcmdファイルに変更したためです。

C:\msys64\msys2_shell.cmdをダブルクリックすることでターミナルは起動しました。そこで、

pacman -S filesystem

で、filesystemをインストールしなおします。メッセージに起動方法が変わったことが出ていました。

あとは、スタートニューのMSYS2 Shellの項目のプロパティを開き、

C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -msys

と書き換えることで起動できるようになります。ポイントは、msys2_shell.cmdを指すように変更することです。コマンドプロンプトのウィンドウも閉じるように/Kオプションを/Cオプションに変更しました。なお、Windows 10では、右クリックでプロパティを表示させることができませんでした。いったん「ファイルの場所を開く」で、エクスプローラーを表示させて、アイコンを右クリックでプロパティを変更することができます。

スタートメニューの問題は、インストーラーがアップデートされれば、いずれなくなると思います。

QEMUに必要なツールのインストール

MSYS2のアップデートが終わったら、QEMUに必要なツールをインストールします。

MSYS2は、パッケージマネージャで管理されているので、次のようにしました。まずは、gccなどのツールをインストールします。

pacman -S mingw-w64-x86_64-toolchain

次に、GTK3をインストールします。

pacman -S mingw-w64-x86_64-gtk3

SDLライブラリも必要なので入れます。

pacman -S mingw-w64-x86_64-SDL2

あとは、makeとcmpとbisonが無いといわれますのでインストールします。

pacman -S msys/make

pacman -S diffutils

pacman -S bison

これで、必要なツールは、インストールできました。あとは、QEMUのソースコードを持ってきて作るだけです。

QEMUを作るときは、MinGW-w64 Win64 Shellを起動して作ります。このときの起動パラメーターは、-mingw64をつけます。スタートメニューのMinGW-w64 Win64 Shellのプロパティを変更する必要がありました。

C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -mingw64

まとめ

QEMUをWindowsで作るにはMSYS2の開発環境が必要になりました。

MSYS2のインストールで、エラーが出るため手動で書き換える必要がありました。

感想

MSYS2のMinGW-w64のGCCのバージョンは、6.1.0です。ちょっと見ないうちにすごく上がってしまいました。

GTK+のWindows版をメンテナンスする人がいないということは、使う人もいないのでしょうね。開発の主力がインターネットのほうに移っているのでしょう。時代の流れを感じます。

MSYS2という環境は、パッケージマネージャがあるので、環境整備はやりやすくなったと思います。