https://naba-san.hatenablog.com/


ESXiが壊れたので再インストール&設定リストアした。

USBフラッシュにインストールしたESXi 7.0が起動しなくなってしまった。

 

症状

・起動中、「imgdb.tgz」がCRCエラーで止まる。

 

そもそもESXi 7.0以降、インストール先の媒体には信頼性の高いSSD等を使用する事が推奨されているらしく、USBフラッシュなんぞにインストールするのが間違ってると言えば間違っている‥(インストール後に気付いたんですけどね。言い訳しても仕方ないよね。)

 

元々使ってたUSBフラッシュはこちら。発熱すごい割に放熱性に乏しいので、あまりオススメしない。

Amazon | 【 サンディスク 正規品 】5年保証 USBメモリ 32GB USB 3.1 超小型 SanDisk Ultra Fit SDCZ430-032G-J57 | SanDisk | USBメモリ・フラッシュドライブ 通販

 

対応方針

そう簡単にSSD増設できないので、何故か未開封のまま手元にあったmicroSDとカードリーダーを組み合わせて再インストールし、急場を凌ぐ事にする。

単に再インストールするだけだと再設定面倒なので、できれば環境設定まるごとリカバリしたい。ただし、起動しなくなった環境からの設定バックアップって結構面倒くさいらしく、

  1. 旧環境の復旧
  2. 起動した所で設定ファイルをバックアップ
  3. 新環境へリカバリ

と手順を踏むのが早いのではと踏んだ。実際これで成功した。

再インストール

microSDはこちら。
都合のよい事にMLCタイプがストックしてあった。(購入から半年ほど死蔵)

amzn.to

カードリーダーはこちら。
USB2.0なので速度は出ないけど、アクセス中ピカピカ光るのは便利。

amzn.to

こいつらをガッチャンコして、元々と同じバージョンを再インストール。
(普通にインストールしただけなので、作業手順は割愛する。)

 

旧環境の仮復旧

まずは旧環境の仮復旧から。今回起動しない原因は「imgdb.tgz」の破損なので、それだけ新環境からコピーする。他のファイルが破損した場合は適宜読み替えること。

新環境を起動し、SSHでshellにアクセス。
旧環境のフラッシュをマウントする為、USBデバイスのパススルーを停止。事前に余計なUSBデバイス類(特にストレージ類)は外しておく。

# esxcli storage filesystem rescan
# esxcli storage filesystem list

# /etc/init.d/usbarbitrator stop

(ここで旧環境のUSBフラッシュを刺す)

# esxcli storage filesystem rescan
# esxcli storage filesystem list

パススルー停止前後のファイルシステムを見比べて、旧環境のファイルシステム(BOOTBANK1, BOOTBANK2)が追加で認識されたことを確認する。

 

ファイルシステムのパスを確認したら、破損したファイルのパスも確認しておく。

# ls -l /vmfs/volumes/(旧環境のBOOTBANK1) *.tgz

多分 imgdb.tgz の存在が確認できるはず。こいつが起動障害の元凶。

 

「imgdb.tgz」は「BOOTBANK1」パーティションに存在しているので、新環境のBOOTBANK1→旧環境のBOOTBANK1へファイルをコピーする。

新環境の BOOTBANK1 は、/vmfs/volumes/BOOTBANK1 よりエイリアスが張られている。(旧環境は、エイリアスが張られてない方のBOOTBANK1)

# cp -a /vmfs/volumes/BOOTBANK1/imgdb.tgz /vmfs/volumes/(旧環境のBOOTBANK1)

 

環境設定のバックアップ

新環境をシャットダウンして、旧環境で起動する。

ここで起動しなければご愁傷様です‥
(新旧環境でコピーする方向間違えてないかとか一度確認してみましょう。)

 

仮起動したら、先ほど同様にSSHでshellアクセス。環境設定をバックアップする。

vim-cmd hostsvc/firmware/sync_config

vim-cmd hostsvc/firmware/backup_config

コンソール上に設定ファイルのexport先URLが貼られるので、ブラウザとかから一式ダウンロードする。

旧環境とはここでおさらば。シャットダウンする。

 

環境設定のリストア

続けて新環境を再度立ち上げる。

