2018 年 9 月 29 日

MacBook Proがスリープからの復帰に失敗して黒画面のまま何も操作できなくなってしまう〜結局強制再起動する羽目に〜どうやらIOUSBFamilyが怪しいみたい

ここのところ数週間のうちにMacBook Proが

１）朝起きたら画面が真っ黒になってキーを押してもスリープから復帰しない

２）持ち歩いていて蓋を開けたら起動した状態で持ち歩いていたはずなのにログオン画面になっており、ログオンしたら「エラーをAppleに報告」のエラーログウインドウが開いている

３）蓋を閉めても画面が光ったままスリープしない・何度か開け閉めしていたら黒画面に落ちてマウスポインタだけが表示されているが何も操作できない…

というような症状が数回続いており、結局こうなると電源ボタン長押しで強制再起動しないとクリアできない…という問題が起きている。

それでこういう場合の切り分けを以下のページを参考にここ数日やっていた。
Mac が勝手に再起動する場合や問題が起きたため再起動またはシステム終了したというメッセージが表示される場合 - Apple サポート

結局どれにも該当しないのだが、切り分けをしているうちにシステムが落ちてログオン画面になる現象が再現、その時にブルースクリーンに出た警告ウインドウが口絵のポップアップに非常に似ていた。

さらに起動後「エラーをAppleに報告するか？」とのポップアップが出るのでエラー内容を確認するために「はい」を押すとパニックログなるログが表示されていた。
コンソールを開いてこれと同じログを探したところ以下のものが一致した。

コンソールを開いてAppleへの報告ウインドウと同じログを探したところ
「Kernel_2018-09-27-205658_hiiragi-no-MacBook-Pro.panic」というログが一致した
要するにカーネルパニックということらしい

そして過去にこれが起こった時の共通の条件を洗い出したところいずれもパニックを起こした時に、あるいはそのちょっと前まで大容量のUSB外付けハードディスクを接続していたタイミングだったことが判明。
IOUSBFamiyというカーネルエクステンション由来のカーネルパニックである可能性が濃厚になってきた。

IOUSBFamilyについては以前にも以下のページで触れた。
USB機器を認識しなくなった場合の対処法〜IOUSBFamilyの不適合について

iTunesがクラッシュしてOSがフリーズ・再起動したら起動に異常に時間がかかるようになって『The IOUSBFamily is having trouble』のエラーを吐くようになってしまった

これが原因だとすると厄介なことになるなぁ…
これが起こり始めたら結局システムの再インストールをしないとクリアできなかった記憶がある。
しかも最近の世代のmacOSって上書きインストールができないというか、結局クリーンインストールになってしまうんだよなぁ。

また十数時間かけてシステムインストールとTime Machineからの全域復元をやらないといけないのか…
ちょっと憂鬱だなぁ

2018 年 9 月 22 日

VirtuialPC 2007の差分ディスクを親ディスクと連結して一つのファイルとしてVMWareに渡す手順〜設定の引き継ぎなどについて

再びVirtuialPC 2007の仮想ディスクをVMWare Fusionに引き継いで過去の検証環境資産をこれからも活かしたいという試みの続き。

繰り返し強調するがここでVirtuaPCといっているのは、Windows7のWindowsXPモードのことではない。

かつてのMacの有力な仮想環境だったが、Microsoftに買収されてWindowsをWindowsの上で実行するだけの機能になってしまったエミュレータソフトのことだ。

このVirtuialPC 2007がWindows7まではなんとか動いていたが、Windows8、10では動かなくなってしまった。
それでVirtuialPC 2007で積み上げてきた数百件の仮想WindowsXP検証環境をなんとかWindows10の端末にも引越しさせようとしている。

何でそんなことしてるんだって、それはあと２年弱でWindows7のサポートが終わるからだ。

もう公式アナウンスが出ているけど2020年にはMicrosoftはWindows7のサポートを打ち切ってこれも「腐ったミルク」の仲間入りをさせる。

そうなったら仕事環境も否が応でもWindows10以上の端末に更新されるだろう。
WindowsXPの検証環境を作っているVirtuialPC 2007は動かなくなる。

この検証環境は、その環境で動いている実機のトラブルをシミュレーションするために構築しているのだが、あと二年でこの世からWindowsXPが消えてくれるか…というとそんなことは絶対に起きない。
下手をするとあと１０年はWindowsXPはユーザー環境で使用されるだろう。

個人のPCではもう滅多に見ないかもしれないが、未だに事業所で使用される専用機端末はWindowsXPで動いているところがかなり多いのだ。

