1月9日長野新幹線車両センターの状況

大雪と言われていたのですが、雪が降っていないので長野新幹線車両センターを訪問してみました。

長野新幹線車両センターの状況

明け方は留置線がいっぱいですが、その時間はスマホでの撮影が厳しいので、日が昇ってきてからの撮影です。外部の照明や車内灯、前尾灯も点灯し、活気ある長野新幹線車両センターが戻ってきました。

夜明けの長野新幹線車両センター

W7の状況

今回は車輪転削庫近辺から。6号車が切り離されて消えています。

W7 長野寄り5両、奥からW723-107, W726-107, W725-107, W726-207+W725-207

これが1月6日水曜日の写真です。わかりにくいかもしれないですが、中央少し左の建屋の所にあった6号車が消えているのが、写真の比較でわかるかと思います。

W7 長野寄り6両、奥からW723-107, W726-107, W725-107, W726-207+W725-207, W726-307

留置線側から見ても、5両になったのがわかります。

右端に写る W7 の長野寄り5両

その6号車W726-307 は奥の5両から切り離されて、車輪転削庫内に多分アントとつながれて留置されています。写真では非常にわかりにくいのですが、6号車の屋根上が隙間から見えます。

W726-307

この角度からは車両の在線はわかりません。

車輪転削庫

6号車が切り離されましたが、そのほかの5両の動きはありません。予想通り、1両づつ切り離しして、次の解体行の車両は車輪転削庫にアントといっしょに収容という形のようです。建屋内収容なら雪でドアなどが凍ったりしないので、適切な措置かなと思いました。

W723-107

臨修庫奥は、9号車 W725-407, 8号車 W726-407, 7号車 W725-307 の 3両に変わりました。

W725-407はいよいよ車体解体待ちになっています。

W725-407

W726-407は、窓ガラスが外されていました。3連休があるので作業が早めのような気がします。

W726-407

7号車のW725-307は車内の撤去中。夜間など人の居ない時には妻面の隠し扉を閉めています。

W725-307

これでE7系 / W7系で形あるのは、車輪転削庫線にある残り6両になりました。

W725-407, W726-407, W725-307

留置線の状況

検修庫も使っているのでどのように留置しているかは早朝に行かないとわかりません。ただ、線路の状況を見ていると、1番線～5番線はまだ使っていなくて留置は6番線～11番線のまま、そして検修庫側には8番と11番を使ったようなので、昨日の東北新幹線のつららでの運転不能もあったことから、早朝の列車は一度検修庫に収容して点検した後に出庫しているのかなと思ったりしました。実際はどうなのかわかりませんが。

留置線みたまま

朝の検修庫は3線とも扉を開けています。検修庫から全ての列車が出庫した後、検修庫の扉は閉じられます。

出庫直前の検修庫

このように、検修庫からの出庫しています。1番線と2番線は空いていて3番線からの出庫です。

検修庫からの出庫

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 1月9日見たまま

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

解体の手が入っていないのは残り 6両。先が見えてきました。また、生首のE723-18や銀色のシートにくるまれたE7の台車、青色のシートにくるまれて線路の上にあるW7の台車には動きなく、生首前には雪が積まれ、台車は雪にうずもれていました。

1月6日長野新幹線車両センターの状況

近所を通ったので、少しですが新年初の長野新幹線車両センターを訪問してみました。

長野新幹線車両センターの状況

検修庫の使用開始に伴い、留置車両が転動して営業車に影響が出ないように、生きている線につながる線には車両を留置しないようになったみたいです。いつもなら必ず1両留置していた検修庫脇の引き上げ線には、車両もアントも置いてありませんでした。

そして、いつも渡り線手前に次の解体対象を留置していたのですが、こちらもそのまま転動すると渡り線経由で営業車に支障してしまうので、車輪転削庫より奥にだけ留置するようになっています。

生首のE723-18や銀色のシートにくるまれたE7の台車、青色のシートにくるまれて線路の上にあるW7の台車には動きはありません。

W7の状況

今回は車輪転削庫近辺から。