先ほどダウンロードしたファイルを何かしらの手段で転送する。(SCPで転送するなり、Web管理コンソールのdatastoreに突っ込むなり好きにするとよい。)

 

またSSHでshellにアクセス。先ほど転送した設定ファイル(tgz)を以下の通りコピーする。

cp -a /vmfs/volumes/618ba7ec-444bbb82-1af8-1c1b0dfa8c49/configBundle-(ホスト名).tgz /tmp/configBundle.tgz

そしてリストアを実行する。(緊張の瞬間です‥!!)

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

実行後は勝手に再起動するので、きちんと立ち上がってくることを期待して待つ。

無事立ち上がった方はおめでとうございました。

 

参考文献

 

Raspberry Pi 3(b+) で mirakurun (Ubuntu 20.04 Server編)

備忘録。

前提

ラズパイ一式

数年単位で死蔵してあった Raspberry Pi 3B (3B+?)。
放熱性の良さそうなケースに入れて、適当なUSB ACアダプタからmicroUSBを介して給電する。

尼のリンクを貼りつつも、今買うならRaspberry Pi 4以降を強くお勧め。(尼は高騰してたので各自お探しください)

チューナー

AliExpressで仕入れたVT20を使いました。S270(PLEX PX-S1UD V2.0)と中身は同じくさい?

正直、蟻で買っても尼で買っても、値段そんなに大きく違わないです。(独身の日とか狙うなら、蟻の方が安いかも‥?)

カードリーダー

NTTcomのアレ推奨。

こちらの怪しいカードリーダーでも難なく使えました。
(SIMスロットにminiB-CAS刺さります。きちんと認識します。)

ちなみに日立マクセルのやつは認識しませんでした。

セルフパワーUSBハブ

Raspberry Pi 3系(及びそれ以前)の環境では、セルフパワーHUBの利用を強く推奨する。(microUSB給電がボトルネックになり、素の状態でも電源がカツカツ。チューナー刺しただけで電源不足に陥り動作不安定になる)

↓私はコレ買いました。

Raspberry Pi 4系は給電方式がタイプCになっているので、ひょっとすると必要ないかもしれない。(ACアダプタの給電性能を遺憾なく発揮してくれる気もするが、4系を持ってないのでよく分からない)

外部ストレージ

microSDに録画するわけにもいかないので、HDDを外付けする。
ラズパイからの給電に頼らないものなら何でも良いと思う。

 

環境構築

OSインストール

flash起動を避けて、HDDからUSB bootしたかったけど、どう頑張っても安定せず諦めた。

代わりに、ちょっとお高めのmicroSDをチョイス↓

amzn.to

OSは Ubuntu 20.04 Server LTS (64bit)。公式でイメージの書き込みツールが出てるのでそれ使うのが楽。

外付けHDD

2.5インチ バスパワーはまず動かないと思った方が良い。運よく認識できても、次回うまく起動しない。(USB Bootが邪魔してsdカードですら起動できない。)

セルフパワー給電できる余りモノ3.5インチケースに、同じく余ってた3.5インチHDD(4TB)をセット。

ゴミパーティション(ZFS)の残骸

同じく余ってた3.5インチHDD(4TB)

ddでも消えないんだなぁこれが。見事にハマりました。
(新品のHDD使ってる人、ZFSの流用に心当たりがない人は無視しておk)

qiita.com

パーティションの作成

gdiskを起動、/dev/sda 等を選んだ後、d→w で削除→反映。
再度gdiskを立ち上げ、 /dev/sda を選んだ後、n→w で新規パーティション作成→反映。

パーティション作成後、/dev/sda1 にパーティションが見えるはずなので、

$ sudo mkfs.ext4 /dev/sda1

パーティションをフォーマットする。

パーティションのマウント設定

起動時に自動マウントさせる為、対象パーティションを特定するUUIDを取得。

$ ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 100 Jan 18 04:21 ./
drwxr-xr-x 7 root root 140 Jan  1  1970 ../
lrwxrwxrwx 1 root root  15 Jan 10 04:56 5496-E6C8 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  15 Jan 18 04:14 675ba907-****-****-****-************ -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  10 Jan 18 04:21 a6a79439-****-****-****-************ -> ../../sdb1

(あれ。今見たらsdbで認識されてるな。)