何でさっさと更新しないのかって…それはお金がないからだ。
世の中には想像以上にネットワークや専用機環境にかけるお金がない会社がたくさんあるということだ。
だからMicrosoftが何を言おうがWindowsXPはあと１０年は駆逐されることがない。

となるとWindowsXPで何が起こっているのか、それを実際に動かしてみる環境が必要になる。

VMware上でWindowsXPが動くことはもう確認済みなので、コツコツVMwareの上で検証環境を構築すればいいのだが、せっかくこれまで作りためたものがあるのにこれをなんとかVMwareに持っていけないかというのが今回の趣旨。

それをする上で障害になることが幾つかある
すでにこれまでのエントリで幾つか解決済みのものもあるが
１）VirtuialPC上のネットワーク設定をVMwareに引き継げない
２）VirtuialPCの差分ディスクがそのままではVMwareでは読み込めない
あたりが課題として残っていた。

今回は検索しても見つからなかったVirtuialPCの差分ディスクを親ディスクと結合して、VMwareに持ってくる手順を見つけたので、それとVirtuialPC上の固定IP設定がVMware上では使用できなくなってしまう問題のコロンブスの卵的解決法も併せて。

最初にVirtuialPC上で差分ディスクと親ディスクの連結を行うが
その前に下準備としてネットワークの固定IP設定をDNS、アドレス自動取得に変越しておく

差分ディスク、親ディスクの連結はVirtuialPCのバーチャルディスクウイザードで行う

これは通常新しい仮想ディスクを作るときに使うウイザードだが
このツールで連結もできることを先日知った

ここでまず「既存のバーチャルディスクの編集」を選択する

次に差分ディスクのvhdファイルのパスを入力する
参照キーでエクスプローラーから選択できる

するとここに差分ディスクと親ディスクの連結メニューが出てくる
あとは書き出し先を指定してやるだけ
注意点は「親バーチャルディスク」を誤って選択してしまうと
親ディスクが書き換えられてしまい他の同じ親ディスクを
使用している差分環境が全部死んでしまうのでここで選択を間違わないこと

書き出しの形式は容量可変のファイルが絶対条件
ここで書き出し先のパスを設定する

これだけでウイザードは完了

完了ボタンを押すとすぐに書き出しが始まる
この差分ディスクは大量に仮想環境を作らないといけないときに
ベースのシステムは親ディスクで作っておきそれぞれの検証環境の細かい変更点だけを
差分ディスクとして保存することで総容量を大幅に節約できるメリットがある
デメリットはこのように違う環境にエクスポートするときにいちいち連結しないといけないこと

結合が完了したときに表示

書き出し先には.vhdというファイルができている

これをVMWareに持ってきてインポートする
私は特にアタッチメントが必要ないMac版のVMWare Fusionでインポートしているが
Windows版のVMWare Workstation Playerでもインポートはできるはず
ただそのインポートのコンバータークライアントがうまく動かないためMacを使っている
インポートできているという人はお知恵を頂けると助かる

先ほどの追加メニューの中のインポートメニューでvhdファイルのパスを選択する

インポートリストに見えたら「続ける」で実行

インポート中の表示

インポートが完了するとVMWare上でもう実行可能な仮想環境として
見えるので実行する前に必要な設定をする
私の場合ネットワークとは切り離したスタンドアローンの
環境にしたいので仮想ローカルネットワークだけの接続に限定する

時刻をホストコンピューターにいちいち合わせに
行かれると困るので仮想環境と、ホストの時刻同期をオフ
ここらの設定はVirtualPCでもやっているがVMWareには引き継がれない

さらに毎分だけではなく再起動しときやサスペンドからの復帰、圧縮などのたびに
時計が戻ってしまわないように先日取り上げた設定もvmxファイルに追記している

起動するとやはりSCSIデバイスが行方不明というような
意味合いの警告が出るがこれのクリアの仕方は不明
気にしなければ問題ない

VMWareに渡した初回起動でVMWare Toolsのインストールは自動的に始まる
これが入らないと画面サイズの調整やマウスの統合などができないのでこれは我慢強く待つ

固定IPは手打ちで設定
以前は手打ちで設定しても前の設定が残っておりしかもVMWare側のGUIから
その設定の解除ができないためそのまま渡すと元の固定IPが使えなくなてしまう
対策は一番最初にやった「IP自動取得」に設定して固定IPの設定をクリアにして
VMWare環境で手打ちで設定再現というなんとも泥臭い方法
これで「このIPは使用できない」という警告を外すことができた
結局ネットワークアダプターは２番になっているのでやはり見えなくなった１番の
ネットワークアダプタを削除することはできていないが実用上問題ない

そして自由に固定IPを設定することができる