W7 長野寄り6両、奥からW723-107, W726-107, W725-107, W726-207+W725-207, W726-307

W7編成の長野寄り6両の動きはありません。7号車W725-307が臨修庫奥に押し込まれるまでは、動きはないでしょう。というのも、既に留置線全てと検修庫が使用開始になっており、奥に留置されている6両を引き出すとしても、アントを使って入替えをするには手前の 7号車と 8号車が邪魔で、それをどこかの線に一時的に置いてアントが奥に入っていくということをしたくても、その一時的に置ける線が今はありません。つまり、一本線で引き出して、V字で解体場所に持っていくしかない状態になってしまっているので、これからの W7の解体は、1両づつ持っていくスタイルになるのではないかと思います。

7号車W725-307は車輪転削庫内に、多分アントとつながれて留置されています。写真では非常にわかりにくいのですが、7号車の屋根上が隙間から見えます。

7号車W725-307

全く動きのない6両。

W723-107

臨修庫奥はW715-507が消え、10号車 W726-507, 9号車 W726-407, 8号車 W725-407 の 3両に変わりました。

W726-407

W725-407

W726-507

もしかしたら、W715-507 は臨修庫内？と思いたくなりますが、搬出のある水曜日で既に静かなので、午前中に搬出されたものと思います。これでE7系 / W7系で形あるのは残り10両になりました。

W726-507, W725-407, W726-407

留置線の状況

丁度検査終了後の車体洗浄をしている所に出くわしました。逆光で編成番号は読み取れませんでした。

車体洗浄中

動いている E7系 / W7系を見ると、「いよいよ復活だね」と感じます。

留置線の状況　真ん中は営業車、車輪転削庫奥に W7

右端にあるW7が解体され、臨修庫と車輪転削庫が修繕完了すると、すべての機能が元に戻ります。W7解体完了がこのままだと1月末か2月になるように思うので、それら建物の修繕は 3月か 4月から始まるのではないかと思います。

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 1月6日見たまま

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

解体の手が入っていないのは残り 7両。先が見えてきました。

ESXi Arm Edition をシリアルコンソール化

今回は ESXi Arm Edition をインストールした Raspberry Pi 4 をシリアルコンソール化し、ヘッドレスシステムにしてみました。

ヘッドレスシステムの ESXi

ESXi のヘッドレスシステム

ESXi では昔からマウスやキーボード、ディスプレイモニター（VMware では MKS：Mouse, keyboard, Screenの略）を使わない、ヘッドレスシステムをサポートしています。このヘッドレスシステムですが、通常は特別な設定を必要とせず、条件が合致すれば自動的にヘッドレスシステムとして検出され、シリアルポートからコンソール操作ができるようになります。

ESXi のヘッドレスシステム検出時の動作

動的な通信速度の設定

ESXi では、MKS のないホストが検出されると自動的にシリアル ポートに対して COM1、115200 ボーに設定して、シリアル ポートに対してDCUI（ダイレクト コンソール ユーザー インターフェイス ）をリダイレクトします。（最終的にシリアルポートは、Port com1, Speed 115200 Baud, Data 8bit, Parity  none, Stop-bit 1, Flow control none で通信をします。）この通信設定の情報の詳細は、SPCR （シリアル ポート コンソール リダイレクト）テーブルがある場合は、そこから値が読み込まれます。このデフォルト設定が無い場合、手動でパラメータを設定し、ヘッドレスとして指定することもできます。

 ※ESXi では速度を Baud の値が出ています。bps ではないので注意。Baud は変調の速度で、bps はデータ信号の伝送速度の単位で、実際の値は同じ場合が多いのですが、電話回線での通信のように、位相変調を使って伝送を行ったりする場合、Baud の伝送速度がbpsより高くなることがあります。

動的なモードの設定

 ESXi が動的にヘッドレスモードを検出すると、シリアルポート経由で通信を始めます。このモードをシリアルポートモードと呼びます。シリアルポートモードでは、入力されてくる文字列のシーケンスに基づき、DCUI（ダイレクト コンソール ユーザー インターフェイス）、シェル、GDBまたはログの各モードで動作します。4つのモードは以下のようになっています。

