敵のいない勉強部屋

勉強記録用。土日を中心に更新。

/etc/profileとscriptコマンド

ターミナルのログを残すために/etc/profileにscriptコマンドを書いて運用していたが、

書き方が原因でcloudstackの起動スクリプトがフリーズしたため対処法をここに記録。

 

・これまでの悪い書き方

# grep script /etc/profile

script /var/log/script/`date "+%Y%m%d%H%M%S"`.log

 この書き方ではscriptコマンドが無限ループし、最悪の場合サーバ全体がダウンするそうな…笑

結構恐ろしいことをしていたようだ。

 

・新しい書き方

P_PROC=`ps aux | grep $PPID | grep sshd | awk '{ print $11 }'`
if [ "$P_PROC" = sshd: ]; then
script -q /var/log/script/`whoami`_`date '+%Y%m%d%H%M%S'`.log
exit

参考サイトの内容を引用させてもらった。

scriptコマンドの親プロセスがsshdの時だけ作動するように分岐しているようだ。

whoamiを使うとGood,ということも勉強になった。

参考サイト

scriptとpsacctでオペレーションログを記録する | Developers.IO

CloudStackAPIを使うには

クラウドAPI

CloudStackのようなクラウド基盤ソフトウェアでは、
APIを通じてインフラを管理(操作)できる。 (※CloudStackGUIも結局は裏でAPIをコールしているだけ)

ここではbashスクリプトを使ってAPIをコールし、

ターミナル上の操作でインスタンスを作成するまでの流れを紹介する。

 

APIキー,SECRETキーの取得

CloudStackGUIから、APIを使いたいユーザのAPIキーとSECRETキーを生成する。

f:id:im_not_enemy:20170916232837p:plain

f:id:im_not_enemy:20170916233026p:plain

②リモートPC(linux系)にスクリプトを作成

エディタを開き、こちらのコードを貼り付けるだけ。
https://gist.github.com/keithseahus/6201354

# vi cloud-api.sh

③必要箇所の書き換え

書き換えるのは前半部分のみ。
ADDRESS -> cloudstackのURIを指定
API_KEY -> ①で生成したAPIキーを指定
SECRET_KEY -> ①で生成したSECRETキーを指定
USE_XMLLINT -> こちらはお好みで0か1を指定(1にするとAPIの結果をxmllintで自動生成してくれます)

・編集前

ADDRESS="https://"
API_KEY=""
SECRET_KEY=""
USE_XMLLINT=0 # true => 1, false => 0

・編集後

ADDRESS="http://192.168.70.250:8080"
API_KEY="ki4nHumoJvC28UG5zVoV6m7Cq3MHF0IQCU-ohd08K9nWrY-FVurx2rOjubmbsOL7VutQPUGnJsoEY50JjQ2e8w"
SECRET_KEY="-g8OejVXQtC_uiHgEJVXafKcvAYRwpMeQV2x0VhyivQBIeeFhpWANR31slAghUs_Kap_D7cbVvuI2tBTPwIkCQ"
USE_XMLLINT=1 # true => 1, false => 0

④実行権限を付与

# chmod a+x cloud-api.sh

スクリプトの実行

・例えばZoneの一覧を取得したい場合
作成したスクリプトの引数の"command="部分で実行したいAPIの名前(listZones)を指定
# ./cloud-api.sh command=listZones

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 484 100 484 0 0 4382 0 --:--:-- --:--:-- --:--:-- 4400
<?xml version="1.0" encoding="UTF-8"?>
<listzonesresponse cloud-stack-version="4.9.2.0">
<count>1</count>
<zone>
<id>0b17bf01-fecb-4d79-bbeb-9632641b7eba</id>
<name>cloud-zone01</name>
<networktype>Advanced</networktype>
<securitygroupsenabled>false</securitygroupsenabled>
<allocationstate>Enabled</allocationstate>
<zonetoken>957d6ba3-fa65-34f8-ba7c-aa428316becf</zonetoken>
<dhcpprovider>VirtualRouter</dhcpprovider>
<localstorageenabled>false</localstorageenabled>
</zone>
</listzonesresponse>

 

