今日はまったりランチで、木都里亭で麻婆丼。きっと、健康的。
投稿者: zen
-
すしのこ
タマノイの「推しの子」コラボの「すしのこ」が売っていたので買ってきた。普段使いするので、何個か買ってくればよかったかも。
このパッケージの違和感のなさがいい。
-
vSphere8.0でVMの自動起動設定を調べる方法
vSphere8.0でESXiの起動時（電源ON時）にVMも起動させる設定がされているVMを調べる方法のメモ
1. vCenter Server にログインする。
2. 「ホストおよびクラスタ」のメニューを開く。
3. 自動起動させたいホストを選択する。
4. 「構成」タブを選択する。
5. 「仮想マシンの起動およびシャットダウン」を選択する。
6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」の選択項目があるので、それぞれを選択する。
7. 起動の部分が「有効」になっているVMが自動起動するVM。起動遅延時間や起動順番を確認すると、どの順番でVMが起動してくるのかがわかる。
-
メモ：.NET8.0の対応Windows OS
ちょっと検索で探しにくかったので、メモ。
.NET8.0（.NET9.0も同じだった）が対応しているWindows OSは以下。
- Windows server 2012以上（2012の場合は、Extended Security Updatesがインストールされていること。サポート無しならばランタイムは動く）
- Windows server Core 2012以上（2012の場合は、Extended Security Updatesがインストールされていること。サポート無しならばランタイムは動く）
- Windows10 バージョン1607以上
- Windows11 バージョン22000以上
参考：
https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md
https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md
-
読了：ソフトウェアデザイン 2024年6月号
いつもどおり、1ヶ月遅れで読了した。Bunの特集が読めてよかった。
Bunの特徴的な部分は特集でわかった。Node.jsとの比較もわかった。読んだけれど、なんだかんだでわからない部分が多い。振り返ってみると、今のNode.jsがどういうものか解っていない、だからBunのことが解らない。というか、JavaScriptランタイムが解っていない。そして、JavaScriptのランタイムが解っていないということがわかったら、なんか見えてきた。禅問答みたいだけど。
結局、書いたJavaScriptやTypescriptを実行するための土台。クライアントサイドだと、ブラウザ的な部分。サーバサイドで動かすときの実行環境でしかなくて、Node.jsが担っていた部分を代替できるかもしれないのがBunということか。Webサーバ機能として、動作させれば、WebAPIとしての機能を作れる。単純にBun環境を作ったのならば、コマンドラインからJavaScriptで、プログラムを動作させられる。開発のところのパッケージ操作やプロジェクトパッケージに目がいってしまって混乱した。動作環境と開発のためのプロジェクト環境がごちゃっとなっているのに慣れないからだろう。
JavaScriptまわりのわかりにくさというか、ごちゃっとなっている感じは落ち着かないのだろうか。ES6、TypeSpcrit、CoffeeScriptとか、それに加えてフロントとバックエンド（サーバサイド）のフレームワークに環境があるのがなぁ。流行り廃りも早いし。そんななことを読み終わったあとに考えていた。
-
ランチ：サブウェイのサンドイッチ（2024/6/19）
今日のランチは、サブウェイで生ハム＆マスカルポーネのサンドイッチ。野菜は増量でボリュームアップ。
久しぶりに食べた。美味しかった。
-
vSphere8.0でESXiの起動時にVMも起動させる設定
vSphere8.0でESXiの起動時（電源ON時）にVMも起動させる設定のメモ。
自動起動は、「ホストがvSphere HAクラスタの一部である場合、仮想マシンの自動起動とシャットダウンが無効になります。」という仕様があるので注意すること。
vSphere8でのホスト起動時の自動VM起動設定
1. vCenter Server にログインする。
2. 「ホストおよびクラスタ」のメニューを開く。
3. 自動起動させたいホストを選択する。
4. 「構成」タブを選択する。
5. 「仮想マシンの起動およびシャットダウン」を選択する。
6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」「手動での起動」の選択項目があるので、「手動での起動」を選択する。ここで表示されている仮想マシンは自動起動設定がされていないVMである。
7. 「編集」をクリックする。
8. 画面内のポップアップで「仮想マシンの起動/シャットダウン設定の編集」が開く。
9. 「手動での起動」を選択し、一覧から自動起動させる仮想マシンを選択する。
10. 「移動先」をクリックし、「自動」または「自動順位付け」を選択する。（移動先の場所はわかりにくいので注意）
11. 上記で選択した「自動」／「自動順位付け」を選択し、選択した仮想マシンが表示されていることを確認する。
12. 確認後、「OK」をクリックする。（クリック前の起動の表示は無効になっているが、これでよい）
13. ポップアップが閉じるので、「仮想マシンの起動およびシャットダウン」で、「自動」／「自動順位付け」を選択し、選択した仮想マシンの起動が有効になっていることを確認する。
もし、自動起動やシャットダウンのタイミングを変更する場合は、編集画面で、起動時間とシャットダウンの時間の秒数を変更する。
-
「vixエラーコード＝21009」でVMware Tools のインストールが失敗。
vCenter Serverから、VM（Windows Server）のVMware Toolsのバージョンアップをおこなったところ、「vixエラーコード＝21009」でVMware Tools のインストールが失敗した。その後、vCenter Serverの画面では、その仮想マシンは「VMware Toolsはインストールされていません」にかわった。
アンインストールは成功しているようで、仮想マシン上もVMware Toolsは無くなっていた。
対処方法
1. 念のため、VM（Windows Server）のVMware Toolsのインストールで利用されていたフォルダを削除。下記のフォルダを中身ごと削除する。アクセス権がないと言われるはずなので、アクセス権を取得してから削除する。
C:\Windows\Temp\vmware-SYSTEM
2. vCenter Serverから、VMware Toolsのインストールを実行する（仮想サーバ上に、VMware Toolsのインストーラーをマウントする）。
3. VMにログインして、VMware Toolsをインストールする。
-
ランチ：瑞華楼のニラレバ（2024/6/18）
今日のランチは、瑞華楼のニラレバ定食。安定のチープチャイナのいためもの。美味しかった。
-
SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーがエラー
SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーでエラーが発生した。
SQL ServerにSSMSでアクセスしてみると、リンクサーバーは存在する。リンクサーバーへの接続も問題なし。Select文でもリンクサーバー先のテーブルを参照できる。プロシージャーを実行すると、OLEDBのエラーが表示される。
リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" から、メッセージ "トランザクションは既に暗黙的または明示的に、コミットまたは中止されています。" が返されました。 メッセージ 7391、レベル 16、状態 2、プロシージャ dbo.プロシージャー名、行 99 [バッチ開始行 2] リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。状況をまとめると・・・
- SQL Server 2005もSQL Server 2019も稼働している。
- もともとはプロシージャーも正常に実行できていた。
- リンクサーバーの接続確認は問題なし
- Select文などを発行すると、正常にリンクサーバーのテーブルにアクセスできる。（Viewでも同様）
- プロシージャーは、失敗する。
- 分散トランザクションの設定はちゃんとできている（もともとは成功していた）。
- リンクサーバーの接続で使用するユーザはアクティブであり、パスワードも問題なし。
- 実行結果を見ていくと、ごくまれに成功しているときがある（SQL Serverへのコネクションは異なる）
いろいろと切り分けた結果、認証先？のAD（Active Directory）のOSバージョンによって、プロシージャーの実行が成功するか失敗するかが分かれていた。古いWindowsOSのADに問い合わせがいくと成功する。新しいOS（Windows Server 2022）だと失敗する。
Windows Server 2022のADに問い合わせされて、SQL Server 2005にアクセスされると、プロトコルとかセキュリティのキーセットの問題ではじかれて分散トランザクションが失敗して、タイムアウトになっているようだ。古いものは、互換性も無くなってきているので、きつい。