Hyper-V第2世代仮想マシンにWindows Server 2012R2をインストールしたらKB3000850適用に失敗する


Windows Server 2016を立てて、Hyper-V上にWindows Server 2012R2仮想マシンを作ろうとしたら、うまくいかない事例が発生。

オンラインのWindows Update実施ではなく、某社が用意した一括適用バッチファイルを実行して適用したところ、必ず適用に失敗し、元に戻す処理が発生するした。

提供されたバッチファイルを分割しまくり、原因を調査していったところ、KB3000850の適用に失敗していることを発見。

問題のKB「Windows RT 8.1、Windows 8.1 および Windows Server 2012 R2 用の 2014 年 11 月付け更新プログラムのロールアップ

既知の事例に第2世代仮想マシンで適用が失敗することが記載されている。

ベースの Windows Server 2012 R2 の HYPER-V ホストを実行して使用して UEFI ファームウェアをサポートする第 2 世代の仮想マシンのゲストを実行しているし、セキュリティで保護されたブート オプションを有効にしたがあります。さらに、ゲスト バーチャル マシンは、Windows Server 2012 R2 を実行しています。

対処方法としてKB2975061「月の 2014 年まで Windows 8.1 および Windows Server 2012 R2 の更新プログラムのサービスを提供」を事前に適用する、とある。

確認してみると、某社提供のパッチ集にKB2975061が含まれていない。

このため、別途KB2975061をダウンロード・適用した後、一度再起動し、そのあとKB3000850を適用したところ、正常に適用が成功した。

このことから、某社提供のパッチ適用スクリプトが問題だったということですね。

あとでWSUS Offline Updateと比較してみよう

Windows Hyper-V仮想マシン上のWindowsライセンス


Hyper-V環境上にWindows Server仮想マシンを導入するとき、「仮想マシンの自動ライセンス認証」という手法により、物理Windows Serverに適用されているプロダクトキーを使用したライセンス認証を行わせることができる。

Windows Server 2012R2ベースのドキュメント「Automatic Virtual Machine Activation

とりあえず現状認識しているライセンスの確認は「slmgr /dlv」を実行することで確認出来る。

ライセンスの適用は「slmgr /ipk ライセンスキー」で適用できる。

MCTの憂鬱「仮想マシン自動ライセンス認証に関して」を見ると、ホストWindows ServerのアプリケーションログにイベントID 12310 として「仮想マシンの自動ライセンス認証要求」のログが出るらしい。

手元に評価版環境しかなかったので実機検証はできず

Hyper-V統合サービスのバージョン確認


Hyper-V上でWindowsを使う場合、Hyper-V統合サービスをインストールする必要がある・・・というのが昔の設定。

いまは・・・というかWindows Server 2016以降はWindows Updateによる提供に代わりました。

これにより、古い資料では、ゲスト上にHyper-V統合サービスがインストールされているかどうかをPowerShell上で「Get-VM | Select Name, IntegrationServicesVersion」を実行し、バージョンを確認する、とかなっていたものが使えなくなっています。

Windows Server 2016環境では「
IntegrationServicesVersion」は「0.0」になります。

では、いまは、どうやってIntegration Sevices Versionを確認するのかと言えば、ゲストOS上で「REG QUERY “HKLM\Software\Microsoft\Virtual Machine\Auto” /v IntegrationServicesVersion」を実行することで確認します。いままでと異なり、ホストOS側では確認できないという点に注意が必要です。

参考資料 「クラスターの検証を実行した際に、Hyper-V 統合サービスのバージョン検証で警告が発生する」 「Manage Hyper-V Integration Services

RHEL7.4をHyper-V上で動かしたらstorvscでSense Key関連メッセージが出た(未解決



Windows Server vNextのHyper-Vの上で、RHEL7.4の仮想マシンを動かしていたら、storvscに関するメッセージが出力される。
[storvsc] Sense Key : Illegal Request [current]
[storvsc] Add. Sense: Invalid command operation code

うちの環境ではハングアップはしていないが、関連しそうな事例として下記を発見。
Bug 1502601 – [Hyper-V][RHEL7.4] hang when thaw on microsoft hyper-v
この問題は「RHSA-2018:1062 – Security Advisory」で解決しているらしい。

…kernelが3.10.0-862.el7ということはRHEL7.5ということですね
とりあえずkernelだけアップデートして様子見・・・

まだ出力される
では、3.10.0-862.9.1.el7にしてみる・・・
やっぱりまだ出力される

果たして、これはどういう問題なんだろうか・・・

Backup ExecでHyper-V仮想マシンバックアップ/リストア時にGRT用テンポラリディレクトリは使われるのか?



Backup ExecではHyper-V/vSphereの仮想マシンバックアップを仮想レイヤーの方からバックアップを行った場合、その仮想マシンの上でWindowsが動いている場合は、ファイル単位でのリストアを行えるGRT機能というのをサポートしている。

で・・・Backup Execの設定を見ていくと、全体設定の中に
・Granular Recover Technology
  バックアップ時にBackup Execが一時的にデータを保存するパス C:\TEMP
  リストア時にBackup Execが一時的にデータを保存するパス   C:\TEMP
というものがある。

仮想マシンバックアップ時にC:\TEMPを観察してみたけど、使用している様子が見受けられない。
不思議に思って調べてみた

Veritas Backup Exec 管理者ガイド「Granular Recovery Technology」の「Granular Recovery Technology を使うバックアップ用の推奨デバイス」

ディスクデバイス、重複排除デバイス、およびディスクカートリッジデバイスに送信された GRT 対応のバックアップジョブの暗号化を有効にすると、Backup Exec は詳細バックアップセットを暗号化された形式でディスクに格納しません。GRT 非対応のバックアップソースのバックアップセットのみが暗号化型式で格納されます。 クラウド、OpenStorage、およびテープデバイスに送信されるバックアップジョブのすべてのバックアップセットは、暗号化型式で格納されます。

ファイルサイズの制限があるボリューム上でディスクストレージデバイスを使う必要がある場合、Backup Exec ではステージングの場所が必要です。 Backup Exec はバックアップジョブの実行中に少しのメタデータをステージングの場所に一時的に格納します。 バックアップが終了したら、ステージングの場所からデータを削除します。 ただし、ファイルサイズの制限がないボリューム上のディスクストレージデバイスを宛先として使う場合、ステージングの場所は必要ありません。

ステージングの場所のデフォルトのパスは C:\temp です。

テープ装置などを使っている場合はステージングの場所が必要。
ローカルのNTFSディスクやCIFS共有を使っている場合は、「ファイルサイズの制限に制限がないボリューム」なので、ステージングの場所は不要。

というわけで、今回テストした環境は、CIFS共有をバックアップ保存先としていたため、ステージング領域が不要であった。ということのようでした。