タグ：kvm

2020/12/26

KVM 環境下の Windows7 内で Virtual PC を動かす

コメント数:
0 コメント
by dotnsf

趣味で古い PC の環境を残しているのですが、しばらくの間、動作確認ができなかった環境を動作させることに成功した時の話です。同じ悩みを持つ人はほとんどいないと思っていますが、備忘録としてブログエントリに残しておきます。

【KVM 環境下の Windows7 内で Virtual PC を動かす必要に迫られた背景】
もともとはずっと OS/2（Warp 4）が動作する環境を残しておきたいと思っていました。最大の理由は「ノーツのバージョン１」が動く、数少ない環境だから」です。それ以外だと同様にして DOS 版 Lotus 1-2-3 や懐かしい DOS ゲームが動くという意味での PC-DOS が動作する環境も残しておきたいと思っていました。ちなみにこれらのインストールメディアは OS 含めて今も持っています。

この環境を残す、という目的のためだけに、しばらくの間は実際にこれらが導入された PC （OS/2 は IBM Aptiva、PC-DOS は東芝 Libretto）を残していました。西暦 2000 年頃の話です。

ただ「個人管理でハードウェアを残す」のはやはり大変でした。なにしろ「滅多に電源すら入れない PC を決して広くもない家に捨てずに残しておく」わけです。ソフトウェアやハードウェアの知識も陳腐化してゆきます。

転換期となったのは「仮想化ソフトウェア」でした。VMWare Workstation をはじめとする PC の仮想化により、ハードウェアそのものは不要となり、ハードディスクをイメージ化することで、ソフトウェアだけでこれらの環境を残すことが可能になりました。PC-DOS は今でも多くの仮想化ソフトウェアで動作しますが、OS/2 が動く仮想化ソフトウェアはあまり多くありませんでした。しかし Microsoft Virtual PC だけは当初のバージョンから OS/2 も動かすことができ、OS/2 を仮想環境下で動かすことが可能となりました。これを知った直後から自分は当時使っていた Microsoft Windows 環境内で Virtual PC を使って OS/2 と PC-DOS 環境を仮想化して残すことができました。

時は流れ、Windows 7 のサポート終了（2020/01/14）が近づくと、多くの Windows 7 ユーザーが Windows 10 へと環境移行しました。自分もメイン機は早々と Windows 10 へ乗り換えました。が、この Windows 10 では Virtual PC は動作しない（サポートされないではなく動作しない、インストールもできない）という問題がありました。ずっと残してきた OS/2 や PC-DOS 環境は Virtual PC 環境向けのイメージとなっていて、動かしていた当時のハードウェアはとっくに残してありません。Virtual PC を動かすためには Windows 7 が必要となり、Windows 7 を動かすためだけに専用の PC を残しておく必要があり、・・・となってしまうと元々上述した問題と同じことになってしまいます。

そこで考えたのが「仮想環境化で Windows7 環境を作り、その中に Virtual PC をインストールすれば今の OS/2 や PC-DOS の仮想資産を残すことができる」でした。当時の自分は Linux をベースとした仮想化システムに興味があり、当時の CentOS 6 の標準機能でもあった KVM を使った仮想環境構築にはある程度慣れていました。このような紆余曲折を経て KVM 環境化に Windows7 をインストールして、その Windows7 内で Virtual PC を使うという環境が生まれることになりました。

【KVM 環境下の Windows7 内で Virtual PC を動かしてわかった問題点】
KVM はある程度わかっているつもりでしたので、KVM 環境で Windows7 の仮想マシンをインストールして動かすこと自体は問題ありませんでした。またその環境にVirtual PC(2007) をダウンロード＆インストールすることも普通にできました。あとは Virtual PC を実行して新しい仮想マシンを既存の（PC-DOS と OS/2 それぞれの）イメージファイルを使って作るだけ、と思っていました。

が、ここで大きな問題が発生しました。KVM 環境の Windows7 にインストールした Virtual PC を実行しようとすると、実環境下ではみたことがない以下のようなエラーが発生してしまいました。Virutal PC の実行直後（既存の仮想マシン一覧が表示される前）にこのエラーが発生してしまうため、実行を諦める以外の選択肢がありません：
2020122601