sudo vim /etc/fstab でマウント設定追加。

LABEL=writable  /        ext4   defaults        0 1
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
UUID=a6a79439-****-****-****-************       /mnt/storage       ext4       defaults       0       0

再起動後、所定の位置(上記の場合は /mnt/storage/)HDDがきちんとマウントされることを確認する。

 

mirakurun

大体こちらの通りに進める。神。

maeda577.github.io

インストールが一通り終わったら、この時点で BonDriver_mirakurun でmirakurunの動作確認しておくと良いかも。

 

録画関係 (EPGStation)

公式のセットアップマニュアルをベースに進める。

github.com

 

【事前準備】

まずはnodeのバージョン確認。
ここは mirakurun のインストールが正常完了していれば問題ないはず。

# node --version
# curl -o - http://localhost:40772/api/version

続けてffmpeg。素の環境だと多分入ってないのでインストールしておく。

# ffmpeg -version
# apt install ffmpeg

pythonも素の状態だとコマンド入ってないので、インストールしておく。

# python --version
# apt install python-is-python3

gccは入ってるかも。

# gcc --version

 

【ビルド準備】

ビルド中はメモリを大量に消費するので、作業に際してmirakurun (を管理するpm2) を落としておく。

sudo systemctl stop pm2-root

 

nodeの設定でメモリ消費を抑えるように仕込んでおく。

 export NODE_OPTIONS="--max-old-space-size=1024"

 

できれば一時的にswap領域も増やしておく。

今回はswap用にUSBフラッシュを刺したが、HDDとかにswapfile作れるならそれでも良いと思う。
swapパーティション切る or DDで空ファイル作る→mkswap→swapn の流れ。

 

【ビルド&インストール】

事前準備はここまで。
EPGStationのインストール先に移動する。HDDのマウント先とかを選ぶと良いと思う。

# cd /mnt/storage/

リポジトリ上のソースをclone、チェックアウトする。

# git clone https://github.com/l3tnun/EPGStation.git

インストール。地味に時間がかかる。

# npm run all-install
# npm run build

インストールが終わったら、設定ファイルのテンプレートを展開する。

# cp config/config.yml.template config/config.yml
# cp config/operatorLogConfig.sample.yml config/operatorLogConfig.yml
# cp config/epgUpdaterLogConfig.sample.yml config/epgUpdaterLogConfig.yml
# cp config/serviceLogConfig.sample.yml config/serviceLogConfig.yml
# cp config/enc.js.template config/enc.js

 

事前に停止した mirakurun を戻しておく。

# sudo systemctl start pm2-root

 

(初期設定)

設定ファイルをざっと確認する。多分ffmpegとかのパスがおかしいので訂正しておく。

vim config/config.yml

  • /usr/local/bin/ffmpeg → /usr/bin/ffmpeg
  • /usr/local/bin/ffprobe → /usr/bin/ffprobe

 

 

Ubuntu 20.04 で 6to4

WebARENA Indigo VPSUbuntu 20.04 LTS をインストールした環境に 6to4 (IPv6) をセットアップしたのでメモ。

 6to4、古の技術と化してて日本語の情報がほぼ無いんですよね。(Indigoがネイティブ対応してくれたらそれで事足りるんだけど‥激安なので文句は言えない。)

 

概要

最初参考にしたページには /etc/network/interfaces にI/F追加しろって書かれてた。
懐かしい。

6to4によるIPv6接続(Linux編) – さくらインターネット研究所

 

20.04 は仕組みが変わり、netplan が使われてるそうで6to4の日本語の設定事例がない‥(初めて使った)。
色々漁って見つけたのがこの情報。結論を書くと、ほぼこの手順のままでおっけー。

HowTo 6to4 NetPlan · Wiki · Максим В. / WikiNotes · GitLab

 

前提

グローバル アドレスが Ubuntu 環境に直接割り振られていること。

手順

# cd /etc/netplan
# ls -l

-rw-r--r-- 1 root root 572 May 7 01:37 50-cloud-init.yaml

手元の環境では、初期構成で「50-cloud-init.yaml」にインタフェースの設定値が登録されていた。この辺はVPSとかだと多少違うかも。
このファイルは勝手に書き換えられる可能性がある為、直接編集してはいけない。

 