• ログ モード：デバッグ ビルドのデフォルト モードで、vmkernel.log をシリアル ポートに送信
• GDB モード：デバッグ専用の場合に使用
• シェル モード：SSH のようなシェル ポート アクセス
• DCUI モード：ダイレクト コンソール ユーザー インターフェイス

シリアルポートはデフォルトで2つのポートをサポートしていて、それぞれ1つ目のcom1にはGDBとログが、com2にはDCUI（ダイレクト コンソール ユーザー インターフェイス）とシェルが出力されます。

それぞれのモードはデフォルトの設定の場合、キーボードのキーシーケンスで切り替えができます。

• ログ モード： Ctrl+G, Ctrl+B, 1
• シェル モード： Ctrl+G, Ctrl+B, 2
• DCUI モード： Ctrl+G, Ctrl+B, 3
• GDB モード： Ctrl+G, Ctrl+B, ?

操作は最初に「Ctrl+G」を押し、次に「Ctrl+B」、そして最後にモード切替の 1, 2, 3, ? をキー入力します。

ログモード Syslog に書き出していれば使わない、そしてGDBモードにしてしまうと、その後はシリアルモードに対して一切の操作ができなくなる（CLIに入ってモードを強制変更しない限り、GDBモードから抜けられない。）ので、通常はDCUIモードとシェルだけで使うと思います。

なお、間違えてGDBモードにしてしまったりしたら、CLI から以下のコマンドで復旧します。

• ログ モード： esxcfg-advcfg -s com1 /Misc/LogPort
• シェル モード： esxcfg-advcfg -s com1 /Misc/ShellPort
• DCUI モード： esxcfg-advcfg -s com1 /Misc/ConsolePort
• GDB モード： esxcfg-advcfg -s com1 /Misc/GDBPort

太字の部分を適切な値、com1 / com2 / none を指定して切り替えます。先に現在のモードを無効にして、次に新しいモードを設定します。

esxcfg-advcfg –s none /Misc/LogPort

esxcfg-advcfg –s com1 /Misc/ConsolePort

このような感じです。

ESXi 側でヘッドレスシステムを設定する

そうはいっても Raspberry Pi 4 で ESXi Arm Edition を使う場合、その小さなサイズを活用して MKS を接続しないのが普通だと思います。しかし、うまく自動的に切り替わらなくて（切り替わらなかったことは無いですが・・・・）操作できなくならないように、ESXi 側も設定変更しておきます。

ESXi に vSphere Host Client でログインし、管理=>システムに移動します。

管理=>システム

検索窓で VMkernel.Boot.tty1Port を指定して、キーの内容を表示します。値が default なので、キーを選択しオプションの編集をクリック、下に表示されている値から該当するものを入力します。Raspberry Pi 4は UART が 0～5 まであり、シリアルポートも設定すれば複数使えるのですが、Raspberry Pi 4 デフォルトの設定では 1つだけで com1 をのみ、そして ESXi 側はログやGDBが通常使用している tty1 が、デフォルトで com1 を使っています。これを変更して VMkernel.Boot.tty1Port を com2 に変更します。（com1 を使わせないということなので、com2 以外でもよいです。）

VMkernel.Boot.tty1Port（変更前）

次に、DCUI が使用する tty2 に対しては、逆にデフォルトが com2 なので、com1 に変更します。

VMkernel.Boot.tty2Port（変更前）

同じように VMkernel.Boot.gdbPort を none に

VMkernel.Boot.gdbPort（変更前）

VMkernel.Boot.logPort も none に変更します。

VMkernel.Boot.logPort（変更前）

最終的に、以下の4つの値が変更されていれば、準備は完了です。初期値はデフォルト設定の際に使われる値で、それを変更するわけです。

