ESXiの最近のブログ記事

ESXiサーバのケースファンを交換しました
昨年チェックしたときにファンの音が目立つように感じたため。
加えて夏を迎える前に気になるところはケアしておきたいというのもあります。


ということで新しいファンに交換。
使用したのはKAZE FLEX 120 PWM。

取り付けにあたってファンの「向き」を確認します。
いくつか確認方法がありますが、私の場合は以下のどっちかです。

• ファンそのものにある記載を確認する
• PCに取り付けて稼働させる

今回はファンの記載を確認しました。





これですね。
横向きの矢印が風が出る向きを示しています。
縦の矢印はファンの回転方向でしょうね。


稼働させて確認するのはどうしても向きが確認できなかった時か、確認するのを忘れて取り付けてしまった時。
どちらかと後者のパターンが多いです......
起動後UEFI（BIOS）に入ってファンの風向きを確認。
手をかざして風を確認してもいいですし、ちり紙を細くちぎってファンの前に出せば目視確認が出来るかと。


ファンの向きが確認できたところで取り付けます。
排気ファンとして使うので外に風が出るように取り付け。





前面吸気の後方排気です。

ファンを交換してファンの音は静かになったように感じます。
交換した効果はあったようです。

先に結果を述べますと「ESXi 6.7 update3で問題なく動作」。


そもそものはじまりは先日ESXiのハードウェアを更新したこと。
その時の残作業がゲストOSが入ったHDDの交換。
詳しく言うと、

非Advanced Formatの500GB HDD
から
Advanced Formatの2TB HDDへと交換

なのです。


最大の懸念はAdvanced Format。セクタサイズが512byteから4096byteに変更された件ですね。
事前調査でESXi 6.7 update2以降なら問題ないということがわかっていましたが、やっぱり不安なわけで。
使用したのはWD Red WD20EFAX-RT。2TBのHDDになります。




結果は一番最初に記述したとおり問題なく動作。

デバイスの認識問題なし。
データストアとしての設定問題なし。
非Advanced FormatのHDDで使用していたゲストOSのコピー操作問題なし。
ゲストOSの起動と動作問題なし。
ゲストOSを起動後24時間以上経過でゲストOS/ESXiともに問題なし。




これにて予定していたESXiのハードウェア更新完了！
非Advanced FormatのHDDを探さなくても済むのは嬉しい。まだ売ってますけど選択肢狭いですからねぇ。
これで今後も安心して使うことができますよ。

ESXiサーバのハードウェア更新を実施しました。
きっかけは先日のESXi 6.7 u2アップデート。
このときハードウェアのさまざまな部分に問題が出ている・出そうだことが判明。
じゃあ全部入れ替えてしまいましょう、ということです。

構成は以下の通り。

• CPU
  Core i3 8100T
  
  
• CPUファン
  サイズ 白虎 弐
  
  
• メモリ
  Crucial 8GBx2(16GB)
  
  
• マザーボード
  ASUS H310M-A R2.0
  
  
• ケース
  IN WIN IW-EM035 USB3.0
  
  
• OS起動用SSD
  WD Green WDS120G2G0A
  
  
• ゲストOS格納用HDD
  WD Red WD20EFAX-RT

今まではずっとキューブ型ベアボーンでしたがそれをやめました。
確かに場所は取らないし静音性も高い。
ただですね、拡張性は押して図るべしですし何より故障時の交換部材が少ないのですよ。電源とか・・・
その辺を考慮して上記の選択となりました。



今回特筆すべきはCPUとケースです。


CPUはとにかく省電力低発熱。なのでTDP35WのCPUにしたい。
しかしIntelCPUの在庫が全然ない。いや、あるはあるんですがミッドからハイエンドのものばかり。
新品で省電力版のCPUなんで皆無ですよ。中古を探して購入しました。
AMDという選択肢もありましたが私の経験不足による問題が起きそうだったので今回はパス。

CPUファンもあわせて購入。それほど気合入れて冷やす必要は無いのでエントリークラスのものを選択。
先日購入した「MONOCHROME VALUE」でもよかったのですが今回はサイドフローを試すこととしました。
最近はトップフローよりサイドフローの方が選択肢多いみたいなので。