トンネルに使うIPv4アドレス情報を取得する。

# ip a

(略)
2: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:13:5d:**:**:** brd ff:ff:ff:ff:ff:ff
inet 164.70.***.**/24 brd 164.70.***.*** scope global ens10
valid_lft forever preferred_lft forever
inet6 fe80::213:5dff:fe13:4c34/64 scope link
valid_lft forever preferred_lft forever

今回は「164.70.***.**」がVPSに割り振られているアドレス。

 

IPv4 グローバル アドレスから、6to4用の IPv6 アドレスを計算する。

# printf "2002:%02x%02x:%02x%02x::1\n" 164 70 *** **
2002:a446:****::1

 

トンネル インタフェース定義を追加。

# cd /etc/netplan
# vim 90-6to4.yaml

network:
    version: 2
    tunnels:
    tun6to4:
        optional: true
        mode: sit
        remote: 0.0.0.0
        local: 164.70.***.**
            addresses:
            - 2002:a446:****::1/16
        routes:
            - to: "2000::/3"
        via: "::192.88.99.1"
        metric: 1 

# netplan apply

netplanを初めて使うので、詳しい事はわからないけど、、

  • local: トンネルを終端する IPv4 アドレス。
    NAT/NAPT 環境の場合はローカル アドレスを指定するらしい。
  • address: 先ほど計算した IPv6 アドレスを指定。
  • via: 6to4 の中継ルーター、固定。
  • routes: IPv6 のルート。2000に縛る必要ない気もする。 あ、これグローバルアドレスに縛ってるだけですね。

 

ちなみに、modeに指定できる値はこの辺参照。ipipとかも設定できそう。
An introduction to Linux virtual interfaces: Tunnels - Red Hat Developer

 

なお脱線ですが、18.04 標準の netplan だと tunnel が使えないそうです。

Ubuntu Server 18.04(Bionic Beaver)でトンネルインターフェースを定義する | DevelopersIO

 

接続確認

試しに www.google.com にIPv6PING

$ ping -6 -c 3 www.google.com
PING www.google.com(nrt12s22-in-x04.1e100.net (2404:6800:4004:80c::2004)) 56 data bytes
64 bytes from nrt12s22-in-x04.1e100.net (2404:6800:4004:80c::2004): icmp_seq=1 ttl=121 time=2.08 ms
64 bytes from nrt12s22-in-x04.1e100.net (2404:6800:4004:80c::2004): icmp_seq=2 ttl=121 time=1.82 ms
64 bytes from nrt12s22-in-x04.1e100.net (2404:6800:4004:80c::2004): icmp_seq=3 ttl=121 time=1.53 ms

--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.531/1.812/2.084/0.225 ms

比較用にIPv4PING

$ ping -4 -c 3 www.google.com
PING www.google.com (172.217.31.164) 56(84) bytes of data.
64 bytes from nrt12s22-in-f4.1e100.net (172.217.31.164): icmp_seq=1 ttl=117 time=1.11 ms
64 bytes from nrt12s22-in-f4.1e100.net (172.217.31.164): icmp_seq=2 ttl=117 time=1.29 ms
64 bytes from nrt12s22-in-f4.1e100.net (172.217.31.164): icmp_seq=3 ttl=117 time=1.15 ms

--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.111/1.185/1.290/0.076 ms

リレールーター挟んでる割には、遅延は1ms以下に収まってて、そこまで悪くない感じ。

 

速度計測できず。

計測したかったんだけど、手持ちの Vultr VPS(Native IPv6対応) とv6で疎通確認が取れず。Vultrからping叩くとunreachable とか帰ってくるので、Vultr側の問題っぽいんだけど‥

$ traceroute6 2002:a446:****::1

traceroute to 2002:a446:****::1 (2002:a446:****::1), 30 hops max, 80 byte packets
1 * * *
2 2001:19f0:7000:c640::1 (2001:19f0:7000:c640::1) 0.839 ms 0.859 ms 0.921 ms
3 vl504-ds1-q8.tyo2.constant.com (2001:19f0:fc00::a47:111) 1.812 ms vl814-ds2-q8.tyo2.constant.com (2001:19f0:fc00::a47:1c9) 1.395 ms vl504-ds1-q8.tyo2.constant.com (2001:19f0:fc00::a47:111) 1.768 ms
4 vl70-er1-q2.tyo2.constant.com (2001:19f0:fc00::a47:2e9) 17.231 ms !H vl20-er1-q2.tyo2.constant.com (2001:19f0:fc00::a47:f5) 17.162 ms !H 2001:19f0:7000::a47:33d (2001:19f0:7000::a47:33d) 0.470 ms !H

 

