Wakeme-VDC で起動したインスタンスをデバッグしてみる
これは Wakame-vdc / OpenVNet Advent Calendar 2014 5日目の投稿です。
昨日は @giraffeforestg さんの「Wakame-vdcのLoadBalancer機能を使ってみる」でした。いつも @giraffeforestg さんの情報量には驚かされます。
今日は3日目で起動したはずのインスタンスに接続できない原因を調べてみようと思います。
WebUI で見ると以下のように確かに running になっているものの、
IP 192.168.122.200 に ssh 接続しようとすると…
$ ssh -i ssh-8y455ans.pem root@192.168.122.200
ssh: connect to host 192.168.122.200 port 22: No route to host
と言われてしまいます。もちろん、セキュリティグループは設定済みですので、念のため iptables も確認すると…(ちょっと出力長いですが、全部貼ります)
[root@wakame-kvm ~]# iptables-save
# Generated by iptables-save v1.4.7 on Fri Dec 5 18:06:48 2014
*raw
:PREROUTING ACCEPT [10185:1787410]
:OUTPUT ACCEPT [9521:2673616]
COMMIT
# Completed on Fri Dec 5 18:06:48 2014
# Generated by iptables-save v1.4.7 on Fri Dec 5 18:06:48 2014
*filter
:INPUT ACCEPT [8524:1529647]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7937:1498592]
:d_vif-nv87ycbr - [0:0]
:d_vif-nv87ycbr_icmp - [0:0]
:d_vif-nv87ycbr_tcp - [0:0]
:d_vif-nv87ycbr_udp - [0:0]
:s_vif-nv87ycbr - [0:0]
:s_vif-nv87ycbr_icmp - [0:0]
:s_vif-nv87ycbr_tcp - [0:0]
:s_vif-nv87ycbr_udp - [0:0]
-A FORWARD -m physdev --physdev-in vif-nv87ycbr --physdev-is-bridged -j s_vif-nv87ycbr
-A FORWARD -m physdev --physdev-out vif-nv87ycbr --physdev-is-bridged -j d_vif-nv87ycbr
-A FORWARD -m physdev --physdev-in vif-nv87ycbr --physdev-is-bridged -j s_vif-nv87ycbr
-A FORWARD -m physdev --physdev-out vif-nv87ycbr --physdev-is-bridged -j d_vif-nv87ycbr
-A d_vif-nv87ycbr -p icmp -m state --state NEW,RELATED,ESTABLISHED -j d_vif-nv87ycbr_icmp
-A d_vif-nv87ycbr -p udp -m state --state NEW,ESTABLISHED -j d_vif-nv87ycbr_udp
-A d_vif-nv87ycbr -p tcp -m state --state NEW,ESTABLISHED -j d_vif-nv87ycbr_tcp
-A d_vif-nv87ycbr -p icmp -m state --state NEW,RELATED,ESTABLISHED -j d_vif-nv87ycbr_icmp
-A d_vif-nv87ycbr -p udp -m state --state NEW,ESTABLISHED -j d_vif-nv87ycbr_udp
-A d_vif-nv87ycbr -p tcp -m state --state NEW,ESTABLISHED -j d_vif-nv87ycbr_tcp
-A d_vif-nv87ycbr_icmp -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_icmp -j DROP
-A d_vif-nv87ycbr_icmp -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_icmp -j DROP
-A d_vif-nv87ycbr_tcp -p tcp -m tcp --dport 22 -j ACCEPT
-A d_vif-nv87ycbr_tcp -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_tcp -j DROP
-A d_vif-nv87ycbr_tcp -p tcp -m tcp --dport 22 -j ACCEPT
-A d_vif-nv87ycbr_tcp -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_tcp -j DROP
-A d_vif-nv87ycbr_udp -p udp -m state --state ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_udp -j DROP
-A d_vif-nv87ycbr_udp -p udp -m state --state ESTABLISHED -j ACCEPT
-A d_vif-nv87ycbr_udp -j DROP
-A s_vif-nv87ycbr -p icmp -j s_vif-nv87ycbr_icmp
-A s_vif-nv87ycbr -p udp -j s_vif-nv87ycbr_udp
-A s_vif-nv87ycbr -p tcp -j s_vif-nv87ycbr_tcp
-A s_vif-nv87ycbr -p icmp -j s_vif-nv87ycbr_icmp
-A s_vif-nv87ycbr -p udp -j s_vif-nv87ycbr_udp
-A s_vif-nv87ycbr -p tcp -j s_vif-nv87ycbr_tcp
COMMIT
# Completed on Fri Dec 5 18:06:48 2014
# Generated by iptables-save v1.4.7 on Fri Dec 5 18:06:48 2014
*nat
:PREROUTING ACCEPT [13:1008]
:POSTROUTING ACCEPT [2:132]
:OUTPUT ACCEPT [2:132]
:vif-nv87ycbr_snat - [0:0]
:vif-nv87ycbr_snat_exceptions - [0:0]
-A POSTROUTING -s 192.168.122.200/32 -j vif-nv87ycbr_snat_exceptions
-A POSTROUTING -s 192.168.122.200/32 -j vif-nv87ycbr_snat
-A POSTROUTING -s 192.168.122.200/32 -j vif-nv87ycbr_snat_exceptions
-A POSTROUTING -s 192.168.122.200/32 -j vif-nv87ycbr_snat
COMMIT
# Completed on Fri Dec 5 18:06:48 2014
う〜ん、iptables は問題なさそうですね。次にインスタンスの実体を見てみます。インスタンスデータは vdc-hva の /var/lib/wakame-vdc/instances/インスタンスID というディレクトリ配下にあります。
# ls -al /var/lib/wakame-vdc/instances/i-ifq0dxis/
total 2783016
drwxr-xr-x. 3 root root 4096 Dec 3 18:57 .
drwxr-xr-x. 4 root root 4096 Dec 3 18:57 ..
-rw-------. 1 root root 5 Dec 5 17:09 kvm.pid
-rw-r--r--. 1 root root 10485760 Dec 5 17:09 metadata.img
-rw-r--r--. 1 root root 2082 Dec 5 17:09 metadata.yml
-rw-r--r--. 1 root root 6 Dec 5 17:09 monitor.port
-rwxr-xr-x. 1 root root 859 Dec 5 17:09 run.sh
-rw-r--r--. 1 root root 6 Dec 5 17:09 serial.port
-rw-r--r--. 1 root root 8 Dec 5 17:09 state
drwxr-xr-x. 2 root root 4096 Dec 3 18:57 tmp
-rw-r--r--. 1 root root 6 Dec 5 17:09 vnc.port
-rw-------. 1 root root 4000000000 Dec 3 18:57 vol-cdxr64zk
それぞれについては説明を省きますが、 monitor.port, serial.port, vnc.port という3つのファイルがあります。このなかで、serial.port と書いてあるファイルの中身を見ると
# cat /var/lib/wakame-vdc/instances/i-ifq0dxis/serial.port
31808
とポート番号が書いてあるので、telnet コマンドで 127.0.0.1:31808 に接続します。
[root@wakame-kvm ~]# telnet 127.0.0.1 31808
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
おや?これはいけませんねぇ。正しく起動していればログインプロンプトが見れるかと思ったのですが、残念です。 では気を取り直して VNC のポート番号を見てみます。
[root@wakame-kvm ~]# cat /var/lib/wakame-vdc/instances/i-ifq0dxis/vnc.port
31167
で、これも serial と同様に 127.0.0.1 で LISTEN しているのですが、今回の Wakame-VDC マシンは GUI を入れていないため、別のマシンからこの vnc に接続したいので、以下を実行して 127.0.0.1:31167 にリモートホストから VNC 接続できるようにします。
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -d 192.168.122.20 --dport 31167 -j DNAT --to-destination 127.0.0.1:31167
うむ、VNC クライアントに「Unable to connect to VNC server」と言われてしまいました。実際にパケットがどこまで流れているかを tcpdump で見てみましょ。
# tcpdump -i any -e -n tcp port 31167
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
18:57:42.908139 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57716 > 192.168.122.20.31167: Flags [S], seq 2006235334, win 29200, options [mss 1460,sackOK,TS val 86101664 ecr 0,nop,wscale 7], length 0
18:58:04.349926 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57770 > 192.168.122.20.31167: Flags [S], seq 805417769, win 29200, options [mss 1460,sackOK,TS val 86107024 ecr 0,nop,wscale 7], length 0
18:58:05.348083 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57770 > 192.168.122.20.31167: Flags [S], seq 805417769, win 29200, options [mss 1460,sackOK,TS val 86107274 ecr 0,nop,wscale 7], length 0
18:58:07.352112 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57770 > 192.168.122.20.31167: Flags [S], seq 805417769, win 29200, options [mss 1460,sackOK,TS val 86107775 ecr 0,nop,wscale 7], length 0
18:58:11.356083 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57770 > 192.168.122.20.31167: Flags [S], seq 805417769, win 29200, options [mss 1460,sackOK,TS val 86108776 ecr 0,nop,wscale 7], length 0
18:58:19.372108 In fe:54:00:2d:3b:28 ethertype IPv4 (0x0800), length 76: 192.168.122.1.57770 > 192.168.122.20.31167: Flags [S], seq 805417769, win 29200, options [mss 1460,sackOK,TS val 86110780 ecr 0,nop,wscale 7], length 0
うーん、ポートの転送ができていないように見えます。 駄目元で stone を使って tcprelay して再度 vnc 接続してみました。
# iptables -t nat -D PREROUTING -p tcp -d 192.168.122.20 --dport 31167 -j DNAT --to-destination 127.0.0.1:31167
# stone 127.0.0.1:31167 192.168.122.20:31167
はい、繋がりました。以下のように grub を呼ぶところまで到達していないことがわかりました。3日目のマシンイメージの作り方が失敗していたことがわかります。
ということで、今日も失敗談なわけですが、インスタンスが起動できているかどうかを見る方法としてはお役に立てるのではないかと思います。
ということで Wakame-vdc / OpenVNet Advent Calendar 2014 5日目の投稿でした。次の日は @hansode さんの「CI周りについて」です。楽しみです :)