2018 年 9 月 15 日

@icon変換

Windowsのexeやdllなどに含まれるアイコン画像を.icoファイルに変換して取り出すアプリ。

もともとは画像変換ソフトだったらしいが、256x256までの任意のサイズのアイコンに対応できるとのこと。

最近はWindowsも大きなサイズの精密なアイコンが増えてきているので、そうした画像を取り出して任意のフォルダに貼り付けてデスクトップを整理したりの用途が可能。
弊サイトもアプリのアイコンを見出しにしているのでこういうアプリは必要になる。

このアプリがいいのはショートカットアイコンをドロップしても本体のアイコン情報を取ってきてくれるところか。
これのおかげでアイコンを取る手間が一手間減る。

使い方は簡単でフォルダアイコンボタンでexeの場所を指定してやるか
ウインドウに直接exeやショートカットをドロップしてやるだけ
それで各種サイズ・タイプのアイコンの一覧を表示する

書き出しはフロッピーデザインの保存ボタンでicoファイルに書き出せる

書き出したicoファイルはMacの画像ソフトでも加工できるので便利
このソフトがいいのはショートカットをドロップしても本体のアイコンを表示してくれることだ

最近Windowsのエントリばっかり書いているがMacなんか全然いじってないんじゃないか…とか言わないでほしい…図星だから（泣

VirtualPCからVMwareに取り込んだ仮想環境で固定IPが引き継げない問題をクリアした…のだがこの工数のかかり方だとハナからVMwareでXP環境作ったほうが速い気がしてきた…

先日VirtualPCで過去作ってきたWindowsXPや７の仮想検証環境をWIndows10のVMware Workstation Playerに引き継ぐ手順を確認しておおむねうまくいったのだが、２〜３点ちょっと問題が出てきたことを書いた。
VirtualPC 2007の仮想環境をVMWare Fusionに移植する手順

この手順でVirtualPCで動いていたWindowsXPの仮想環境はWindows10の上でも確かに動く。

WindowsXPなんてオワコンなんだからそんな物引き継がんでよろしい…というのは正論なのだが個人のユーザと違ってビジネスユーザの専用機上では今でもWindowsXPは大量に動いていて、おそらく東京五輪どころかその先１０年くらいは完全には消えて無くならない見通しだ。

企業ユーザがWindows10対応の新しいミドルウエアや専用システムに切り替えるお金を惜しんでいるのだから仕方がない。
世の中のかなりの多くの企業は「サポート終わったから」というだけの理由で簡単に専用機を更新したりできるほど予算を潤沢に使えるわけではない。

それはいいのだが、そういう『裕福』なユーザのためにWindowsXPの検証環境も残しておかないといけないのだが、業務環境ではもうWindowsXPは使用できないしWindows7だってあと２年のうちに更新されてしまう。
だから少なくともWindows10でWindowsXPや7を動かして、今の実機環境をシミュレーションできる仮想環境を残しておかないといけない。

それでVirtualPCで作ってきたWindowsXPや７の仮想検証環境をWIndows10のVMware Workstation Playerに移行するという必要が発生するのだが先日の検証で２立つほど問題が出てきた。
１）元の環境で使用していた固定IPがなぜか引き継いだ仮想環境では設定できない
２）Windows上のVirtualPC仮想環境をVMware Workstation Playerで直接取り込めないのでMac上のVMware Fusionで一度VMWare仮想ファイルに変換するという余計なステップがあって手間が半端でない

このうち１）のほうは解決した。

実機環境は固定IPのネットワークなので仮想環境でも固定IPが振られているのだが
VirtualPCからVMware Workstation Playerに引き継いだ仮想環境でその固定IPを
設定しようとすると「このIPアドレスは（存在しない）PCIイーサネットアダプターに
すでに割り当てられており使用できない」という警告が出て設定できない
このことからIP設定は引き継がれているようだがホストの設定からも仮想環境の
設定からも見えないのでこのIPの割り当てを解除することができない

この問題を解決すべくMacで一度VMファイルに変換してというステップを飛ばして
直接VirtualPCからVMware Workstation Playerに取り込むほう帆を試してみた
「Player」ボタンのファイルメニューの開くで仮想環境の実態を選択する
VMware Workstation直なら選択するファルはvhdファイルではなくvmcファイル
こちらのファイルが設定情報を持っているはずなので見えなくなったIP設定もこちらが持っているはず

ところがMac版のVMware Fusionと違ってVMware Workstationは
「変換にはVMwareのvCenterコンバーターが必要」という警告が出る

VMWare vCenter Converter Standalone Client

VMwareのコンバーター用付属アプリ。