・サービスオファリングの一覧を取得したい場合

# ./cloud-api.sh command=listServiceOfferings

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2379 100 2379 0 0 43597 0 --:--:-- --:--:-- --:--:-- 44055
<?xml version="1.0" encoding="UTF-8"?>
<listserviceofferingsresponse cloud-stack-version="4.9.2.0">
<count>4</count>
<serviceoffering>
<id>d32187cd-044b-4c3c-9284-0ddd928d3733</id>
<name>Medium Instance (HA)</name>
〜以下略〜

 

・テンプレートの一覧を表示したい場合
"command="以外にも引数が必要となる
# ./cloud-api.sh command=listTemplates templatefilter=self

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1081 100 1081 0 0 16620 0 --:--:-- --:--:-- --:--:-- 16890
<?xml version="1.0" encoding="UTF-8"?>
<listtemplatesresponse cloud-stack-version="4.9.2.0">
<count>1</count>
<template>
<id>66bad79b-e298-4e4e-9741-c768f7ddf8eb</id>
<name>web-linux-01-temp</name>
〜以下略〜

 

インスタンスを作成したい場合
サービスオファリング、テンプレート、ゾーンも引数で指定する必要がある
# ./cloud-api.sh command=deployVirtualMachine serviceofferingid=d32187cd-044b-4c3c-9284-0ddd928d3733 templateid=eac558b0-5ee5-11e7-ba23-90fba6067579 zoneid=0b17bf01-fecb-4d79-bbeb-9632641b7eba

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 225 100 225 0 0 380 0 --:--:-- --:--:-- --:--:-- 380
<?xml version="1.0" encoding="UTF-8"?>
<deployvirtualmachineresponse cloud-stack-version="4.9.2.0">
<id>f8056f37-489c-4b6d-83d5-eb8f366d5bae</id>
<jobid>a0d870b1-fb34-49a9-9633-29167bd10832</jobid>
</deployvirtualmachineresponse>

このようにjobidが返ってくる。

hypervisorやSystemVMが裏でプロビ処理を行っており、その完了を待つ必要があるのだ。

※これを非同期ジョブ(AsyncJob)と呼ぶ。

処理の成否はこのjobidを使って確認する。

・処理の成否確認

# ./cloud-api.sh command=queryAsyncJobResult jobid=a0d870b1-fb34-49a9-9633-29167bd10832

※処理中 jobstatus=0
※処理成功 jobstatus=1 ★今回はこちら
※処理失敗 jobstatus=2

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2419 100 2419 0 0 25138 0 --:--:-- --:--:-- --:--:-- 24938
<?xml version="1.0" encoding="UTF-8"?>
<queryasyncjobresultresponse cloud-stack-version="4.9.2.0">
<accountid>190363c5-edd4-4341-ad9a-84ff5866f4df</accountid>
<userid>42814bac-434e-4396-affb-fd4f62348af1</userid>
<cmd>org.apache.cloudstack.api.command.user.vm.DeployVMCmd</cmd>
<jobstatus>1</jobstatus>
〜〜以下略〜〜

インスタンスが作成されている

今回、インスタンス名はCloudStackが自動で生成しているが、
任意の名前を付けたい場合はcommand=deployVirtualMachineAPIコール時に引数"name="と"displayname="を追加で指定すれば良い。

f:id:im_not_enemy:20170916234817p:plain

・使用可能なAPI一覧

CloudStack API Reference

APIのコール時に必要な引数等や、返り値のxmlの読み方なども確認できる。

API名に(A)がつくものは、非同期ジョブであることを指している。

・他製品(ツール)との連携

今回はbashスクリプトAPIをコールしたが、APIキーとSECRETキーを使えばより様々なツールとの連携が可能になる。 (例: Jenkins, Terraform, Packer ...)
こちらについても今後、使用例を紹介していきたい。