このエラーメッセージ（「このコンピュータの物理プロセッサとは互換性がありません」）の意味がわかりにくく、最初は 64 ビット版の Virtual PC と間違えて 32 ビット版の Virtual PC をインストールしてしまったのかと思いましたが、この推測は間違っていました（64 ビット版 Windows7 に 32 ビット版 Virtual PC をインストールしようとすると、インストール中にエラーとなり、インストールは完了しません。今回はインストールまでは完了しているのでこの現象とは異なります）。

ともあれ、Virtual PC が動かないのであれば、既存の Virtual PC で動作実績のある仮想ディスクファイルが存在していても PC-DOS や OS/2 を動かすことはできません。結局の所 Windows 10 環境へ移行したタイミングで OS/2 が動作する仮想環境を失ってしまうことになりました（PC-DOS は動かそうと思えば KVM 内で直接動かすことは可能でしたが、OS/2 は KVM では動きません）。特殊な環境ということもあったのか、この現象をググって調べても解決することはありませんでした。そのため OS/2 の動作環境を残すという目的のためだけに Windows7 の実機を残しておく必要に迫られ、結局「IBM Aptiva を残しておいた頃と同じ、元に戻ってしまう」ことになってしまったのでした。

ここまでが約１年前の話です。その後、この問題が未解決のままだったことをすっかり忘れてしまい、そのまま約１年が経過して、年末の PC 環境整理中に再びこの問題を思い出すことになったのでした。

【KVM 環境下の Windows7 内で Virtual PC を動かすために必要な設定】
改めてエラーメッセージ（「このコンピュータの物理プロセッサとは互換性がありません」）を、KVM というキーワードと合わせてググってみても同様の現象を見つけることが出来なかったので、もう解決策があるという前提で試行錯誤で行くしかありません。

で、仮想マシンの KVM 側の設定を眺めているうちに、このような画面にたどり着きました：

KVM 側から見た、仮想マシンの Processer 設定画面です（普段はこのような画面を見る必要すらないので、こんな設定項目があることすら気づいていませんでした）。物理 CPU の割当数を変更したりする画面なのですが、その中に Configuration という項目があり、モデル欄が空になっています。。

このモデル欄は "486" とか "Pentium" といった CPU モデルを選択可能な項目になっているのですが、そのモデルが選択されていないため空になっている、という設定内容でした。念の為書いておきますが、他の Windows や Linux 仮想マシンでも、このモデル欄は空の設定になっていて、それでも問題なく動いています。実際この Windows 7 でも Virtual PC を導入しようとするまでは、この設定で問題にはなっていませんでした。

試しにここで "Copy host CPU configuration" ボタンを押して、ホストマシンの CPU 情報を参照して同じ設定にしてみました（モデル欄には "Opteon_G3" という値が自動入力されました。この値でなくても、ホストで使われている CPU の値が指定されていれば大丈夫だと思います）。この状態で「適用」しました：

そして改めて仮想マシン（Windows 7）を起動し、Virtual PC を実行すると・・・　なんと！問題なく実行され、初期画面（新しいバーチャルマシンウィザードの開始画面）が表示されました：

そのまま作業を進めて、別の Windows7 機で動いていた PC-DOS の仮想ディスクをコピー＆指定して作成した PC-DOS 仮想マシンを動かすことができるようになりました！

OS/2 環境も同様に KVM 環境下の Windows7 内 Virtual PC で動作させることができるようになりました：

いやあ、ここまで長かった！　とりあえず KVM 内の Windows 7 では Virtual PC を動かすこと自体ができないのではないかと半ば諦めていたのですが、なんとか解決することができました。　めでたし、めでたし。。

ちなみに、元々のエラーメッセージでは「少なくとも Pentium II」が必要と書かれていました：
2020122601