VMWare製品の購入登録をして「My VMware」のアカウントを作っているユーザならフリーでダウンロードできる。

VMware Workstation Playerは変換にはv.5.5が必要だと表示しているが、サイトにはv.6.0以上のバイナリしか見当たらなかったため一応バージョンが一番近い6.0をダウンロードしてきてテストした。

結果的にはうまくいかなかったので失敗した話を書くのはしんどいのだが、これも情報のうちなので。

ダウンロードしてきたファイルの中のexeを実行するとインストーラが立ち上がる

インストール自体には成功したのだがこれで仮想環境ファイルを読み込むと
「サポート外のファイル」という警告が出て取り込みに失敗する
結局VirtualPCからVMware Workstation Playerに取り込むという手順には
「Macに渡してMac上のVMware Fusionで一度VMWareファイルに変換する」
というプロセスが飛ばせない結論となった
なぜだかは現在リサーチ中

もう一つの同一の固定IPが使えない件はネットワークアダプターを複数設定して
削除すれば固定IPが解除されるのではないかという発想でアダプターを二つにしてみた
この考え方自体は間違っていたわけだがこのおかげで怪我の功名的に原因が判明した

設定はアダプター１には従来の設定のまま
アダプター２をデフォで追加す

これをMacで変換してWindows10のVMware Workstation Playerに渡した

Mac上て起動してマイネットワーク右クリックでプロパティに入る

やはり全く同じで（存在しない）ネットワークアダプターがIPを占有しているという警告が出るのだが
Macに渡した時点でネットワークアダプターが見えなくなっていることに気がついた
ここでは「ローカルエリア接続３」となっていて先ほど設定したアダプター１と２が見えていない
Macで変換するとvmcファイルが抱いている設定が引き継げないのでこうなると思われる
そしてIPアドレスだけは存在しないアダプターに振られているのでIPは使えなくなる

そこで最初のVirtualPC上でアダプター１はIPアドレスを自動にした
ここで開放しておけば後で設定できなくなることもないはず

ビンゴでVMware Workstation Playerに渡した後も実機環境の固定IPが設定できるようになった

そして仮想ネットワーク内でちゃんと割り当てたIPで接続している

ということで最終的に当初の目的のVirtualPCからVMware Workstation Playerに仮想環境を引き継ぐことはできることが判明したのだが、固定IPの設定をあらかじめ外さないといけないとか、実際の変換のプロセスをMacに渡してVMware Fusion上でやらないといけないとか、工数が多すぎて実用的でないことも判明した。

WindowsXPの環境がこれでVMware Workstation Player上で一つできたわけだから、それをコピーしてそこに一から検証環境を作っていったほうが工数も時間も少なくて済むかもしれない。

なんだかなぁ…

2018 年 9 月 12 日

VirtualPC 2007の仮想環境をVMWare Fusionに移植する手順

ここでいうVirtualPCとはWindows7以降の「クラシック環境」ともいうべきWindowsXPモードのことではない。

文字通りWindowsの上でWindowsやLinuxを起動して運用していた仮想環境のホストアプリのVirtualPC 2007のことで、このVirtualPC 2007で作った仮想環境をVMWareで動かす手順を備忘録として書き留めておく。

当方で仕様しているMacの環境の都合でキャプチャはVMWare Fusion 7で撮っているが、現在の最新環境はVMWare Fusion 10でもうYosemiteでは動かないが、インターフェイスはそんなに変わらないはずだ。
また本当の目的はVMWare Workstationに取り込む手順を模索していたのだが、これもホストがMacかWindowsかの違いだけで大して変わらないはずだから役に立つはずと思いメモした。

VMware Fusion

お題はWindowsXP、Windows7で作り続けてきたVirtualPC 2007の載せているWindowsXPの検証環境資産をVMWare Workstationに移植したいという目的で、そのテストとしてVMWare Workstationと互換性があるVMWare Fusion 7でインポートの手順を試した。

手順そのものは簡単でVirtualPC 2007の「My Virtual Machine」フォルダのプロジェクトフォルダの中のvhdファイルをインポートするだけだ。

VMWare Fusionのファイルメニューのインポートで移住する環境ファイルを選択する

「既存の仮想マシンを選択」メニューの「ファイルを選択」ボタンをクリック

VirtualPCのフォルダをどこに作っているかによるが何も設定していなければ
デフォルトはマイドキュメントの中の「My Virtual Machine」の中の
それぞれのプロジェクトフォルダの中にあるはず
その中のvhdファイルを選択する

リストに仮想マシンが表示されたら「続ける」ボタンで作成を始める

仮想マシンのインポートが始まる