KVMでsnapshotをとるには

参考サイト

Enable Snapshot with KVM on CloudStack - cloud-mate.org

 

global設定の変更

KVMでのsnapshotの取得はデフォルトで無効化されているので、有効化する。

mysql> update configuration set value="true" where name="KVM.snapshot.enabled";

# /etc/init.d/cloudstack-management restart

 

management-server.logの確認

しかし、guestVMのsnapshotが取得できない! まずはmanagement-server.logを確認

2017-07-25 00:09:53,931 DEBUG [c.c.s.s.SnapshotManagerImpl] (Work-Job-Executor-7:ctx-546a75ae job-178/job-179 ctx-7dd89d67) (logid:d7942c39) Failed to create snapshot 

 ざっくりとしたエラーメッセージ…

ちなみにjavaのexceptionも出ていた

com.cloud.utils.exception.CloudRuntimeException: Failed to backup 66a441af-bae9-457a-8330-6573b3c1d574 for disk /mnt/5fd97e14-cdc8-3ed0-8847-dbebfa8f8cae/76809d58-171a-40a7-9745-5fa1bc018100 to /mnt/94a2b615-187d-37bf-96e9-9b61278662f0/snapshots/5/30 

 ちょっとこれだけではわからないので、KVMホスト側のログも確認。

 

agent.log (KVM)の確認

management-server.logで上記のエラーが出る直前、KVMから下記のようなメッセージを受け取っている。

2017-07-25 00:09:53,353 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-2:null) (logid:) Seq 7-446419313063100482: No more commands found

この Seq 7-446419313063100482 という番号がとても重要で、シーケンス番号などと呼ばれる。

前半の "7" はhost_idを指し、これでどのホストとやり取りしているかがわかる。

# mysql -u root cloud -e "select name from host where id=7;"

+------------+
| name       |
+------------+
| host_kvm04 |
+------------+

というわけで、host_kvm04にログイン。

/var/log/cloudstack/agent/agent.logを確認。

2017-07-25 00:10:17,001 DEBUG [kvm.storage.KVMStorageProcessor] (agentRequest-Handler-3:null) (logid:d7942c39) Executing: /usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh -b /mnt/5fd97e14-cdc8-3ed0-8847-dbebfa8f8cae/76809d58-171a-40a7-9745-5fa1bc018100 -n 66a441af-bae9-457a-8330-6573b3c1d574 -p /mnt/94a2b615-187d-37bf-96e9-9b61278662f0/snapshots/5/30 -t 66a441af-bae9-457a-8330-6573b3c1d574
2017-07-25 00:10:17,225 DEBUG [kvm.storage.KVMStorageProcessor] (agentRequest-Handler-3:null) (logid:d7942c39) Exit value is 2

 原因はここのようだ・・・scriptの実行に失敗している。

 

qemu-imgの罠

managesnapshot.shの中身を見てみる。

# vi /usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh

$qemu_img convert -f qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName >& /dev/null
if [ $? -gt 0 ]
then
  printf "Failed to backup $snapshotname for disk $disk to $destPath " >&2
  return 2
fi

 ここの処理で失敗している。

$qemu_imgが何を指しているか確認したところ…

qemu_img="cloud-qemu-img" 

 cloud-qemu-img…?

そんなコマンドないが…

# which cloud-qemu-img

/usr/bin/which: no cloud-qemu-img in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

調べたところ、CentOS6.5以降では標準インストールされるqemu-imgが-sオプションをサポートしていないらしく、代わりにcloud-qemu-imgたるものが必要らしい。

 

cloud-qemu-imgのインストー

参考サイトに従って下記手順を実施。

yum install wget

# mkdir cloud-qemu-img

# cd cloud-qemu-img/

wget http://vault.centos.org/6.4/updates/x86_64/Packages/qemu-img-0.12.1.2-2.355.el6_4_4.1.x86_64.rpm

# rpm2cpio qemu-img-0.12.1.2-2.355.el6_4_4.1.x86_64.rpm |cpio -idmv