$ ping6 -c 3 2002:a446:****::1

PING 2002:a446:****::1(2002:a446:****::1) 56 data bytes
From 2001:19f0:fc00::a47:2e9 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:19f0:fc00::a47:2e9 icmp_seq=3 Destination unreachable: Address unreachable

--- 2002:a446:****::1 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2001ms

6to4 って、相手事業者によって疎通できない相手がいるっぽいですね‥(致命的じゃね?)

 

参考

research.sakura.ad.jp

gitlab.com

developers.redhat.com

dev.classmethod.jp

ESXi 6.7 のパッチ適用

redj.hatenablog.com

ほぼこちらの内容通りに実施。

 

まずは現在実行中のバージョンを確認しておく。

[root@esxi1:~] esxcli software profile get
(Updated) ESXi-6.7.0-20200804001-standard-customized
Name: (Updated) ESXi-6.7.0-20200804001-standard-customized
Vendor: VMware, Inc.
Creation Time: 2020-09-29T23:21:14
Modification Time: 2021-04-25T15:11:21
Stateless Ready: True
Description:

2020-09-29T23:21:13.881252+00:00: The following VIBs are
installed:
vmkusb-nic-fling 2.1-6vmw.670.2.48.39203948
----------
Updates ESXi 6.7 Image Profile-ESXi-6.7.0-20200804001-standard
(customized)

VIBs: (略)

 

最新のパッチをダウンロードして、SCPでESXi ホストに転送しておく。
SSHを有効にした後、WinSCPか何かで転送すればOK。

https://my.vmware.com/ja/group/vmware/patch#search

[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] ls -la
total 467072
drwxr-xr-x 1 root root 73728 Apr 25 14:46 .
drwxr-xr-t 1 root root 77824 Apr 25 14:46 ..
-rw-r--r-- 1 root root 476662495 Apr 25 14:44 ESXi670-202103001.zip

 

パッチZIPに含まれるプロファイルを確認。

[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] esxcli software sources profile list -d /vmfs/volumes/6084****-********-****-**********42/ESXi_Update/ESXi670-202103001.zip
Name Vendor Acceptance Level Creation Time Modification Time
-------------------------------- ------------ ---------------- ------------------- -------------------
ESXi-6.7.0-20210301001s-no-tools VMware, Inc. PartnerSupported 2021-03-04T10:17:40 2021-03-04T10:17:40
ESXi-6.7.0-20210304001-standard VMware, Inc. PartnerSupported 2021-03-04T10:17:40 2021-03-04T10:17:40
ESXi-6.7.0-20210301001s-standard VMware, Inc. PartnerSupported 2021-03-04T10:17:40 2021-03-04T10:17:40
ESXi-6.7.0-20210304001-no-tools VMware, Inc. PartnerSupported 2021-03-04T10:17:40 2021-03-04T10:17:40 

 no-tools と standard は文字通り VMware Tools を含むかどうか、末尾のs有無はセキュリティ更新のみ(s付き)か否か(sなし)を示すらしい。

 

必要に応じてプロファイルの詳細を確認する。

[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] esxcli software sources profile get -p ESXi-6.7.0-20210304001-standard -d /vmfs/volumes/6084****-********-****-**********42/ESXi_Update/ESXi670-202103001.zip
ESXi-6.7.0-20210304001-standard
Acceptance Level: PartnerSupported
Name: ESXi-6.7.0-20210304001-standard
Vendor: VMware, Inc.
Creation Time: 2021-03-04T10:17:40
Modification Time: 2021-03-04T10:17:40
Stateless Ready: True
Description:

Updates ESXi 6.7 Image Profile-ESXi-6.7.0-20210304001-standard

(以下略)

 

更新実施(メンテナンスモード→適用)

