Skip to main content

VCF Lab Constructor(VLC)でネステッドな VMware Cloud Foundation 4.0 環境を気軽に作る


はじめに

VMware Cloud Foundation(VCF)という、SDDC Manager で SDDC 環境全体をイイ感じに管理できる製品があり、これを(ハンズオンラボでなく)自宅で触りたくなりました。ただの趣味というか興味です。

しかし VCF は、お行儀のよい SDDC 環境をしっかりした規模で作るための製品なので、自前で構築しようと思えば、たとえ最小構成でも、256 GB のメモリと 10 TB 超の SSD と 2 つの 10 GbE の NIC を積んだサーバを 4 台用意しないといけません。また、上位ネットワークとは BGP で会話できないといけないですし、DNS サーバや DHCP サーバなど周辺にもいろいろ必要です。さらにはネットワーク構成の詳細やさまざまなオブジェクトの命名など ワークブック の 400 ちかいパラメータを決定する必要もあります。

要するに、自宅で気軽に触れる程度のものでは到底ないわけです。ネステッドで作ればハードウェア面はある程度ごまかせはするものの、周辺サーバの用意やパラメータの決定は、ちょっと触れればいいとほんのり思っているくらいのモチベーションではしんどいものがあります。

とはいえ、海外のさかんな自宅ラボ事情を考えると、自宅で触りたい勢は世界のどこかには存在しているはずで、そう思っていろいろ調べていると、VCF Lab Constructor(VLC)なるものの存在を知りました。このエントリでは、これを使ってネステッドな VCF を構築するまでの流れを紹介します。

VCF Lab Constructor(VLC)

概要

VCF Lab Constructor(VLC)は、VCF をネステッド環境で簡単に構築できるようにいろいろお膳立てをしてくれるツールです。詳しくは VMware のブログで紹介されています。

引用元: Deep dive into VMware Cloud Foundation – Part 1 Building a Nested Lab

具体的には、VLC 経由でデプロイすることで、

  • 値が全部埋まったサンプルのパラメータ(JSON)が提供されていて、ただ動けばよいレベルであればそのまま使える
  • Cloud Builder アプライアンスをパラメータに従って自動でデプロイしてくれる
  • デプロイした Cloud Builder アプライアンスの中に、DNS サーバや BGP ルータなど、必須の周辺サーバの機能を無理やり同居させてくれる
  • パラメータに従って vSAN の構成要件を満たした ESXi を ESXi 上の仮想マシンとしてデプロイしてくれる
  • (指定すれば)Cloud Builder での Bring-Up プロセスも開始してくれる

などのメリットが得られます。これによって、VCF に必要な Cloud Builder と ESXi 環境がサクッと整うため、気軽に VCF を試す環境を得るためのハードルが一気に下がるわけです。

引用元: Deep dive into VMware Cloud Foundation – Part 1 Building a Nested Lab

もちろん公式にサポートはされていませんが、開発は VMware のなかのひとであり、また Slack のコミュニティもあって、それなりにワイワイしています。

準備

VLC のダウンロード URL は、次の URL から登録することで得られます。

ここで得られる URL は最新版のダウンロード用ですが、過去のバージョン用の URL は Slack でピン止めされたメッセージでリストされています。

なお、VCF のバイナリ(Cloud Builder の OVA イメージ)と、VCF を構成する各製品(vCenter Server、ESXi、vSAN、NSX-T)のライセンスキーは別途必要です。ぼくは VMUG Advantage なヒトなのでそれで入手しています。

ハードウェア要件

VLC にはインストールガイドも付属しており、それによると、現在のバージョンでは、

  • 1 台の ESXi(6.7 以降)
    • 128 GB 以上のメモリ
    • 800 GB 以上の SSD

が最低要件とされています。本来の VCF のハードウェア要件からは圧倒的に小さいですが、それでもそこそこのモノは必要ですね。

今回の環境

といいつつ、残念ながら上記の要件を満たせるハードウェアが自宅にないので、以下の環境で踏ん張ることにしました。

  • 1 台の vCenter Server で管理される 2 台の ESXi 7.0
    • 各 32 GB のメモリ(2 台の合計で 64 GB)
    • 各 512 GB の SSD(2 台の合計で 1 TB)
    • 共有ストレージなし

どうにかして処理を 2 台で分散させることにしてディスク容量を確保し、メモリの不足については、パフォーマンスを犠牲にしてオーバコミットをさせまくる前提にします。

手順

細かい手順や注意事項は付属のガイドや Slack のピン止めされたメッセージで案内されているので、ここでは概略だけ紹介します。

環境の準備

VLC に付属のガイドに従って、環境を整えます。

母艦となる物理 ESXi 側では、vDS で MTU を 9,000 にして、トランクモードのポートグループをひとつ作りました。このポートグループに仮想 ESXi と Cloud Buider が接続され、VCF 関連のすべてのパケットが(VLAN のタグ付きで)流れることになります。ポートグループのセキュリティ設定は、プロミスキャスモードなどもすべて承諾しています。

また、今回は二台の ESXi で無理やり分散させるため、vDS のアップリンクもトランクにして、上位にちょっといいスイッチをつなぐことで、ESXi 間で 9,000 バイトのジャンボフレームも VLAN もそのまま流せるようにしています。

作業端末となる Windows 10(ドキュメントや図で触れられている Jump Host)は、仮想マシンではなく、普段使いの Windows 10 をそのまま使うことにしました。積んでいる Intel の物理 NIC が VLAN を喋れたので、サブインタフェイスを作って VLAN ID や IP アドレスをガイドと同等に構成しています。

パラメータの用意

VCF の最新は 4.0.1 ですが、VMUG Advantage でダウンロードできる VCF が 4.0 だったので、VLC も 4.0 をダウンロードしました。

バンドルされている JSON は二つありますが、今回は NO_AVN を使います。AVN(Application Virtual Network)については こちらのエントリで説明 されています。

  • AUTOMATED_AVN_VCF_VLAN_10-13_NOLIC_v4.json
  • AUTOMATED_NO_AVN_VCF_VLAN_10-13_NOLIC_v4.json

この JSON ファイルは、VLC が Cloud Builder や仮想 ESXi をデプロイするときのパラメータになるだけでなく、Cloud Builder がマネジメントドメインをデプロイするときの Bring-Up プロセスのパラメータとしてもそのまま使えます。

この段階で、JSON ファイル中の以下の箇所に、ライセンスキーを埋め込んで上書きしておきます。

{
  ...
  "esxLicense": "<Insert ESXi License>",
  ...
  "vCenterSpecs": [
    {
      ...
      "licenseFile": "<Insert vCenter License>",
      ...
    }
  ],
  "vsanSpecs":[
    {
      ...
      "licenseFile": "<Insert vSAN License>",
      ...
    }
  ],
  "nsxtSpec":
  {
    ...
    "nsxtLicense": "<Insert NSX License>",
    ...
  },
  ...
}

VLC の起動と設定

VLCGui.ps1 を PowerShell で実行すると、進捗表示とログ表示用の PowerShell ウィンドウと、操作用の GUI が起動します。

DNS サーバなど、必要な周辺サービス含めて VLC でデプロイする場合は Automated を、自前で用意しているものを使わせる場合は Manual を選択します。今回は全部オマカセしてしまうので、Automated です。

