Raspberry Pi OSなどのDebian系OSのviで、方向キーによる移動やバックスペースを使えるようにする

Raspberry Pi OSなどのDebianベースのOSにおいてviを使う際に、入力モード(i または aを押して文字入力ができる状態)にした際に方向キーで移動しようとすると、ABCDの文字が入力されてしまう。

方向キーと文字の関係は以下の通り。

   A
   |
D -+- C
   |
   B

とても不便なので、viで方向キーを用いても通常通りカーソルを移動できるように設定する。併せてviでバックスペースも正常に使用できるように対処する。

設定手順

各ユーザーのホームディレクトリに.vimrcというファイルを作成し、以下2行の設定を書き込んでやればよい。

set nocompatible
set backspace=indent,eol,start

ワンライナーで設定したい場合は以下の通り実施する。すでに.vimrcがある可能性を考慮して、追記でリダイレクトしている。

$ echo -e "set nocompatible\nset backspace=indent,eol,start" >> ~/.vimrc
$ cat ~/.vimrc
set nocompatible
set backspace=indent,eol,start

これだけで、特に再ログイン等も不要で、次回vi実行時から設定が反映され、入力モードであっても方向キーが使えるようになる。

参考

• Vim: options.txt

更新履歴

• 2018/3/26 新規作成
• 2024/1/21 補足情報を追記

「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」のエラーを解消する。

仮想環境に構築したドメイン参加済みのWindows OSに対して、スナップショットなどからリストアすると、以下エラーによりドメインアカウントを用いてもログインができなくなることがある。

「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」

これは「セキュアチャネルの破損」と呼ばれる事象であり、ドメイン再参加または、コマンドによるセキュアチャネルの修復作業が必要となる。

今回はPowerShellのコマンドを用いて本エラーを解消し、再びドメインアカウントにてログインできるようにする手順を記載する。

環境

• ドメインコントローラ : Windows Server 2016
• ドメイン参加対象のクライアント : Windows Server 2019

エラー解消手順

1. ロカールアカウントでログイン

ドメインアカウントではログインできないので、ローカルアカウントでログインを行う。

2. PowerShellにてセキュアチャネルの状態を確認

PowerShellを管理者として開き、Test-ComputerSecureChannelを実行する。セキュアチャネルが破損している場合は、以下の通りFalseと表示されるはずだ。

PS C:\> Test-ComputerSecureChannel
False

3. セキュアチャネルを修復

引き続きTest-ComputerSecureChannelを用いてセキュアチャネルの修復を行う。セキュアチャネルの修復には、-Repairオプションと-Credentialで任意のドメインアカウントを指定する。

PS C:\> Test-ComputerSecureChannel -Repair -Credential [ドメイン名]\[ドメインアカウント名]
True

指定したドメインアカウントのパスワード入力を求められるので入力する。

数秒待ちTrueが返ってくれば、セキュアチャネルの修復は完了となる。

4. ドメインアカウントで再ログイン

一度ログアウトし、ドメインアカウントにて再度ログインを行う。問題なくログインできれば作業は完了となる。

参考

• Test-ComputerSecureChannel (Microsoft.PowerShell.Management) - PowerShell | Microsoft Docs

HP ENVY 4520のプリンターの印刷設定が保護違反で表示されない問題 (例外コード 0xe06d7363)

以前使っていたプリンターのノズルが詰まってしまい、いくらクリーニングしても印刷がかすれてしまう状況になってしまった。プリンターは年賀状の印刷時以外はほとんど使うこともなく特にこだわりもないので、かなり古いモデル (2015年販売) となる中古の「HP ENVY 4520」を購入した。インク付きで7,000円だった。

しかし、いざ印刷しようとすると、HP ENVY 4520のプリンターの印刷設定画面が保護違反で開けない問題が発生した。表示されているメッセージは以下の通りとなる。

C:\WINDOWS\splwow64.exe
関数アドレス 0x00007FFEA7FF3B29 保護違反が発生しました。(例外コード 0xe06d7363)
プロパティページの数ページまたはすべてのページが表示されない可能性があります。