次にケース。そこそこ小さくてそこそこ取り回しが良くて出来るだけ普通のもの。
これらの条件をクリアするのがIN WINのIW-EM035 USB3.0。
M-ATX用のミニタワーとしてそこそこ小さくてそこそこ取り回しがよい。
それでもって普通の構造。

小ささを追求するなら別のケースもありますが、このケースは無理がない範囲で小さいのが良いんです。
3.5インチベイはシャドウベイも合わせて４つありますので拡張性もあります。
不要であればシャドウベイ2つ分の取り外しが可能です。
それらとは別に2.5インチのシャドウベイも１つ持っています。



以下はケースに途中まで組み込んだときの写真。

シャドウベイ2つ分は不要なので取り外しました。本来なら前面ファンの前につきます。

HDDはまだですが空間はいい感じに空いているかと。エアフローも問題ないはず。
これだけの大きさがあれば将来の拡張ないし別の用途に転用となっても使いまわすことができるでしょう。
個人的におすすめのケースですね。詳しくはメーカーサイトをどーぞ。




残りのパーツをさくさくと組んで動作確認をします。
温度が見たいのでMemtest86を30分ほど動かして確認。





マザーボードの温度が32度。CPUの温度が（見づらいですが）こちらも32度。
問題ないでしょう。


その後ESXi 6.7を新規にインストール。パッチを当てて6.7 Update3となりました。
作業時間の都合でゲストOS用HDDはそのまま利用します。
旧サーバからゲストOSの入っているHDDを移植。ゲストOS起動してひとまず作業終了。


ゲストOS用HDDを変える作業はまた後日実施。

ESXi 6.7 Update 2をインストールしました。


もともとESXi 6.0を使っていましたがそこに新規インストールという形で実施。
アップグレードを行わなかったのはOSインストール領域として使っていたUSBメモリを変更したため。
USBメモリに何か問題があったわけではないですが、３年ぐらい使ってたので予防交換ですかね～。

インストール及び再設定はあっという間でした。１時間もかかってない。
それほど込み入った設定をしていないからだと思います。
ゲストOSもそれぞれ登録しなおして起動＆動作確認。
特に問題なし。



ただし、ハードウェア上の課題がいくつか見受けられましたね。

まずCPUが古くてサポート外との通知。動作はする。
それからHDDをそろそろ変えた方がよさそう。最近動作音が目立ちます。
HDDはESXi 6.7でAFT対応済みとのこと。以前はAFT非対応を探してましたからねぇ。
今でも（2019/6）入手出来るみたいですが選択肢は相当狭まってます。これは嬉しい。


ファンも交換しながら使っていますし、いろいろ鑑みるとハードウェアの全面見直しをしたほうがよいのかも。

自宅のESXi 5.0を6.0にバージョンアップしました。
昨年HDDを交換した際に「いい加減最新にバージョンアップしなくては・・・」と思ってましたが、ようやく実行。
今まではUSBメモリに新規インストールしていましたが、今回はCD-ROMからのバージョンアップを選択。
昔はddでUSBメモリに書き込むぐらいしか選択肢が無かったんですけどねぇ・・・・って相当前の話ですな。


CD-ROMからブートしてインストール先にUSBメモリを選択すると、既存のESXiからのバージョンアップ（Upgrade）を選べます。
Upgradeを実行してしばし待つ。しばらくすると上記の画面が出て作業完了。正味１０分というところでしょうか。
バージョンアップ時に設定は引き継いでいます。
追加作業は6.0用のvSphere Clientをインストールしたのとライセンス投入ぐらい
すぐ使えました。


さて、バージョンアップによる変化は・・・・私の運用だと特になし。
HDDのSMART値が見れるようになったぐらい。
もともとSMART値を見るコマンドは用意されてましたがきちんと値が取れませんでした。
環境が悪いのかバージョンアップしてなかったのが悪いのか。

今回のバージョンアップでSMART値の取得が出来ることが確認できたので、これでHDDの調子が悪い時に確認できます。


HDD交換の時にすったもんだしたAFTの対応は結局不明（確認できず）。まー多分OKなんでしょう。

ちょっと前にお話しした、

「HDDから異音するので交換したら交換後のHDDの音はもっとうるさかった」

ですが、その後音の軽減ができないかいろいろ試みました。
結果かなり小さくはなりましたが、やはり気になる時は気になる。
己を騙し騙し使用を継続していましたが、精神衛生上よくないので再度のHDD交換を決意。