終了したらこういう感じの基本パラメータが表示される
ネットワーク設定などが失われる可能性があるので詳細を確認したい場合は
「設定のカスタマイズ」ボタンで起動する前に設定を確認できる

仮想マシンのリストにインポートしたWindowsXPのサムネールが見えているはず

起動時にSCSIドライバが不足しているという警告が出る
この対処法は現在研究中だがNATで使用するなら全く問題ない

こうしてWindows上のVirtualPC 2007で作成したWindowsXP環境をMac上のVMWare Fusionに移植できた

この仮想環境の初回起動時にちゃんとVMware Toolsがインストールされていることは確認している

ところが元々の検証環境で使用していた固定IPアドレスとしようとすると
存在しないPCIイーサネットカードがそのIPを占有しているという警告が出てIP設定ができない
そのIP以外の固定IPは使えるわけだから問題ないといえば問題ないのだが
使用できないIPのためにネットワーク設定を全部変更しないといけないのが不便だ
IP設定の見落としを検証したいために検証環境を使っている場合には全く無意味になる
移植は諦めて新規でXP環境を作ればいいだけの話なのだが…

iTunesでAppのアップデートのダウンロードに失敗するようになった〜iOSの仕様変更によりいよいよiTunesでアプリ管理はできなくなるらしい

先日から表題の通りiTunesでAppのアップデートのダウンロードに一部失敗するようになった。

これまでAppの管理はアップデートでもファイルはマージ済みのバイナリ全体をダウンロードしていたが、最近のiOSで差分アップデートもiOSデバイスが受け付けられるようになったらしい。

その差分アップデートはURLの記述法が変わったようでiTunesでもダウンロードに失敗するようになった。

iTunesでアプリのバックアップを取っているのは以下のエントリのように古くてApp Storeから除外されたアプリもiTunesにバックアップしておけばiPhoneなどに復元できるからだ。
iTunesはv.12.7でアプリのバックアップ・管理機能は削除されたが12.6.3にロールバックすることでこれまで通りアプリの管理ができるようになった。
詳細は以下を参照

iTunesがv12.7にバージョンアップしてメニューからAppが消えた〜今後のアプリ管理はiOSデバイスでやれということらしい
ロールバックしたiTunesを「アップデートせよ」という通知から解放するには開発者向けにリリースされたv12.6.3にアップする

MicrosoftのWordやShazamなどのアップデートがiTunesでダウンロードできなくなった

AppSitter

iTunes12.7で除外されたiOSアプリの管理機能を引き継ぐことができるiOSアプリ管理ユーティリティ。

iTunesが一部のアプリのアップデートをダウンロードできなくなったので、同じくiOSアプリ管理機能を持ったユーティリティのAppSitterも試してみた。

AppSitterはiTunesが持っていたアップデートの管理、iPhoneなどのアプリのバックアップなどを継続できる。
同じようにiTunes Storeからリジェクトされた古いアプリも管理して、iPhoneなどをリセットした後も復元できる。
フリーウエアだがシェアウエア登録すればバージョンダウンも可能になる。

これならダウンロードができるかと試してみたが、結果は同じでこれはiTunesなどの側の問題ではなくiOSのアップデートが毎回アップデートマージ済みのアプリ全体をダウンロードする仕様から、iPhoneなどのデバイス側で差分アップデートをマージできるように変更されたためだと思われる。

iTunesでアップデートに失敗したMicrosoft Word

AppSitterを起動してApp情報をインポートした
これでダウンロードすればアップデートがうまくいくのではないかと試した

ちなみにこのアプリはiTunes Storeで購入済みのリストを表示して現在のiPhoneなどの
iOSデバイスのスクリーンがどういうレイアウトになっているかも管理できる便利アプリ
iTunes12.6以下のアプリ管理機能をそのまま引き継いだようなユーティリティだ

iTunesのダウンロード情報を見るとMicrosoft Wordは
最新バージョンが2.17でマージサイズは360MBとなっている

ところがダウンロード成功となっているがライブラリの
Application Supportフォルダの中にあるAppSitterフォルダの中身を見てみると
ダウンロードしたMicrosoft Wordのサイズは315バイトとなっている
差分にしてもサイズが小さすぎる気がするが何れにしてもマージされていないので
このままではアプリとして起動できるファイルになっていない
つまりiTunesもAppSitterもアプリ管理としては使えなくなってしまったということだ

結論をいうと新規ダウンロードでURLがiTunesで無効になってしまったしAppSitterならダウンロードできるが差分のアップデートだけのダウンロードだけになって、これまでのマージ済みのアプリ全体のダウンロードができないのでどちらも使えなくなった。