上記メッセージや例外コードをもとに検索すると、ドライバをアンインストールして再インストールせよといった情報が出てくるが、ドライバを何度インストールしなおしても事象は改善しない。

Windows UpdateによるWindows 10のバージョンアップにドライバが追従できていないことが原因のようで、アップデート済みのWindows 10のノートPC2台の両方で本事象が発生した。逆に言えば、古いWindows 10であれば正常に動作することを確認した。

しかし、いろいろ試したところアップデート済みのWindows 10においても、本事象を解消できる手順を確立できたので、以下に記載する。

環境

• Windows OS : Windows 10 バージョン1909
• プリンタ : HP ENVY 4520

解消手順

1. HPのサイトよりドライバをダウンロード＆インストール

もし、ドライバを未インストールの場合は、以下HPサイトより「HP ENVY 4520シリーズ基本ドライバー - ITプロフェッショナル向けのみ」をダウンロードしインストールしておく

• HP ENVY 4520オールインワンプリンターシリーズ ソフトウェア及びドライバーのダウンロード | HP®カスタマーサポート

2. プリンタのIPアドレスを確認＆固定IPアドレスに設定

DHCPの場合、プリンタのIPアドレスが変更となった際に印刷に失敗する可能性があるため、IPアドレスの固定を行う。HP ENVY 4520は、本体の液晶画面またはWebの管理画面のどちらかを使って設定できる。以下はWeb管理画面の設定例となる。

3. Windowsにプリンタを手動で追加

Windowsメニュー→「設定」→「デバイス」→「プリンターとスキャナー」を選択する。

「プリンターまたはスキャナーを追加します」を選択するとプリンタの検索が始まる。しばらく待つと「プリンターが一覧にない場合」という表示がされるので選択すると、「プリンターの追加」画面が表示される。

「その他のオプションでプリンターを検索」画面では、「TCP/IPアドレスまたはホスト名を使ってプリンターを追加する」を選択する。

「ホスト名またはIPアドレスを入力します」画面では、以下の通り入力する。

• デバイスの種類 : TCP/IPデバイス
• ホスト名またはIPアドバイス : プリンターのIPアドレス
• ポート名 : 自動入力

「どのバージョンのドライバーを使用しますか?」画面では、「現在のドライバーを置き換える」を選択する。

「プリンター名を入力してください」画面では、デフォルトのまま「次へ」を選択する。

「HP ENVY 4520 seriesが正しく追加されました」画面では、そのまま「完了」を選択する。

4. 印刷設定画面の表示確認

この状態で、追加されたHP ENVY 4520 seriesの「管理」を選択する。

以下の通りエラーなく印刷設定の画面が表示されるようになれば、対処完了となる。

Tera TermでLinux操作中にキー入力を受け付けなくなった場合は「Ctrl + Q」を押してみよう

まれにTera Termを使ってLinuxを操作していると、キー操作を受け付けなくなって操作ができなくなることがある。泣く泣くTera Termを×ボタンで閉じて接続しなおして対処していたが、これには原因と解決策があったという小ネタとなる。

## 原因

「Ctrl + S」を押したこと。

## 解決策

「Ctrl + Q」を押す。

以上となる。どうやら、Tera Termの仕様ではなく、Linuxの仕様として「Ctrl + S」を押すと画面出力を停止してしまうらしい。

ESXiをvCenter Serverに登録した際に「ホスト上のサードパーティ I/Oフィルタ ストレージ プロバイダの登録/登録解除に失敗する」のエラーが出る

ESXiをvCenter Server (vCSA)に登録した際に以下警告メッセージが表示された場合の対処方法を記載する。

"ホスト上のサードパーティ I/Oフィルタ ストレージ プロバイダの登録/登録解除に失敗する"
※英語表記の場合"Registration/unregistration of third-party IO filter storage providers fails  on a host"

原因

