結果的に、Build22468 が諸悪の根源と結論付けました。
現在は、Build22454 で安定。
コレのその後になります・・・
仮想マシンの作成、動作検証。ビルドアップ要求が来る、そしてまた不調に陥る。
しばらくコレの繰り返しで、途中から今まで使えていたアプリが起動不可になる、挙げ句の果てにはプロダクトキーが無効ですよと言い始める始末。
もう使うのやめようかと、考え始めた矢先。再度 Build21354 で仮想マシンを再作成。順を追って Build22454 でビルドアップを止めたところ、全てが安定しました。
不調になったアプリは再インストで何とか復旧。プロダクトキーは11は使えて10で弾かれるという状況なので、ライセンスルールの問題なのでしょう。深追いは止めました。
Windows11は10に比べると、海外版から日本語版への変更は手続きがかなり簡略化されて楽だったのですが、ソレ故何故ソコはやっておいてくれない的な、再設定のこぼしがあってやはり面倒くさい。
僕はこのシステムロケールの階層に気が付かなくて、アプリの文字化け是正に手間取ってしまいました。
その昔 XP を使っていた頃、不調が続いて 週末はXPのリカバリのためにある。そんな時期があったのですが、ソレを思い起こす1週間となり、疲れ果てました・・・
しかし、Windows11の実行要件を厳しくしたことで、色々と弊害アリな感じでしょうか。リリース版に近づくほど、仮想マシンで使うには塩梅の良くないWindows11 ARMです。
この様な状況の中で、ひとつ収穫だったのがParallelsの仮想マシンという概念の優位性。
仮想マシンはMacから見ると1つのファイルにしか見えなくて、中を窺い知ることは出来ません。Mac側からCドライブ配下のファイルをサルベージしたい、なんてことは不可能です。ところがこのファイルをコピーすることで、簡単にWindows環境がまるっとバックアップ可能。不調なシステムは塩漬けして、新しい仮想マシンで復旧を急ぐ。そんな事が簡単にできます。
今回都合3つの仮想マシンを作成して、マウント変更をしながら不具合の状況の切り分けをしたのですが、とても便利でした。
もしコレが単独のWindowsPCで行っていたら、さらに気の遠くなるような作業の連続だったでしょうね。
何しろすべてはMac上で走っている。モニターもキーボードもトラックボールも共有。そしてソレは安定稼働。復旧作業をしながら他のリサーチを、1つのデバイスでシームレスに行える。コレは一度体験するとやめられないです。
また今まで気づいていなかったのですが、複数の仮想マシンを同時に起動出来ること。
起動は仮想マシンのアイコンを、それぞれダブルクリックでOK。これだけで、Windows10と11が M1Mac 上で並走しています。
Windows11に10を重ねてみましたが、ちょっと不思議な光景。
ひとつのMac上で、ふたつのWindowsが走る。
Parallelsがサポートしているのか深堀りしていませんので、安定性は検証していませんが、可能性を感じる面白い状況です。
その仮想マシンのファイルを、現在外付けデバイスのSSDにマウントして使用しています。
コレも問題なく安定稼働。このケースの転送速度があれば僕の用途では問題なし。
Windows環境本格運用後、ストレージを意外と占拠しはじめたので、次案を検討していたのですが、喫緊の課題ではなくなりました。
さて、Windowsa11 ARMとParallels仮想マシン。今後どうなるのでしょうか?
Microsoftのお家事情に振り回される事は必至ですが、ぜひとも共存を目指してほしいですね。取り敢えず、当面ビルドアップは凍結で様子見です。
でも、まもなくMacOSのメジャーアップデートが控えているのですよ。
今度はMac側でゴタゴタがあるかもしれません。コレもしばらく放置かな。
でもMac使いは、うっかりアップデートしてしまうのですよ・・・