この解消法はない。

というかIOSデバイスのアプリはiOSデバイスで直接管理して、App Storeでリジェクトされた古いアプリはもう使うなということでPCやMacを使って管理したりバックアップするという運用をもうAppleが認めていないということのようなのでどうしようもない。

2018 年 9 月 8 日

VMWare FusionのゲストOSの時刻同期を完全に切る方法

VMWareを検証環境として使っている。

Windowsの場合はVMWare Workstationを、Macの場合はVMWare Fusionを使っている。

この二つの仮想環境は仮想イメージの互換性があるので、Windowsでの検証をMacで引き継ぐとか検証環境を共有して別のアプローチをするとか使い道があって愛用している。

以前Windowsに関してはXP以前の環境ではVirtualPCも使用していたが、これはWindows7以降はサポートしていないためVMWareシリーズに完全に移行した。

VirtualPCではゲストOSの時刻同期を切る設定をしていてゲストをリジュームして数日にわたって検証を続けたり、過去や未来の日付に時計を動かして自由に時刻の影響する検証もできていた。
その方法は以下に解説した。
VMWare FusionでゲストOSとホストOSの時刻同期をオフにする〜同様のことをVirtual PC 2007でもやる方法

この方法でVirtualPCもVMWare FusionもVMWare Workstationも時刻同期を無効にすることができる。

だがVirtualPCではできていたリジューム後も同じ時刻の流れで検証を続けるとか、再起動しても時計が元に戻らないとかがこの設定ではVMWareでできなかった。

何か方法があるはずだ…そのうち調べなきゃ…と思っていたがなかなか手が回らなかった。
やっと調べる時間ができて調べてみたらなんとその方法はVMWareのナレッジベースにちゃんと書いてあった。

時刻同期の無効化 (1189)

VMWareハイエンドソフトはvmxファイルに以下の設定項目の文字列を追加する

注： 0 は無効、1 は有効です。

tools.syncTime = "0"
time.synchronize.continue = "0"
time.synchronize.restore = "0"
time.synchronize.resume.disk = "0"
time.synchronize.shrink = "0"
time.synchronize.tools.startup = "0"
time.synchronize.tools.enable = "0"
time.synchronize.resume.host = "0"

GSX、VMware Fusion、VMware Player、および VMware Workstation では、"0" の代わりに "FALSE" を使用する

tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
time.synchronize.tools.enable = "FALSE"
time.synchronize.resume.host = "FALSE"

VMWareではVirtualPCと違って数分おきにホストOSの時刻を見に行く設定がありこれがデフォルトではオンになっているがGUIの設定でオフにできる。

しかしゲストの起動時や終了時、リジュームからリストアする時、イメージを圧縮した時、vmware toolsの変更などのたびにホストOSの時計を見に行くようにもなっていて、これはGUIの設定ではオフにできなかった。

以下の要領でこれらの自動同期をすべてオフにできる。

VMWareでは仮想環境の設定の「詳細」で「時刻同期」のチェックを外せば
数分おきにホストOSの時計に時刻を合わせ込む動きを止めることができる
しかしこれでは再起動やサスペンドから復帰した時にまた親OSの時計に合わせに行ってしまう

この設定を変更するためにMacの場合は仮想環境のパッケージバンドルの中を覗く
右クリックで「パッケージの内容を表示」

この中の.vmxという拡張子がついたファイルをテキストエディタで開く

vmxファイルの中に「tools.syncTime」という文字列があるはずだが
これが「tools.syncTime = "TRUE"」となっていれば自動時刻同期は有効で
「tools.syncTime = "FALSE"」となっていると無効というのは前回も書いた

これだけでは数分おきの自動時刻同期がオフになるだけなので
追加の設定をこのように書き足してやる
設定値はすべて「FALSE」にしておけば再起動やサスペンドからの復帰
vmwareツールのオンオフ、バージョンアップ、仮想イメージの圧縮の時に時計が戻ったりしない

上記設定を追記してゲストOSを起動して時計を過去に戻して見る

この状態でサスペンド、そしてサスペンドしたら今度はサスペンドからの復帰

この通り時計はホストOSの時刻ではなく先ほどの時刻の続きから始まる
検証に中断が入りそうな長期間の運用や、何度も再起動しないといけない検証の時に便利

.vmxの設定をすべてTRUEにしてみた
すると今度は再起動などの操作のたびにホストOSの時計に合わせ込む

2018 年 9 月 4 日

最近MacBook Proの起動が遅いと思ったらSSDのTrimが外れていた〜手動でTrimして設定もかけたら元の爆速に戻った

