/var/log/study

つまり雑記

VMwareのデータセンター向け製品を個人で検証するためのTips

Intel NUC VMware

この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の3日目の記事です。 id:yaaamaaaguuu が記事を書き、職場の先輩である id:hidemium さんからフィードバックを受けて加筆修正したものになります。(hidemiumさんありがとうございました。)

2日目はdaprでつくるマイクロサービスでした。daprが便利そうなことが伝わってくる記事でした。自分も後日試してみたいと思っています。

皆様にとって、2020年はどのような年だったでしょうか？

個人的には VCP-NV と呼ばれるVMwareの資格を取得するために色々と取り組んだことが心に残っています。

資格試験のためだけではないですが、自宅にVMware製品を導入した検証環境を構築してVMware製品を検証することが多かったため、そのまとめとして、VMwareのデータセンター向け製品を個人で検証するためのTipsを紹介することで、個人で検証するためのハードルを下げることができたら良いと思っています。

目次

注意事項

あくまで検証用途です。本番環境で今回紹介するTipsを適用すると、本番環境でサポートされなくなる可能性のある手法も含みます。筆者宅の検証環境などで試していることが大半ではありますが、試す際はご自身の責任でお願いいたします。

とにかく手早く設定方法などを確認したい

VMwareが用意しているHands on Labを利用しましょう。

labs.hol.vmware.com

利用したい製品がデプロイされるHoLを起動し、用意してあるトレーニングのメニューを無視して、 自分の確認したいことをさっと確認してみる、というのは新しい製品で検証環境が十分でないときに有効な手段です。

とにかく物理で動くESXiを用意したい

ESXiはMyVMwareに登録したらisoをダウンロードできたと思うので、そちらを利用すると良いです。

ネットワークの構成や性能にかかわらず、物理のESXiを用意したい場合は、IntelのNUCを購入しESXiをインストールするのが良いと思います。なぜIntelのNUCを推すかというと、William Lam 氏のブログ https://www.virtuallyghetto.com で頻繁に推されていて、 動作確認がされていることが多いからです。もし将来的にvSANなどを検証したい場合は2.5インチベイがあるほうを選ぶと良いです。

NUCなどを利用していてPCIeなどで物理NICを拡張することができない場合や、適当なコンピュータのマザーボードのNICがESXiに対応していない場合はこちらのDriveを導入してUSB NICをつかうことになります。USB NICは製品によってサポートされるMTUの上限が異なるポイントに注意してください。(自分が複数購入したものは4500程度でした。)

個人的には試せていないのですが、 (1台あたりの価格が通常のNUCよりだいぶ高価ですが) Intel NUC9 extreme を利用するとNICの構成の問題を解消できると思います。

またx86にこだわらない場合、Raspberry piなどで試せるESXi Arm Editionなどが選択肢に入ってくると思います。

flings.vmware.com

物理ノードのリソースは、システム要件 (+お財布事情) に沿って用意していただくのが良いですが、vCenter,NSXの検証でCPUのリソースの実消費は比較的少ないのに対し、メモリの実消費は比較的多いことに注意する必要があります。

具体的な話をすると、筆者の検証環境は、core i3-6100U, 32GBのメモリのNUCが3台構成のところにvCenter/NSX-T Managerをデプロイ、HAとvSANを有効にしている状態で以下のようなリソース状況です。

f:id:yaaamaaaguuu:20201203034500p:plain

本番環境では互換性のある物理サーバーを用意してください。

物理環境でなくてもいいからESXiを用意したい

物理のマシンにESXiをインストールする以外に、ESXiを仮想マシンとして用意する方法があります。ネステッド もしくは ネスト と呼ばれています。物理のESXiの上にNested ESXiをデプロイして、Nested ESXiの上に仮想マシンをデプロイして色々試すことが可能です。試したことはないですが、VMware のWorkstationやFusionで動作させる方法もあるようです。

Nested ESXi を用意するには２つ手法があります。

  1. ESXiのisoを利用して仮想マシンにインストールする
  2. William Lam 氏が公開しているNested ESXiのovaを利用する

上記の2つの方法のうち、前者に取り組むことは勉強にはなりますが、用意するのに割と手間がかかります。Lam氏の公開しているNested ESXiのイメージが非常に実用的なため、そちらを利用するとよいでしょう。ただし、公開されているovaのハードウェアバージョンが比較的新しいため、 場合によっては自分でisoから用意する必要があります。

Nested ESXi を稼働させるにはいくつか気をつけたほうが良いことがあります。

  1. https://kb.vmware.com/s/article/2009916?lang=ja にも記載がある通り、 Nested ESXiはサポートされないので、本番環境で利用しない方がよいと思います。
  2. Nested ESXIに与えるCPUやメモリは、ESXiのシステム要件に準拠すると良いのですが、NSXを動作させるためのESXiとしてNestedを利用する場合は、8GBのメモリは与えたほうが無難です。
  3. Nested ESXiが接続する仮想スイッチの設定については Why is Promiscuous Mode & Forged Transmits required for Nested ESXi? を読むと良いです。
  4. Nested ESXiをクローンする前に、How to properly clone a Nested ESXi VM? を読むと良いです。

個人の検証環境にもvCenterやNSXを用意したい

あくまで個人向けの検証用途の話です。

VMUGのAdvantage のライセンスを利用するのが良いと思います。値段は$200/year (2年継続だと $180/yer, 3年継続だと $170/year)だそうです。

www.vmug.com

2020/12/02 だと、vCenter, NSX-v, NSX-T, vSAN, Tanzu などに加えて、
VMware FusionやWrokstationのProなどがダウンロードできるライセンスとなっています。

