INDEX
熟々と書いてましたがダイエットしました。
記事一覧 - 不完全なマシマロ (最近50件)
記事一覧 - 不完全なマシマロ (51件目-100件目)
記事一覧 - 不完全なマシマロ (それ以降)
KVM環境でIntel iGPUグラフィックを仮想マシンにパススルー(というか共有)する
表題の通り。今回はIntel GVT-g、いわゆるvGPUな仕組みを使う。
vGPUとは、GPUを仮想化し、複数のゲスト インスタンスから一つの物理GPUを共用できるようにする仕組み。つまり複数のゲストOSにGPUを提供できる。
物理端子は一つしかないので、ゲストOSからの映像出力はサポートしないが、ゲストOSでGPUが使えるとリモデとかが軽くなるし、たぶんQSVとかも動くはず。(この機能、ESXi向けにも提供してほしい)
ついでに言うと、ホスト向けのGPU出力を殺さずので、普段の鯖管理で画面が出てねぇ!みたいな事態を避けられる。
ホストOSとして使ったのは Rocky Linux 9.0 + Cockpit(管理ツール)。
KVM自体の設定はこのあたりを参考に済ませる。ついでにゲストOSも作成しておく。
- QEMU、KVM、libvirtの基礎知識まとめ - えんでぃの技術ブログ (hatenablog.jp)
- KVMの初期設定、及びvirsh, virt-installによるVM作成 - えんでぃの技術ブログ (hatenablog.jp)
- Cockpit GUI によるKVM操作 - えんでぃの技術ブログ (hatenablog.jp)
大まかな手順は以下。事前にVT-x/VT-dをBIOS上で有効化しておくこと。
- Rocky Linux 8 : KVM : GPU パススルー : Server World (server-world.info) (IOMMUの付近)
- Tutorial: Passing an Intel GPU to a Linux/KVM Virtual Machine – Interesting things (tmm.cx) (仮想マシンの構成xml以外のところ)
RHEL系だけど、KVMの設定さえしてしまえば、ディストリビューション間でやる事は大差なさそう。(どちらかというと Cockpit で作成した仮想マシンに若干癖あり、他のマネージャー使った場合と勝手が違うかもしれない。)
- 上記の手順では、ゲスト構成で既存の仮想GPUを完全に置換しているが、そちらは残しつつ追記。(WebConsoleから見えなくなるのはつらい)
- パススルーして見せる先のPCIのバス位置は既存と被るので適当に変更。
手元の環境では、仮想マシンの構成XMLは /etc/libvirt/qemu に存在した。
<graphics type='egl-headless'>
<gl rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/>
</graphics>
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='on'>
<source>
<address uuid='a0d7bae4-45bf-47c2-a13b-9a6fa4dd08d0'/>
</source>
<address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
</hostdev>
xml編集後はきちんと反映する。
# virsh define Windows10.xml
複数ゲストにiGPUを共有したい場合、サービスを複数個作成する、またはサービス内でcreateを複数叩くなりするとよい。以下サンプル。
[Unit]
Description=Setup GVT[Service]
Type=oneshot
ExecStartPre=/usr/bin/bash -c 'echo a0d7bae4-45bf-47c2-a13b-9a6fa4dd08d0 > /sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V5_8/create'
ExecStart=/usr/bin/bash -c 'echo 58e3b221-8a07-4e02-bad5-b70404769969 > /sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V5_8/create'[Install]
WantedBy=multi-user.target
あとCockpitのWeb管理画面から作ったVMにPCIパススルーを設定すると、仮想ディスク イメージのバージョンが古いって怒られた気がする。ディスクイメージを変換するだけで、もし起動時に怒られたときはコマンド叩いて適当に変換する。
ゲストOS向けに、Intel HD Graphics ドライバを入手してインストール。
導入するドライバはホストと同じものでOK。
例えばSkylake世代のWindows 10向けの場合は以下が適合する。
もし準仮想化ドライバが未導入の場合、ついでに入れておく。
【画面が真っ暗になった場合】
Intel HD Graphics が有効化されると、その時点でプライマリ ディスプレイが Intel HD Graphics に取られてしまい、Web コンソールが見えなくなることがある。
画面出力は必要ないので、スタートアップにショートカットなどを仕込んで、ディスプレイを切り替えるようにすることで回避可能。
- スタートアップ ディレクトリは「shell:start menu」→プログラム→スタートアップ の辺りにある。
- ディスプレイの切り替えには「DisplaySwitch.exe /internal」(1台目のみ)、「DisplaySwitch.exe /external」(2台目のみ)、「DisplaySwitch.exe /clone」(1台目と2台目の両方に複製出力 ※GPUを跨ぐ為、対応GPUかつWin10限定) などが標準コマンドで使える。(Win8.1で確認済)
- 仕込みの際はセーフモードに切り替える必要あり。
セーフモードの起動には「詳細な起動オプション」を呼び出す必要がある。事前に「bcdedit /set {default} advancedoptions yes」などでオプションを有効にすることで呼び出し可能。 - 何をするにしてもコマンドが叩けなくて詰む場合、一度iGPUのパススルーを無効にして作業すべし。とりあえずセーフモードが有効にできれば何とかなる。
- 色々仕込んだ後、ログイン操作も困難になると思うので、「DevicePasswordLessBuildVersion」とか「netplwiz」でググって自動ログインを仕込んでおくとよい。
- ログイン後に何が起きてるのか知りたい場合、リモート デスクトップを仕込んでおくと良いかもしれない。
一通りの設定が終わったら、仮想マシンからGPUが見えるようになるはず。
ちなみに、この状態だとOSからGPU自体は見えるが、物理端子へゲストOSの映像は出力されず、ホストのコンソールがそのまま出力される。
(物理端子も込みでゲストにGPUを見せたい場合は完全にPCIパススルーをする必要があるが、手元の環境では映像出力に一度も成功していない‥)
【追記 - 2022/11/20】
その後もProxmox VE 6.2 等と比較しながら試用してみたけど、どうにもGPUパススルーすると安定せず。残念ながらKVM自体の使用を断念し、ESXiに切り替えましたとさ。
ESXiが壊れたので再インストール&設定リストアした。
USBフラッシュにインストールしたESXi 7.0が起動しなくなってしまった。
症状
・起動中、「imgdb.tgz」がCRCエラーで止まる。
そもそもESXi 7.0以降、インストール先の媒体には信頼性の高いSSD等を使用する事が推奨されているらしく、USBフラッシュなんぞにインストールするのが間違ってると言えば間違っている‥(インストール後に気付いたんですけどね。言い訳しても仕方ないよね。)
元々使ってたUSBフラッシュはこちら。発熱すごい割に放熱性に乏しいので、あまりオススメしない。
対応方針
そう簡単にSSD増設できないので、何故か未開封のまま手元にあったmicroSDとカードリーダーを組み合わせて再インストールし、急場を凌ぐ事にする。
単に再インストールするだけだと再設定面倒なので、できれば環境設定まるごとリカバリしたい。ただし、起動しなくなった環境からの設定バックアップって結構面倒くさいらしく、
- 旧環境の復旧
- 起動した所で設定ファイルをバックアップ
- 新環境へリカバリ
と手順を踏むのが早いのではと踏んだ。実際これで成功した。
再インストール
microSDはこちら。
都合のよい事にMLCタイプがストックしてあった。(購入から半年ほど死蔵)
カードリーダーはこちら。
USB2.0なので速度は出ないけど、アクセス中ピカピカ光るのは便利。
こいつらをガッチャンコして、元々と同じバージョンを再インストール。
(普通にインストールしただけなので、作業手順は割愛する。)
旧環境の仮復旧
まずは旧環境の仮復旧から。今回起動しない原因は「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アクセス。環境設定をバックアップする。
コンソール上に設定ファイルの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をチョイス↓
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)
パーティションの作成
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
大体こちらの通りに進める。神。
インストールが一通り終わったら、この時点で BonDriver_mirakurun でmirakurunの動作確認しておくと良いかも。
録画関係 (EPGStation)
公式のセットアップマニュアルをベースに進める。
【事前準備】
まずはnodeのバージョン確認。
ここは mirakurun のインストールが正常完了していれば問題ないはず。
# node --version
# curl -o - http://localhost:40772/api/version
続けてffmpeg。素の環境だと多分入ってないのでインストールしておく。
pythonも素の状態だとコマンド入ってないので、インストールしておく。
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
Ubuntu 20.04 で 6to4
WebARENA Indigo VPS に Ubuntu 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.yamlnetwork:
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 にIPv6でPING。
$ 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
$ 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 って、相手事業者によって疎通できない相手がいるっぽいですね‥(致命的じゃね?)
参考
ESXi 6.7 のパッチ適用
ほぼこちらの内容通りに実施。
まずは現在実行中のバージョンを確認しておく。
[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できるようになりました。やったね!