WIN1@Codename

Codename

ライブマイグレーションの設定が少し楽になったかも

以前ライブマイグレーションの設定でこんな記事を書きました
https://www.gmo.jp/report/single/?art_id=157

Windows Server 2016 で改めて設定を確認してみたところ、面倒だったActive Directoryの委任設定で、
「任意のサービスへの委任でこのコンピューターを信頼する(Kerverosのみ)」
を選択してもライブマイグレーションが出来るようになっていました。

20184506010739

以前は、「cifs」と「Microsoft Virtual System Migration Service」を任意のプロトコルで追加しないとライブマイグレーションができませんでした。
GUIでも面倒でしたが、この部分スクリプトに落とし込むのも結構大変でした。
http://www.vwnet.jp/Windows/WS12R2/MoveVMSetting/MoveVMSet.htm


GUIではチェックを入れるだけですが、「任意のサービスへの委任でこのコンピューターを信頼する(Kerverosのみ)」をスクリプトに落とし込むと

$Acct = Get-ADObject -Filter {Name -eq "<ServerNmae>"} -Properties userAccountControl
$NewUAC = $Acct.userAccountControl -bor 0x00080000
Set-ADObject -Identity $Acct -Replace @{"userAccountControl" = $NewUAC}

(https://bamcisnetworks.wordpress.com/page/5/)

となります。


Hyper-Vのホスト設定のコード化が少し楽になりそうです。

New-NetNat エラー修正方法

Windows Server 2016 から利用できる New-NetNat コマンドですが、時々エラーとなってNatの設定ができなくなる場合があります。

New-NetNat : パラメーターが間違っています。
発生場所 行:5 文字:1
+ New-NetNat -Name "Nat -InternalIPInterfaceAddressPrefix 192.168. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (MSFT_NetNat:root/StandardCimv2/MSFT_NetNat) [New-NetNat]、CimException
    + FullyQualifiedErrorId : Windows System Error 87,New-NetNat

 

このエラーの修正方法を紹介します。

Net Stop winmgmt #WMIと関連サービスを停止します
Rename-Item C:\Windows\System32\wbem\repository repository_bak #フォルダ名を変更
Net Start winmgmt #WMIと関連サービスを再開します


WMIのC:\Windows\System32\wbem\repository フォルダ内容に問題があるため、新しいNAT設定ができないようです。

ReFS上のNTFSフォーマットのvhdxファイルは、ReFSの速さとNTFSの使い勝手を実装する

新しいファイルフォーマットのReFSは、Hyper-Vで利用する場合NTFSと比べて利点もありますが、NTFSでできたことが一部できないなど、使い勝手で用途を選ぶ必要があります。

ReFSの利点
・ファイルデーターの破損を確実に検出
・オンラインで破損ファイルの修復が可能
・ファイルが使用する物理ディスク内の領域(論理セクター)をメタデータで管理
・ファイルをコピーする場合、メタデータの操作(論理クラスターの割当と変更)で完結し、物理データの操作は不要
・容量固定のvhdxファイルの作成が速い
・チェックポイントの削除(ファイルの結合)が速い

ReFSとNTFSの比較
20175625110602.jpg


ですが、vhdxファイルをうまく使うことで、ReFSの利点とこれまでのNTFSの使い勝手を同時に利用することができるようになります。

サーバー上の物理ドライブとしてEドライブがReFSでフォーマットされています。
20175225110612.jpg

Eドライブ内にNTFSフォーマットの容量固定10GBの仮想ハードディスクを作成します。
かかった時間はわずか2秒ちょっと。ReFSなので速いです。
20170625120603.jpg


作成したvhdxファイルをサーバーにマウントして、Fドライブとします。
20170925120617.jpg

通常であればNTFSフォーマット上で、vhdxディスクファイルを容量固定で作成するとそれなりの時間が必要となりますが、ReFS上のvhdxファイルをNTFSでフォーマットすることで、ReFSのパフォーマンを持ったNTFSフォーマットのドライブとして利用することができます。

Fドライブ上に容量固定で5GBのvhdxファイルを作成してみましょう。
201714251206070.jpg
2.4秒ほどで作成されました。

通常のNTFSドライブでは
20173025120628.png
3分以上かかりますね。

以上、ということで、ReFSとNTFSは使い方次第で利用価値が大きく広がります。




Hyper-V上で稼働中の仮想マシンのVHDを使って、物理マシンでVHDブートする方法メモ (これも「V to P」?) 追記 2

VHDブートするvhdファイルは必ずベーッシクディスクドライブに置くこと!

ダイナミックディスク上に置いたvhdファイルだと、bcdedit /set  でエラーになります。

Windows Update 後に sysprep を実行したら「致命的なエラーが発生しました」の対処方法

しばらくWindowsUpdateを行っていなかった仮想マシンに、まとめてWindowsUpdateを実施しました。

かなりの数のアップデートがありまつことしばし。

その後、この仮想マシンのイメージをコピーして、sysprepを実行したところ、「致命的なエラーが発生しました」とのこと。

20150122050450

sysprepのログを見てみると

"C:\Windows\System32\Sysprep\Panther\setuperr.log"
[0x0f0073] SYSPRP RunExternalDlls:Not running DLLs; either the machine is in an invalid state or we couldn't update the recorded state, dwRet = 0x1f
[0x0f00ae] SYSPRP WinMain:Hit failure while processing sysprep cleanup external providers; hr = 0x8007001f

slmgr -dlv コマンドでリセット回数を確認しても、問題ありません。
20155622070433

skiprearm をsysprepの応答ファイルにいれて、sysprepの3回という制限は解除しているのですが、このエラーを解消するためには、sysprepの回数制限でエラーが起きた場合の対処方法と同じ処方が必要となります。

1.2つのレジストリを下記の内容に編集します。
HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\GeneralizationState\CleanupState:2
HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\GeneralizationState\GeneralizationState:7

2.コマンドプロンプトで下記の2つのコマンドを実行します。
msdtc –uninstall
msdtc –install

3.再起動します。

4.改めてsysprepを実行します。

これで「致命的なエラー・・」が発生しなければ成功です!

次のページ

FC2Ad