キー	デフォルト設定	初期値	設定値
VMkernel.Boot.gdbPort	default	com1	none
VMkernel.Boot.logPort	default	com1	none
VMkernel.Boot.tty2Port	default	com2	com1
VMkernel.Boot.tty2Port	default	com2	com1

これだけで、ヘッドレスシステム化（シリアルコンソール化）は出来上がりです。

私の場合、念のために boot 時にこの設定が反映されるよう、boot.cfgにも以下のパラメータを追加しています。

ファイルの場所：/bootbank/BOOT.CFG

修正内容： kernelopt にオプション gdbPort=none logPort=none tty2Port=com1 を追記
修正前

kernelopt=FeatureState.bnxtroce_unstable=enabled autoPartition=FALSE FeatureState.nmlx5_rdma_unstable=enabled FeatureState.bnxtnet_unstable=enabled FeatureState.ena_unstable=enabled FeatureState.nmlx5_core_unstable=enabled

修正後

kernelopt=FeatureState.bnxtroce_unstable=enabled autoPartition=FALSE FeatureState.nmlx5_rdma_unstable=enabled FeatureState.bnxtnet_unstable=enabled FeatureState.ena_unstable=enabled FeatureState.nmlx5_core_unstable=enabled gdbPort=none logPort=none tty2Port=com1

これで起動時にGDBとログを使わずに、DCUI を com1 に出せるになりました。

ヘッドレスシステム ESXi Arm Edition の画面キャプチャ

いつもの DCUI

DCUI ログイン画面

System Customization 画面

System Customization 画面

画面表示はみんな一緒

他の操作画面

コマンドラインシェルモード

シェルモード

ログイン後の画面

最後の行は表示切れているけれど、すべての表示はされている

Raspberry Pi 4 の設定

Raspberry Pi 4 側の設定は、raspi-config コマンドを使ってシリアルポートを有効にするだけです。Raspberry Pi OS で Raspberry Pi 4 を起動し、コマンドプロンプトから

sudo raspi-config

コマンドを実行し、5 Interfacing Options=> P6 Serial でシリアルポートを有効にするだけです。これで再起動すれば Raspberry Pi 4 はシリアルコンソールが使えるようになります。

Raspberry Pi 4 からシリアルポートを取り出す

Raspberry Pi 4 では複数の　3.3V シリアルポートを GPIO ピンから取り出すことができます。そして、それぞれ別々の設定で動作させることができます。（UART0～UART5）

 しかし、シリアルポートを有効にして使えるのは一つだけ、UART1 の mini UART だけです。他はごにょごにょしないと使えません。（UART0 は Bluetooth につながっています。）

UART1 は GPIO の以下のピンと接続されています。

• TXD　GPIO 14 => 8番ピン
• RXD　GPIO 15 => 10番ピン

詳細のピン配置は以下を参照してください。

www.raspberrypi.org

つまり、シリアルポートとして取り出すには、この2つのピンと Grand を取り出せば OK です。

シリアルポートを取り出すアダプタは、以下のものを使いました。他にも同等の Raspberry Pi 4 で使えるものが出ているので、お気に入りのものを使うとよいと思います。

Amazon.co.jp： GAOHOURaspberry Pi ラズベリーパイ用の USB－TTLシリアルコンソールのUSB変換COMケーブルモジュールのケーブル: 家電・カメラこれはまさにダメなものでした。先日の Windows UpdateをかけてWindows 10を新しいバージョンにしたところ、早速使えなくなってしまいました。PL2303 / PL2303HX / PL2303HXA もものは、安くても買わないほう場無難です。私も買いなおしました。

ただ、このアダプタも使用しているものは PL2303HX なので、いつ使えなくなるかわかりません。できれば FTDI 対応のものを使うことをお勧めします。同じようなタイプで PL2303 のものや CH340 のものもあるのですが、それぞれ正規チップではなくてコピー品の互換チップのものが多く出回っています。互換チップだと Windows 10 などでは動作しない＆チップベンダーのドライバからもはじかれるので、チャレンジせずに動作実績のあるものを選択するのが良いと思います。正規品は Windows 10 で何もしなくても認識されます。
なお、PL2303HX などの互換チップを買ってしまった場合は、PL2303_Prolific_DriverInstaller_v1.5.0 のような古いドライバを適用すると動きます。ベンダーサポート対象外なのでリンクは載せませんが、探してみれば見つかるかもしれません。

