2020-08-10

zabbix5.0でDockerの監視メモ

セットアップ

zabbixでDockerを監視するには、zabbix_agent2が必要なので、以下のドキュメントに記載されているOSをを利用すること。

www.zabbix.com

zabbix serverのセットアップは以下に沿う。
agent2は、パッケージのセットアップまでは一緒で、インストールするパッケージが、zabbix_agent2だけで良い。

www.zabbix.com

Dockerを監視する

以下の通り、 Template App Docker があるので、監視対象のhostに、Template App Docker を紐付けたら良い。
(なければ、zabbixのリポジトリからxmlが拾ってこれる。) Templateを紐付けたのに監視が開始できないときは、監視対象のOS上で、zabbix agentを動かしているユーザーをdocker groupに所属させると良いはず。また監視できる項目についても、以下のURLに詳細が記載されている。

www.zabbix.com

動作確認について

監視対象のホストで以下のコマンドを叩く

zabbix_agent2 -t docker.ping -c /etc/zabbix/zabbix_agent2.conf

zabbix server が稼働するホストで以下のコマンドを叩く
(こちらがうまく行かないケースならば、監視対象のホストでzabbix agentを動かしているユーザーをdocker groupに所属させると良いはず。)

zabbix_get -s ${target_ip} -k docker.info

2020-07-25

ESXi 6.7 以降の vmxnet3 を利用している仮想マシンの上でTrexを動かす

要は、Trexが依存しているライブラリ等のバージョン問題の話なので、TrexがDPDK20.05を取り込んだら賞味期限切れの記事になります。

TrexというOSSのトラフィックジェネレータがあります。

https://trex-tgn.cisco.com/

これの動作確認を試そうと思いましたが、ESXi 6.7 以降のvmxnet3では、2020/07/25時点でのlatestのTrex (v2.82) では動作しなかったので、動かせるようにするための記事です。

ESXi 6.7 以降の vmxnet3 を利用している仮想マシンの上でTrexなぜ動かないのか？

バージョンを記載しておくと、自分の手元の環境では、ESXi 7.0, Trex 2.82 の組み合わせで動いてません。

Trexというのは、DPDK を利用しています。このDPDKはDPDKに対応しているNICのドライバを持っています。

今日時点でのTrexはv2.82, Trexがベースとして利用しているDPDKのバージョンは20.02です。 DPDKの最新版は20.05みたいです。

vmxnet3 というのはESXiを利用しているとおなじみの仮想NICです。 vSphere 6.7 で vmxnet3 v4 というのがリリースされています。 (なので、記事のタイトルはESXi 6.7以降と書いています。)

問題点としては、(おそらく) DPDKがvmxnet3 v4 対応してからこのコミット (2020/03/08に取り込まれているので、多分DPDK20.05に入っている修正) までDPDK側にバグがあり、 DPDKが用意するドライバとNICを紐付けることができませんでした。

Trexのフォーラムなどでも投稿されていますが以下のようなメッセージが発生し、Trexが起動しません。

./t-rex-64 -i
...
vmxnet3_v4_rss_configure(): Set RSS fields (v4) failed: 1
vmxnet3_dev_start(): Failed to configure v4 RSS
vmxnet3_dev_start(): Device activation: UNSUCCESSFUL

修正方法

github.com

要は、上記のcommitをTrexに適用して、ビルドできればOKです。

Trexのビルド方法はwikiに記載があるのでソレに従います。なるべく新し目のgccと、依存ライブラリをインストールしたうえで作業すると良いと思います。

github.com

$ mkdir /opt
$ cd /opt
$ git clone https://github.com/DPDK/dpdk.git
$ cd dpdk
$ git checkout 52ec00fd1474e8f99f3da705b7efe95ba994b352
$ git clone https://github.com/cisco-system-traffic-generator/trex-core.git -b v2.82
$ cd trex-core
$ \cp -fa ../dpdk/drivers/net/vmxnet3 src/dpdk/drivers/net/
$ cd linux_dpdk
$ ./b configure
$ ./b build
$ cd ../linux
$ ./b configure
$ ./b build