VCF EMS JSON に先に用意した JSON ファイルを、CB OVA Location に Cloud Builder の OVA ファイルをそれぞれ指定します。右側にはデプロイ先の vCenter Server か ESXi の認証情報を入力して、Connect を押下し、目的の構成を選択状態にします。

Bring-Up プロセスまで続けて実行させてしまう場合は Do Bringup? にチェックを、Cloud Builder と仮想 ESXi のデプロイまでで終える(その先は本来の VCF の構築手順に従って自分でやる)場合はチェックを外します。今回は、小細工もしたいのでチェックを外します。Bring-Up プロセスの詳細を知りたいなどお勉強目的の場合も、チェックを外した方があとあとわかりやすいでしょう。

この後、Validate を押下するとバリデーションが走り、問題なければ Construct! が押下できるようになります。

このバリデーションで、データストアの空き容量もチェックされます。選択したデータストアに 800 GB の空きがないと怒られてしまうので、今回は VLCGui.ps1 のバリデーションの条件文をちょろまかして強引に進めました。

Construct! を押下して走り出してしまえば、あとは待つだけです。Do Bringup? にチェックを入れていた場合は、このまま VCF のマネジメントドメインが完成して SDDC Manager が使える状態になるまで、ひたすら放置すれば勝手に進みます。典型的には 3.5 時間とされていますが、遅い環境だと 9 時間程度かかる例もあるようです(数字だけ見ると長いですが、ほんとうに放置するだけなので、手作業で作るよりは比較にならないほど楽ですね……)。

Do Bringup? にチェックを入れていない場合は、Cloud Builder のデプロイと仮想 ESXi の構成だけなので、数十分程度で終わるでしょう。

Cloud Builder と仮想 ESXi の完成

本来は Cloud Builder のデプロイだけでも手作業 ですが、VLC では OVF Tools を使ってパラメータを流し込んでいるようです。画面を眺めていると、そうして Cloud Builder がデプロイされて構成されたあと、GoBGP や MaraDNS などを使って Cloud Builder に周辺サービス群がねじこまれていく様子が見えます。

Cloud Builder 関係の作業が終わると、4 台の仮想 ESXi の作成が始まり、そして終わります。ESXi も、本来であれば VIA などを使って手作り する必要があった作業です。ラクですね。

今回のように Do Bringup? にチェックを入れなかった場合は、VLC の出番はここで終わりです。

デプロイ先の状態を見ると、Cloud Builder の仮想マシンと、仮想 ESXi が並んでいる様子がわかります。

今回は、VLC でデプロイ先をローカルデータストアにした影響で、Cloud Builder も仮想 ESXi も物理的に同じ ESXi に載ってしまっています。物理リソースが潤沢であればそれで全く問題はありませんが、今回はそうではないので、この段階で 4 台のうち 2 台の仮想 ESXi をもう一方の物理 ESXi に移行して、コンピュートとストレージの負荷分散をはかりました。

VCF の Bring-Up プロセスの実行

VCF の初期構築作業の肝(とぼくが勝手に思っている部分)が、この Bring-Up プロセス です。構成さえ事前に決めれば、vCenter Server も vSAN も NSX-T も SDDC Manager も全自動で仕上げてくれる、VCF によるライフサイクル管理のメリットの一端が垣間見える部分です。

付属の JSON を使った場合は、この段階でホスト名 CB-01a.vcf.sddc.lab で Cloud Builder にアクセスできるようになっているはずです。ログインして、EULA を確認して進めます。

VxRail ではないのでそのまま次へ。

環境要件が表示されます。いろいろありますが、事前準備と VLC によって充足されているか、充足できていなくても無視できる程度にはなっているはずです。

続行するとパラメータを設定するパートに入ります。本来は、ここか VMware の Web サイトからワークブックをダウンロードして、値を埋め、再度ここにアップロードして進めるものですが、VLC の実行時に利用した JSON がここでそのまま使えます。

つまり、今回は、ワークブックを埋めなくてもよく、JSON をアップロードすれば進めます。

バリデーションが開始されます。いくつか警告が出ますが、警告であれば確認の上で Acknowledge で了承して進められます。

続行すると、楽しい構築の始まりです。

あとは、表示されている大量のタスク(スクロールバー参照)が全自動でごりごり進んでいくのを眺めているだけで終わりです。壮観ですね。

VLC で Do Bringup? にチェックを入れていた場合は、VLC が Cloud Builder の API 経由でこの Bring-Up プロセスをキックすることになり、その結果、最初から最後まで VLC だけで透過的に全自動、な見え方になります。

Bring-Up プロセスは、早くて数時間、遅いと半日程度はかかると思います。放置してもよいですが、タスクの中身を見たりデプロイ先の各管理画面に直接入って過程を観察したりするとたいへんおもしろく、かつお勉強になり、これを手でやれといわれたら死んでしまう感じです。

すべてのタスクが Success になって走り切ったら、完成です。

トラブルシュート

Bring-Up プロセスのどこかでエラーが起きたときは、エラーメッセージに加えて、それぞれの管理画面やログファイルを直接のぞくと調べやすくなります。付属の JSON を使った場合は、

  • Cloud Builder: CB-01a.vcf.sddc.lab
  • ESXi: esxi-[1-4].vcf.sddc.lab
  • vCenter Server: vcenter-mgmt.vcf.sddc.lab
  • NSX-T Manager: nsx-mgmt.vcf.sddc.lab
  • SDDC Manager: sddc-manager.vcf.sddc.lab

あたりです。認証情報は JSON に含まれています。

なお、今回のように物理リソースが貧弱な場合は、たまに単なる高負荷で失敗することもあるようです。ネステッド環境内で DRS による vMotion がキックされることもあり、それが負荷に拍車をかけている場合もあります。

このようなとき、単純なリトライで成功する場合もありますが、状況によってはネステッド環境内の DRS のモードを変更したり、リトライ前に手動で vMotion するなどして(物理ホストレイヤでの)負荷の平準化をはかるとよさそうです。VCF 的には DRS はもりもり動かすべきですが、リソースに余裕はないので仕方なしです……。

このほか、VLC のガイド内にもヒントがいろいろありますし、Slack にも情報がたまっています。

VCF の管理と拡張

Bring-Up プロセスが無事に完了したら、SDDC Manager が利用できるようになっているはずです。付属の JSON では、sddc-manager.vcf.sddc.lab です。

ネステッド環境の vCenter Server に入れば、マネジメントドメインの構成も探索できます。

NSX-T の管理画面も触れますね。

現時点でできているのはマネジメントドメインだけなので、本来はここからさらにワークロードドメインを追加構築したり、vRealize Suite をデプロイしたり、VCF 4.0 であれば vSphere with Kubernetes を使ったワークロード管理機能を有効化したり、ネットワークをうにゃうにゃしたり、それっぽいことをいろいろやっていくわけです。

なお、ネステッド環境を拡張したい場合は、VLC の Extension Pack! から、空の ESXi を追加構築できます。追加に必要な JSON も付属しています。

まとめ

VCF Lab Constructor を使って、自宅のラボ環境に、ネステッドな VMware Cloud Foundation 4.0(VCF 4.0)を構築し、その過程を体験・観察しました。

