Hyper-V Replikation und die Pagefile

Für alle, die virtuelle Maschinen replizieren, dürfte dies interessant sein.

Lässt man die Pagefile in Standardeinstellung auf c:, dann trägt sie deutlich zu hohem Replikationstraffic bei.
Will man die Pagefile nicht mitreplizieren, muss man sie auf eine nicht replizierte Platte verlagern.

Windows hat damit kein Problem, Hyper-V offenbar schon. Nachdem ich die Pagefile verlagert hatte, fror die VM nach Neustarts gelegentlich an der Anmeldemaske einfach ein.

Zum Test habe ich Skripte geschrieben, die die VM über Nacht immer wieder runterfuhren und wieder neu starteten - hier kam es bei etwa jedem 4. Neustart zu diesem Problem. Das Selbe habe ich dann mit Suspend und Resume versucht - mit dem selben Ergebnis.

Lösung war sehr einfach: zusätzlich eine kleine Pagefile (200 MB) auf c: vorhalten und den Rest auf die nicht-replizierte Platte.

Umgebung:
Hyper-V Core 2019
Gen2-VM: Server 2016 1607 (up2date) (40 GB RAM, Pagefile ist system-managed size, etwa 6 GB)
Die virtuelle Pagefileplatte ist über SCSI (default und einzig Mögliches für Gen2 VMs) angebunden

Dieses Problem war schon bekannt war und hängt laut Altaro mit der SCSI-Emulation zusammen (siehe https://www.altaro.com/hyper-v/hyper-v-page-file-settings/

Tuning a page file for a virtual machine is not significantly different from tuning for a physical server. There is one restriction: you cannot place a virtual machine’s swap file on a VHD that is attached to the virtual SCSI chain. This is because the SCSI driver is synthetic, so it doesn’t load until after the virtual machine’s operating system has attempted to initialize its page file. You must place swap files for virtual machines on VHDs attached to the IDE chain. The IDE drives are emulated, so they are visible to the virtualized operating system prior to loading any drivers and the swap file can be properly initialized.

Nun stellt sich doch die Frage: wenn das so ist, wie stellt sich Microsoft das dann vor? Gen2 VMs bieten wie gesagt gar keine IDE-Emulation an.