再交換用に用意したのはWesiternDigitalのWD500AAKX。500GBのHDDです。非AFT。

もともとこのHDDは最初の交換時に候補に入れていたのですが、容量不足が懸念で躊躇してました。ゲストOS全部合計すると５００GB近いので。
出来れば容量1TB以上且つ非AFTのものはないかと探していたところ、見つかったのが先日使用した「MD03ACA200」。
この時は「2TBだひゃっほーい」と喜んでいたんですけど。



なので、まずはコピーするゲストOSを厳選します。
過去のバックアップとか、今はまず使うことのない環境とかを捨てます。
これでなんとか300GBいかないぐらいまで圧縮。

これら厳選したゲストOSをコピー。
コピー完了後、ケースのふたをして、元の場所に設置して、スイッチオン！動作確認！
今度こそ静かになってくれ！



まず、動作自体はOK。
ゲストOS稼働させつつ、動作音を確認・・・・・・うむ、ほぼ無音。
念の為一旦ESXiを再起動させ、再度ゲストOS稼働。操作しながら音を確認。

大丈夫です。
MD03ACA200で発生していた「ガリガリ」といった激しめの音や、もともとの「カッ・・・カッ・・・」といった音も発生していません。
ただし、「ふお〜ん」「しゅわ〜ん」といった低周波の音が響きます。
ケースが共振して発生しているようで、重しを乗せたら低周波の音は聞こえなくなりました。



これで本来求めていた状態となりました。ほんと遠回りしたわ。

元を言えば、非AFTのHDDを求めるがゆえに選択肢を狭くしてしまったのが原因。
ESXiでもAFTのHDDでも問題なく動作することを確認するべきでしょうね。
必要があればESXiのバージョンアップもするか。

私が使用しているさまざまサーバを仮想化してつっこんでいるESXi。
ふと「カッ・・・・カッ・・・・」と何やら好ましくない音が聞こえてるのに気が付いたんですよ。


それほど目立つ音では無いのですが、たしかに音がする。
音源を探るとどうもHDDから発生している模様。
しかも結構頻繁に起きる。１分待てば大体発生する。

これはHDDが壊れる予兆か？
先日スピーカーが壊れたと思ったら今度はHDDかよ！
※スピーカーはONKYOのGX-70HDを購入しました

ESXiが死亡するともろもろ全滅するので非常に好ましくない。
前回HDDを変更したのはいつだ？・・・・2010年12月に交換している模様。
となると３年半。
気温や湿度が変化するなら２４時間稼働で３年半なので、何か起きてもおかしくないでしょう。

HDDを交換します。

・・・結論を先に言うと「HDD交換」はうまくいくも別の問題が発生しました。

ESXiが完全に死亡しても困らないようにゲストOSのバックアップはこまめに取っておきたいところ。

ssh周りがESXi 5.0でいろいろ変わっていたのでちょこっとメモ。
前が3.5だったから、というのはありますが、いろいろ変わってた。

• ESXi 5.0へのsshログイン有効化

以前はコンソールからF2押して・・・でしたけどそんなことしなくてもTroubleshooting OptionsからEnable ESXi Shellで有効化出来る模様。
vSphereClient上でも有効化出来るみたい。

• Teratermでのsshログイン

ssh有効化したあと今までどおりTeratermでログインしようとしたら出来ない・・・
「チャレンジレスポンス認証を使う」を使うでログインすればOK。
なお、Puttyは何もしなくてもいけた。

• scpでのファイルコピー

ようやくESXiにログインしていざゲストOSをscpでコピー、と思ったら出来ない。
DNSの名前解決待ちか？とも思いましたが、調べてみたFireWallの設定が必要な模様。
構成→セキュリティプロファイル→ファイアウォールのプロパティを選択。
SSHクライアントにチェックを入れてOKを押す。
もちろんscpだけじゃなく普通のsshクライアント操作をESXiから行う場合もこの設定が必要。

・・・・という過程を経てゲストOSをコピーしました。
vSphereClientからでもゲストOSのコピーは取れますが、コマンドラインからやる方が何かと都合いいので。


ちなみにscpでのコピー速度がむちゃくちゃ早くなった。
ESXiをバージョンアップしたからなのか、ハードウェアを変えたからなのかは不明。
いづれにしろメンテしやすくなったので大歓迎。

