敵のいない勉強部屋

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

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のインストール、ホスト登録まで完了させたい。

もやもやは続く

仕事の昼休憩中にHDD(中古:1TB,2700円)とSATAケーブル(JUNK:210円)を購入。

帰宅後、先日動作不良を起こしたHDDと入れ替えてOSインストールを行った。

 

が、しかし。。。

状況は変わらず。

インストールはできるものの、起動に失敗。

「Error 1962: No operating system found. Boot sequence will automatically repeat.」

 

原因がHDD不良である可能性が下がった。

相変わらず他のPCでOSをインストールしたHDDを挿せば、ちゃんと起動する。

応急処置ではあるが、これで起動はできるし、ひとまず良しとするか。

 

私の頭で思いつく原因は

「HDDへの書き込みには失敗して、読み込みだけはできる」

なんてことだが、そんなことあるのだろうか。

 

もしそうだったとしても、物理的な不具合はどこで発生しているのか。

今後、KVMホストとしてちゃんと動いてくれるのか(新しいことが書き込めないならアウトだよなぁ)

 

もやもやは続く。

これこそJUNK

自宅にもCloudStackの検証環境がほしいと思い、

KVMホスト用に、秋葉原でJUNK PCを購入。 (ThinkCentre Edge 71 Small: 6,000円)

JUNK PCを買うのはこれで3台目だが、動作不良を起こしたのは初めてだった。

 

CentOSのインストール自体は何事もなく完了。

その後再起動をしたところ以下のメッセージで起動失敗。

「Error 1962: No operating system found. Boot sequence will automatically repeat.」

 

なぞのメッセージにしばらくあたふたしてしまったが、

他のPCとHDDを付け替えてみたり、SATAのケーブルを差し替えてみたりして、

なんとか原因を切り分けた。

 

どうやらHDDがだめみたい。

他のPCから持ってきたHDDでは起動成功したし、

反対に他のPCにHDDを持って行くと起動失敗した。

近々新しい(JUNKの)HDDを買ってきて、付け替えてみるとしよう。

 

それにしても、HDDがだめでも

インストール処理には失敗しないって、そんなことあるのか・・・?

 

ネットで調べても、同じような境遇の人が見つからない。

これ以上の深堀はひとまずやめておこう。

もやもや。