vCSAとESXiの間にFirewall等で通信制御をしている環境において、以下通信許可が不足していることが原因となる。

送信元	送信先	送信先ポート
vCSA	ESXi	9080/tcp

対処

1. Firewall等の通信許可設定で、vCSA→ESXi方向の9080/tcpを許可する。
2. vSphere Clientにて、[vCenter Server] -> [設定] -> [詳細] -> [ストレージ プロバイダ]を選択する。
   
   
   
3. [ストレージプロバイダの同期]を選択し、ESXiが表示されることを確認する。なお、9080/tcpのポートが許可されていない場合は、この操作はエラーで失敗する。
   
   
   
4. ESXiの警告メッセージは手動でリセットしないと消えないようなので、[緑にリセット]を選択して、警告を解除する。
   
   
   

ESXiをvCenter Serverに登録した際に、ESXiが頻繁に「応答なし」になる

ESXiをvCenter Server (vCSA)に登録した際に、ESXiが頻繁に応答なしになる事象が発生した。

ESXiのイベントとしては「ホストが応答しません」のエラーが出力される。

なお、「応答なし」になるタイミングや頻度は以下となる。

• メンテナンスモード有効/無効時
• vSphere HA有効/無効時
• 1分間に1回(ただし、1秒以内に回復)

原因

vCSAとESXiの間にFirewall等で通信制御をしている環境において、以下通信許可が不足していることが原因となる。
※ESXi→vCSA方向の通信要件となるため注意。

送信元	送信先	送信先ポート
ESXi	vCSA	902/udp

対処

1. Firewall等の通信許可設定で、ESXi→vCSA方向の902/udpを許可する。
2. ESXiのイベントで「ホストが応答しません」が発生しないことを確認する。また、「ホストのCPU使用率が灰色から緑に変わりました」といったメッセージが表示されていることも確認する。
   
   
   

「間違って削除されたりしないようにこのオブジェクトは保護されています」でActive DirectoryのOUが削除できない場合の対処

Active Directoryで「組織単位 (OU) 」を作成する際に、「間違って削除されないようコンテナーを保護する」というチェックボックスがある。

この設定はデフォルトで「有効」となっており、特に気にしなければそのままOUを作成することとなるが、いざOUを削除しようとすると「間違って削除されたりしないようにこのオブジェクトは保護されています」と表示され削除することができない。

とはいえ、当然二度と削除できなくなるわけではないので、削除手順について簡単に記載する。

OU削除手順

1. 「拡張機能」を有効にする

「Active Directory ユーザーとコンピューター」の画面を開き、メニューバーの「表示」→「拡張機能」を選択し、拡張機能を有効にする。

2. OUのプロパティを開き「誤って削除されないようにオブジェクトを保護する」のチェックを外す

次に削除対象のOUを右クリックし、「プロパティ」を表示させる。「拡張機能」を有効にすることで、通常表示されない「オブジェクト」タブが選択できるようになるので、「誤って削除されないようにオブジェクトを保護する」のチェックを外し、「OK」を選択する。

3. OUを削除

削除対象のOUを右クリックし、「削除」することで問題なく削除されるはずだ。

4. 「拡張機能」を無効にする

最後に、メニューバーの「表示」→「拡張機能」を再度選択し、拡張機能を無効にしておく。

Ubuntu 20.04のGoogle Chromeで、プロキシ経由でインターネット接続できなくなった場合の対処手順

Ubuntuをメインのデスクトップ環境として、日々使うようにしているのだが、ある日突然Google Chromeにプロキシ設定が適用されなくなり、インターネット閲覧ができなくなる事象が発生した。本件の解消方法について、簡単ではあるが記載する。

環境

• Ubuntu 20.04 LTS

Google Chromeをプロキシ経由で接続できるようにする手順

CLIでGoogle Chromeを起動する際にプロキシ設定を行う

Google Chromeを実行する際に、--proxy-server="<Proxy IP Address>:<Proxy Port>"のオプションを付与することで、プロキシ設定を行った上でGoogle Chromeを起動することができる。