あたかもサクサク成功させたかのように書いていますが、実際は何度かの失敗のあとにたどりついています。

  • 単一の ESXi(32 GB のメモリ、512 GB の SSD)のみを使ってデプロイしようとしたら、データストアがあふれて失敗
  • 単一の ESXi(32 GB のメモリ)と外付けの NFS データストア(2 TB の HDD)を使ってデプロイしようとしたら、処理が遅すぎて NSX-T Manager のデプロイから進めず失敗
  • 二台の ESXi(各 32 GB のメモリ)と外付けの共有 NFS データストア(2 TB の HDD)を使ってデプロイしようとしても、NSX-T Manager のデプロイから進めず失敗

要するに、潤沢なリソースはとにかく正義です。富豪的解決はだいじです。動けばいいや、と割り切るにも限度はあり、こういう無茶をしてもまともに動く環境は得られません。

最終的には本エントリで紹介したように 2 台にうまく分散させることで Bring-Up までは成功しましたが、重すぎてほぼ使い物にならないのが正直な現実でした。

とはいえ、構築プロセス(の一部)を体験できるという意味で、知的好奇心の充足には非常に有効であり、いろいろ見えておもしろかったです。満足しました。

もちろん、構築そのものが高度に自動化されているからといって、設計も同じ程度に楽かといえば当然そんなことはまったくないでしょうし、それどころかむしろ設計、とくに周辺サービス群とのインタラクションとパラメータの具体化、そして長期的な運用プロセスの定義こそがキモな気もするわけで、過度な期待はせずに、できるだけ誠実に向き合っていきたいものですね。


vSphere Lifecycle Manager (vLCM) で ESXi を 6.7 から 7.0 にアップグレードして管理する


はじめに

前回のエントリ で、vSphere 6.7 の環境のうち、vCenter Server を 7.0 にアップグレードして、最新のパッチの適用も行いました。このエントリでは、ESXi を 7.0 にアップグレードし、パッチの適用も行います。

ESXi 6.7 から 7.0 へのアップグレード方法は、ドキュメントでも提示されている とおりにいくつかありますが、今回は、vSphere 7.0 からの新機能である、vSphere Lifecycle Manager(vLCM)を利用します。パッチの適用も vLCM を利用します。

対象の ESXi は、Intel の NUC(NUC8i5BEK)にインストールされています。VMware 的には非サポート(HCL に載っていない)ですが、気にせずできる範囲でやっていきます。

vSphere Lifecycle Manager

これまでも、vSphere 環境のライフサイクル管理の目的で、vSphere Update Manager(VUM)と呼ばれるツールが存在していました。vSphere 7.0 からは、これが vSphere Lifecycle Manager(vLCM)に置き換わっています。

VUM も vLCM も、vSphere 環境のバージョンやパッチの適用状態に任意の基準を決めて、実環境のその基準からの逸脱を確認し、基準に準拠させる修正作業も実行できる、というざっくりした説明の限りでは大きな違いはありませんが、その基準の考え方に、従来どおりの『ベースライン』に加えて、『イメージ』という概念が新しく登場しています。この『イメージ』こそが vLCM の大きな特徴なようです。

考え方

これまでの『ベースライン』による管理では、例えば、ある特定のパッチの適用状態を管理できた一方で、そのパッチ以外のパッケージ構成やバージョンについては、何ら関知しませんでした。つまり、同じベースラインを複数のホストに添付して管理したとしても、その全ホストのパッケージ構成が完全に一致していることは保証できませんでした。

これに対し、vLCM で新しく登場した『イメージ』では、

  • ベースイメージ
    • VMware がバージョンごとにリリースする ESXi そのもので、ブート可能で完全な状態を構成するコンポーネントの集まり
  • ベンダアドオン(任意)
    • OEM ベンダが提供する追加のドライバやパッチ、追加機能など
  • ファームウェアやドライバアドオン(任意)
    • ハードウェアベンダが提供するファームウェアやドライバなど
  • コンポーネント(任意)
    • サードパーティ製の追加ドライバや追加機能など

をまとめて管理するようです。つまり、ESXi を構成する全コンポーネントのあるべき状態(Desired State)を(任意でファームウェアまで含めて)宣言的に『イメージ』として定義できます。イマドキな考え方ですね。詳しくはドキュメントに書いてあります。

vLCM では、従来通りの『ベースライン』による管理と『イメージ』による管理のいずれも利用できますが、

  • 『イメージ』による管理は、ホストクラスタに対してのみ有効化できる
    • クラスタの全台が ESXi 7.0 以降である必要がある
    • クラスタの全台がステートフル(Auto Deploy でなくディスクからブートする)である必要がある
    • クラスタの全体が同一ベンダのハードウェアである必要がある
  • 『ベースライン』管理から『イメージ』管理には切り替えられるが、いちど『イメージ』管理にすると『ベースライン』管理には戻せない
  • 7.0 の時点では、NSX や vSphere with Kubernetes を含むクラスタは『イメージ』での管理は行えない
    • 『イメージ』を利用したホストの修正を行うと、それらのエージェントが削除される
  • ファームウェアの管理まで行う場合、ハードウェアベンダから提供される Hardware Support Manager プラグインの導入が必要
    • 現時点では Dell か HPE のみの模様
    • Dell であれば OpenManage Integration for VMware vCenter (OMIVV)、HPE であれば iLO Amplifier が必要で、それぞれ仮想アプライアンスとして構築する

などなど、種々の注意事項や制約があるようです。ドキュメントをしっかり読まないとハマりそうですね。

なお、従来はパッチやドライバの最小単位は VIB でしたが、7.0 からはコンポーネントなる概念に代わっています。コンポーネントには、一つ以上の VIB を論理的にグループにしたものです。この辺もドキュメントに書いてあるので、作業中の用語に混乱しそうな場合は確認しておくとよさそうです。

今回の作業

今回は、最終的に『ESXi 7.0 を vLCM でイメージ管理できる』状態を目標に、以下を行っていきます。

  • ベースラインを利用して、ESXi 6.7 を 7.0 にアップグレードする
  • イメージでの管理に切り替える
    • その過程で、最新のパッチをベースにしたイメージを作成する
  • イメージを利用して最新のパッチを適用する

ESXi 6.7 の 7.0 へのアップグレード

まずは ESXi を 6.7 から 7.0 にアップグレードします。イメージによる管理は ESXi 7.0 以降でないと行えないため、アップグレードはベースラインを利用して行うことになります。

vLCM のメニュは、vSphere Client に完全に統合されています。というか、もともと VUM だった項目が vLCM になっています。

まずは、アップグレード用のベースラインを作る準備として、[インポートされた ISO] タブから、元になる ISO ファイルをインポートします。

インポートできました。

続いて、ベースラインを作成します。[ベースライン] タブで [新規] > [ベースライン] から、インポートした ISO ファイルを利用したアップグレードベースラインを作ります。

できました。

作成したベースラインをクラスタ(かホスト)に添付します。

デフォルトでは、事前定義された二つのベースライン(重要なホストパッチ、ホストセキュリティパッチ)が最上位の vCenter Server オブジェクトに添付されていて、クラスタやホストにもこれが継承されていますが、今回は事前に分離してから作業しています。