# cp ./usr/bin/qemu-img /usr/bin/cloud-qemu-img

# which cloud-qemu-img

/usr/bin/cloud-qemu-img

 
snapshot取得成功

記念のスクリーンショット

f:id:im_not_enemy:20170725010858j:plain

 解決できて満足です。

構築成功 -CloudStackとの戦いは始まる

参考サイト

CloudStack徹底入門 - 日本CloudStackユーザー会 - Google Books

備忘:CloudStackを試した際のあれこれ-[Id of Radiance ver.5]

 

VLANの準備

Advanced Zoneを使うにはVLANに対応するswitchを用意し、事前にPortを開けておく必要がある。今回はNetGear SG105Ev2を使用した。VLANIDは1〜5まで。

f:id:im_not_enemy:20170710222540p:plain

Traffic設定

Guest Traffic用に専用のNICを割り当てることが推奨されているが、予算的に用意できないので、すべてのTrafficをひとつのNICに割り当てた。

f:id:im_not_enemy:20170710222740p:plain

Zone登録完了

その他特に注意すべき設定はなく、とうとうZone登録に成功。

f:id:im_not_enemy:20170710223203p:plain

 

しかし。。。

SystemVMが起動してこない

お約束すぎる。。 本来自動で生成されるべきSystemVMが生成されません。

management-server.logを確認したところ、生成失敗->削除 を繰り返している。

 

CloudStackがVMを作成する際、以下の順番で処理が流れる。

VM作成先のホストの選定

②SecondaryStorageから、PrimaryStorageへテンプレートをダウンロード

③ネットワークの準備

④Hostに対して起動リクエスト送信

 今回は④で失敗していた。

2017-07-09 15:40:39,841 DEBUG [c.c.a.t.Request] (Work-Job-Executor-52:ctx-979bae17 job-21/job-87 ctx-1747cde3) (logid:00cc4591) Seq 1-8544172918051963133: Received: { Ans: , MgmtId: 159410496632185, via: 1(host_kvm01), Ver: v1, Flags: 10, { StartAnswer, Answer } }
2017-07-09 15:40:39,891 INFO [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-52:ctx-979bae17 job-21/job-87 ctx-1747cde3) (logid:00cc4591) Unable to start VM on Host[-1-Routing] due to s-18-VM の cgroup を作成できません: そのようなファイルやディレクトリはありません

 業務でも見たことのないエラーだったので、一旦Zoneを無効化して自動生成を

止め、すぐさまGoogleで対処方法を調べる。

 

どうやら、Host側で設定をうまく読み込めていないらしく、cgroupサービスをリスタートすることで解消される模様。

# /etc/init.d/cgconfig restart

 

再度Zoneを有効化し様子を見るが状況は変わらず。

更に調べたところ、cloudstack-agentで解消されることもあるそうな。

# /etc/init.d/cloudstack-agent stop
# /etc/init.d/libvirtd stop
# /etc/init.d/libvirtd start
# /etc/init.d/cloudstack-agent start

Zoneを有効化すると、SystemVMの作成に成功!

f:id:im_not_enemy:20170710224311p:plain

 

CloudStackとの戦いは始まったばかりである

ようやくCloudStackを自宅でも使えるようになりました。

残りのホストも追加して、ガンガン検証に使っていきたいと思います。

 

 

ホスト登録失敗 -agent起動の壁

今度こそホスト登録に挑戦!

しかしagent起動の壁が立ちはだかった。

 

参考サイト

Quick Installation Guide for CentOS 6 — Apache CloudStack Installation Documentation 4.9.0 documentation

[CLOUDSTACK-5985] Unable to add a kvm host in UI - ASF JIRA

agent起動の壁

Zone, Phisical Network, Pod, Cluster..etc と、各コンポーネントのパラメータを入力後、[launch]を押下。

祈るような気持ちで画面を見つめていたが。。案の定失敗(ちなみにこの時は気づいていなかったが、まちがえてBasic Zoneで登録しようとしていた。)