$ /usr/bin/google-chrome-stable --proxy-server="<Proxy IP Address>:<Proxy Port>" &

しかし、毎回ターミナルからコマンドを実行するのも手間がかかるので、次にGUIのアプリケーションメニューからGoogle Chromeを起動する際にプロキシ設定がされるように設定を行う。

GUIのアプリケーションメニューの設定を修正する

Ubuntuのアプリケーションメニューの起動オプションに、CLIで実施したのと同様に--proxy-server="<Proxy IP Address>:<Proxy Port>"オプションを付与することで対処する。しかし、Ubuntuのアプリケーションのメニューは、そのままではGUIで編集することができない(おそらく設定ファイルを直接修正すれば対処できるが未検証)ので、アプリケーションメニューの管理ツールである「メニューエディター (MenuLibre)」をインストールする。

$ sudo apt install menulibre -y

インストール後、アプリケーションメニューに「メニューエディター」が追加されているので選択する。

左メニューの「インターネット」→「Google Chrome」を選択する。

「アクション」ボタンを押すと、「新しいウインドウ」と「新しいシークレット ウインドウ」の2つが設定されているので、それぞれの起動コマンドに、--proxy-server="<Proxy IP Address>:<Proxy Port>"のオプションを追加する。私の環境では以下のように設定した。

• 新しいウインドウ：/usr/bin/google-chrome-stable --proxy-server="192.168.33.23:8080"
• 新しいシークレット ウインドウ：/usr/bin/google-chrome-stable --incognito --proxy-server="192.168.33.23:8080"

上記設定を実施したのち、左上の「ランチャーを保存」ボタンを押して設定を保存する。

設定後、メニューからGoogle Chromeを起動すると、問題なくプロキシ経由でインターネット接続できるようになった。

RHEL 7のemergency modeを体験した話

先日RHEL 7のディスクマウントの検証をしていた際に、OS再起動後、emergency modeになって正常に起動できなくなってしまった。

対処した内容

rootパスワードでログインせよ、と記載されているのでrootパスワードを入力してログインしてみる。

ログインすると通常のコマンドを受け付ける状態になる。

emergency modeの冒頭のメッセージに記載されていたjournalctl -xbを素直に叩いてみる。すると、大量の起動時のログが出力されるので、ひたすらスペースキーを押して確認していくと、ログの終盤に赤字のエラーログを発見した。

メッセージは以下。

Time out waiting for device dev-mapper-rhel\x2ddata.device.

どうやらLVM2のデーモンがデバイスのタイムアウトで異常終了している模様。直前に設定した/etc/fstabがあやしいので確認してみると、デバイス名をミスっている。。。

[root@localhost ~]# cat /etc/fstab

/dev/mapper/rhel-root   /                       xfs     defaults        0 0
UUID=1b3eb24d-7d2c-4023-9d4d-933bea63cd3f /boot                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0
/dev/mapper/rhel-data   /data                   xfs     defaults        0 0
　↑★rhel-dataではなくdata-dataが正しい

上記を修正して再起動すると、問題なく起動することができた。よかったよかった。

……と思ったのだが、fstabの記述ミスはともかく、障害等でディスクが見えない状況となった場合もemergency modeになってしまい、OSが起動できなくなるという問題がある。

そこで今回は、もしマウントが失敗する場合であっても、該当のマウント処理をスキップしてOSを起動させる方法も調べてみた。

回避策「fstabでnofailをオプションを指定する」

emergency modeとなった原因の「/etc/fstab」は、以下構文で記載する。

<ストレージデバイス> <マウントポイント> <ファイルシステム> <マウントオプション> <dumpコマンドの対象とするか> <起動時にfsckでファイルチェックを行うか>

上記の「マウントオプション」は通常defaultsのみ指定をすることが多いが、ここにnofailオプションも追加し、nofail,defaultsを指定する。このオプションにより、OS起動時にストレージデバイスが存在しない場合でもエラーとならず、OS起動に成功する。

