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共有をバックアップ保存先としていたため、ステージング領域が不要であった。ということのようでした。

BackupExec / NetBackupでWinPEを使った起動ディスクで仮想マシンをリカバリするとNIC設定が消える場合がある


BackupExec 20.1を使ってHyper-V上のWindows Serverのバックアップを行った。
最初、Hyper-V経由で仮想マシンとしてのバックアップにしようと考えていたのだが、BackupExecでは特定のドライブのバックアップを取らないという設定が出来ず、必ず全ドライブをバックアップする必要があることが分かった。
このため、対象サーバにBackupExec Agentをインストールして、エージェント経由でのバックアップを取ることにした。

で、Windows ADKを使用したSDR起動ディスクを作って、フルリストアのテストを行ったところ問題発生。
NICが2つついている場合、片側につけたIPアドレス設定がリカバリされない。

いろいろ条件をかえて試してみたけど、必ず発生している。

どうやら仕様らしい。

Veritasのサイト上だとNetBackup / vSphere環境での話として、「After restore a Windows Virtual Machine to original or alternate location, Virtual NIC settings may be changed or lost.」というのが掲載されている。

回避方法はなく、手動で再設定しろ、だそうな

vSphere環境でCentOS7やUbuntu 16.04などをインストールするとコンソールが高解像度過ぎる


vSphere環境でCentOS7やUbuntu 16.04などをインストールすると、X-Windowを起動しないコンソール画面での解像度が高くて使いにくいという問題が発生しやすい。

せめて1024×800ぐらいに収まらないか・・・と思ったら設定はあった。

Adding video resolution modes to Windows guest operating systems (1003)
上記の日本語版KB「Windows ゲスト OS へのビデオ解像度モードの追加 (2078472)

高解像度にしたい場合は、上記にある手順をいろいろやらなければならないが、低解像度にしたい場合は、vmxファイルの直接編集の必要はなく、仮想マシンオプションの詳細にて「svga.maxWidth」と「svga.maxHeight」の値を追加するだけ良い。

仮想マシンの電源を停止した状態で、仮想マシンオプションの詳細を開き、svga.maxWidthを1024、svga.maxHeightを800で追加している。


2018/05/25 追記

なお、Hyper-Vの場合は、grubへの設定で対応する。
Changing Ubuntu Screen Resolution in a Hyper-V VM

上記はUbuntuの場合の例となっているが、RedHat/CentOSでも基本的には同じ
grubの設定に、「video=hyperv_fb:1024×800」を追加して解像度を指定する。という形になる。


2019/07/17追記

RHEL8のインストーラで発生する英語だと問題なかったのが、日本語にした途端画面外にはみ出る、ということへの対応について「vSphere上にRHEL8を日本語でインストールしようとするとインストーラがちゃんと表示されない」で記載しました。

まぁ、インストール時のカーネルオプションとして 「inst.resolution=1024×800」 を追加する、という話ですね。