添付すると、アップグレード前なので、非準拠と判定されます。

ここから、ベースラインに合わせる修正作業をしていきます。今回はクラスタに対してまとめて修正を実行しましたが、一台ずつ実施したい場合はホスト単位でももちろん構いません。

修正のための設定をして、続行します。

今回は [今すぐ] にしたので、直ちに適用が始まりました。クラスタ内のホストで 1 台ずつ、

  • 対象ホスト上の稼働中の仮想マシンの移行
  • 対象ホストのメンテナンスモードへの切り替え
  • アップグレード
  • 対象ホストのメンテナンスモードの終了

が行われていきます。サポートされていないハードウェア(NUC8i5BEK)を使っていますが、特に問題なくすんなりとアップグレードされて起動してきました。

仮想マシンが共有ストレージ上にない場合は、Storage vMotion まではしてくれないので、そのホストのアップグレードはスキップされます。その場合、手動で仮想マシンを逃がすなど対処してから再度修正処理を実行します。

最終的に、クラスタ内の全台がベースラインに準拠した状態になったら、アップグレードは完了です。

なお、アップグレードが完了した段階で、ESXi のライセンスが評価モードに切り替わっています。必要に応じて、新しく vSphere 7.0 のライセンスキーを追加し、ホストに適用してください。

ベースラインからイメージへの切り替え

クラスタのホスト全台が ESXi 7.0 以上になったので、ベースライン管理からイメージ管理に切り替えます。

事前準備として、ベースイメージを取り込みます。オフラインバンドルの ZIP を取り込んでもよいですが、今回はインタネットから取得するため、vLCM の設定画面から、以下の URL の利用を有効化します。

  • https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

有効化後、[アクション] > [更新の同期] を実行して、[デポのイメージ] タブにベースイメージのリストが表示されていることを確認します。執筆時点では 7.0.0b7.0.0bs がありますが、違いは VMware のブログ でも説明されています。下部では、ベンダアドオンなども確認できますね。

デポにイメージが表示されたら、クラスタをベースラインからイメージに切り替えていきます。

クラスタの [アップデート] > [イメージ] で、[イメージのセットアップ] からウィザードを開始します。

今回は、アップグレードの残骸(古い fdm の VIB、おそらく今は無効にしている HA をかつて有効にしていた影響)がスタンドアロン VIB として検出されてしまいました。もし今後もこの VIB を導入したままにしたい場合は、この VIB を含むコンポーネントをイメージに含める必要がありますが、今回はただの残骸で不要なので無視します。

ここで ESXi のベースイメージと、任意でベンダアドオンやファームウェアなども選択します。Dell や HPE など、きちんとサポートされるハードウェアを使っている場合は、このあたりから必要な追加コンポーネントを指定することになります。

サポートされているハードウェアを使っていて、かつ、Harware Support Manager が事前に構成されている場合は、あらかじめハードウェアとファームウェアの組み合わせなどを定義しておくことで、ここでファームウェアなどの構成もイメージに含められるようです。

今回はもちろんないので、ミニマムで ESXi のバージョン(執筆時点で最新の 7.0.0b)だけを指定して保存します。

イメージを保存すると、コンプライアンスの確認が走ります。今回は、次の 2 点が検出されていますが、どちらも想定内です。

  • ホストのバージョンがイメージと異なる
  • スタンドアロンの VIB(前述した残骸)がインストールされている

どちらも、このあとの適用作業で修正されます。後者はつまり削除されるわけですが、このように、イメージに含まれない余計なモノが入っていると削除される点は、かつてのベースラインでの管理とは異なる、イメージでの管理の特徴的なところの一つだと思います。

続行すると、イメージ管理への切り替えは完了です。

イメージに準拠するようホストを修正する

クラスタの [アップデート] > [イメージ] の画面で、イメージのコンプライアンスの確認や、事前チェック、修正時の動作に関する設定、実際の修正などが行えます。

修正の実行前には、事前チェックをしておくとよさそうです。修正の失敗の原因になる諸々をチェックして教えてくれます。例えば今回の環境だと、DRS が無効で、かつ vCSA が動作しているホストで問題が検出されました。一台ずつ対応すればよいだけなので、気にしないことにします。

クラスタの全台を修正する場合は [すべて修正] を、ホスト単位で修正する場合はホスト名の左の […] から [修正] を実行します。

確認画面が出て、続行すると修正が開始されます。ホストで何が行われるのか見せてくれるのは、わかりやすくてよいですね。

進捗は元の画面で逐次表示されていきます。これもわかりやすくてよいですね。

途中、停止状態の vCenter Server 6.7(前回のエントリ で作業した残骸で不要なヤツ)が乗っているホストで、vCenter Server が稼働中かつ DRS が無効だから適用できない旨の怒られが発生しました。停止状態でも vCenter Server が居ると(移行できなければ)ダメなようで、不思議な仕様だなあと思いつつ一時的にインベントリから削除して回避しています。

そんなこんなで順次修正が完了し、イメージを遵守できた状態になりました。めでたしめでたし。

まとめ

vSphere 7.0 からの新機能である vLCM を使って、ESXi のアップグレードと、イメージ管理によるパッチ適用を行いました。

NSX や vSphere with Kubernetes を構成するホストでは利用できないなど、制約はまだあるものの、イメージによる管理は VUM よりも素直でわかりやすい印象を受けました。

今回は試しませんでしたが、API を使って JSON ベースでの管理もできるようで、構成管理の負荷を下げる余地はまだまだありそうです。今後の機能追加やサポート範囲の拡大にも期待できそうですね。


vCenter Server を 6.7 から 7.0 にアップグレードする


はじめに

最近 vSphere 7 が出たので、おうちの牧場をアップグレードします。

この牧場は、物理的には Intel の NUC(NUC8i5BEK)にインストールした vSphere 6.7 が 2 台で、その片方に vCSA 6.7 が居る状態です。共有ストレージとして QNAP(iSCSI/NFS)がありますが、諸々の事情で vCSA は ESXi のローカルデータストア(M.2 SSD)に配置しています。外部認証ソースも外部 PSC も使っていない、ミニマムな感じです。

サポートされるアップグレード順序は、KB78221 で説明されています。今回の環境はとてもちまっとしたアレなので、素直に vCenter Server を上げてから ESXi を上げるのみです。

このエントリでは、vCenter Server のアップグレードだけを扱います。

ESXi のアップグレードもこの後でもちろんしますが、これには VUM の後継である vSphere Lifecycle Manager(vLCM)を使ってみたいので、別エントリとして投稿 しています。

vSphere 7.0 の理解と準備

根本的に、vSphere 7.0 になって、

  • ESXi 6.0 以前のサポートが廃止された(6.5 以上が必須)
  • Windows 版の vCenter Server が廃止された
  • 外部 PSC が廃止された(アップグレードの過程で統合される)
  • Flash ベースの vSphere Web Client が廃止された

などなど、アーキテクチャレベルでいろいろ変更があります。

そういう何やかやふくめ、アップグレードにあたっては何はともあれドキュメント読みましょうねという感じなので、KB や製品ドキュメントを一通り見ておきます。