# cat /etc/fstab
/dev/mapper/rhel-root   /                       xfs     defaults        0 0
UUID=68f1f8f7-ab56-410a-aa4c-8401fc6f7894 /boot                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0
/dev/mapper/vg_sdb1-lv_sdb1   /                 xfs     nofail,defaults 0 0　←★nofailを指定

「/var/log/messages」にはemergency mode時と同様に、Timed out waiting for device dev-mapper-vg_sdb1\x2dlv_sdb1.device.のエラーメッセージが出力されるが、その後Startup finishedと表示されており、起動に成功していることがわかる。

# tail /var/log/messages
Aug 29 16:01:01 localhost systemd: Removed slice User Slice of root.
Aug 29 16:01:37 localhost systemd: Job dev-mapper-vg_sdb1\x2dlv_sdb1.device/start timed out.
Aug 29 16:01:37 localhost systemd: Timed out waiting for device dev-mapper-vg_sdb1\x2dlv_sdb1.device.
Aug 29 16:01:37 localhost systemd: Dependency failed for /mnt2.
Aug 29 16:01:37 localhost systemd: Job mnt2.mount/start failed with result 'dependency'.
Aug 29 16:01:37 localhost systemd: Startup finished in 498ms (kernel) + 3.065s (initrd) + 1min 30.363s (userspace) = 1min 33.927s.
Aug 29 16:01:37 localhost systemd: Job dev-mapper-vg_sdb1\x2dlv_sdb1.device/start failed with result 'timeout'.
Aug 29 16:01:49 localhost systemd: Created slice User Slice of root.
Aug 29 16:01:49 localhost systemd: Started Session 2 of user root.
Aug 29 16:01:49 localhost systemd-logind: New session 2 of user root.

上記設定をしたのち、試しに仮想ディスクを取り外した状態で仮想マシンを起動させてみたところ、問題なく起動することができた。

Windows Server 2019のペイントでpngやjpgが保存できない問題

(2019/6/7 追記)
Windows Updateしても上記事象が再発してしまった。原因不明。

小ネタとなる。
Windows Server 2019のペイントを使って画像を保存しようとすると、以下エラーによって保存できない事象が発生した。

このファイルは保存できません
保存が中断されたので、ファイルは保存されませんでした。

いろいろ調べたが原因は不明だった。

しかし、ダメもとでWindows Updateして、再起動すると事象は解消した。リリースノートをざっと見たが書いていないのでどのパッチで解消したかは不明だが、もし同様の事象が発生して悩んでいる方がいる場合は、Windows UpdateでOSを最新化してみよう。

OS再起動後にAnsible AWXのコンテナ起動ができなくなる問題

以前、Ansible AWXのインストール手順について以下記事にて記載したが、インストール時に発生した問題の一つに、インストール後にOS再起動すると、なぜかAWXのコンテナが起動しないという事象があった。

★以前の記事はこちら↓

Ansible AWXをインストールしてみた
https://tech-mmmm.blogspot.com/2018/09/ansible-awx.html

以下はAWX起動失敗の事象発生時のログとなる。docker psコマンドでは何も表示されず、docker startコマンドでコンテナを起動しようとしても失敗する。

# docker ps　　　←★何も表示されない
# docker ps -a
------------------------------
CONTAINER ID IMAGE                      COMMAND                  CREATED             
STATUS                        PORTS               NAMES
dc063a8e3de0 ansible/awx_task:latest    "/tini -- /bin/sh ..."   25 hours ago        
Exited (143) 22 minutes ago                       awx_task
705aceeb6ed8 ansible/awx_web:latest     "/tini -- /bin/sh ..."   25 hours ago        
Exited (143) 22 minutes ago                       awx_web
24b247a05f54 memcached:alpine           "docker-entrypoint..."   25 hours ago        
Exited (128) 22 minutes ago                       memcached
edd9864f0f44 ansible/awx_rabbitmq:3.7.4 "docker-entrypoint..."   25 hours ago        
Exited (137) 22 minutes ago                       rabbitmq
2061929d6cf7 postgres:9.6               "docker-entrypoint..."   25 hours ago        
Exited (128) 22 minutes ago                       postgres
------------------------------