じゃあ、このプロセッサー情報を（ホストと同じではなく）"Pentium II" と指定して適用すればいいのではないか？　と最初は考えていました。が、そのように設定すると Pentium II と同様のウェイトがかかってしまうようでした。その結果、Windows 7 の起動そのものにものすごく長い時間がかかるようになりました（下画面は通常環境だと一瞬だけ表示されるもので、ユーザーが目の当たりにすることはほぼないのですが、プログレスバーがゆっくり進む様子が見て取れました）。そしてその結果なのか、何度も起動と途中終了＆強制リセットを繰り返す無限ループに入ってしまい、起動することはありませんでした：

↑Windows 7 時代では貴重な起動画面のスクリーンショット

タグ：: #kvm; #windows; #virtualpc

2015/07/04

KVM 環境での CentOS イメージファイルの引越し

コメント数:
0 コメント
by dotnsf

自宅サーバー環境での KVM 仮想化サーバーがお亡くなりになってしまいました・・・ (ToT)

某メーカーのデスクトップPCに CentOS + KVM を導入して仮想化サーバーに使っていたのですが、初夏の温度上昇に耐えられなかったのか、うんともすんとも言わなくなってしまいました。マザーボードレベルでやられたっぽいです。ちなみに買ってまだ２年、ここのはもう買わない。

幸いにして、KVM のイメージファイルのバックアップは取っていたので、最新状態ではないにせよ救える仮想マシンもありそうです。で、別マシンを用意して CentOS + KVM を導入し、バックアップイメージファイルをインポートして起動させてみたら・・・　期待通りに動いてくれません。。

症状として、仮想イメージ自体のインポートは成功して、KVM 内で起動はしてくれます。ただネットワーク（eth0）を認識してくれないため、ループバックアドレス(locahost)でしか使えません。もちろんインポート前には eth0 が使えていて、そのための ifcfg-eth0 などもちゃんと存在しているのに、です。単純なイメージインポートではこうなってしまうようです：

もう少し詳しく（ifconfig -a コマンドで）調べてみると、どうも eth0 ではなく eth1 を認識している模様。ただ ifcfg-eth1 は用意していないのでネットワークとしては使えません：

これがどういうことかというと、イメージファイルをインポートした際にネットワークインターフェースのハードウェアアドレス（MAC アドレス）が変わってしまって、eth0 ではなく eth1 として認識され、これまでの設定では正しく動かなくなってしまった、ということのようです。

対策としては２通りあります。１つは eth0 用の設定を eth1 用に書き換えて使う方法です。具体的には /etc/sysconfig/network-scripts/ 以下の ifcfg-eth0 を ifcfg-eth1 にリネームして、その中身の eth0 になっている箇所を eth1 に書き換えてリブートする方法です。この方法だと比較的簡単にできて、（eth1 をネットワークポートとして）動くことは動きます。

ただ、あくまで eth0 で動かしたい、という要望もあると思います。以下にその手順を紹介します。

まず上記の ifconfig -a コマンドの結果として、eth1 のハードウェアアドレスとして認識された結果（上記画像だと 52:54:00:9B:56:24）をメモしておきます。改めて /etc/udev/rules.d/70-persistent-net.rules をテキストエディタで開き、eth0 の ATTR{address}=="**:**:**:**:**:**" の **:**:**:**:**:** 部分をメモした内容で書き換えます：

システムが DHCP でアドレスを割り当てられる設定になっている場合は /etc/sysconfig/network-scripts/ifcfg-eth0 を編集して、HWADDR の行をコメントアウトするか、または上記と同じ MAC アドレスの値に書き換えて保存します：
2015070405

これでシステムを再起動すると、eth0 が認識されるはずです：

無事に KVM の CentOS イメージの引越ができました。

タグ：: #kvm; #centos

2015/02/18

KVM 内の CentOS インスタンスの複製コマンドを改良する

コメント数:
0 コメント
by dotnsf

KVM(Kernel-based Virtual Machine) は CentOS/RHEL(RedHat Enterprise Linux) 環境に標準装備の仮想ハイパーバイザーです。わかりやすく言えば、VMWare Server のような機能がカーネルにはじめから用意されている（はじめから有効にはなっていない）ので、CentOS/RHEL でも、それ以外の Linux ディストリビューションでも単体で仮想環境を構築することができます。　僕も自宅の個人環境で使っています。KVM 環境の構築手順はこちらのエントリを参照ください：
CentOS に KVM 環境を構築する