先日お亡くなりになったうちのESXiですが、無事復活しました。
新しい箱はShuttle SH61R4。

CPUやメモリは以下のとおり。

• Core i3-2120T
• コルセア製PC3-10600(DDR3-1333)メモリ 4GBx2

HDDは以前使っていたものを転用。
ESXiの起動はUSBメモリから。

なので、実質の購入はSH61R4とCPU/メモリだけです。
全部で3万円ぐらい。
お安くすみました。

うちのESXiは普段リソース消費しないので、CPUやメモリをハイスペックのものにする必要はありません。
なので、CPUは低発熱モデルを選択。TDP35W。
メモリは以前4GBで動作させてたので8GBでも十分。

新しい箱にしてまず思ったのは非常に静かであること。
場合によってはファンの変更も考えてましたが、その必要はなさそうです。
CPUが普段仕事しないので、その結果あまり熱も出ず、ケースファンが常にゆっくり回っている、というのも静かさの理由の一つと思われ。

ちなみにESXiは5.0を選択しました。
今までずっと3.5で動いていたのでこれを気にバージョンアップ。
ほんとは障害の時に余計な変更をするのはあまりよくないんですが。

SH61R4のオンボードNICは蟹ことRealtekのNICでしたが、5.0で問題なく認識しました。
蟹が認識することがESXi 5.0の一番のセールスポイントです（違う）。
でも、今まで使っていたIntelのNICがもったいないのでそっちを使う。

ESXiの各種セットアップも特につまることなし。
こころなしか全体的にゲストOSの反応がよくなったような気がする。
ハードウェアの変更・ESXiのバージョンアップ両方関係してそうです。

熱の問題に関しては、

• CPUを低発熱モデルにした
• 置き場所の変更

で、乗りきろうかと。
あと箱の容量がSG31G2と比べて多少大きくなってますね。
中の空間が広がっており、熱がこもりづらくなってると思います。




全作業は半日程度で終了。
元のゲストOSが用意できていれば復旧に手間がかからないのがESXiの良いところですね。

うちのESXi（SG31G2）がお亡くなりになった模様。
マザーボードが死んだっぽい。

PSODが出たので再起動したら異常に動作が不安定に。
画面はノイズ出まくり。
そのうち勝手にBIOSが初期化され、ついには電源入れても画面が出なくなってしまいました。

動作確認はいわゆる最小構成で行っており、メモリやCPUの異常の可能性もありました。
が、チップセットのヒートシンクがさわれないほど熱くなっており、これが原因と判断。
ファンをつけて強制冷却しても異常状態は変わらなかったのでチップセットが死んでるんじゃないですかね。

・・・・確かによく熱暴走してたんですよねぇ。

幸いHDDは生きてるので新しい箱を用意すればESXi上の仮想サーバ群は復活可能。
念のため仮サーバでESXiを稼働させ、動作に問題ないことを確認。
ついでに最悪の自体を想定して、重要な仮想サーバのバックアップをとる。

あとは新しいサーバを用意すればOK。

一応仮サーバで動作しているので、新しいサーバの手配は急がなくてもよし。
熱問題を考慮したサーバを用意すべきですねぇ。
スペースの都合上どうしてもキューブタイプを選ばざるをえないですが。

配置場所変えてみようかな～。

先日PSODになったESXiサーバはその後再発はせず現在元気に動いております。
やはり熱暴走ですかね。

ほこりで吸気口がつまるのを防ぐべく新しい場所を選定中ですが、どうもいい場所が決まらなくて。
ベストな場所は既にファイルサーバが占拠中。
このベストな場所は環境がいいので他にもネットワーク機器やサーバ類がいくつかあり、場所の確保が難しい。
置けるは置けるけど、ESXiサーバも含め吸気口・排気口塞ぐ可能性があるもんで。
整理すれば設置出来る・・・・かな？

で、今後のことも考えてESXiサーバを新調することも検討しときます。
マザーボードはH67チップセットで動く模様。
これにできるだけ低発熱のCPUを乗せる。

ケースはキューブ型をやめてミニタワーぐらいで。
キューブ型でも運用に支障がないのは分かっていますが、汎用性・パーツの流用性を考えるとミニタワーがいいのかな、と。