# docker ps start awx_task awx_web memcached rabbitmq postgres
------------------------------
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/df4e19d15cbdb563d55602931631de5d08c2b99692c6efc1ffcb5277569a3b66/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/8a56664e15b48857218f4c68345350ed9155a5c142baa30fb2e619d7e16fc571/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/67a0d9de802d8833e30b0d4c6edec9e8ee60ed7698f1585ea3fd059999bb908d/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/f49a15172956a3572d94652d38f2c9716c6de54f5ecf23a0c1cc609fc53f79af/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/b4e8287273c50c3909024b910166fab055b51888e0fbcd07df09a02c24404cca/merged: invalid argument
Error: failed to start containers: awx_task, awx_web, memcached, rabbitmq, postgres
------------------------------

最初は「error creating overlay mount」というメッセージから、ファイルシステムの問題を疑っていたのだが、最終的には以下問題であることに行き着いた。

Error response from daemon: devmapper: Error mounting '/dev/mapper/docker-253:2-8652374-' on '/var/lib/docker/devicemapper/mnt/': invalid argument
https://github.com/moby/moby/issues/29622

どうやら、SELinuxをきちんと無効化しない状態でOSを再起動すると発生するらしい。たしかに、「setenforce 0」のコマンドで「Permissive」の状態でAWXをインストールしたのち、/etc/sysconfig/selinuxのファイルに「SELINUX=disabled」を設定してOS再起動したら発生したので、事象としては合致している。

ということで回避策は、SELinuxを「Permissive」ではなく「Disabled」の状態にしてからAWXをインストールする、ということになる。
※前回の記事もSELinux無効化設定後、一度OSを再起動するよう手順を記載している

ESXi 6.0をESXi 6.7にアップグレードしようとしたら、RealtekのNICドライバーが競合してエラーとなった話

自宅の検証環境では、vSphere Clientで操作できることから、ESXi 6.0をあえて利用してきた。しかし、先日vSphere 6.7が発表されたことを受け、そろそろ最新版のESXiにバージョンアップしてみることにした。

結果的には先日別記事に記載したRealtekのNICドライバーが原因にて、アップグレードには失敗してしまったが、ESXi 6.7をインストールして、再設定をすることで利用できるようにはなったので、簡単に実施した手順についてまとめておく。

実施手順

1. ESXiのカスタムイメージでブート

ESXi 6.7のISOイメージを入手し起動するのだが、今回は別記事で記載したRealtekのNICドライバーが組み込まれたカスタムイメージを利用する。

★別記事はこちら↓
RealtekのNICのドライバーを組み込んだESXi 6.7のカスタムイメージを作成する
https://tech-mmmm.blogspot.com/2018/05/realteknicesxi-67.html

ISOイメージでブートすると以下のような画面が表示されるので、そのままエンターキーを押す。

インストール画面が表示されるまでしばらく待つ。なお、画面取得のため、今回はESXi on ESXiでバージョンアップ検証を実施している。この際に、ESXiの要件として、以下を満たしていない場合、インストールができないので注意しよう。

・CPU：2コア以上
・メモリ：4GB以上

たとえば、メモリが4GBより小さい場合は、パープルスクリーンにてエラーとなり、「Not enough main memory is available to continue.」と表示される。

2. インストール開始

インストールが開始されるので、エンターキーを押す。

3. EULAに同意

EULAが表示されるので、F11キーを押す。

4. インストール先ディスクを選択

インストール先ディスクを選ぶことができるので、容量やデバイス名をもとに、インストールディスクを判別して選択し、エンターキーを押す。当たり前だが、インストール先ディスクを間違えると、最悪ディスクの中の仮想マシンデータまで消えるので注意すること。

5. インストール方式を選択