ビルドできたら

ビルドに成功したら、 trex-core ディレクトリ配下にscriptsというディレクトリができると思います。scripts配下ではリリースされたものと同じようなことができます。

$ cd /opt/trex-core/scripts
$ ./t-rex-64 -i

T-Rex自体の動作確認などは、以下のページなどを参考に動作確認を実施してみると良いと思います。

foobaron.hatenablog.com

2020-07-24

私的 homelab向け vSphere 7.0 アップグレードメモ

VMware

ESXi 6.7 -> ESXi 7.0 にアップグレードしたのでそのメモ

次 ESXi 7.x にアップグレードする際に自分が参照する用

あくまでhomelab向けの話なので、プロダクションに適用する際はこの記載を信用しないこと。

homelabの大まかな構成

vSphereの観点でhomelabの構成を軽く書いておく

vCenter
- 6.7
- vSANクラスタを構成している
データストア
- NFS 1台
- vSAN
ESXi
- 6.7
- 3台
物理ホスト構成
- ベース
  - NUC6i3SYH
- NIC
  - 組み込みのnicが1つ
  - USB NICが2つ
- ディスク
  - usbメモリ 32GB
    - boot drive
  - NVMe
  - HDD

アップグレードの流れ

vCenterをアップグレードしてから、ESXiをアップグレード

アップグレードしたいバージョンを決める
アップグレードパスが問題ないか軽く見とく
- VMware Product Interoperability Matrices
USB Network Native Driver for ESXi がアップグレード先のバージョン対応をリリースしているか確かめる
- 未対応なら諦める

vCenter アップグレード

vCをアップグレードすること自体はだいたい1~2時間程度で終わる (インストーラーが動く環境を手に入れるのに時間がかかった)

ESXi/vCenterのisoを手に入れておく
vCenterのインストーラーが動く環境を用意する
- isoをマウントするとGUIのインストーラーのバイナリがあるのでソレを実行する
- インストーラーはLinuxでも動くが、UbuntuやCentOSなどメジャーなディストリを想定している
- 自分はUbuntu GUI+RDPの環境を用意した
vCenter をアップグレードする
- 6.7 -> 7.0 は以下の問題を踏んだ程度だった。
  - vswitchzero.com
- 要件的にはTinyでも良いのだが、検証の快適さを求めてsmallにしている
  - docs.vmware.com

ESXi アップグレード

USBのboot driveを作成して利用する方法。こっちも方法を確立さえしてしまえば1台1h程度で作業が完了した。

モダンなやり方としては、LifeCycle Managerを利用する方法もあるが、ハードウェアコンパチビリティの無いhomelabという都合でLifeCycle Managerが正しく動作しなかった。 (アップグレードできたかのように見えるが、ESXiをrebootすると以前のバージョンに戻ってしまう問題に当たった)

以下を見て、ESXi7.0 のbootable usb を作る
- docs.vmware.com
(7.0へアップグレードするとき)
- 以下を読んで /bootbank の領域についての変更を把握しておく
- kwmtlog.blogspot.com
ESXiをアップグレードする
- メンテナンスモードに入れる
  - docs.vmware.com
  - アクセシビリティの確保を選ぶと良さそう
  - (vSANの何かに困っていてこのページに当たってしまった人向けに書いておきますが、困っていたらVMwareに聞いたほうが確実です。)
- 実際のアップグレード
  - boot driveにしたUSBを刺して、reboot
  - 自分の利用しているNUCだとF10を2回押すと, boot driveが選択できるようになる
  - ESXiのインストーラーを指定して起動する
- host clientにアクセスし、sshを有効化しておく
- USB NIC用のvibをインストールする
  - USB NICをscpなりで、esxiに持っていく
  - esxcli でオフラインバンドルとして、usb nic用vibをインストールする
アップグレードしたESXiを接続し、残りのホストをアップグレードする
- vSANクラスタを壊さないように、時間的余裕を持って取り組むこと

アップグレードが完了したら

vDSのアップグレードを実施しておくと良い
- NSX-T 検証などをする際に重要なポイントになるはず。

最後に