最近あまり気にしていなかったのだが、ここのところ愛機のMacBook Proが何かにつけて遅い気がしていた。

特にFinderでアプリケーションフォルダやユーティリティフォルダの中を表示するとか、システムの起動後のユーザー画面の表示に時間がかかるとかが顕著で気のせいかと思っていたが、さすがに先日これは気のせいではないと思い久しぶりにFusion Drive化したDriveの健康状態を確認することにした。

MacBook ProにSSDを増設して自前Fusion Drive化した経過とその結果の速度の変化については以下の2014年のエントリを参照。
そう、もう４年経っているのである。

老兵MacBook Pro近代化改修計画発動〜まずはSSD導入〜Fusion Drive化計画を実行〜おおむね結果は良好だが痛恨のミスも…（前半）

老兵MacBook Pro近代化改修計画発動〜SSD＋HDDをFusion Drive化する手順は意外に簡単だった〜そのメリットとデメリット〜実際の速度アップ実測値（後半）

そしてバッテリー駆動が１時間もたなくなってしまったために交換バッテリーに自前保守で交換した経緯とその結果は以下を参照。
こちらも交換後４年経っている。
老兵MacBook Pro近代化改修計画第二弾発動！〜チャージ５００回４０分しかもたないバッテリーを新品に交換

Disk Sensei

SSDの速度劣化を防ぐTrimをシステムが起動できなくなるリスクを回避しながら設定できる安全なドライブユーティリティー。

SSDはリチウムバッテリーと同じで使用していると経年劣化でだんだん読み書きの速度が遅くなるという事実があることは以下のエントリで書いた。
老兵MacBook Pro近代化改修計画発動〜SSD＋HDDをFusion Drive化する手順は意外に簡単だった〜そのメリットとデメリット〜実際の速度アップ実測値（後半）

この経年劣化は防ぐことはできないが、劣化を遅らせることはできる。
それがSSDドライブのTrimの有効化で有効化することで実用上は問題ないレベルまでSSDの劣化を遅らせることはできるが、問題はmacOSのYosemite以降、Trim Enablerなどのユーティリティーを使用して有効化していると、なんらかの弾みでファームウエアのNVRAMに初期化がかかった時にカーネルエクステンションの認証が無効になってしまいシステムが起動できなくなる。
この経緯は以下に書いた。
MacBook Proが突然「進入禁止」マークを出して起動できなくなった〜YosemiteでSSDを使用してTrim Enablerを使っている場合、セーフブートも危険〜その復旧法

これはPRAMクリアやセーフブートでも起こることが判明し、しかも一度コレにはまってしまうとクリアするのがかなり面倒で修復ボリュームからターミナル操作、あるいは別の起動ボリュームからイネーブラの解除などが必要になってくる。

こうした面倒な問題を回避するために、安全にTrimを有効化するのがこのDisk Senseiということになる。
YosemiteでSSDのTrimを有効にしていると通行止めマークが出て二度と起動できなくなる恐怖の体験を克服〜Disk Senseiがこの問題を解決してくれる

このDisk Senseiもシェアウエアに移行したが今回図らずもTrimの有効性を再認識したのでこのシェアウエアは登録する価値があると思う。

最近MacBook Proが何だか起動もFinderなどの表示もやたら時間がかかるようになってきた
それで久しぶりにDisk Senseiを起動したらなんとTrimが外れていた
いつ外れたのかはっきりしないがシステムのアップデートのたびに外れるようだし
長らくコレの操作をしていなかったのでもう一年位上は外れっぱなしだった気がする
スライドスイッチでTrimを有効化して再起動するとTrimが有効になる

さらにマニュアルでTrimをかけることもできる
再起動ついでに手動Trimもかけてみた
所要時間は３時間ほど

手動Trimをかけた後Blackmagic Disk Speed Testを使って読み書き速度を計測した
かける前のベンチマークも取っておけばよかったと反省したが格段に表示や書き込みが速くなった

これは４年前SSDを導入してTrimを有効化した時に取ったベンチマーク
上のベンチマークはこれに比べると５％劣化しているが４年で５％なら上等である
SSDを導入してMacBook Proが見違えるように爆速に
なったのに感動したあの頃に戻れたということだ
ちなみに速度の読みは５％減だがインジケーターの針の角度が
ずいぶん下がったのはBlackmagic Disk Speed Testが4Kに対応したからで
もう時代はそういうところまで来ているということ
ますます９年落ちのMacBook Proが老兵になってきたということだ

ついでに４年前にバッテリーの交換も実施しているのでその劣化も計測した
coconutBattery3を使用して充電可能容量がどれくらい減ったかを確認できる
充電回数は１９２回で設計容量に対して85.4%の充電容量でこれも４年間の劣化としては上出来