KVM には GUI/CUI 両方の管理ツール／コマンドが用意されていて、仮想イメージのクローン（複製）なども行うことができます。ただこの複製ツールが手軽に使えるかというと、実用上ちょっとした問題がありました。

その問題点は、この「複製」というのは「仮想イメージをまるごと複製」するのですが、ホスト名と MAC アドレスまでまるごと複製してしまう、という点でした。つまりあるサーバーインスタンスのイメージを複製すると、同じホスト名で、同じ MAC アドレスのネットワークインターフェースを持った異なるサーバーが用意される、ということです。　またネットワーク設定も複製されるため、例えば固定 IP アドレスが設定されている環境であれば同じ IP アドレスが割り振られることになりますし、DHCP 設定だとすると、同じ MAC アドレスのサーバーが別に存在していることになり、DHCP サーバーからは区別ができません（結果、正しい IP アドレスが取得できず、ネットワークが使えない状態で起動してしまいます）。

要は、複製コマンドそのものに問題があるわけではない（むしろ、複製という意味では正しい）のですが、イメージを複製した後にホスト名と MAC アドレスを変更したい（そこまで含めて自動化したい）のです。ただホスト名は AAA から BBB に変更すればよい、という正解が決まっているのでいいとして、MAC アドレスは変更したいといっても「では変更後の値を何にするのか？、一意に生成できるのか？」という問題もあったりして単純ではありません。またこれらの処理を自動化するとなると、起動していない仮想サーバーイメージ内のファイルシステムを外から操作することになるので、これも特殊なコマンドを使うことになります。その辺りを含めてシェルスクリプト化するまでを紹介します。

というわけで、目標として今回は clone-guest.sh というシェルスクリプトを作って、

# clone-guest.sh AAA BBB

というコマンドで、AAA という仮想マシンイメージを BBB という仮想マシンに複製できるようにします。複製そのものは /usr/bin/virt-clone コマンドを使えばできるのですが、その際に BBB は AAA とは異なる MAC アドレスを持っているように変更します。また複製後にこの BBB を自動起動するようにしてみます。また今回作成するシェルスクリプトでは複製の対象を CentOS/RHEL とします（これらのシステムを前提として MAC アドレス変更の処理を追加するためです）。

まず最初に「そもそもホスト名と MAC アドレスの変更ってどうやるの？」という疑問が生じます。ホスト名については CentOS/RHEL では /etc/sysconfig/network 内に HOSTNAME=**** として記載されているので、ここを書き換えるだけで済みます。具体的には例えば複製元の /etc/sysconfig/network に HOSTNAME=AAA.domain.com のような記載が含まれていたら、複製先では HOSTNAME=BBB.domain.com と書き換えればいい、ということになります。

一方、MAC アドレスはちと複雑です。まず MAC アドレスを書き換える必要のあるファイルが、
　- /etc/sysconfig/network-scripts/ifcfg-eth0
　- /etc/udev/rules.d/70-persistent-net.rules
の２つあります。更に書き換え後の MAC アドレスは現在とは異なる一意の値にする必要があるため、どのように生成するか、という問題も含まれているのでした。ここは詳しくは後述しますが /usr/bin/uuidgen コマンドを使って動的に取得するようにします。

次に、起動していない仮想イメージファイル内のファイルシステムへどのようにアクセスするか？　ですが、こちらは KVM 標準の以下のコマンドを活用して実現します：

- /usr/bin/virt-cat     外部から仮想イメージ内の特定ファイルに対して cat を実行する
- /usr/bin/virt-copy-in 外部から仮想イメージ内の特定ファイルにコピーする

これらのツールと、KVM の一般的な仮想管理コマンドである virsh(/usr/bin/virsh) を組み合わせて、clone-guest.sh を以下のような内容で作りました。青字は僕のコメントです：

#!/bin/sh

# 作業ディレクトリ
work_dir=/tmp/clone-guest