あくまでhomelab向けの話なので、プロダクションに適用する際はこの記載を信用しないこと。

2020-04-27

packerのvsphere-iso builder

VMware packer

VMwareのvSphere環境で, isoから仮想マシンのイメージを作成するための自動化ツールとして、Packerが挙げられます。

そのPackerでも内部的にはbuilderという形でいくつかの選択肢があり、VMware製品環境ではvmware-isoというのをよく使っていたのですが、vsphere-isoというのがあることに最近気づきました。

詳細はここ

ちなみに開発元はJetBrainsらしいです。JetBrains最高だな...

vsphere-iso buildrの注意点

2020/04/27時点でissueを上げるべきなのは https://github.com/hashicorp/packer
- もともとプラグインとして開発されていたvsphere-isoのbuilderはPakcer 1.5.2 ~ 本家リポジトリにマージされたため
ただし、開発元のJetBrainsのほうにも100程度のissueが残されているので、わからないことがあったらそっちも覗くと良い
- https://github.com/jetbrains-infra/packer-builder-vsphere

vsphere-iso builder の良い点

vmware-isoでは必須だったGuestIPHackの有効化が不要になっている
- GuestIPHack はVMのビルドに使うESXiごとに設定する必要のある項目
- 共用の検証環境でこっそりGuestIPHackを有効にするなどは微妙だと思っていたので良い改善点
vCenter配下のクラスタ指定でVMをビルドできるようになった
- ホストに特定の設定が入っているか？を気にする必要がなくなった恩恵だと思います。
- (手元で検証している限り、クラスタ内に存在するホストを指定しないと動かないのですが、クラスタを指定するとホストの指定を無視するような振る舞いをしてます。 )
VM起動後の操作にVNCを使わなくなった？
- vmware-isoのときは、コンソールへの操作にvncを使っていた記憶があります
- vsphere-isoにはvncの設定がなくなったのでweb API経由での操作に切り替わったかもしれないです。
サンプルが豊富
- https://github.com/jetbrains-infra/packer-builder-vsphere/tree/master/examples
- 大概のビルドの設定はここのサンプルにあるので悩んだら眺めると良い

ぱっとVMをビルドしてみた限りでは、vsphere-iso builderはvmware-iso builderの不便な点を解消したものになっているので、新規でvSphere環境でisoからVMの作成を自動化したい場合は、vsphere-iso builderを使うと良いと思います。

2020-04-27

私的Nixosアップデートメモ 20.03

nixos

nixos を 19.09 -> 20.03 にアップデートしたのでメモ書き

20.03 のコードネームは Markhor で、面白い角を持った動物だった。

リリースノートはこれ

NixOSのアップデート

チャンネルの変更
- sudo nix-channel --add https://nixos.org/channels/nixos-20.03 nixos
- sudo nix-channel --update nixos
システムパッケージのアップデート
- sudo nixos-rebuild switch --upgrade
ユーザーパッケージのアップデート
- nix-env --upgrade

アップデート後の対処

KDE5を使っている環境でアプデ後にいくつかアプリが駄目になるのが頻発するのでメモ。

再インストール/アップデートはnoxコマンドを使えば良い。

なにはともあれやること
- glibcを再インストール/アップデートする
FirefoxなどでIMEの切り替えがおかしい
- fcitxとfcitx-mozcを再インストール/アップデートする
Terminator でIMEの切り替えがうまく行かない
- terminator を再インストール/アップデートする
Albertの背景透過がうまく行かない/起動しなくなる
- albertを再インストール/アップデートする
- ハードウェアの設定 -> ディスプレイとモニタ -> Compositor -> コンポジターの起動を有効にするにチェックを入れる

2020-04-13

VMRCをdockerコンテナに詰めてLinuxから使う

VMware Docker

自分は普段、NixOS というOSがインストールされたLaptopを使っている。

で、VMwareの製品はたいていUbuntuやRHELをサポートしていて、当然NixOSはサポートに入っていない。

なので、NixOSからVMware製品がインストールされたUbuntuのコンテナを起動して使うことになる。任意のディストリにVMware製品をインストールするのもできると思うが、多分Ubuntuコンテナに詰めるほうが楽だと思う。