[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] vim-cmd hostsvc/maintenance_mode_enter
[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] esxcli software profile update -d /vmfs/volum
es/6084****-********-****-**********42/ESXi_Update/ESXi670-202103001.zip -p ESXi-6.7.0-20210304001-standard
Update Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: (略)

再起動

[root@esxi1:/vmfs/volumes/6084****-********-****-**********42/ESXi_Update] reboot

 

再起動後のバージョンを取得、モジュールが色々更新されていることを確認。

[root@esxi1:~] esxcli software profile get
(Updated) ESXi-6.7.0-20210304001-standard
Name: (Updated) ESXi-6.7.0-20210304001-standard
Vendor: VMware, Inc.
Creation Time: 2021-04-25T15:10:56
Modification Time: 2021-04-25T15:11:21
Stateless Ready: True
Description:

2021-04-25T15:10:56.058635+00:00: The following VIBs are
installed:
nvme 1.2.2.28-4vmw.670.3.132.17167734
vmkusb 0.1-1vmw.670.3.143.17700523
vmw-ahci 2.0.7-2vmw.670.3.143.17700523
tools-light 11.2.5.17337674-17700514
vsan 6.7.0-3.143.17661912
esx-base 6.7.0-3.143.17700523
esx-update 6.7.0-3.143.17700523
vsanhealth 6.7.0-3.143.17665851
cpu-microcode 6.7.0-3.139.17700514
----------
2020-09-29T23:21:13.881252+00:00: The following VIBs are
installed:
vmkusb-nic-fling 2.1-6vmw.670.2.48.39203948
----------
Updates ESXi 6.7 Image Profile-ESXi-6.7.0-20200804001-standard
(customized)

VIBs: (略)

 

メンテナンスモードを終了

[root@esxi1:~] vim-cmd hostsvc/maintenance_mode_exit

 

 お疲れさまでした。

ESXi上で他所の環境で作ったUSB VMFSドライブをマウントする

sshなどでコマンドが実行できること。

 

ゲストへのUSBパススルーを停止。

[root@localhost:~] /etc/init.d/usbarbitrator stop 

 

対象のUSBデバイスが見えていることを確認する。

[root@localhost:~] lsusb
Bus 002 Device 002: ID 4971:8017 SimpleTech
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 0e0f:8002 VMware, Inc. Root Hub
Bus 001 Device 001: ID 0e0f:8001 VMware, Inc. Root Hub

今回の対象はこの子 → SimpleTech

 

ESXiから認識可能なVMFSを表示。

[root@localhost:~] esxcli storage vmfs snapshot list
608****-********-****-**********42
Volume Name: external-ssd
VMFS UUID: 6084****-********-****-**********42
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1 

今回の対象はこのボリューム → 「Volume Name: external-ssd

 

マウント実行。

[root@localhost:~] esxcli storage vmfs snapshot mount -l external-ssd 

 

[root@localhost:~] ls -la /vmfs/volumes/
total 1796
drwxr-xr-x 1 root root 512 Apr 25 17:25 .
drwxr-xr-x 1 root root 512 Apr 25 16:42 ..
drwxr-xr-x 1 root root 8 Jan 1 1970 32db****-********-****-**********4b
drwxr-xr-t 1 root root 73728 Apr 25 16:30 6084****-********-****-**********42
drwxr-xr-x 1 root root 8 Jan 1 1970 6085****-********-****-**********dd
drwxr-xr-x 1 root root 8 Jan 1 1970 c679****-********-****-**********ab
lrwxr-xr-x 1 root root 35 Apr 25 17:25 external-ssd -> 6084****-********-****-**********42

 

無事にマウントできました。めでたしめでたし。

 

 

(おまけ)ESXi Shell 上で tar.gz を作る。マルチスレッドで。

HDDの移行作業をしようとしたが、SATAポートの数が限られている為、移行元と移行先を同時に刺す事ができず。

仕方なく、一時退避のためにUSBストレージを経由する事にしたけど、容量が限られていたので、軽く圧縮をかけてから保存した。(ブロック・ストレージって、使ってない領域もスペース食ってますからね)

 

[root@esxi1:/vmfs/volumes] tar c 5f83****-********-****-**********42 | pigz -5 > external-ssd/internal-hdd.tar.gz 