f:id:im_not_enemy:20170708123848p:plain

・management-server.logの確認

2017-07-02 15:16:12,252 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-10:ctx-d277448f ctx-da62adad) (logid:8f4921ae) Unable to find the server resources at http://host_kvm01
2017-07-02 15:16:12,256 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-10:ctx-d277448f ctx-da62adad) (logid:8f4921ae) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions

リソースが見つからないと... 名前解決はできているので、通信自体はできてると思うんだよな。

ということで、ホスト側のagent.logを確認。

2017-07-02 15:34:23,865 ERROR [cloud.agent.AgentShell] (main:null) (logid:) Unabble to start agent: Failed to get private nic name

private nicの名前が取得できず、agentが起動できない...どういうこと?

確かにagentは起動できていない。手動でrestartしても、/var/log/subsys/cloudstack-agentを消しても状況は変わらず。

# /etc/init.d/cloudstack-agent status

cloudstack-agent は停止していますがサブシステムがロックされています

 

・ログをINFOモードからDEBUGモードへ切り替えて見てみよう。

# sed -i s/INFO/DEBUG/g /etc/cloudstack/agent/log4j-cloud.xml

# /etc/init.d/cloudstack-agent restart

# view /var/log/cloudstack/agent/agent.log

2017-07-03 01:03:56,543 DEBUG [kvm.resource.LibvirtComputingResource] (main:null) (logid:) guest(private) traffic label 'cloudbr1' not found as bridge, looking for physical interface
2017-07-03 01:03:56,543 DEBUG [kvm.resource.LibvirtComputingResource] (main:null) (logid:) public traffic label 'cloudbr0' not found as bridge, looking for physical interface

cloudbr0(guest用)とcloudbr1(public用)が見つからないらしい。本来なら自動で作成されるはずなのだが、私の環境ではホストにNICがひとつしかないから失敗しているのかな?

というわけで、自動作成をOFFにし、手動でcloudbr0を作成したところ、agentの起動に成功!

 

・cloudbr0とcloudbr1自動作成→cloudbr0を手動作成に変更

# cp -ip /etc/cloudstack/agent/agent.properties /etc/cloudstack/agent/agent.properties.default

# vi /etc/cloudstack/agent/agent.properties 

# diff /etc/cloudstack/agent/agent.properties.default

/etc/cloudstack/agent/agent.properties

47c47
< # public.network.device=cloudbr0
---
> public.network.device=cloudbr0
51c51
< # private.network.device=cloudbr1
---
> private.network.device=cloudbr0

 

・cloudbr0設定

# vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0 

# cat /etc/sysconfig/network-scripts/ifcfg-cloudbr0

DEVICE="cloudbr0"
BOOTPROTO="static"
BROADCAST="172.16.255.255"
DNS1="172.16.0.1"
GATEWAY="172.16.0.1"
HWADDR="52:54:00:1A:59:10"
IPADDR="172.16.0.201"
NETMASK="255.255.0.0"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Bridge"

# vi /etc/sysconfig/network-scripts/ifcfg-eth0
# cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"
BOOTPROTO="static"
HWADDR="52:54:00:1A:59:10"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Ethernet"
BRIDGE="cloudbr0"

# brctl addbr cloudbr0
# brctl addif cloudbr eth0

# brctl show

bridge name bridge id STP enabled interfaces
cloud0 8000.000000000000 no
cloudbr0 8000.5254001a5910 no eth0
virbr0 8000.525400ad7e4e yes virbr0-nic

# service network restart

 

・agent起動

# /etc/init.d/cloudstack-agent start
Starting Cloud Agent:
# /etc/init.d/cloudstack-agent status
cloudstack-agent (pid 4825) を実行中...

 

起動成功!

ホスト登録は再び次回の記事に持ち越し!

環境構築までの道のりは長い。。。

cloud-management インストール

hostが1台でもcloudstackは構成できるので、先にcloudstack-managementを動作させておく方針に変更しました。