熱もこもりづらくなるでしょうし、NICを2枚さしても大丈夫かな？
ゲストOSごとに使うNICを変えるとかやってみたい、と。

ま、今の環境でむちゃくちゃ困っているわけでないのでしばらくは今のキューブPCのままですね。
とりあえず置き場所チェンジを早くしよう。

ファイルサーバはずっと利用していたSS21Tとおさらばしたいが、来年かな？
BTXマザーってことをのぞけばいいヤツなんですが。

昨日自宅サーバにつながらなくなったのでESXiの画面つけてみたら案の定PSOD(Purple Screen of Death)。

キューブ筐体(SG31G2)が全体的に熱持っていたので熱暴走したっぽい、と思うが前回はHDDのエラーだったので一応HDDもチェックする。
とりあえず電源切って筐体掃除。

うーむ、このShuttleのキューブ筐体は側面下段から吸気して、背面の8cmファンで排気するようになってますが、側面下段の吸気口である穴がほこりで埋まってる模様。

穴が埋まって吸気の効率落ちたんでしょうね。
背面も側面ほどではないもののほこりがつまってる。

とりあえずほこりを全部落とす。徹底的に。
その後HDDを別筐体にさしてSmartの状態をチェック。
ヤバいエラーは無い模様だ。

ESXi再稼働させ、ゲストOSも動かす。
ディスクI/O関連のエラーが出てないかチェック。
・・・・・とりあえずないみたい。今のところは。

ただ前回はバックアップを取ろうとゲストOSのコピーをしてた時にエラーでたのでまだ何とも言えず。

熱は稼動後1時間ぐらい経った時点で筐体を触ったが明らかにPSODだったときと温度が違う。

ESXiをキューブ型PCで使ってる上に静音化して熱持ちやすいのに、床に近い割とほこりを吸い込みやすい場所に設置しているのがそもそも問題なのかも。

置き場所の変更も考えるかな～。
・・・単なる熱暴走、ってことで片付けたい。とりあえず様子見。

万が一に備えてESXiのゲストOSのバックアップを取っていたらI/O error発生しコピー失敗。
再現性もあり。
また、ESXiのにmessagesにもI/O errorの出力あり。

Dec 22 23:42:34 vmkernel: 2:13:03:19.327 cpu0:1542)LinBlock: 1926: I/O error, dev 16:00 (hdc), sector 1235802807

ハードの可能性じゃないの～？と思っていた矢先に一気にその可能性が高まってしまった・・・・・
ハードの交換はめんどくさい・・・

が、そうも言ってられないのでHDDの交換作業開始。
コピーに問題のあったゲストOSは捨ててもいいゲストOSなのでそれが唯一の救い。
メールが全部溜め込んであって一番重要なメールサーバが無事コピー出来たので山は越えた。

ちなみにHDDじゃなくてマザーボードやケーブルに問題が、って可能性もあるんだよね・・・・
HDD交換後もエラー出ていないか監視しないと。
監視はとりあえず人力・・・・

昨日のESXi3.5でPSODが発生する件ですが、予定通りsfcbdを停止させました。
これでしばらく様子見。
これまでの傾向から何か対処しても1ヶ月持たなかったので1ヶ月以上PSODでなければ効果があったと判断できそう。

止め方に関してはHP technical supportのPSOD Due to Memory Leak in sfcbdを参考にした。
※リンク出来なかったので見たいかたはググってください

ただ、もういい加減4.1にしようよ、という気になったので計画立てて4.1に移行したい。
仮想OS上のドライバとか変わっちゃう可能性あるから調べないといけないし、USBメモリ起動もやめたいなぁ。

年明けたら。

週末は自宅サーバで二つほど問題が発生して対応してました。

一つは先日PSODが頻発したESXi 3.5が再びPSOD。
もう一つはSambaとWindows 7 間でのコピーがおかしい。

前者はもうちょい調査が必要。あたりをつけつつはある。
PSODを引き起こすプロセスはsfcbdで、googleなどで検索すると各所で問題になってる模様。
sfcbdって何者？と調べてみるとSmall Footprint CIM Brokerとあり、（最後のdはdaemonと思われ）ゲストOSのヘルスチェック・ステータス取得用？と思われる。よく分からん。
とりあえずこのsfcbdを止めることにしてみる。止めればsfcbdが原因となるPSODは発生しない。