前述のNUCなどにESXiをインストールするか、Fusion/Workstationで各アプライアンスを起動して検証する形になると思います。

複数の物理マシンを用意してvSphere + NSX + α を動かしたい

各種vSphereやNSXの機能の利便性を実感するには、複数のESXiがある方が良いケースが多くあります。そして複数のESXiを用意して検証をするには最低限スイッチとNASではないかと考えています。

  • スイッチ
    • EdgeRouter Xをスイッチとして採用している話をよく伺います。
      • 多少高価ですが、DHCPやDNSの役割をもたせることができたり、VLANを解釈してくれたりと何かと便利です。
  • NAS
    • SynologyかQNAPのNASを採用している話をよく伺います。
    • vSphere のHA や vMotionを試すには必須です。

宅内検証環境の物理構成の詳細に言及し始めるとキリが無いので、この記事ではこの程度にとどめます。

vCenterをESXiにさっとデプロイしたい

vCenterをESXiにさっとデプロイするには、isoからGUIのインストーラーを起動するのが一般的ではあると思います。
ただ、vCenterをインストールする際のパラメーターは決まり切っているので、
検証の際に何度もいちいちGUIでパラメーターを埋めて...というのは面倒な気がします。

そんな時は、govc をつかって、vcsaのアプライアンスをデプロイすると良いです。

# iso をmountする, ディレクトリは適当
mount -t iso9660 VMware-VCSA-all.iso /mount_dir
# iso 内のvcsaのovaからインポート用の情報を生成する
govc import.spec /mount_dir/VMware-vCenter-Server-Appliance-xxxx_OVF10.ova | jq . > vcsa_import_spec.json

# vcsa_import_spec.json を適切に編集する
# guestinfo.cis.deployment.autoconfig = "True" にすると、
# vcsaを起動後にパラメーターに沿って自動的に設定してくれます。
# https://www.virtuallyghetto.com/2016/10/how-to-deploy-the-vcenter-server-appliance-vcsa-6-5-running-on-vmware-fusion-workstation.html が参考です。

# import.ova には適当にデータストアやデプロイ先を指定するオプションが必要です。
govc import.ova -options=vcsa_import_spec.json /mount_dir/VMware-vCenter-Server-Appliance-xxxx_OVF10.ova

こちらの方法はVMwareのドキュメントに記載があるものではないので、あくまでデプロイを簡易にする非公式手順であることに留意してほしいです。

NSX Managerが起動できない もしくは NSX Managerを起動するとほかのVMが起動できない状況に対処する

NSX-T Managerもovaをデプロイ直後はメモリのリソースの予約 (手元の環境で見ると16GBのメモリ) が入っています。検証環境のリソース状況によっては、NSX Managerが起動できないケースや、NSX Managerが起動できても他のVMが起動できなくなるなどが考えられます。

リソース不足起因のトラブルを踏まないようにするためには、検証環境のリソースを増強するのが良いのですが、暫定的にはNSX Managerのメモリの予約を外してしまうことでNSX Managerや他のVMが起動できなくなることを回避できます。

商用の環境でNSX-T Managerのリソースは予約は外さないでください。

NSX-T のマネージャーでスナップショットをとりたい

NSX-T Managerはスナップショットをサポートしていません。そのためにアプライアンスでスナップショットを無効にする方法 がドキュメントに記載されています。またNSX-T 3.0.1 以降ではスナップショットが取れなくなるための設定が予め入っています。

しかし、個人の検証レベルではサポートを受けられるか否かよりも、例えばテキトウにスナップショットを取ってアップデートを実施してみるなどの気軽さのほうが大事な気がします。ということで、ドキュメントに書いてあることに逆らうことにはなりますが、仮想マシン オプションから snapshot.MaxSnapshots を必要に応じて編集すると良いと思います。

まとめ

VMwareのデータセンター向け製品を個人で検証するためのTipsを記載しました。何かの参考になれば嬉しいです。

今回のTipsは個人向けということで、ドキュメントの互換性や手順などを、思いっきり無視しているモノとなります。
間違っても商用の環境で試すなどはしないでください。

この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の3日目の記事でした。

明日の4日目はGit Hooksでうっかりミスを防ぎたいだそうです。gitのhookは非常に便利なのでどのような記事が投稿されるのか楽しみですね。

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

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

DPDK Trex ESXi VMware

要は、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

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

VMware

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

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

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

homelabの大まかな構成

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

  • vCenter
  • データストア
    • NFS 1台
    • vSAN
  • ESXi
    • 6.7
    • 3台
  • 物理ホスト構成
    • ベース
      • NUC6i3SYH
    • NIC
      • 組み込みのnicが1つ
      • USB NICが2つ
    • ディスク

アップグレードの流れ

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

vCenter アップグレード

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

  • ESXi/vCenterのisoを手に入れておく
  • vCenterのインストーラーが動く環境を用意する
  • vCenter をアップグレードする
    • 6.7 -> 7.0 は以下の問題を踏んだ程度だった。
    • 要件的にはTinyでも良いのだが、検証の快適さを求めてsmallにしている

ESXi アップグレード

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

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

  • 以下を見て、ESXi7.0 のbootable usb を作る
  • (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向けの話なので、プロダクションに適用する際はこの記載を信用しないこと。

packerのvsphere-iso builder

VMware packer

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

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

詳細はここ

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

vsphere-iso buildrの注意点

vsphere-iso builder の良い点

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

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

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

nixos

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

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

リリースノートはこれ

NixOSのアップデート

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

アップデート後の対処

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

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

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

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が動くようになるはず。