tar c の引数には移行対象のボリューム(ディレクトリ)を指定。固めた結果をpigzで圧縮してるだけ。引数の5は圧縮率。多分1とかでも相当減ると思う。

 tar単体でgzまで作るより、pigzでgz圧縮させる方が間違いなく早かったです。

 

但し、これだと隠しファイル(ピリオド始まり)がtarアーカイブの対象にならないようなので、必要に応じてfindとか併用すると良さそう。(詳しくはググって下さい)

 

ちなみに、移行先HDDでの展開は素直にtarしたのですが、こちらは糞時間かかりました。(展開の方が時間かかるって‥)

 

(更におまけ)

ESXi同士の移行ならscpした方が確実そうですが、デフォルトだとESXi上のshellでsshを叩くとタイムアウトする。悩んだ末に見つけたのがこちら。

[FYI] ESXi 6.7 の Shell から scp でデータをコピーしたい (nakoruru.jp)

esxcli network firewall ruleset set --ruleset-id=sshClient --enabled=true
esxcli network firewall ruleset list

※ 転送元、転送先どちらもsshサービスを有効にしておく事。

これで無事にホスト間でscpできるようになりました。やったね!

ESXi 6.7 +PT2 (PT3) パススルー + Intel QSV をやりたい。

ESXi を使った PT2 仮想化+QSVエンコードにトライ中。

まだ全然完成してないけど、試行錯誤の内容を忘れそうなので、そろそろメモに残しておく。

検証構成:

USB-Flash に ESXi をインストールし、SSD は全領域をVMのストレージとして割り当てる。

PCIパススルーなので、Intel VT-d とかに対応したCPUが必要。
パススルーを受けるゲストOSは、仮想マシンのメモリ割り当てを固定する必要がある。ホストのメモリ量はその点を見越して多めに積んでおくことを推奨。

ESXi のカスタマイズISO作成 (7.0対応)

標準イメージは Realtek NIC に対応しない為、カスタマイズISOを作成する。
管理者権限で立ち上げた powershell にて。(ESXi 7.0 を使う場合、v67をv70に書き換える)

PS C:\Windows\system32> Install-Module -Name VMware.PowerCLI
PS C:\Windows\system32> Set-ExecutionPolicy Unrestricted
PS C:\Windows\system32> cd C:\createESXi\
PS C:\createESXi> .\ESXi-Customizer-PS.ps1 -ozip -v67
PS C:\createESXi> .\ESXi-Customizer-PS.ps1 -v67 -izip .\ESXi-6.7.0-20200804001-standard.zip -pkgdir .\vibs\ 

作業ディレクトリには、 以下のスクリプトを配置(githubが最新版)

追加したいドライバは「vibs」フォルダの下に配置。入手元はこの辺。

ライセンスは普通に取得してください。インストール手順も普通にどうぞ。

Realtek NIC について

6.7 まではドライバが存在するが、手元の環境だと自動ネゴシエーションで 1000Mbps でリンクアップしなかったり、動作が怪しい。(1000Mbps に固定しても、知らぬ間に 10Mbps, 100Mbps とかに落ちてる事がある)

USB-NICよりマシかな?って思って6.7選んだけど、ぶっちゃけUSB-NICの方が安定してる疑惑あり。

USB-NIC について

手元にあるASIXチップ搭載NICを幾つか試したが、NICとして認識しない率が結構高い‥?(USBパススルー対象になってしまう)

  • PLANEX UE-200TXG: NG
  • IODATA ETG4-US2: NG
  • Logitec: LAN-GTJU3: OK 6.7 のみOK (7.0では認識できず)

# ESXi に繋ぎたい時とゲストに繋ぎたい時、どう切り替えればいいんだ‥?

(参考)

https://twitter.com/colinhd8/status/1031468984149766145

PT2 パススルー

Windows で検証した限り、特にハマる要素なし。(PT3 もうまくいくんじゃね?)
冒頭に記載の通り、PCIパススルーを使う際はメモリ割り当てを固定する必要あり。

USBパススルー

結構相性が出た。

ゲストの環境設定で USB ホストを 2.0→3.0 に変えると、認識しなかったデバイスが認識する場合があった。(例えば USB 3.0 対応フラッシュとか。多分逆もありそう)

カードリーダーは、どう頑張っても HITACHI はうまく認識しなかった(再起動すると切れる)。NTT com推奨。