# この作業で使う各種コマンド
cmd_awk=/bin/awk
cmd_cat=/bin/cat
cmd_cut=/bin/cut
cmd_grep=/bin/grep
cmd_mkdir=/bin/mkdir
cmd_sed=/bin/sed
cmd_uuidgen=/usr/bin/uuidgen
cmd_arp=/sbin/arp
cmd_virsh=/usr/bin/virsh
cmd_virt_cat=/usr/bin/virt-cat
cmd_virt_clone=/usr/bin/virt-clone
cmd_virt_copy_in=/usr/bin/virt-copy-in

source_bridge=br0 # KVM のブリッジインターフェース名（デフォルトだと virbr0）
original_domain_name=$1 # 複製元（AAA）
clone_domain_name=$2 # 複製先(BBB)

# 仮想イメージのあるディレクトリ
domain_image_dir=/var/lib/libvirt/images
clone_domain_image_path=$domain_image_dir/$clone_domain_name.img # 複製先仮想イメージファイル


# パラメータを２つ（複製元と複製先）指定して実行していることを確認
if [ "$clone_domain_name" = "" ] ; then
echo "Usage: clone-guest.sh <domain_name> <clone_name>"
exit 0
fi

# 作業ディレクトリが存在していなかったら作成
[ ! -e $work_dir ] && $cmd_mkdir -p $work_dir


# virt-clone コマンドで普通に複製
$cmd_virt_clone \
  --original $original_domain_name \
  --name $clone_domain_name \
  --file $clone_domain_image_path 

# 複製前の仮想イメージ内の /etc/sysconfig/network を取り出して作業ディレクトリに保存
$cmd_virt_cat -d $original_domain_name \
  /etc/sysconfig/network \
  > $work_dir/network.org

# 複製前の仮想イメージ内の /etc/sysconfig/network-scripts/ifcfg-eth0 を取り出して作業ディレクトリに保存
$cmd_virt_cat -d $original_domain_name \
  /etc/sysconfig/network-scripts/ifcfg-eth0 \
  > $work_dir/ifcfg-eth0.org

# 複製前後の仮想イメージの MAC アドレスを取り出す
original_mac_addr=$( \
$cmd_virsh domiflist $original_domain_name \
| $cmd_grep $source_bridge \
| $cmd_awk '{print $5}' \
)
clone_mac_addr=$( \
$cmd_virsh domiflist $clone_domain_name \
| $cmd_grep $source_bridge \
| $cmd_awk '{print $5}' \
)

# 複製前後の仮想イメージの UUID を取り出す
original_nic_uuid=$( \
$cmd_cat $work_dir/ifcfg-eth0.org \
| $cmd_grep -i uuid \
| $cmd_cut -d'=' -f2 \
| $cmd_sed 's/"//g' \
)
clone_nic_uuid=$($cmd_uuidgen)

# 複製後の仮想イメージの ifcfg-eth0 を書き換え
$cmd_cat $work_dir/ifcfg-eth0.org \
| $cmd_sed -e "s/$original_mac_addr/$clone_mac_addr/i" \
-e "s/$original_nic_uuid/$clone_nic_uuid/i" \
> $work_dir/ifcfg-eth0

# 複製後の仮想イメージに書き換え後の ifcfg-eth0 を書き戻す
$cmd_virt_copy_in -d $clone_domain_name \
  $work_dir/ifcfg-eth0 \
  /etc/sysconfig/network-scripts/

# 複製前の仮想イメージ内の /etc/udev/rules.d/70-persistent-net.rules を取り出して作業ディレクトリに保存
$cmd_virt_cat -d $original_domain_name \
  /etc/udev/rules.d/70-persistent-net.rules \
  > $work_dir/70-persistent-net.rules.org

# 複製後の仮想イメージの 70-persistent-net.rules を書き換え
$cmd_cat $work_dir/70-persistent-net.rules.org \
  | $cmd_sed "s/$original_mac_addr/$clone_mac_addr/i" \
  > $work_dir/70-persistent-net.rules

# 複製後の仮想イメージに書き換え後の 70-persistent-net.rules を書き戻す
$cmd_virt_copy_in -d $clone_domain_name \
  $work_dir/70-persistent-net.rules \
  /etc/udev/rules.d/