まずは1台登録できるか試してみましょうということで。

今回も参考サイトの手順に従えばほぼほぼ問題なく進んだため、躓いた箇所のみ掲載。

参考サイト

Quick Installation Guide for CentOS 6 — Apache CloudStack Installation Documentation 4.9.0 documentation

 

つまずきポイント - tomcat6がyumでインストールできない

# yum -y install cloudstack-management

http://cloudstack.apt-get.eu/centos/6/4.9/repodata/87fe24a3f0e235623e2965b7a3508ff0ba59c6b5e3cba3fc1b5156910c3b1826-filelists.sqlite.bz2: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

なにやらファイルが見つからないようです。

ブラウザで確認したところ、正しいURLは下記のようで。

http://cloudstack.apt-get.eu/centos/6/4.9/repodata/6588bf6af0efb5764ffd34807d8cdd17552feee124aa9592b8b00999c0299912-filelists.sqlite.bz2

 

これどうすればいいんだ。。

思い浮かんだ選択肢は2つ。

  ①ソースからコンパイルする

  ②他のリポジトリからインストールする

 迷わず②を選びました。

 

■epelリポジトリの登録

# rpm -Uvh http://ftp.riken.jp/Linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

# yum -y install cloudstack-management

しかし。。。

http://cloudstack.apt-get.eu/centos/6/4.9/repodata/87fe24a3f0e235623e2965b7a3508ff0ba59c6b5e3cba3fc1b5156910c3b1826-filelists.sqlite.bz2: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

何も状況が変わらない! そんなはずは。。。

調べたところ、yumにもキャッシュがあるそうで。

キャッシュをクリアしたところうまく行きました!

# yum clean all

# yum -y install cloudstack-management

cloudstack-managementインストール完了

その他もろもろの設定も完了し、GUI表示までたどり着きました。

--> http://172.16.0.101:8080

ホスト登録は次回へ持ち越し。 

f:id:im_not_enemy:20170705014946p:plain

 

 

 

 

 

 

nested KVM構築(CentOS6)

今回はKVM on KVM いわゆる nested KVM で環境を準備したので、その手順をまとめる。

参考サイトの手順に従えば、ほとんどつまずくことはなかった。

ようやくCloudStack検証環境構築に一歩近づくことができた。 

参考サイト

 ・CentOS 6 - KVM - インストール : Server World

 ・仮想化された日々:kvmのドライバモジュールロード時のエラー - livedoor Blog(ブログ)

 ・KVMのゲストOSをブリッジ接続に変更する: 気の向くままに・・・

 ・CentOS 6 - KVM - KVM をネストする : Server World

BIOS設定変更

 Intel(R) Virtualization Technology を [Disabled] -> [Enabled] に変更

CPU仮想化対応確認

# grep vmx /proc/cpuinfo

※フラグが表示されること

KVMインストー

・パッケージインストー

# yum install -y qemu-kvm virt-manager libvirt libvirt-python python-virtinst 

・モジュール確認

# lsmod | grep kvm

kvm_intel 55432 0
kvm 346318 1 kvm_intel

・サービス起動

# /etc/init.d/messagebus start

# /etc/init.d/libvirtd start

仮想ブリッジ作成

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

DEVICE=eth0
TYPE=Ethernet
HWADDR=8c:89:a5:23:50:c5
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
BRIDGE=br0

# vi ifcfg-br0
# cat ifcfg-br0

DEVICE=br0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPADDR=172.16.0.102
NETMADK=255.255.0.0

DNS1=172.16.0.1
GATEWAY=172.16.0.1

# brctl addbr br0
# brctl addif br0 eth0
# brctl show

bridge name bridge id STP enabled interfaces
br0 8000.8c89a52350c5 no eth0
virbr0 8000.525400eff9dc yes virbr0-nic

# service network restart

・br0にIPアドレスが振られていることを確認