【2021/10/28 追記】

件の日立カードリーダー(M-520U)、デバイスマネージャー上で無効→有効を繰り返すことで、稀にきちんと認識できる場合があることに気付いた。

devcon.exe を使って、スタートアップ時に以下のスクリプトを叩く事でうまく認識できるようになる‥かもしれない。

@echo off
cd %~dp0
: Enable_M520U
echo Enable Smartcard Reader/Writer M-520U
devcon enable "USB\VID_0858&PID_2102&REV_0100"
TIMEOUT /T 5

devcon status "USB\VID_0858&PID_2102&REV_0100"|find "problem: 10"
IF NOT ERRORLEVEL 1 (
  echo Disable Smartcard Reader/Writer M-520U
  devcon disable "USB\VID_0858&PID_2102&REV_0100"
  TIMEOUT /T 3
  GOTO Enable_M520U
)

exit

ハードウェアIDはデバイスマネージャー上で確認して各々置換、devcon.exe の入手方法、スタートアップ スクリプトの指定方法は適当に調べて下さい。

環境によっては、iGPUのパススルーでも「再起動後にうまく認識しない(エラーコード43)」みたいな問題があるようなので、そのスタートアップ処理にも流用できるかもしれません。(シャットダウン時に無効化スクリプトも併せて配備しておく方が安定するかも)

【2021/10/30 更に追記】

PCI-Express to USB3.0 なボードをPCIパススルーすることで問題が生じなくなりました。他にもESXiのUSBパススルーって細かな制約が多そうなので、USBハードウェア常用するなら絶対に刺しておいた方が良さそうです。

iGPU パススルー (Intel HD Graphics)

ものごっつい曲者。全くすんなりいかない。

ゲストが Windows の場合

Windows インストールの時点ではパススルーさせず、後からパススルーを追加した。

そのままではドライバがコード31とかで読み込まれなかったが、これは「hypervisor.cpuid.v0 = "FALSE"」で回避可能。後は通常通り Intel の提供ドライバをインストール。

手持ちのPCではドライバの読み込みまでは確認したが、物理ポートからの映像出力を確認できず。(この状態でもQSVは動作した)

ゲストがUbuntuの場合

<調査中>

OSインストールの時点でGPUが繋がっていると操作不能になる為、こちらも後からパススルーを追加する。

フレーバーが Server/Desktop、起動モードが BIOS/EFI の組み合わせで動きが違うように見えるが、大抵画面は出力されないし、SSHすら繋がらず完全にハングアップする事もある。(症状が安定しない‥)

「hypervisor.cpuid.v0 = "FALSE"」の設定有無で動きは変わる様子。(ドライバが何かチェックしてる?)

#この手の情報を調べてると「mce.enable = "TRUE"」と「vhu.enable = "TRUE"」が並んで出てくる事があるが、どちらもよく調べてないので効果は不明。

ゲストがCentOSの場合

<調査中>

OSインストール後にiGPUを接続する方法のみ検証中。

デスクトップなしの場合、起動自体は問題なく完了するが、時間差でi915ドライバを読み込むのか?途中でVMRSのリモートコンソールが操作不能になる。(物理ディスプレイに何も出ない‥)

(Linux) 物理端子の認識状況
# ls -l /sys/class/drm/
# grep . /sys/class/drm/card?-*/status

Intel Graphics - ArchWiki 

(脱線)シリアル接続を使ったコンソール ログイン

↑の調査で起動の様子を確認する為、仮想環境とのシリアル接続を試してみた。操作される側のゲスト設定は以下参照。

www.hiroom2.com

www.hiroom2.com

隣にWindows ゲストOSを準備して、それぞれの仮想マシンにシリアル ポートを追加する。

f:id:naba_san:20201004173048p:plain f:id:naba_san:20201004173112p:plain

Windows 側から TeraTerm とか開いて立ち上げると、懐かしい感じの起動メッセージが出てきてコンソール操作できる。

(メモ)ESXi を代替できそうなもの

  • oVirt
  • Proxmox VE
  • kimchi

 (さらにメモ)現時点で一番正解に近そうな情報源

7.0なんだよなぁ‥CPUの世代も違うし動くかなぁ‥頑張って上げるか‥

www.virtuallyghetto.com