ここからリンクされている KB や関連ドキュメントもざっくり眺めます。マジメなことをいうとそもそも vSphere 7.0 はぼくが使っている NUC への導入をサポートしていませんが、7.0 に限らず昔からそう(アップグレード前の状態でそもそも非サポートな状態)なので気にしないことにします。

OEM のドライバを使っている場合はどうしろとか、現行バージョンが vCSA の 6.7 U2c か U3 なら事前にコレをやれとか、いろいろ書いてあるので、該当する場合はその通りにするとして、凝ったことををしていない今回のようなシンプルな構成であれば、実際の作業はウィザードをぽちぽちするレベルで終わりです。

もちろん、現行が外部データベースを使っていたり、めちゃくちゃ古かったり、外部 PSC が居たり、そもそも Windows 版だったり、外部 VUM を立てていたりすると、いろいろ考慮事項も当然でてくるので、その辺りはドキュメントを読んでください。

vCenter Server のアップグレードプロセス

標準のアップグレード手順に従う場合、処理の流れはだいたいこんな感じです。一連の作業は、ウィザードに従うと自動で順次行われます。

  1. 新しい vCSA インスタンスがデプロイされます。この段階では、IP アドレスは作業用の一時的なもの(作業時に指定)が付与されます
  2. 現行の vCSA から、構成情報がエクスポートされます
  3. 新しい vCSA にエクスポートされたデータを転送します
  4. 現行の vCSA が停止され、現行の vCSA が使っていた IP アドレスや FQDN が新しい vCSA に設定されます
  5. エクスポートされたデータを使って、新しい vCSA に構成が復元されます

この後、状態を確認して、必要な後処理(これもドキュメントがありますが、典型的にはライセンスの投入など)を行えば、vCenter Server のアップグレードは完了です。

新しい vCSA を現行の vCSA と同じインベントリに配置する場合、作業の流れの都合上、仮想マシン名は現行の vCSA のものとは別にする必要があります。この場合、もし仮想マシン名も現行のものを維持したいのであれば、あとから手作業で仮想マシン名の変更(と、ファイル名まで気にする場合は Storage vMotion)が必要です。

vCenter Server のアップグレード

やっていきます。今回は Windows の端末上で GUI インストーラを使って作業しました。

ISO をマウントして、./vcsa-ui-installer/win32/installer.exe を叩くとインストーラが立ち上がるので、[Upgrade] を選択します。

あとは愚直にウィザードに従っていきます。まずは Stage 1 です。

現行の vCSA の情報を入力して、接続を確認します。認証情報と、現行の vCSA それ自体が動作している ESXi の情報も入力します。

新しい vCSA のデプロイ先の ESXi の情報を入力します。

新しい vCSA の仮想マシン名とパスワードを指定します。新しい vCSA が現行の vCSA と同じインベントリに並ぶことになる場合は、現行の vCSA と同じ仮想マシン名だとこの段階で怒られるので、別の名前を入れます。

新しい vCSA のサイズを指定します。

新しい vCSA を配置するデータストアを指定します。シンプロビジョニングにしたい場合はチェックも入れます。

新しい vCSA が利用するポートグループを選択して、バージョンアップ中だけ利用される一時 IP アドレスなどを入力します。

確認画面で [FINISH] を押下すると、デプロイが始まります。

デプロイ先に指定した ESXi を見ると、新しい仮想マシンができて、パワーオンされる様子が観察できます。vCSA 7.0 は、Photon OS 3.0 がベースのようですね、vCSA 6.7 は Photon OS 1.0 でした。

で、終わると、Stage 2 への進め方が案内されます。[CONTINUE] を押下するか、指示された URL にアクセスして続行します。

ここから Stage 2 です。[NEXT] で進むと、アップグレードの事前チェックが開始されます。

このアップグレードの事前チェックでエラーがあると先に進めないので、その場合はどうにかして直します。

今回は、環境固有の構成(6.7 の構築時点で手抜きして DNS サーバを立てずに強引にごまかしていた)の都合上、名前解決関連でエラーになったので、この段階で新しい vCSA に SSH でログインしてごにょごにょして修正しました。この方法は本筋ではないので本エントリの末尾で補足します。

エラーを解消したあとも警告がいくつか残りましたが、エラーでなく警告であれば、確認の上で続行できます。今回は想定内の警告のみだったので、そのまま進めました。

アップグレードするデータの種類を選びます。構成情報だけでなく、過去のタスクやイベント、パフォーマンスの統計情報なども移行できるようですが、その分データ量や作業時間は増えるようです。今回は、せっかくなので全部にしました。

CEIP を構成します。参加すると、表示されている機能が使えるようになります。逆にいえば、参加しないとこれらの機能は使えなくなります。参加状態は後からも変更できます。

現行 vCSA のバックアップを取得済みであることを宣言して続行します。バックアップ、実は取っていませんでしたが、失敗してもまあヨシな環境なのでそのまま進めました。

最後の最後に、現行 vCSA が停止する旨の確認がでて、了承すると実際の処理が開始します。

あとは待ちです。移行のデータは新旧の vCSA 間で直接やりとりされます。作業端末は経由しません。

移行データのエクスポートがひと通り終わると、現行 vCSA がシャットダウンされ、新しい vCSA の構成やサービスの起動、移行データの適用が始まります。この段階から、新しい vCSA が旧 vCSA の IP アドレスなどを持つようになります。

完了しました。

アップグレード後の確認と後処理

完了後、vSphere Client の URL にアクセスすると、確かに HTML5 版のみになっていました。

見た目や操作感は vSphere 6.x の頃とほとんど変わりません。

移行作業中に指定した通り、設定やインベントリ情報だけでなく、過去のタスクやイベント、パフォーマンスの統計情報などもきれいに残っています。

ただ、すぐに目に入るだけでも、

  • vCenter Server のライセンスが評価モードに変わっている
  • 旧 vCSA の仮想マシンが残っている
  • 新 vCSA の仮想マシン名は作業中に指定したもののままだ

あたりは対処が必要そうです。

ライセンスキーは 6.x と 7.x で違うので再適用が必要なのは当然ですが、仮想マシン名は、実体のファイル名まで気にする場合は Storage vMotion でデータストアを移行しないといけないので、ちょっと注意ですね。

vCenter Server の最新パッチ適用

アップグレードが終わったので、アップデートをしようとしました。

vSphere Client からは、Update Planner を利用して、アップデート(パッチ)の有無や適用の事前チェック結果などを確認できます。ただし、この Update Planner は、CEIP に参加していないと使えない(エラーが出る)ようです…… 謎仕様ですね。

既定では、vCSA に接続された ISO ファイルの中身と VMware の公開リポジトリがアップデートの取得先として探索されます。定期的なアップデートの自動チェックも設定できます。

トラブル: アップデートが進まない

で、実際の適用は、VAMI から数クリックで行える…… はずなので、VAMI にログインして、最新のアップデートをいちどステージングして、その後インストールを開始したところ、

  • プログレスバーが『インストールが進行中です』で 0 % からまったく進まない
  • 別セッションで VAMI にログインしようとすると『アップデートの進行中です』が表示されてログインできない
  • パフォーマンスチャートを見ても何も動いていなさそう

な状態になってしまいました。予想ダウンタイムが 254 分というのもにわかには信じがたい数字です。