# 複製後の仮想イメージの network を書き換え
$cmd_cat $work_dir/network.org \
| $cmd_sed -e "s/$original_domain_name/$clone_domain_name/i" \
> $work_dir/network

# 複製後の仮想イメージに書き換え後の network を書き戻す
$cmd_virt_copy_in -d $clone_domain_name \
  $work_dir/network \
  /etc/sysconfig/

# 複製後の仮想イメージを起動
$cmd_virsh start $clone_domain_name

echo "Clone $clone_domain_name has been started."
exit 0

sed だの awk だのを駆使してなんとか作った、という感じです（苦笑）。あとはこのファイルを clone-guest.sh という名前で保存し、実行権限を与え、パスの通ったディレクトリに置いておけば、

# clone-guest.sh AAA BBB

という感じで、既存の AAA という仮想環境を BBB という名前で複製して、各種設定ファイルまで書き換えて、起動する、という使い方ができるはずです。　ここまでできるようになると、KVM もかなり便利に使えてます。

タグ：: #virsh; #centos; #rhel; #kvm; #clone

2014/05/16

Stackato を導入してプライベートな Cloud Foundry 環境を（KVM に）構築する

コメント数:
0 コメント
by dotnsf

Cloud Foundry をベースとした PaaS 環境は色々な会社から提供されていますが、その商用プライベート版の１つに Stackato （スタッカート）があります。

Stackato は（PaaS なので当たり前といえば当たり前ですが）ホスティングされた環境を利用することもできますし、Amazon EC2 や HP Cloud Services 上にデプロイして利用するためのパッケージも用意されています。また小規模向け限定だと思われますが、仮想環境用のイメージファイルをダウンロードすることで、自社のオンプレミスなどの全くのプライベートな環境内に構築して利用することも可能です。

この最後のケースですが、イメージファイルは VirtualBox / VMWare / vSphere / KVM 環境それぞれ用意されているので、これらのいずれかの環境があれば試してみることができます。

というわけで、自分の KVM 環境を使って Stackato を導入してみた時の様子を、最初のセットアップまで紹介します。仮想環境を今から用意するのであれば PC に VirtualBox をダウンロードしてインストールするのが手軽かな、と思っていますが、もし KVM 環境を整えるのであればこちらを参照ください：
CentOS に KVM 環境を構築する

まずは Stackato のイメージをダウンロードします。ダウンロードサイトから目的の仮想環境にあったものを選んで "Direct" と書かれた箇所をクリックするとダウンロードが始まります（１ファイルが2GB近くあります）：

ダウンロードしたファイルを展開すると、選択した仮想環境用のマシンイメージファイルが現れます。Stackato V3.2.1 の KVM 用イメージであれば stackato-img-kvm-v3.2.1.img というファイル名でした（展開後のサイズは10GB近く）。

これを KVM 内で稼働させます。VirtualBox や VMWare など、他の環境を使う方はその環境なりの方法でイメージファイルを仮想マシンとして起動させてください。以下しばらくは KVM で仮想マシンマネージャーを使って起動させる場合の説明になります。

まずは KVM のホストマシン上で「仮想マシンマネージャー」を起動します：
2014051401

仮想マシンマネージャーが起動したら "localhost" と書かれた箇所を右クリックし、「新規」を選択します：

作成する仮想マシンの名前を適当に（図では "stackato"）入力します。また先程展開したイメージファイルから作成するので「既存のディスクイメージをインポート」を選択して「進む」をクリックします：

「既存のストレージパス」には「参照」ボタンをクリックして、先程展開した Stackato のディスクイメージファイルを選択します。また「OS の種類」には "Linux" を、「バージョン」はこのイメージの元になっている "Ubuntu 10.04" を選択します：

「メモリー」欄には Stackato に割り当てるメモリサイズを指定します。推奨値は 2GB 以上となっているので 2048(MB) と入力します。メモリに余裕がある環境であればもっと大きな数値でも構いません（但し、このダウンロードイメージを使う場合の上限は4GBらしいです）。なお1GB(1024) を指定した場合でも起動はしましたが、起動時に警告メッセージが表示されました。CPU は Stackato 環境に割り当てる仮想CPU数を指定してください：