接続はこのアダプタであれば白い線を8番ピンに、緑の線を10番ピンに、黒い線はいずれかのGrandに、そして赤い線は使いません。そして、USB 側は PC に接続するだけで使用できるようになります。

接続例：8番、10番そして14番を使っています。（6番Grandはファンが使っているので）

これだけで、ヘッドレスシステムの ESXi 出来上がりです。この記事では ESXi Arm Edition をヘッドレスシステム化する例として書きましたが、この内容はそのまま x86 の ESXi でも利用できます。KVM 使ってマウス、キーボード、モニターを切り替えている環境から、全てシリアルポートで管理するシンプルな構成に変えてみるのも面白いかもしれないですね。私は次にシリアル<=>Ethernet変換アダプタを使って、LAN経由でコントロールするようにしていく予定です。

おまけ

購入したけれど使っていなかった Chromebookをシリアルコンソールサーバーにしました。

Chromebook をシリアルコンソールサーバにした

/dev/ttyUSB0 ～ USBハブでシリアルコンソールケーブルをつないだ分だけ管理ができるので、これでようやく Chromebook も有効活用できそうです。

-----

[2021年1月20日：Windows Update で PL2303がだめになる部分を追記]

解体された E7系／W7系の先頭車他、昨年のトピック

明けましておめでとうございます。新年初めての記事として、今まで解体された E7系および W7系の先頭車の写真をまとめてみました。最初の頃は災害復旧と火事場泥棒対策の警察の巡回も厳しかったため行くのを避けていました。そして、水害半年後の5月以降から訪問及び写真を撮影するようにしてきていますので、3月初旬に解体完了した F10、そしてその後に解体が始まった F7のグランクラスの3両の写真はありません。撮影できているのは E723-10 以外の 6両と W723 2両、E714は 5月前に解体完了している -7, 10, -14 の撮影ができませんでした。また全部 iPhone での撮影なので、撮影場所の都合でまともな写真じゃないのもありますが、とりあえず撮影できている先頭車両の写真をまとめました。

なお、W7 の W723-107 はまだ解体されていませんので、現状の写真のまま掲載しています。

E714 / W714 グランクラス

E714-1

E714-1

E714-2

E714-2

E714-7

撮影できず

 E714-8

E714-8

E714-10

撮影できず

E714-14

撮影できず

 E714-16

E714-16

E714-18

E714-18

W714-502

W714-502

W714-507

W714-507

E723 / W723

E723-1

E723-1

 E723-2

E723-2

E723-7

E723-7

 E723-8

E723-8

E723-10

撮影できず

E723-14

E723-14

E723-16

E723-16

E723-18

E723-18

W723-102

W723-102

W723-107

W723-107

特徴的な動きがあった2両

特徴的な動きがあった、F7 の E723-7 と E723-18 の 2両です。

E723-7

E723-7 長期留置場所に移動したとき

E723-7 置きっぱなし

E723-7 解体中

E723-18

E723-18 解体中

E723-18 切り落とし断面

吊り上げ

E723-18 カバーをかけて吊り上げてトレーラーへ

積み込み

E723-18 構内移動

トレーラーで移動

カーブはゆっくりと

E723-18 トレーラーから降ろして設置

E723-18 雪の中

 E7 系の台車

E7系の台車 1セット

E7系の台車アップ

W7系の台車

W7系の台車 1セット

搬出車体

E714-1

けっこう凸凹に積んでいる

真ん中に方向幕部と右にE7系ロゴ

手前は車体の肩の部分

E725-18

奇麗に積んでいる

手前は車体の肩の部分

屋根の肩の部分が多い

車両避難訓練

JR関係者の送迎バス

訓練列車の出発を撮影中

訓練編成の F13 が 6番線に

 復活した長野新幹線車両センター