解決策: VAMI を使わない

調べるとどうも KB があります。

内部でいちどコケていたのか何なのか、進捗がうまく更新されなかったみたいですね。素直に KB の通りにやってみます。

# cat /etc/applmgmt/appliance/software_update_state.conf
{
    "state": "INSTALL_IN_PROGRESS",
    "version": "7.0.0.10400",
    "latest_query_time": "2020-07-18T16:04:05Z",
    "operation_id": "/storage/core/software-update/install_operation"
}

# cp /etc/applmgmt/appliance/software_update_state.conf /tmp/software_update_state.conf.org

# service-control --stop applmgmt
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service applmgmt...
Successfully stopped service applmgmt

# rm /etc/applmgmt/appliance/software_update_state.conf

# service-control --start applmgmt
Operation not cancellable. Please wait for it to finish...
Performing start operation on service applmgmt...
Successfully started service applmgmt

# cat /etc/applmgmt/appliance/software_update_state.conf
{
    "state": "UP_TO_DATE"
}

これで、たしかにログインできるようになりました。GUI で見る限りではインストール前の状態に戻っています。

が、ふたたび GUI からインストールをしようとしたら、再発しました……。

仕方ないので、再度復旧させて、今度は CLI でアップデートを試してみます。見てみると、そもそもステージングが正しくされていない模様。

Command> software-packages list --staged
 [2020-07-19T02:07:58.201] : Packages not staged

GUI の表示がおかしそうなので、GUI からはいちどステージングを解除して、

ステージング自体も今度は CLI から行います。

Command> software-packages stage --url --acceptEulas
 [2020-07-19T02:10:46.201] : Not running on a VMC Gateway appliance.
 ...
 [2020-07-19T02:10:47.201] : Staging process completed successfully

Command> software-packages list --staged
 [2020-07-19T02:11:16.201] :
        category: Bugfix
        ...
        version: 7.0.0.10400
        updateversion: True
        allowedSourceVersions: [7.0.0.0,]
        buildnumber: 16386292
        ...

目的のモノがステージングされてくれたので、インストールします。

Command> software-packages install --staged
 [2020-07-19T02:14:52.201] : Validating software update payload
 [2020-07-19 02:14:52,670] : Running validate script.....
 [2020-07-19T02:14:53.201] : Validation successful
 [2020-07-19 02:14:53,680] : Copying software packages 127/127
 [2020-07-19 02:17:10,915] : Running system-prepare script.....
 [2020-07-19 02:17:12,928] : Running test transaction ....
 [2020-07-19 02:17:14,945] : Running prepatch script.....
 [2020-07-19 02:18:42,103] : Upgrading software packages ....
 [2020-07-19T02:20:09.201] : Setting appliance version to 7.0.0.10400 build 16386292
 [2020-07-19 02:20:09,265] : Running patch script.....
 [2020-07-19 02:26:47,947] : Starting all services ....
 [2020-07-19T02:26:48.201] : Services started.
 [2020-07-19T02:26:48.201] : Installation process completed successfully

10 分くらいで終わりました。254 分とは……?

無事に最新になっています。

Command> com.vmware.appliance.version1.system.version.get
Version:
   Version: 7.0.0.10400
   Product: VMware vCenter Server Appliance
   Build: 16386292
   Type: vCenter Server with an embedded Platform Services Controller
   Summary: Patch for VMware vCenter Server 7.0.0
   Releasedate: June 23, 2020
   Installtime: 2020-07-18T22:37:32.988Z

そんなわけで、もしかすると vCSA のアップデートは VAMI より CLI のほうがトラブルを招きにくいかもしれませんね。そのうち修正されるだろうとは思いますが……。

まとめ

vSphere 6.7 環境のうち、vCenter Server を 7.0 にアップグレードし、パッチの適用も行いました。

アップグレードプロセスや全体的な使用感も 6.7 とは大きく変わっていないので、これまで通り安心して使えそうです。サクサク動いてくれて快適です。

次のエントリ では、vLCM を利用した ESXi のアップグレードとパッチ管理を行っていきます。

補足: vCSA 自身を vCSA 用の DNS サーバにする

アップグレード前、つまり 6.7 の構築時点で手抜きをしていたので、今回の環境内には DNS サーバがありません。このため、アップグレードの Stage 2 の冒頭の事前チェックで、新しい vCSA から現行の vCSA のホスト名が解決できずにエラーになりました。

アップグレード前の vCSA 6.7 は、DNS サーバがなくても FQDN で構成できるようにするため、vCSA 自身を vCSA 用の DNS サーバにしていました。具体的には、

  • vCSA の /etc/hosts にエントリを追加する
  • vCSA で動作している Dnsmasq に /etc/hosts を参照させる

ことをしていました。なお、自宅のラボなので好きにやっていましたが、もちろん非サポートです。

同じことは vCSA 7.0 でも有効なようですし、DNS サーバをわざわざ立てるのもアレなので、今回もこれを行いました。もちろん非サポートです。

Stage 1 のあと、かつ Stage 2 の前であれば、すでに vCSA への SSH ができる状態なので、指定していた一時 IP アドレスに接続して、/etc/hosts に必要なエントリを追記します。

# vi /etc/hosts
# cat /etc/hosts
...
192.168.0.201 kuro-vcs01.krkb.lab kuro-vcs01
192.168.0.200 kuro-qnap01.krkb.lab kuro-qnap01
192.168.0.202 kuro-esxi01.krkb.lab kuro-esxi01
192.168.0.203 kuro-esxi02.krkb.lab kuro-esxi02

この後、Dnsmasq の設定ファイルを修正して、Dnsmasq が /etc/hosts のエントリを DNS クエリへの応答に利用できるようにします。no-hosts をコメントアウトして、オマケで bogus-priv を足すだけです。

# sed -i 's/^no-hosts/#no-hosts\nbogus-priv/' /etc/dnsmasq.conf
# cat /etc/dnsmasq.conf
listen-address=127.0.0.1
bind-interfaces
user=dnsmasq
group=dnsmasq

no-negcache
#no-hosts
bogus-priv
log-queries
log-facility=/var/log/vmware/dnsmasq.log
domain-needed
dns-forward-max=150
cache-size=8192
neg-ttl=3600

この後、Dnsmasq を再起動します。

# systemctl restart dnsmasq

これで、OS がホスト名の名前解決を試みたときに、透過的に /etc/hosts のエントリも応答されるようになりました。dignslookup で確認できます。

# dig kuro-esxi01
...
;; ANSWER SECTION:
kuro-esxi01.            0       IN      A       192.168.0.202

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
...

vCSA(というか Photon OS)は、名前解決時の第一参照先が(/etc/resolv.conf で) 127.0.0.1:53 になっています。vCSA の場合は、このポートで Dnsmasq が待ち受けているため、上記の手順で名前解決に透過的に /etc/hosts が利用できたということです。

なお、DNS サーバがなくても、すべて FQDN でなく IP アドレスを指定してデプロイすれば、上記のような面倒なことをしなくても構築は可能です。


ValveX-SE と真空管