選択したディスクが、もともとESXiがインストールされている場合、インストール方法の選択画面となる。選択肢は以下3つとなる。

・Upgrade ESXi, preserve VMFS datastore：アップグレード(VMFSのデータは消さない)
・Install ESXi, preserve VMFS datastore：新規インストール(VMFSのデータは消さない)

・Install ESXi, overwrite VMFS datastore：新規インストール(VMFSのデータを消す)

今回はアップグレードが目的となるため、Upgrade ESXiを選択し、エンターキーを押してみた。

すると、残念ながらエラーとなり、先に進めなくなる。どうやら、net55-r8168とnet51のドライバーが競合しているようなメッセージのようだ。

そこで1つ前の画面に戻り、2つめのInstall ESXi, preserve VMFS datastoreを選択すると、問題なく先に進むことができた。ただし、ESXiの設定はすべて消えてしまうため、ネットワークや仮想マシンの登録、NFSやiSCSの設定などを再設定する必要があるため注意となる。

6. インストールの最終確認

あとは、言語やrootのパスワードを設定したのち、最終確認画面が表示される。問題なければF11キーを押せばよい。

インストールが開始する。容量が小さいので数分で完了するはずである。

7. インストール完了

インストール完了画面が表示されたら、エンターキーを押して、再起動を行う。

8. ESXi起動

再起動後、問題なければ以下のような画面が表示されるはずである。

9. インストール後初期設定

以降の手順の詳細は割愛するが、以下のような手順で進めればよい。

・管理ネットワークのIPアドレスやホスト名を設定
・VMware Host Clientに接続

・Host Clientにて、ネットワークの設定を実施。この際に、もともと使用していたネットワークラベル名で再設定を行う
・Host Clientにて、データストアブラウザを開き、「.vmx」ファイルを右クリックして、「仮想マシンの登録」する。これにより仮想マシンが登録され起動できるようになる。また、事前にネットワークラベルを正しく再作成しておけば、特にNICの設定変更等は不要で、そのまま仮想マシンを起動できるはずである

以上で結果的にESXi 6.0をESXi 6.7にアップグレードすることができた。途中で発生したRealtekのNICドライバーの競合が発生しないような場合では、もともとインストールされていたESXiの設定引き継がれるはずなので、手順がもっとシンプルになるはずだ。

ESXi 6.7の仮想マシンのネットワークアダプタで、ポートグループが設定できなくなる問題

ESXi 6.7において、仮想マシンのネットワークアダプタに対してポートグループを設定しようとした際に、以下画面のように本来存在するはずのポートグループが表示されず、設定ができなくなる事象が発生した。

いろいろ調べると発生する原因がわかったので、発生原因と対策について記載することにする。

発生原因

本事象を発生させる手順を説明することにする。まず、ポートグループが以下2つある状態から作業を実施する。

• VM Network : 仮想マシン用ポートグループ
• Management Network : VMkernel用ポートグループ

作業前のvSwitchの状態は以下の通り。 ポートグループ「VM Network」に「test」という仮想マシンが1台存在する状況となっている。

ここで、VMkernel NICを追加してみる。その際に、ポートグループを「VM Network」に設定する。

作成後のVMkernel NICの状態は以下の通り。

設定後のvSwitchの状態は以下のようになる。

ポートグループ「VM Network」にVMkernelポートが設定されることにより、仮想マシンのポートが消えしまっている。これが原因で、仮想マシンの設定画面においてもポートグループの設定ができなくなってしまうようだ。
※ただし、設定ができなくなるだけで、仮想マシンの通信には影響はなかった。

どうやら、1つのポートグループにVMkernelポートと仮想マシンのポートの共存はできないようだ(であれば、共存設定ができてしまうこと自体が問題な気がするが)。

回避策

VMkernel NIC作成の際に、VMkernel NIC専用の「新規ポートグループ」を作成すればよい。

この場合のvSwitchの状態は以下の通りとなる。

上記設定に変更した場合、以下の通り、仮想マシンからも正常にポートグループが選択できるようになった。