VMRC をコンテナに詰める

VMRCは、vSphereで作成したVMのコンソールにアクセスできるアプリケーションで、 web版もあるけど、諸事情によりwebではない方を使えるようにしておきたい。

出来上がったのがこちら。以下のDockerfile とmyvmwareからダウンロードしてきたVMRCのインストーラーを使ってビルドしたら出来上がる。

gist.github.com

$ ls -1
Dockerfile
VMware-Remote-Console-11.1.0-15913118.x86_64.bundle*
$ docker build . -t vmrc:latest

使いかた

docker上で起動したfirefoxをホスト側で操作する - takapiのブログ

上記の方のコマンドを参考に、以下のような感じでrunするとOK

# 実行前にxhostを忘れない。
docker run -it --privileged=true --net=host --rm -e 'DISPLAY=:0' -v /tmp/.X11-unix/:/tmp/.X11-unix/ vmrc:latest 'vmrc://${host}/?moid=${moid}'

これで最低限、vmrcが動くようになるはず。

2019-11-30

GUIを触らずにvSphereを操作するためのgovcレシピ

VMware govc

この記事はFJCT アドベントカレンダー 2019の初日の記事です。

明日は @zombeanさんの FJCTで知ったもの、身についたものいろいろ書こうと思います となります。

さて。本日はニフクラの運用メンバーらしくvSphere周りとして、GUIを触らずにvSphereを操作するためのgovcレシピをいくつか書き残します。本記事のターゲットはgovcを触ったことがある程度の人です。触れない人はこの記事の前半として、GUIを触らずにvSphereを操作するためのgovc入門とtips を書いたので読んでほしいです。

2019年に利用したgovcコマンドの備忘録的な側面が強いので、網羅性はありませんし、普段govcを使っている人にとって目新しいことは無いですが書いていきます。

以下は別解答が多数あると思われます。 (もとイケてる方法があるじゃん！と思った場合一緒にIaaSを作りましょう！！！)

複数の操作対象があるパターン

ケースにもよると思いますが以下のようなことをすることが多いです。

govc find ${cond} | xargs govc ${operation}

VMの電源on, off

VMの電源on, off自体は govc vm.power でできるのだけど。使いそうなオプションとしていくつかあり、 -offでパワーオフ, -onでパワーオン、-s でシャットダウン、-wait で電源の上げ下げのタスク完了を待つなどのオプションがついている。 -M オプションは複数のVMを一度に電源on できるオプション

以下は電源を上げるケース

govc find . -type m -name "${VM-NAME}" | xargs govc vm.power -on -M=true

以下はシャットダウンのケース

govc find . -type m -name "${VM-NAME}" | xargs govc vm.power -s -wait=false

VMのデバイス情報を引く

VMのデバイスの情報はgovc vm.info でも引けるが、 device.info を利用するほうが良い。

govc device.info -json -vm `govc find -type m  -name="${VM-NAME}"` | jq .