過去１０年ほどiBookの代からバッテリーの容量変化のヒストリーグラフ
先代のバッテリーは大体４年で容量が半分になってしまったが
今回のバッテリは容量が８割以上残っている
バッテリーの充電回数が少ないからだと思う
先代のバッテリーは４年で充電回数が５００回を超えていたからで
使い方でバッテリーの寿命は大きく変わる

2018 年 9 月 2 日

Microsoft Remote Desktop

マイクロソフト社純正のリモートデスクトップコネクションのクライアントアプリMac版。

以前から愛用していたMicrosoft　RDCのver.2は最近のWindows Updateの認証変更によりついにWindowsにも繋げなくなってしまった。

仕事柄WindowsXPにもつながないといけなかったので環境を変えたくなかったので最近までver.2を使っていたが、ついに使い物にならなくなったのでRemote Desktop8に乗り換えた。

変更点はデフォゲの設定ができるとか、スクリーンサイズの表示が自由に変更できるようになったとかメリットが多い。
また今回試したところ、WindowsXPにもver.8で接続できることも確認した。
ならばメリットしかないということになる。

やっと乗り換えたところだが、ver.8はマイクロソフトの推奨ではなくなるようだ。
Microsoftもver.10を推奨している。

残念ながらver.10は動作環境がEl Capitan以上となっているので８年落ちのMacBook ProのYosemiteでは動かない。

MacBook Proの更新、事態は急を告げているのかもしれない。

リモートデスクトップの操作画面は随分変わった
起動したパネルの追加ボタンで接続の設定を追加する

ここに設定を入れていく
設定名は自分がわかりやすい名前、PCnameはホスト名か
IPアドレス、デフォゲが必要ならGatewayに入れる
あと必要なのはユーザー名とパスワードだけと簡単だ

管理者権限で接続するかとかコピペを制約するかなどの権限設定はここ

設定した接続パラメーターを選択してスタートボタンで接続する

ウインドウサイズの設定が細かくできるようになったのもRDCの改善点
スクリーンサイズ、フルスクリーン表示かウインドウ表示かなどの選択が可能
Macのスクリーンに合わせてスケール表示することもできるようになっている

Windowsの認証は最近のアップデートで一段とうるさくなったみたいで
毎回認証の確認タグが表示される

接続を切る時はメニューからあるいはコマンド＋Wキーで切断できる
スケーリングもここでワンクリックで解除したり戻したりできるので
拡大して操作したりスケーリング表示に戻して全体を把握するのも容易い

解像度を相手のスクリーンサイズに合わせてフルスクリーン表示を解除して
Macのスクリーンサイズにスケール表示する設定にした

するとこういう感じでMacのスクリーンサイズに合わせて
ウインドウのスクリーンを縮小して表示
8bitの低品質で接続すると色数が制限されてアイコンの透過も省略されて表示される
その代わりWAN経由でも軽快に動く
VNCが使えない環境でもRDCで遜色なく表示できる

スケーリングを解除した場合の表示
マウスに追随するようになったのでマウスを動かせば見えていない範囲にもスクロールできる
コマンド＋２またはメニューからスケール表示にすぐ戻れるのでそこは画面共有より便利になった

接続品質を32bitに変更すると色彩も正確に表示されアイコンの黒い枠も出なくなった
表示は綺麗になったがWAN経由での接続の場合表示がカクカクになるだろうから
接続品質に合わせて解像度は選択することになる

以前別のエントリでも取り上げたがVNCと違ってリモートデスクトップコネクションの場合
遠隔からシステムの終了、再起動などのメニューが操作できない

そういう必要が出てきた場合はコマンド＋Rキーを叩いてcmdと打って
コマンドプロンプトを起動し再起動の場合はshutdown -r、
終了の場合はshutdown -sを入力する必要がある

またApp StoreにはJISキーボードに対応していないなどの
古いレビューが未だにトップに表示されるがちゃんと
Macから日本語キーボードで日本語入力ができる
こういうところに書いてあるいい加減なレビューは信じるなということだ

そしてVNCよりアドバンテージがあるのは日本語のテキストをMacにもコピペできるということだ
Windows上でControl＋CキーでコピーしMacの画面に移ってコマンド＋Vキーでペーストできるのが面白い

リモートデスクトップの接続設定はWindowsと共有できる
Exportメニューから.rdcの拡張子のリモートデスクトップファイルを生成できる

これをWindows版のRDCに渡すことができるしWindowsのRDCで
書き出した.RDCファイルをMacにインポートすることもできる