最後に内容を確認して「完了」をクリックします：

Stackato 仮想マシンが起動している様子です：

仮想イメージの起動が完了するとこんな感じの画面になります（IP Address はDHCPで割り振られた、この Stackato マシンのIPアドレスです）。また画面内に "https://stackato-mm7d.local" と書かれたURL（赤字部分は環境によって変わります）は管理コンソールへアクセスするための URL ですが、後で使うのでメモしておきます。
ここからは KVM に依存しない内容に戻ります：

まずはこの Stackato 環境にログインしてみます。"l"（エル）キーを押して、ログイン画面に移ります。デフォルト状態ではユーザー名／パスワードともに "stackato" が設定されているので、この内容を入力してログインします：

ログインできました。CPU やメモリの状態、内部アドレスなどが表示されてプロンプトになります。なお stackato ユーザーが sudo 権限を持っているので、sudo を使うことでシャットダウンやリブートを含めた管理者権限でのコマンド実行を行うことも可能です：

管理コンソールへアクセスするには、自分の PC や仮想ホストマシンから先程のログイン画面に表示されていた URL にブラウザでアクセスします。が、このホスト名は Stackato が自動的に割り振ったものであって、当然ですがそのままでは（名前解決ができないため）アクセスできません。　これを解決するために DNS を設定してもいいのですが、手っ取り早い方法としてはブラウザを使うマシンの hosts ファイル（Unix/Linux 系であれば /etc/hosts、Windows 系であれば C:\Windows\System32\drivers\etc\hosts）を編集して以下の１行を追加します：

192.168.0.101 stackato-mm7d.local api.stackato-mm7d.local

この最初のアドレス部分は作成した Stackato 仮想マシンの IP アドレス（画面に表示されているもの）で、その右にホスト名、更にスペースを空けて api. を頭に付けたホスト名を記述します。

これでブラウザからホスト名指定でアクセスできるようになりました。改めてブラウザのアドレス欄に https://api.ホスト名/ （上記の一番右に追加した api. 付きの名前）と入力してアクセスします。すると以下の様な管理画面（の初期設定画面）が表示されます：

それぞれ以下の内容を入力し、"Yes, I agree to the Stackato Terms of Services" にチェックを入れて、最後に右下の "Setup First Admin User" ボタンをクリックします：
- Username: 管理ユーザー名
- Email Address: メールアドレス
- User Password: 管理ユーザーのパスワード
- Confirm Password: （確認用）同じパスワード
- Organization Name: 組織名／社名
- Space Name: デプロイ空間名称（適当に "dev" とか）

するとログイン画面が表示されます。ここに先程入力した管理ユーザー名とパスワードを指定してログインします：

正しくログインが完了するとこのような画面が表示され、各種管理機能にアクセスすることが可能になります：

とりあえず導入から起動、そして一通りのセットアップをした上で、管理コンソールにアクセスするまでを紹介しました。

実際のアプリケーションのデプロイなどはもう少し調べた上で別途紹介したいと思っています。

（2014/May/17 追記）
続きはこちらです。

タグ：: #stackato; #kvm; #paas; #cloudfoundry

2014/01/25

CentOS に KVM 環境を構築する

コメント数:
2 コメント
by dotnsf

CentOS に仮想化環境の KVM を導入する手順を紹介します。

KVM は Kernel-based Virtual Machine で、仮想化環境のハイパーバイザーです。VMWare などと同様に、KVM 環境の中に仮想のマシン（「ゲストOS」といいます）を作って、あたかも独立した一台のマシンがあるかのように利用することができます。大きな特徴としてまず「無料である」こと、加えて名前の由来になっているように Linux のカーネルの一部として、標準搭載されている機能なので、導入が比較的容易であることが挙げられます。またハイパーバイザー型であるため、KVM 自体は１台の物理的な Linux マシン（「ホストOS」といいます）の中で動き、その制御も Linux を通して行うことになります。例えば管理用のコンソール機能などもホストOS上の Linux アプリケーションとして提供されており、仮想HDDはホストOSからは１つのファイルとして扱います。