# ip a

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 8c:89:a5:23:50:c5 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8e89:a5ff:fe23:50c5/64 scope link
valid_lft forever preferred_lft forever

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 8c:89:a5:23:50:c5 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.102/16 brd 172.16.255.255 scope global br0
inet6 fe80::8e89:a5ff:fe23:50c5/64 scope link
valid_lft forever preferred_lft forever

 guestVM作成

# virt-install --name=kvm_host01 --os-type=Linux --os-variant=rhel6 --ram=4096 --vcpu=2 --graphics none --disk=/home/host_kvm01/image/host_kvm01,size=40 --network bridge=br0 --location=http://ftp.riken.jp/Linux/centos/6.9/os/x86_64/ --extra-args='console=tty0 console=ttyS0,115200n8'

※guestVMのコンソールにてCentOSをインストー

# grep vmx /proc/cpuinfo

※この時点ではvmxフラグが立っていないことを確認

# shutdown -h now

※guestVMをシャットダウンしておく

nested KVM設定 (HostOS側で実施)

カーネルバージョン確認(2.6.32)

# uname -a
Linux thinkcentre02.local 2.6.32-696.el6.x86_64 #1 SMP Tue Mar 21 19:29:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Xenリポジトリ登録

# yum -y install centos-release-xen

# cp -ip /etc/yum.repos.d/CentOS-Xen.repo /etc/yum.repos.d/CentOS-Xen.repo.default

# vi /etc/yum.repos.d/CentOS-Xen.repo

※編集箇所抜粋

[centos-virt-xen]
name=CentOS-for-Xen
baseurl=https://buildlogs.centos.org/centos/6/virt/x86_64/xen-46
gpgcheck=0
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization

 ・カーネルUpdate

# yum --enablerepo=centos-virt-xen -y update kernel

カーネルオプション追加

# cp -ip /boot/grub/grub.conf /boot/grub/grub.conf.default
# vi /boot/grub/grub.conf
# diff /boot/grub/grub.conf.default /boot/grub/grub.conf

16c16
< kernel /vmlinuz-4.9.34-29.el6.x86_64 ro root=/dev/mapper/vg_thinkcentre02-lv_root rd_NO_LUKS rd_NO_MD rd_LVM_LV=vg_thinkcentre02/lv_root crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=jp106 rd_LVM_LV=vg_thinkcentre02/lv_swap LANG=ja_JP.UTF-8 rd_NO_DM rhgb quiet
---
> kernel /vmlinuz-4.9.34-29.el6.x86_64 ro root=/dev/mapper/vg_thinkcentre02-lv_root rd_NO_LUKS rd_NO_MD rd_LVM_LV=vg_thinkcentre02/lv_root crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=jp106 rd_LVM_LV=vg_thinkcentre02/lv_swap LANG=ja_JP.UTF-8 rd_NO_DM rhgb quiet kvm-intel.nested=1

・ホストOS再起動

# reboot 

カーネルバージョン確認(4.9.34)

# uname -a
Linux thinkcentre02.local 4.9.34-29.el6.x86_64 #1 SMP Tue Jun 27 14:10:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

・CPU情報確認

# virsh capabilities | egrep "<model>|<vendor>"

<model>Nehalem</model> ※確認ポイント①
<vendor>Intel</vendor> ※確認ポイント②
<model>selinux</model>
<model>dac</model>

・guestVM設定変更 

# virsh list --all

Id   名前                  状態
----------------------------------------------------
 -    kvm_host01       シャットオフ

# virsh edit kvm_host01

※以下の記述を追記

<cpu mode='custom' match='exact'>
  <model fallback='allow'>Nehalem</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vmx'/>
</cpu>

# virsh start kvm_host01

# virsh console kvm_host01

# grep vmx /proc/cpuinfo

※vmxフラグが立っていることを確認

 

明日はこのKVM上にVM作成のテストをして、

それがうまく行けば、残り3台分のnested KVM環境を構築しよう。

できたらそのままcloudstackのインストール、ホスト登録まで完了させたい。