万策尽きたとき

提供: 釧路高専プロ研Wiki
移動先: 案内検索

CloudStack上で、万策尽きたときに行うことをブラックボックスではなく、ホワイトボックス、SHIROBAKOします。


利用者向け[編集]

VMから外に繋がらない[編集]

以下のことをやってください。

  1. CloudStack「ネットワーク」の通信規則をチェック
    通信規則が「157.114.164.0/24」で、「157.114.16.93」に繋がらないとか
  2. hostname「localhost」になっていないかどうか
    なっていたら、仮想ルータが死んでいるときに立てられたVMで、DHCPによる自動設定が失敗していると思うので、再起動するか、dhclientして一応hostnameを適切に設定してください。
  3. 学外などProxyを介さないと通信出来ない場所ではないかどうか
    Proxyは、「http_proxy」or/and「https_proxy」です。
  4. Proxyを介しても通信できないポートではないかどうか
    学外にある端末のTCP:22だったり
  5. そもそも電源が入っているか
    他のところも試しましょう

それでもダメなら、CloudStackのUIから、自信のネットワークを選択し、「ネットワークの再起動(クリーンアップなし)」 をしてください。それでもダメなら、「ネットワークの再起動(クリーンアップあり)」をしてください。

それでもダメなら、しばらく諦めてください。

外からVMに繋がらない[編集]

このあたり、

  • NWのFW
  • ポートマッピング
  • マシンのFW(# iptables -L)
  • マシンでサービスが起動しているか?($ netstat -nl | grep PORT_NUMBER)
  • 途中経路のFW(学外からだと絶対に繋がらない)

を確認してください。

ICMPでさえもデフォルトでは通らないため、3、4年生の時に習った「PINGを打って分割統治で...」とやっても無駄です。

インスタンスの操作ができない[編集]

1日くらい待つか、諦めてください。


管理者向け[編集]

「DBに直接SQL文を発行することを恐れるな」

~ 管理について、この先生きのこる先生

エラーログは、

  • /var/log/cloudstack/management/management-server.log
  • /var/log/cloudstack/agent/agent.log
  • /var/log/libvirt/libvirtd.log

あたりを確認しましょう。

アップデート時の注意[編集]

アップデート前に必ず、システムVMテンプレートをCloudStackのUIから登録しましょう。 アドレスはアップデートガイドに載っています。

テンプレートは学外にあるので、Proxyを通す必要がありますが、Global Settingsの「secstorage.proxy」がそれです。 普段は停止していますが、あるサーバのTCP:25252でSquidが稼働します。ダウンロードの際に、そのサーバで「service squid start」し、完了したら「stop」してください。

なお、Squidの設定では、「無認証、157.114.160.0/24上のホストのみにProxyを提供し、上位Proxy(proxy.gcc.kushiro-ct.ac.jp)に、s140713の認証情報を付けて転送」するようにしています。 パスワードも平文で書いていますが、見たらそっと閉じてください。

ちなみに、テンプレートを一度適当なサーバにダウンロードし、PythonのSimpleHTTPServerなどでサーバを立て、CloudStackから利用しようとしたのですが、弾かれました。 アクセスログは残るのですが、すぐ切られます。 登録の際のダウンロードURLは、TCP:80 or TCP:443 しか受け付けないのですが、TCP:80だったので、Content-typeかも知れません。

便利[編集]

  • virsh list

NFS絡み[編集]

cloudstack-agentが、「既にmountされていて起動できない」というログを吐く場合。 以下の流れで作業します。

  1. 「virsh list」して実行中のVMが無いことを確認
    あったらCloudStackからVMを別ホストに移行させたり、停止したり。無理な場合は諦める。
  2. cloudstack-agent、libvirtdをstopする
  3. dfする
    192.168.30.1をNFSサーバとして、「/mnt/(長い文字列)」にマウントされていることを確認
  4. 「umount /mnt/(長い文字列)」を実行
    恐らく「Busy」と言われる。
  5. 「fuser -muv /mnt/(長い文字列)」を実行
    「qemu-kvm」が原因であることがわかる
  6. それをkillallする
  7. 再びアンマウント
  8. libvirtd、cloudstack-agentを起動

その後、CloudStackManagerに認識されたら終わりです。

Agent(ホスト)がUpしない[編集]

CloudStackUIから、ホストが一向にUpしない場合。

一度、ホストの登録を削除すると良いかも知れません。 その後、「157.114.160.0/24」なアドレスを指定して再登録。

インスタンスがStartしない[編集]

ログが出るならそれに従いましょう。

謎の挙動でログも出ない場合、ホストに残った過去のVMが原因かも知れません。

  1. 「virsh list --all」する
    「シャットダウン」があれば、この可能性がある。
  2. 「virsh undefine (VM名)」を全てのシャットダウンしたVMに対して実行
    ダメな場合は、「virsh managedsave-remove (VM名)」を実行してから。

これを全てのホストで行います。

なお、冒頭で「ログが出ない」と書きましたが、 これまで、agent.logに「Google製ライブラリ?のJSONパースの例外」が出ていたのに、 対策後は出なくなりました。何か関係があるかも知れません。

インスタンスを強制的に停止させる[編集]

「Starting」になったままのVMを強制的に停止させます。

  1. Managementサーバで稼働中のMySQLサービスにアクセス
  2. DB「cloud」を使う
  3. 「user_vm」というテーブルがあるので、適切に「Starting」を「Stopped」に変更

これで、操作できるようになります。 精神衛生上悪いので、仮想ルータなどシステムVMの場合は、Startせず、そのまま破棄してしまったほうが良い気がします。 システムVMの場合は、そのまま放っておいても起動します。 仮想ルータの場合は、該当のネットワークを「クリーンアップあり」で再起動すると、新しく作られるようになります。

そして、ここまで書いたのですが、もしかするとAPIを使えば、強制的に停止というのもできるかも知れません。


「DB Exception」[編集]

「DELETE FROM async_job WHERE async_job.id= 6439」のように、Jobかが完了して削除を試みたけど消せなかったのような挙動のときに。

DBから手打ちすると、

mysql> DELETE FROM async_job WHERE async_job.id= 6439;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`cloud`.`async_job_join_map`, CONSTRAINT `fk_async_job_join_map__join_job_id` FOREIGN KEY (`join_job_id`) REFERENCES `async_job` (`id`))

のような感じに。外部キー制約がかかっているらしい。そのため、

DELETE FROM async_job_join_map where join_job_id=6439;

で消してから実行する。大抵何件か溜まっているので、ログを観察し続ける。

構築者向け[編集]

もう本当にダメなとき。

NICの順番に注意[編集]

  • あるホストで「cloudbr0:ゲスト」「cloudbr1:ストレージ」…とかしたらそれで統一
  • 物理NICも「eth0はcloudbr0に接続…」としたら統一。ゲストVLANと紐付くNICが統一されない。

QinQ[編集]

  • IEEE802.1q Tunneling
  • VLANの中でVLANを使う
  • CloudStack専用にスイッチが用意できるのであれば、VLAN対応スイッチだけで良い(基本NWならVLAN未対応でも何でも良い)
  • 知らないプロトコルを知らない機器で使う
  • PICA8辛かった
  • 魂のある温もりのこもったコマンド「set interface gigabit-ethernet te-1/1/29 family ethernet-switching dot1q-tunneling mode external」
  • 10GbEなのに「gigabit-ethernet」とはこれいかに
  • なお、QinQしないと、VM作っても、「localhost」になってしまう
  • DHCPも当然無理。