しかしそもそもなんで急にsfcbdがおかしくなったの？という話もあり、ハードに問題が発生しているのかもしれない。
なんだろう・・・・USBメモリは変えたしなぁ～。
あるいは3.5から4.0にVerUPするか。
やはりきちんと認定通ってる機器じゃなきゃダメかな（今はShuttleのキューブPC）。

で、後者のコピーの問題は多分直った。Samba側で使っていたNIC（VIA）のドライバに問題があった模様。IntelのNICがやはりドライバの問題でNGなので余ってたRealtekを投入。
復旧。
Intelがダメで蟹（Realtek）がOKとは・・・・

XP<->Win7間でネットワークを介したコピーに問題があることはよくあるらしい。
その場合、セキュリティソフトが悪さしていることもしばしばあるらしい。
今回いろいろ試して結果としてはWindows7側ではなく、Samba(FreeBSD8.0)のNICが原因でしたが、どうもWindows7のネットワークを介したコピーはいろいろ問題ありそうだ。
SMB2.0になったことも関係しているのかしら。

しかしこれでほぼ2日間潰した。ちくしょうめ。

先週仮想サーバのESXiの調子が非常によくありませんでした。
具体的にはよく落ちる。
ゲストOSの反応が無くなり、ESXiそのものも反応無くなるので直接コンソールのぞくとPurple Screen of Death(PSOD)状態。

初めて見たときはなんだこの変な色は！と思いましたよ。
↓こんな感じなんですが。

これが２、３日に一回、だんだん頻度が上がって最終的に毎日になりました。

予想した原因は以下の２つ。

• ESXiをインストールしたUSBメモリが限界に来た
• 使ってるVersion（3.5.1 Update2）が持ってるバグ

両方とも考えられるので使ってないUSBメモリにチェンジしてVersionUP。
ESXi4.0/4.1にしたときの環境変化に対応している暇がないのでとりあえず3.5.1の最終版。そうでなくてもゲーム用PCの環境移行終わってないのに。
いつかは4.0/4.1にしたいんですけどね。

で、無事安定動作するようになりました。
ちなみにESXi導入したのが去年の今頃なので、USBメモリが問題なら1年後また発生する可能性がある。
で、あればそれまでに4.0/4.1にアップグレードしたいなぁ。

うちのESXiで使用しているHDDがSeagateのビンゴモデル（ST3500320AS）でビンゴファームウェア(SD15)だったのでWesternDigitalの1TBを買ってきて入れ替えました。

仮想OSだとゲストOSとホストOSのメンテ完全に切り離せるのがメリットですね。
今回もゲストOS全部止めてSeagateからWesternDigitalにまるごとコピーして終わり・・・・・のはずだったんですが、以下の問題が出ました。

• コピーが・・・・遅い

Strage作成後、ESXiにsshでログインしてcpでコピーしたのですが２０GB程度に３０分ほどかかってしまいました。ローカルコピーなのに・・・・・

ちなみにまったく別のシステムのVIC上でコピーしても遅かったので、そういうもんなんでしょうかね？

• MACアドレスが変わってた

コピーしたあとDatastoreをブラウズし、vmxファイルを右クリックしてInventry追加。 初回起動にUUID（固有ID）変えるかといったので変えた。 たぶんこれが原因でゲストOSのMACアドレス代わりました。 その結果、通信が恐ろしく不安定に。

機器の故障でH/W交換した後に他の機器が古いMACアドレス覚えていて通信できなくなるのはよくあることです。
その場合新しいMACを再学習させてやります。

ただ、今回はうちのブロードバンドルータがうまく学習できなかったらしく、通信自体は成立するのにブツブツ切れます。TCPの再送起きまくり。
ブロードバンドルータ再起動してARPクリアしたら解消したので、ブロードバンドルータのARP学習に問題があったと思うのですが、それでなぜTCPの再送が起きまくってたのかは不明です。

ゲストOSのMACアドレスは手入力も出来るので、前のMACアドレスと同じものにしておく、ってのが解決策なのかもしれない。

ということで移行作業は無事完了。
いろいろと苦労しましたが、やってみないとわからないしね～。
SeagateのHDDはちゃんとした対応策が出るまで寝かせることにします。
ちなみに動いてました。認識しないなどの問題は出ていません。