愛用の真空管ヘッドホンアンプ ValveX-SE のノイズが気になるようになってきた、というか、前からずっと気になっていたので、真空管を交換しました。買うにあたってなんとなく調べはしたけれど、真空管の世界は本当にもうよくわからない。

大学生だった頃に HD650 と一緒に買ったものですが、製造元がすでになくなってしまっているので、今では中古以外では手に入りません。10 万円以下クラスのヘッドホンアンプでは、当時はけっこう有名でしたね。

交換前後の違いがわかるとおもしろいので、交換前の無音状態をまず記録しました。波形はこれです。

無です。

でも縦軸をめっちゃ拡大すると、ノイズっぷりが見えます。プツプツというかワシャワシャというかガサガサというか、そういう感じで聴こえます。

左右ともノイズはあるものの、とくに右側(チャンネル 2)が顕著でした。ひとまず、真空管起因のノイズであることを断定するため、分解して左右の真空管を入れ替えてみます。

かわいい。

真空管の左右を入れ替えたら、ノイズも左右が入れ替わったので、真空管が原因といってよさそうです。回路の別のところでなくてよかった。

もともと使われていた真空管は、Electro Harmonix の 12AU7A/ECC82 EH というモノでした。

同じものもまだ買えそうですが、在庫がなさそうだったのと、そしてちょっとくらい沼を覗いてみてもいいじゃない? という気持ちに嘘をつけず、そんなわけで違うどれかを買うことにしました。

……という動機で調べはじめたら、型の互換だのマッチングだの単語はわからないし、12AU7(ECC82)系はメジャな型で互換品もたくさんあるみたいで、本当にもう何が何やらわからなくなりました。

困ったので、もうひと踏ん張りいろいろ見て調べて考えてから、とりあえず高いヤツを適当に買っておきました。

沼の先住民の先生にも(たぶん)ポジティブな評価をいただけたのでよしとします。

買ったのは JJ の ECC802S GOLD というものです。

箱にはなにがしかの測定結果が書いてある。

二本組を買ったので、よくわからないけれど、この二本の何らかの特性が組み合わせて使うのに適しているのだということにします。Amazon の商品種別の MP て、Matched Pair ですかね。わからん。

とりあえずかわいいので記念撮影。

交換して、ノイズはなくなりました。上が交換前、下が交換後。

前後の測定条件が厳密ではないのと、あと電源由来のなにかもあって完全ではないけれど、聴覚上はばっちり問題なくなったのでよしとします(二回目)。

なお、音の違いはわかりません。


デジタル一眼レフカメラを 5,000 円で無理やり Web カメラ化する実験的方法(Windows)


HDMI のキャプチャのことをいろいろ調べていたら おもしろそうなブログ を見つけたので、実際に遊んでみました。これはその記録です。

免責

  • 安定性は不明 です、実験程度 に捉えてください
  • 当然ながら ハードウェア HDMI キャプチャのほうがよい です。もしくはプラグインを書くべきです
  • 映像は 実測で 0.5 秒ほど遅延 しますし、画質は落ちます し、CPU をとても食い ます
  • 音声は得られません
  • 何かが起きても ぼくは責任は取りません

TL; DR

手順

結論

  • 使えないことはないけれど、CPU をほんとうに食うし、0.5 秒くらい遅延するので、この方法が活用できるシーンは限られそうだ
  • 素直にハードウェア HDMI キャプチャを使うか、LKV373 を使うにしてもプラグインを書く方がよいだろう

概要

できることと注意

この方法によって、

  • PC やゲーム機の映像を、YouTube Live などの生配信で使う
  • デジタル一眼レフカメラの映像を Zoom や Teams や Meets で使う

などが、ハードウェアの HDMI キャプチャを用意するよりは比較的低コスト(約 5,000 円)でできるようになります。

ただし、端的に言って 品質を相当犠牲にする ことになり、

  • CPU をめっちゃ食う
  • 映像が 0.5 秒くらい遅延して配信される
  • 音声は別に工夫(分離器で音だけ取り出す、コードを追加する、など)が必要
  • 安定して動作するかどうか誰もわからない

な点には注意が必要です。

別解

単に デジタル一眼レフカメラの映像を Web カメラ化したいだけ であれば、macOS なら Camera Live と CamTwist、キヤノン製のカメラなら EOS Webcam Utility など、より低コストかつ理想的な別解があります。

また、LKV373 を使う場合でも、macOS であれば、別の方のブログで OBS Studio のプラグインを実装している偉大な例があります。

で、Windows でソニーの α7iii なぼくはこれが使えず、とはいえ、OBS Studio のプラグイン作りはいきなり手を出すにはしんどかったので、手間がかからない代わりに CPU にはめっちゃ優しくない 方法でがんばる、のが本エントリです。

必要なもの

  • Lenkeng の HDMI 延長器 LKV373(またはその OEM 品)の、送信機(TX、Sender)
    • 受信機は不要
    • Amazon だと これ とか。約 5,000 円
    • 後継の LKV373A だと使えないのでややこしい
    • 本体の裏に V2.0 があれば LKV373(使える)、V3.0 だと LKV373A(使えない)らしい?
  • PC の有線 LAN ポート
  • golkv373
  • VLC media player
  • OBS Studio

キモはいちばん上のこれです。

裏の V2.0 が大事みたいです。

手順

配線

HDMI ソースと LKV373(TX)をつなぎ、LKV373(TX)と PC を LAN ケーブルで直結します。

LKV373(TX)がデフォルトで 192.168.168.55/24 を持っているので、PC 側の NIC には同じセグメントの適当な IP アドレスを固定で割り当てます。LKV373(TX)の IP アドレスは Web の管理画面から変えられますが、その場合は、PC 側も併せて変えます。

golkv373 の準備

golkv373 のバイナリをダウンロード してきて、起動します。自分でビルドしてもよいです。署名がどうのこうので怒られたら、納得の上でとにかく実行します(ダブルクリックで起動せずにコマンドプロンプトや PowerShell から叩けば怒られませんが、どちらでもよいです)。

ファイアウォールの穴あけも必要です。LKV373(TX)と接続している NIC のプロファイルを Get-NetConnectionProfile かなにかで調べて、そのプロファイルで通信を許可します。

起動するとなんやかや出力されて、

2020/xx/xx xx:xx:xx Program started as:  [C:\...\golkv373-v0.5.2-win64.exe]
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