上記でも触れましたが、KVM は Linux のカーネルに含まれる形で実装されています。今回は Linux ディストリビューションとして CentOS を利用する前提で説明します。CentOS 自体のインストール方法については過去のブログエントリを参照してください：
『CentOS の導入』

KVM を利用するにはハードウェア的な条件があります。CPU が仮想化支援機構（Intel-VT, AMD-V）に対応している必要がある、ことです。

~~/proc/cpuinfo に flags として vmx が含まれていれば仮想化支援機構に対応済みと判断できます。~~
/proc/cpuinfo に flags として vmx （Intel版）か svm （AMD版）が含まれていれば仮想化支援機構に対応済みと判断できます（2016/Mar/20 修正）。

# cat /proc/cpuinfo | grep '(vmx|svm)' （この結果、何かが表示されれば対応していることになる）

また利用する前に BIOS の設定を変更し、この仮想化支援機構の機能を有効にしておきます。

では CentOS に KVM を導入する手順を紹介します。まずは yum で KVM に必要なモジュールをまとめてインストールします：

# yum -y install libguestfs libguestfs-tools libguestfs-tools-c libvirt libvirt-client python-virtinst qemu-kvm virt-manager virt-top virt-viewer

インストールできたら KVM(libvirt) の自動起動を ON にしておきます。これで CentOS の起動と同時に KVM が有効になります：

# chkconfig libvirtd on

この段階で一度再起動して、KVM が有効になった状態で OS を起動します：

# shutdown -r now

再起動後、ホストOSにブリッジインターフェース(br0)を作成します。このあと KVM 内に作成する全てのゲストOSはこのブリッジインターフェースを経由してインターネットを含めた外部ネットワークにアクセスすることになります。

ブリッジインターフェースは eth0 をベースに作成することにします。そのため、まずは ifcfg-eth0 をコピーして ifcfg-br0 を作り、ここから br0 の雛形を作成します：

# cd /etc/sysconfig/network-scripts # cp ifcfg-eth0 ifcfg-br0

ifcfg-br0 を編集します。内容は基本的に eth0 のものをそのまま使いますが、TYPE 属性を Bridge に変更します（大文字小文字に注意）：

# vi ifcfg-br0 DEVICE=br0 TYPE=Bridge ONBOOT=yes :

続いて ifcfg-eth0 を編集します。こちらは「（設定済みの）br0 経由で使う」ことを宣言することになります（大文字小文字に注意）。加えて IP アドレス関連の設定は br0 の方で行っていて、そちらへのブリッジをするだけなので eth0 では不要です（コメントアウトします）：

# vi ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BRIDGE=br0 #IPADDR=192.168.0.2 #PREFIX=24 #GATEWAY=192.168.0.1 #DNS1=192.168.0.1 DEFROUTE=yes :

この状態でネットワークを再起動します：

# /etc/init.d/network restart

ブリッジインターフェース(br0)が追加されたことを確認します：

# brctl show bridge name bridge id STP enabled interfaces br0 8000.002185aba9e1 no eth0 virbr0 8000.525400ca36c8 yes virbr0-nic

ブリッジインターフェースが２つ（br0, virbr0）確認できます。今作成した方(br0)ではない、もう１つのブリッジインターフェース virbr0 は KVM の導入と同時に作成されるものです。
これもブリッジインターフェースとして使えることは使えますが、パフォーマンスが悪いので明示的に br0 を作ったのでした。

この状態では virbr0 は不要なので削除します。また再起動時に自動作成されないよう設定します：

# virsh net-destroy default # virsh net-autostart default --disable

以下のコマンドで default の State が inactive になっていて、かつ Autostart が no になっていることが確認できれば設定完了です：

# virsh net-list --all Name State Autostart ----------------------------------------- default inactive no

ここまでの設定で KVM 関連ツール（仮想マシンマネージャーとか）が使えるようになっているはずです。KVM の使い方については別の機会に。

タグ：: #centos; #kvm

まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf