Windowsの高速スタートアップ(ハイブリッドブート)に関して
Surface Pro3を使っていて感じるのは非常に起動が早いということ。
元々利用していたMacbook Airも起動がはやかったけれどそれ以上に早いかもしれないと感じている。
SSDの恩恵もあるのでしょうが、ほかにも秘密がありそうだなと思って調べてみたらありました。
Windows8以降に搭載されている技術で、高速スタートアップというものみたいです。
どういうものかというと、
単純ではあるが前回のシャットダウン時にOSの情報を一部分保存しておき、
次回起動時にはその情報をロードして処理の短縮をしているとのこと。
もう少し細かくいうと、Windowsが起動する際にはまずOSのカーネルをロードする。
その次に、デバイスドライバをロードするんですが、
この情報を前回のシャットダウン時に保存しておくとのこと。
要は一番時間のかかるであろう、デバイス周りの処理をスキップしてしまうという方法で短縮している。
確かに、頻繁にHWの構成が変更されるわけではないし理に適っているかもしれない。
当然、HW構成が変更した際には通常の起動処理をしないといけないけど。
では、どのようにしたら通常の起動になるのか？という話だが、
高速スタートアップを無効にするか、再起動を実施すれば通常の起動処理になるようです。
自分が利用しているSurface Pro3はデフォルトだと高速スタートアップが有効。
その状態で「シャットダウン」で停止させると、ドライバ情報を書き出して停止、
次回起動時に、書き出した情報をロードして高速スタートアップが動作する。
一方で、「再起動」の場合はドライバ情報を書き出さず、通常の起動処理で立ち上がるようです。
普段そんなに「再起動」なんてしないから、知らずに「シャットダウン」運用をしていたら
ある時から不安定に、、なんてことが起きるかもしれない。
(特にデバイスの追加とか削除があった場合)
ちなみに、高速スタートアップの有効化・無効化は
「電源オプション」＞「システム設定」から変更可能。
最後に、デバイス情報を保存しておくという処理に関してだが、
Cドライブ配下にある、hiberfil.sysがそのファイルらしい。(不可視ファイル)
どこかで聞いたことある気がすると思ったら、
このファイル「休止状態」でシステムを停止する際に情報を保存するファイルじゃん。
参考URL:
Windows10の高速スタートアップって何？速いけど危ない？無効にする方法は？ | ligamap
ハイバネーション（hiberfil.sys）を無効にする･削除する]
pagefile.sysとhiberfil.sysの解説ページ
InstantGO(旧Connected Standby)について
半年前に4年間共にしたMacbook Airが調子が悪くなったのでSurface Pro3を購入。
モバイルPCはもっぱらMacだったので、新鮮な感じです。
実際のところ、非常に便利でWindows10で快適に利用できています。
で、モバイル機器はほぼMacだったのでWindowsをモバイル環境で利用するにあたり
いろいろと発見があるわけです。
例えばWindowsには「スリープ」、「休止状態」というのが元々あったかと思います。
※Windows8以降では「休止状態」はデフォルトでは表示されないらしい。
また、「休止状態」が利用できる端末かどうかというのもあるらしい。
Tips:電源オプションをcmdからいじるには、powercfg.exeを利用する
www.atmarkit.co.jp
そして、「スリープ」の挙動も変わってきているらしい。
現在InstantGOと呼ばれているが、
「従来のスリープ」は完全にOSデータをメモリに保存して停止していたのに対し、
InstantGOが有効状態の「スリープ」は、ネットワーク機能は有効のままになるらしい。
いわゆるスマホのアプリケーションみたいに、
アプリケーションが通信を行い機能を提供できるようにという配慮から生まれた技術とのこと。
InstantGOに対応していない端末の「スリープ」はいわゆる「従来のスリープ」と同様になる。
InstantGOに対応しているかの確認方法は下記で可能。
「powercfg /a」を実行して、
「スタンバイ (S0 低電力アイドル) ネットワークに接続されています」
と出力されれば対応している端末と判断できる。
C:\Windows\System32>powercfg /a
以下のスリープ状態がこのシステムで利用可能です:
スタンバイ (S0 低電力アイドル) ネットワークに接続されています
休止状態
高速スタートアップ
以下のスリープ状態はこのシステムでは利用できません:
スタンバイ (S1)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
スタンバイ (S2)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
スタンバイ (S3)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
ハイブリッド スリープ
スタンバイ (S3) は使用できません。
参考URL:
Microsoft Surface の電源状態
Windows 8 & 8.1はダメOSなのか - 第2回 | マイナビニュース
Windows TIPS：Windows 8／8.1で休止状態設定を有効にする - ＠IT
データストアへのアクセスが遅い on ESXi6.0
少し前にESXi5.1からESXi6.0u1へアップデートしました。
(インストールの方法としては、新規インストールというかたちで）
アップデート後に気になった点として、データストアへのアクセスが遅く感じました。
特に書き込みの面で顕著な気がします。
ESXi6.0がリリースされてから、しばらく時間がたっていますので
事例がないかなと調べてみたらありました。
結論としては、HPのドライバに問題がありそうとのこと。
自宅ではHP製のサーバを利用しているということもあり、
ESXiインストール時には、HPのカスタムイメージを利用しています。
※ちなみに下記からダウンロードしています。
HP製サーバに必要なドライバが組み込まれているので楽です。
HP and VMware’s infrastructure as a service solution | Hewlett Packard Enterprise
どうも、最近のバージョンのカスタムイメージに含まれている
アレイコントローラドライバが良くないようです。
自分が利用した「vSphere 6.0 U1 Nov 2015」というカスタムイメージには
HP製の下記ドライバが組み込まれています。
[XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
上記のドライバ中、scsi-hpvsaの「5.5.0.100-1OEM.550.0.0.1331820」というバージョンが良くないようです。
そこで、ドライバをダウングレードして実績のあるものに差し替えました。
Very slow acces to datastores on HP MIcroserver... | VMware Communities
既に海外の有志の方々が検証してくれており、上記のサイトを参考にドライバを入れ替えています。
Before:scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820
After: scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820
#適用するパッチを格納 cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/ #ESXiをメンテナンスモードへ esxcli system maintenanceMode set --enable true #既存のドライバを削除 esxcli software vib remove -n scsi-hpvsa -f #対象のドライバをインストール esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode #再起動して反映 reboot #再起動後、変更されているのを確認 [XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
これで改善されました。
ESXiをUSBブートで利用時の、パススルー設定に注意。
ESXiをはじめ、最近の仮想化製品はデバイスを仮想マシンにアタッチできるので便利ですよね。
仮想マシンだからという制約がかなり低減されていると思います。
ESXiだとパススルーと呼ばれてまして、
その名のとおりESXiホストに接続されているデバイスを仮想マシンに直接接続させることが可能。
で少し前に、ふとUSBを仮想マシンに接続させようとした際にトラブリました。
何気なくUSBを仮想マシンに接続させるために
パススルーの設定をして、設定適用のために再起動しました。
普通にESXiが起動して、USBデバイスも
仮想マシンから見てるようになりめでたしめでたしと思ったのですが、
その後幾つか気になることが発生しました。
設定を変更した内容が、再起動したら消える。
→これは定期的にESXiはバックアップ処理を入れているから
そのタイミングに合わなかったのかな？と思って
自分を納得させました。（気付けよ。。というはなしなんですが）
ESXiのvib(パッチ)を適用したら、下記エラーがでて怒られる。
(このタイミングでブートデバイスである、USBデバイスになにか問題がある？と思った）
「The transaction is not supported : ・・・略・・・ cannot be removed live.」
で、ESXiのコンソールに接続してデバイス一覧を確認したら、
Bootデバイスが一覧にありませんでした。。(trueが一つもない)
[XXXX@XXXX:~] esxcli storage core device list | grep Boot Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false
こうなるとESXiがUSBメモリを認識できていないのは確実。
最近の設定変更を思い出してみると、タイトルになるのですがUSBのパススルー設定をしたなと。
ここで、USBのコントローラ毎パススルー設定をしているのが発覚。
ESXiが起動するまでは、BIOSからブートメディアとして見えているが、
ESXiがメモリにロードされて完全に起動するとパススルー設定が有効化させて、
ブート用USBメモリがESXiから見えなくなるという。。
なので、設定もメモリ上では保持しているが、
再起動等する際には保存されないので先祖返りするということに。
じゃあ、どうやって設定を戻すの？ということになるわけです。
設定変更しても、ブート用USBメモリに設定が反映されないのでしょと。
はい、こうなると再インストールした後に設定を戻すしかありません。
それは、、うん、そうだよね。ということになるのですが。
ちなみにVMWareのKnowledge Baseにご丁寧に説明もあります。
ESXiがUSBからブートしているのを検知できるんだから、設定時に警告だしてくれないかなぁ。
ちょっと求めすぎかなぁ。
PowerShell DSC Configuration設計に関して
PowerShell DSCに関して、まだまだ情報は少ないのが現状。
サンプルとかに関してはちらほらネット上にあるのだが、
より実用的な、大規模な設定を投入することになると、サンプルのようにはいかなくなる。
以下、より実用的なConfigurationを作成するにあたり参考にしたサイトが以下。
■巨大なDSC Configurationの考え方
ParameterとRoleの活用に関しての記載がある
Designing Node Configurations in PowerShell DSC - Nicholas Dille
■DSCにおける、設定とConfigurationの分離
複数のConfigurationに分割しての実装方法に関して
■Nested Configuration の問題点
ネスト構造のConfigurationに関しての問題点に関して記載している。
自分は、ネスト構造を採用しているけど。
Reusing #PSDSC Node Configuration with Nested Configurations - the Horror! - Nicholas Dille
ちなみに、DSCはまとまった情報得るのが難しいのが現状かと思うが、
書籍としては下記が非常に良かった。
下手に情報をパラパラとネットで集めるよりは、この本をベースに始めるのがいいかと思う。
こっちの本も、まだ購入していないけど気になる。
VMWare ESXiのインストールおよびアップグレードのベスト プラクティス
システムを設計するうえで、利用する製品の機能・仕様を理解するのは非常に大事です。
特に、製品ベンダーの公式の資料というのが何よりも大切な指針となります。
（当然、ソースレベルで使用を確認できる唯一の組織になりますからね）
VMWareのESXi製品は、毎回バージョン毎に「インストールおよびアップグレードのベストプラクティス」が
KB Blogに公開されています。
それぞれ、ESXi 5.1, 5.5, 6.0のページが公開されています。
各ページともに下記内容で構成されています。
■システム要件
ESXiが既定しているHW要件に関しての記載があります。
特にESXiで肝になるのは、CPU、NIC、メモリサイズとかでしょうか。
CPUは、HW仮想化のサポートの有無(Intel VT)、
NICはサポートしているNICでないとドライバが対応していない等があります。
おすすめはIntel製のNICですね。迷ったらIntel、それでなくてもIntelが基本です。
メモリに関しても、最低要件が定められており、ESXi5.5ですと4GBです。
加えて、サポート対象としているSATAコントローラも記載があるのですね。
■起動要件
ここはUEFIの話とかです。
■ストレージ要件
ESXiのインストールに必要な容量としては1GBが必要です。
加えて、5.2GB以上のディスクがないとスクラッチ領域がRAM上に置かれるようです。
つまり、再起動するとデータが消えるということです。
当然、推奨はされていません。
※スクラッチ領域とは、ESXiのログ、システムスワップ含むデータを保持する領域です。
インストール後に、スクラッチ領域を別途指定可能です。
USB,SDカードにインストールする場合も、8GB未満ですとスクラッチ領域を作成しないようです。
8GBのUSBにESXiをインストールしている方は要注意です。
■ESXi ホストのアップグレードまたは移行のベストプラクティス
文字通りですが、エンタープライズ向けですとアップグレードまたは移行を考えることもあるかと思います。
その際のベストプラクティスがまとめられています。
ところで、エンタープライズでESXiのアップグレードってそんなに需要あるんですかね。
移行はともかく。
HP Lights-Out スタンド アロン リモート コンソール for Windows
サーバ機器にはリモートからコンソール接続できる機能が搭載されていることが多いです。
これは、トラブルのたびにデータセンターへダッシュして、コンソールを開いて作業することにならないためにも非常に大事です。
HP製のサーバにはiLoというリモートコンソールの機能が搭載されていますが、
多くの方がブラウザ経由でアクセスして、利用しているかと思います。
自分がよくであう状況としては、ブラウザのバージョンが低くてうまく画面を取得できない、
Javaがインストールされていない（Java版のリモートコンソールの場合）などなど、
意外とうまく動いてくれないことがありました。
トラブルの時くらいしか利用しないため普段はまったく意識しません。
が、いざトラブル時に利用できないと焦るのです。。
そこで、タイトルの件になるのですが、
ブラウザを利用しなくてもよい、スタンドアロンのソフトウエアがあるようです。
初めて知りましたが、これならメンテナンス用の端末にインストールしておけば確実ですね。
※メンテナンス用の端末のブラウザを保全しておけよという意見もまぁあるのですが。
Drivers & Software - HP Support Center.
また、HPさんはiOS,Android版のコンソールアプリもリリースしているみたいです。
HP iLO Mobile - Google Play の Android アプリ
以下、参考サイト。
あまり知られていない HP iLO リモートコンソールの 5 つの Tips - 仮想化でプリセールスしてるSEの一日