2020/xx/xx xx:xx:xx No active transmitters
[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:   export GIN_MODE=release
 - using code:  gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /src/:IP/frame.mjpg       --> main.main.func2 (4 handlers)
[GIN-debug] GET    /src/:IP/frame.jpeg       --> main.main.func3 (4 handlers)
[GIN-debug] GET    /src/:IP/                 --> main.main.func4 (4 handlers)
[GIN-debug] GET    /status                   --> main.main.func5 (3 handlers)
[GIN-debug] GET    /                         --> main.main.func6 (3 handlers)
[GIN-debug] Listening and serving HTTP on :8080

続けて毎秒のログが出始めるはずです。状況に応じて出方が変わります。

ファイアウォールに阻まれているなど、LKV373(TX)と疎通できていない状態のときは、No active transmitters だけが繰り返し出力されます。この場合、設定を見直してどうにかします。

...
2020/xx/xx xx:xx:xx No active transmitters
2020/xx/xx xx:xx:xx No active transmitters
2020/xx/xx xx:xx:xx No active transmitters
...

疎通できているけれども映像が入力されていない場合は、keepalive sentNo active transmitters が両方出力されます。この場合は HDMI のソースに何の信号も来ていない可能性があります。

2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx No active transmitters
2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx No active transmitters
2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx No active transmitters

疎通できていて映像も送られてきているときは、フレームレートなどが表示されます。

2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx 192.168.168.55: MB/s=2.66 FPS=30.00 lost=0
2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx 192.168.168.55: MB/s=2.69 FPS=30.00 lost=0
2020/xx/xx xx:xx:xx keepalive sent to 192.168.168.55:48689
2020/xx/xx xx:xx:xx 192.168.168.55: MB/s=2.71 FPS=30.00 lost=0

ブラウザで http://localhost:8080/ にアクセスして、LKV373(TX)の IP アドレス(デフォルトなら 192.168.168.55)を選択すると、転送されてきている映像が表示されます。単に映像が観たいだけであれば、これで終わりです。

この段階で、192.168.168.55 からの映像は、

  • http://localhost:8080/src/192.168.168.55/frame.mjpg

で Motion JPEG としてストリーミングされています。ここから、OBS Studio でこの Motion JPEG を映像ソースとして取り込めるように設定していきます。

プレイリストファイル(XSPF)の作成

OBS Studio では、メディアソース で Motion JPEG の URL を直接指定しても映像は取り込めます。が、

  • バッファされるので遅延が増えるうえ、バッファの設定を変えられない
  • 遅延が蓄積していく(ように見える)

ので、URL だけでなくキャッシュ設定も含まれたプレイリストファイルを作って、それを OBS Studio から読ませる方法を取ります。

プレイリストの作成には、VLC media player を使います。VLC media player を起動して、

  • [メディア] > [ネットワークストリームを開く] を開き、
  • URL に http://localhost:8080/src/192.168.168.55/frame.mjpg を入力して、
  • [詳細オプション] で [キャッシュ] を [0 ms] にして
  • [再生]

します。この段階で遅延がひどかったりフレームレートが低かったりする場合は、余計なものを閉じてやり直すなどするとよさげです。

キャッシュを増やすとより安定しますが、増やしただけ遅延が純増します。ここでは強気に 0 ms です。

で、映像が極端な遅延なく見えていれば、[メディア] > [プレイリストファイルを保存] して、XSPF ファイルを保存します。この XSPF ファイルがプレイリストで、キャッシュの設定もここに含まれています。

保存したら、VLC media player はもう要らないので閉じます。

OBS Studio の設定

最後に、OBS Studio で、ソースとして VLC ビデオソース を追加し、その設定画面で先ほどの XSPF ファイルを追加すれば、完了です。

ここからさらに OBS-VirtualCam などを使って仮想デバイスに出力すれば、別のソフトウェア(Zoom など)でも映像を利用できることになります。

実測

次のパタンで遅延や CPU 使用率などを比較してみます。

  • Web カメラとして使うパタン
    • 本エントリの方法を使った場合
    • ハードウェア HDMI キャプチャを使った場合
    • 市販の Web カメラを使った場合
  • HDMI キャプチャとして使うパタン
    • 本エントリの方法を使った場合
    • ハードウェア HDMI キャプチャを使った場合

登場人物

  • PC
    • Intel NUC6i5SYH
    • Intel Core i5-6260U @ 1.80 GHz
    • 32 GB RAM
  • ハードウェア HDMI キャプチャ
    • Ezcap269
  • 市販の Web カメラ
    • Logicool C270

測定方法

ブラウザでストップウォッチを表示 させて、測定パタンに応じた経路で最終的に Zoom に表示します。

各画面に時間が表示されている状態で、充分に速いシャッタスピード(1/800 程度)で全体を撮影すると、撮影できた各画面の時間の差が遅延時間そのものを表すことになります。

Inter BEE などの展示会では、似た方法をよく低遅延伝送のデモンストレーションで見かけますね。表示させるソースをストップウォッチとフレーム数とで迷いましたが、遅延はミリ秒表記のほうが個人的に馴染みがあるのこうしています。

Web カメラとして使うパタン

本エントリの LKV373 を使った方法は、遅延も CPU 使用率も圧倒的に大きくなりました。

方法遅延CPU 使用率経路
本エントリ(LKV373)460 ms 程度80 ~ 100 %ソース → α7iii → LKV373 → OBS Studio → Zoom
ハードウェアキャプチャ150 ms 程度20 ~ 40 %ソース → α7iii → Ezcap269 → Zoom
市販 Web カメラ60 ms 程度20 ~ 40 %ソース → c270 → Zoom

そもそも、ある瞬間を α7iii が取り込んで HDMI で出力する(≒ カメラの液晶に表示される)までに 70 ms くらいの遅延があるみたいでした(カメラ側の設定で変わる部分かもですが未調査です)。460 ms の内訳は、

経路遅延
ソース → α7iii70 ms
α7iii → LKV373 → OBS Studio220 ms
OBS Studio → Zoom170 ms

な具合です。OBS Studio の仮想カメラでは、デフォルトで入る 3 フレームのバッファ設定をそのままにしているので、その分も含まれるでしょう。

HDMI キャプチャとして使うパタン

カメラを経由しない分遅延は改善されますが、それでも LKV373 を使った方法は、遅延も CPU 使用率も圧倒的に大きいままです。

方法遅延CPU 使用率経路
本エントリ(LKV373)370 ms 程度80 ~ 100 %ソース → LKV373 → OBS Studio → Zoom
ハードウェアキャプチャ80 ms 程度20 ~ 40 %ソース → Ezcap269 → Zoom

370 ms の内訳は、

経路遅延
ソース → LKV373 → OBS Studio200 ms
OBS Studio → Zoom170 ms

な具合でした。

画質

LKV373 を通すと、JPEG らしさのある圧縮ノイズが視認できるレベルで乗ってきます。

自分のブログを映した別 PC の画面を LKV373 経由で OBS Studio に取り込んで等倍キャプチャしたものがこれです。

ハードウェア HDMI キャプチャだとこういう劣化はなく、ここにさらに配信プラットフォーム側の圧縮が乗ってくることになるので、画質面もこの方式のデメリットです。

まとめ

強引に多段変換してどうにかする手法では、遅延も CPU 使用率も大きくなるというごく当たり前のことが確認できました。

同じ LKV373 を使う手法でも、先の macOS 用の OBS Studio のプラグイン を使うのであれば、原理的にはオーバヘッドは相当減らせると推測できるため、プラグインの開発に至ったモチベーションも合理的なものと言えそうです。

CPU 使用率の高騰が許容できるなら、例えば録画や生配信の用途であれば、音声に意図的に遅延を入れて同期を取れば使えないこともないかもしれません。一方、オンライン会議などでは、音声を遅延させるわけにもいかず、そうすると声と映像が 0.5 秒ズレることになってしまうので、なかなか使いづらそうです。そしてどちらの場合でも、この方式の安定性はだれにも保証できません。

いずれにせよ、最近は安いハードウェアキャプチャは 10,000 円強で手に入りますし、予算が許せばそうする方が、あらゆる面で合理的だと思いました。