以下は vm.info のときのjson。DeviceのTypeがなくてどれがどのデバイスか？を機械的に判別するのが難しい。

        "Hardware": {
          "NumCPU": 1,
          "NumCoresPerSocket": 1,
          "MemoryMB": 32,
          "VirtualICH7MPresent": null,
          "VirtualSMCPresent": null,
          "Device": [
            {
              "Key": 200,
              "DeviceInfo": {
                "Label": "IDE 0",
                "Summary": "IDE 0"
              },
              "Backing": null,
              "Connectable": null,
              "SlotInfo": null,
              "ControllerKey": 0,
              "UnitNumber": null,
              "BusNumber": 0,
              "Device": null
            },

以下は device.info を引いたときのjson。DeviceのTypeがあるので機械的判別がしやすい。

{
  "Devices": [
    {
      "Name": "ide-200",
      "Type": "VirtualIDEController",
      "Key": 200,
      "DeviceInfo": {
        "Label": "IDE 0",
        "Summary": "IDE 0"
      },
      "Backing": null,
      "Connectable": null,
      "SlotInfo": null,
      "ControllerKey": 0,
      "UnitNumber": null,
      "BusNumber": 0,
      "Device": null
    },

あるホスト上の電源オン状態のVMのインベントリパス

ホスト名を調べておいた上で以下のコマンドを叩くと、あるホストの上にいるpowerdOnVMのインベントリパスがとれます。

govc find -i . -type h -name ${HOST-NAME} | xargs -Ih govc find . -type m -runtime.powerState poweredOn -runtime.host h

あるホスト上の電源オン状態のVMの情報収集

上のヤツに更にvm.infoをつなげるパターンです。更に vm.info -json を使ってjqで絞り込むパターンがあると思います。

govc find -i . -type h -name ${HOST-NAME} | xargs -Ih govc find . -type m -runtime.powerState poweredOn -runtime.host h | xargs govc vm.info

クラスタにあるESXiのリストを取得する

あるクラスタに所属するESXiを調べる方法はいくつかあるのですが、これが一番簡単な気がします。これも host.info につなげる方法があるかな？と思います。

govc find . -type c -name ${ClusterName} | xargs govc ls -t HostSystem

データストアの残容量順に並べる

どのデータストアが一番残っているか？はたまに気にしたい事項だと思っていて、以下のような方法で引けます。

govc datastore.info -json | jq '.Datastores[].Info| [(.FreeSpace|tostring),.Name]  | join(" ")' -r | sort -n

あるデータストアを消費している順にVMを調べる

これの方法が見つけられていないのが残念

あるvCenter配下のデータストアのタイプ一覧

あまり無いと思うが、datastore.infoつながりで、こんな感じでvC配下のデータストアのタイプが調べられます。

govc datastore.info -json | jq '.Datastores[] | [.Info.Name, .Summary.Type] | @csv' -r

あるESXiのオプションを調べる方法

たまにESXi側の設定を一括で調べたいことがあり、以下のコマンドを gocv find . -i -type h と組み合わせて使うことがある。

govc host.option.ls --host=${InventoryPath} ${OptionName}

あるESXiのサービスを調べる方法

オプションと同じ要領で、サービスも調べられそう.

govc host.service.ls --host=${InventoryPath} ${OptionName}

あるESXiのvibのリストを調べる

govc host.info では見れなさそうなのでesxcliで直接叩きに行く

govc host.esxcli softoware vib list

アドベントカレンダーに向けて書けたのはここまでなのでまたgovcをパチパチと叩いたら追記します。

/var/log/study

つまり雑記

zabbix5.0でDockerの監視メモ

セットアップ

Dockerを監視する

動作確認について

ESXi 6.7 以降の vmxnet3 を利用している仮想マシンの上でTrexを動かす

要は、Trexが依存しているライブラリ等のバージョン問題の話なので、TrexがDPDK20.05を取り込んだら賞味期限切れの記事になります。

ESXi 6.7 以降の vmxnet3 を利用している仮想マシンの上でTrexなぜ動かないのか？

修正方法

ビルドできたら

私的 homelab向け vSphere 7.0 アップグレードメモ

homelabの大まかな構成

アップグレードの流れ

vCenter アップグレード

ESXi アップグレード

アップグレードが完了したら

最後に

packerのvsphere-iso builder

vsphere-iso buildrの注意点

vsphere-iso builder の良い点

私的Nixosアップデートメモ 20.03

NixOSのアップデート

アップデート後の対処

VMRCをdockerコンテナに詰めてLinuxから使う

VMRC をコンテナに詰める

使いかた

GUIを触らずにvSphereを操作するためのgovcレシピ

複数の操作対象があるパターン

VMの電源on, off

VMのデバイス情報を引く

あるホスト上の電源オン状態のVMのインベントリパス

あるホスト上の電源オン状態のVMの情報収集

クラスタにあるESXiのリストを取得する

データストアの残容量順に並べる

あるデータストアを消費している順にVMを調べる

あるvCenter配下のデータストアのタイプ一覧

あるESXiのオプションを調べる方法

あるESXiのサービスを調べる方法

あるESXiのvibのリストを調べる