水没後、一番手前で車両を入換ながら車両の点検中

F2の入替え中。2番線は F1で 1番線は W7

窓と扉の撤去

仕業交番検修庫の窓とドアの取り換え

中の工事

仕業交番検修庫内の工事

正面扉の工事

正面扉辺りに足場をかけて工事

復活直前の、洪水対策を済ませた仕業交番検修庫

架線死活表示器は「切」

復活直前の、仕業交番検修庫

架線死活表示器は「入」

検査開始後の、仕業交番検修庫

仕業交番検修庫のドアオープン

仕業交番検修庫に活気が戻ってきた

12月29日長野新幹線車両センターの状況

御用納め後の、長野新幹線車両センターを訪問してみました。

長野新幹線車両センターの状況

流石に御用納めの後は何もしていませんでしたが、先週の12月26日に訪問した際に渡り線手前に置いてあった 2両、7号車 W726-307 と 8号車 W725-407 が、車輪転削庫内に収容されていました。但し、車輪転削庫の収容できる長さが 1両分なので、7号車は半分外に出ています。

外に出ている W726-307

残りは建屋内、

建屋の隙間から見える W725-407 の屋根

アントを見かけることができなかったのですが、もしかしたらこの8号車の前に転動防止のストッパーを兼ねて収容されているかもしれません。

W7の状況

臨修庫奥の 11号車 W715-507, 10号車 W726-507, 9号車 W726-407 の状況は変わらず。

W725-407 の外された扉もそのまま

W725-407

W726-507 はガラスもそのまま残り、

W726-507

写真ではわからないですが、W715-507 も変わらずです。

W715-507

もしかしたら、W714-507 は臨修庫内？と思いたくなる光景です。残りの6両、W723-107, W726-107, W725-107, W726-207, W725-207, W726-307 は写真を撮影しませんでしたが、車輪転削庫奥にそのまま置いてあります。

留置線の状況

朝はぎっしりの留置線は、日中は全てで払っていて閑散としています。水害発生前には近所に来ても全く訪問しなかったのは、このように車両を見ることができなかったからですね。右奥に留置状態の W7 6両が見えます。

日中の留置線

早朝深夜の留置線（12/26撮影）

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 12月29日見たまま

いつもは解体待ちの車両が置いてある場所も、奇麗さっぱり車両無し。

検修庫側

年末年始はこの状態ですね。

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

今年の解体作業は終了のようで、次の動きは御用始めの 1月4日以降ですね。

ESXi Arm Edition v1.2 でどこまでできるか「vSphere沼にハマっておぼれてみた」vSAN編

前回のESXi Arm Edition v1.2 でどこまでできるか「vSphere沼にハマっておぼれてみた」では,

Raspberry Pi 4 と周辺装機器を用意しハードウエア組み立てと ESXi Arm Edition のインストール、そして vCenter Server への登録（データセンターとクラスタへ）までやりました。今回はその先、外付けした USB ケースに入れた M.2 SSD デバイスを使って vSAN を組んでみます。

前回のおさらい

前回の記事では、Raspberry Pi 4 に ESXi Arm Edition をインストールした 4ホストを、vCenter Server の「クラスタのクイックスタート」を使い、クラスタ構成するところまで行いました。そして、vCenter Server のバージョンによっては vSphere HA の検証ができるので、その環境のための VIB のインストールまで説明をしています。以下の状態ですね。

クラスタ

今回はその先、「3.ホストの設定」から進めていきます。

まずはストレージデバイスの準備

今回は一般的な x86_64 のハードウエアではない Raspberry Pi 4 を使うため、ストレージ関連のデバイスは全て Micro SD または USB でつながなければなりません。Micro SD はUEFI や今後は ESXi Arm Edition のブート用に使われるので、ストレージデバイスとして使うことはできません。それより、そもそも Micro SD のメディア書き込み制限が先に来てしまうでしょう。そこで、今回は USB 3.x のケースに入れた M.2 SSD を 3本用意して、ストレージデバイスとして使うことにしています。

M.2 SSD を使った USB ストレージデバイス

でも、このままではどんなに頑張っても vSAN の必要とする SSD としては認識されず、USB Disk としか認識されません。そこで、すべてのデバイスに対して「私は SSD ですよ！」と認識させるおまじないを掛けます。おまじないと言っても esxcli コマンドですね。

まず、USB デバイスを仮想マシンにパススルーするサービスを停止します。これは前回やっているのでここでは作業しないで良いのですが、一応流れとして思い出せるように記載します。

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off

これで USB ストレージデバイスがそのまま見えるようになりました。

Diskの状態

次のおまじない、vSANがUSBストレージを使えるように詳細設定を追加します。以下のコマンド 2つを入力します。

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

これで Disk にしか見えなかった USB 3.x のケースに入れた M.2 SSD が SSD として見えるようになりますので、次は STAP に新規ルールを追加

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba32:C0:T0:L0 -o "enable_ssd enabled_local"

最後の "enable_ssd enabled_local" は実際には "enable_ssd" だけで機能します。次にパスのマスク解除。

esxcli storage core claiming unclaim -t device -d mpx.vmhba32:C0:T0:L0

そして、ルールを再読み込み、読み込んだルールの実行。

eesxcli storage core claimrule load
esxcli storage core claimrule run

最後に vSANに Flash だよと認識させる設定を追加。

esxcli vsan storage tag add -d mpx.vmhba32:C0:T0:L0 -t capacityFlash

これで Disk にしか見えなかった USB 3.x のケースに入れた M.2 SSD が SSD として見えるようになります。

SSDに変身

クイックスタートの続「３．クラスタの構成」

ここまで準備ができたら左ペインでクラスタを選択し、中央ペインで「設定」=>「クイックスタート」と進んで、「３．クラスタの構成」を開始します。[構成]ボタンをクリックして Distributed Switch を設定、アップリンクが 2つ必要なのに対して 1つめは Raspberry Pi 4のオンボードの vmnic128 を、2つめは USB の 100M の NIC vusb0 を指定して、とりあえずエラーにならないようにします。

Distributed Switch

次は vSAN ストレージトラフィック用の IP アドレスを指定します。DHCP 配布しているならそのまま、していなければホストごとに固定 IP アドレスを設定します。

ストレージトラフィック

詳細オプションは、このクラスタをどのように構成するかになります。さすがに Raspberry Pi 4 でストレッチクラスタまでやることは無いと思うので、NTP サーバーを指定するだけで先に進みます。この詳細設定で気になる設定項目「Enhanced vMotion Compatibility」（EVC）は、CPU Platformが全く異なるので使えません。なので、設定もできないようにグレーアウトで出てきます。

詳細オプション

先のコマンドでしっかり Flash として設定ができていると、次の「ディスクの要求」では以下のように自動的に推奨構成としてディスクの構成が行われます。

ディスクの要求

ホスト単位で見ても、期待通りの構成が組まれていました。

ホスト単位でグループ化

最後にプロキシーを使っている場合の設定がありますが、我が家の家ラボでは使っていないのでそのまま先に、

プロキシ設定

確認画面は内容を確認して、問題なければ[終了]で構成を開始します。

確認画面

これで Raspberry Pi 4 上の ESXi Arm Edition に vSAN が出来上がりました。

vSANの物理ディスク

データストアとしても見えるようになります。

vSANDatastore

かなりイレギュラーな形で Raspberry Pi 4 の ESXi Arm Edition 上に vSAN 組んでいますので、もちろん性能や意図しないトラブルもあるかもですが、とりあえずそれっぽく組めたので良しとします。

12月26日長野新幹線車両センターの状況

クリスマスも終わった年の瀬の最後の週末、雪の降る中訪問してきました。

長野新幹線車両センターの状況

12月22日に検修庫への試運転が行われマスコミに公開された後、12月25日から臨修庫（臨時修繕庫）と車輪転削庫（車輪研削庫）本稼働した長野新幹線車両センター。列車の検査をする検修庫（仕業交番検査庫：仕交検査庫）も息を吹き替えしています。

仕交検査庫全景

パッと写真を見ただけではわからないかもしれませんが、正面扉が全開し中の明かりもついているのが見えます。

そして正面上部の架線死活表示器も

架線死活表示器

しっかり赤く「入」電気が来ていることを示しています。

W2の状況

水曜日には残っていた W2 ですが今日は既に姿もなく、最後の 1両の W715-502 も昨日搬出済みのようです。どうやら W715-502 の解体作業は早かったようですね。そして、その代わりに臨修庫内には W714-507 が収容されています。今日一気に解体していくという感じでしょうか。

W7の状況

そのような流れの中、臨修庫奥は臨修庫側から 11号車 W715-507, 10号車 W726-507, 9号車 W726-407 が解体されています。W7最初の解体車両、グランクラスの W714-507の姿は見られないので臨修庫内で車体の解体中、もしかしたら今日の夕方か月曜日に搬出になるかもしれません。ということで、車両の状態で今日見られるのは、W714-507 除いた 11両です。

W715-507, W726-507, W725-407

前々から気になってはいたのですが、時々この W725-407 のように先に扉が外され、その場所を別のもので養生している車両があるのですが、これは何をした結果なのかが気になります。部品として確保したのか、それとも開けることができない程固着してしまっていて壊して撤去したのか、どちらにしても廃車なので構わないのでしょうが、わざわざ別のもので塞いでいるのは、盗難対策なのかもしれないですね。

一番手前の 9号車 W725-407 は、金沢寄りの扉以外は見た目変わらず。車内の撤去だけのようです。

W725-407

次の 10号車 W726-507 も外観はガラスの撤去もまだのようで、車内の撤去のようです。

W726-507

一番奥の W715-507 はガラスも外され、臨修庫内の W714-507 搬出後に直ぐに車体解体に入れそうです。

W715-507

次に 8号車の W725-407 と 7号車の W726-307 は、いつものアップルブリッジ赤沼の近くに置いてあります。水曜日と同じ場所で動かずですね。

W726-307, W725-407

残りの6両、W723-107, W726-107, W725-107, W726-207, W725-207, W726-307 も、車輪転削庫奥のままです。

W726-307, W725-207, W726-207, W725-107, W726-107, W723-107

この 6両を動かすには手前の W726-307, W725-407 をどかさなければならないのですが、留置線も検修庫も復活した現在アントの走れる範囲が狭まっているので、この6両の移動は W726-307, W725-407 が移動し終わってからかもしれません。なので、来週以降か来年入ってからでしょうか。

今日のアント、臨修庫前に停まっていました。検修庫脇は留置線からまっすぐ移動できる場所のため、営業車両がやってくる可能性もあります。そのため直接営業車両とバッティングしない臨修庫前に置いているのかもしれません。

アント

留置線の状況

 留置線は夜間 6本いるようで、依然と同じように 6番～11番が使われています。1番～5番はダイヤ改正後に使われるのでしょうか。

留置線

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 12月26日見たまま

奥のほうに少し見える W7の残り6両以外は、昔の長野新幹線車両センターに戻ったように見えます。

留置線、本線側から

留置線からの出庫は、5:40、5:50、6:20、6:45、7:05と出発していきます。なので、その時間に合わせてアップルブリッジ赤沼または留置線長野寄りに行くと、つららを切り裂いていきパンタグラフから火花を出して出庫する新幹線を見ることができます。この時期限定の光景です。そして、時々タイフォンを鳴らして出発する列車もあります。明け方の冷たい空気の中、タイフォンを鳴らして出発する新幹線 E7、格好が良いです。

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

W7 の解体も本格化、W714-507 と W715-507 が年内解体完了しそうです。あと少し、来年1月末には全ての解体が終わりそうな勢いになりました。

おまけ

E723-18 の生首の動きはありません。

E723-18

E7系の台車もそのまま。

E7系の台車

W7系の台車は、ブルーシートが裂けて空気ばねが露出していました。

W7系の台車