The use of 'mode:vm' in Sysprep

[stefanes]

We are currently building VM images based on the templates in this repo and deploying them to VMs of different sizes and CPU configurations (depending on developer needs). With that in mind I would like to understand more about possible implications with this change: #5136

Can we still do that with the images built with /mode:vm switch? Can we e.g. still mix and match between number of cores, amount of memory, and/or AMD/Intel CPUs?

---

From the Sysprep documentation:

/mode:vm

Generalizes a Virtual Hard Disk (VHD) so that you can deploy the VHD as a VHD on the same Virtual Machine (VM) or hypervisor. After the VM restarts, the VM can boot to OOBE. For example:

Sysprep /generalize /oobe /mode:vm

The only additional switches that apply to VM mode are /reboot, /shutdown, and /quit. You must deploy the VHD on a Virtual Machine (VM) or hypervisor with the same hardware profile. For example, if you created VHD in Microsoft Hyper-V, you can only deploy your VHD to Microsoft Hyper-V VMs with a matching hardware profile. Deploying the VHD to a different VM with a different hardware profile might cause unexpected issues.

---

For the hosted Azure Pipelines and GitHub Actions agents you build these images on Standard_D8s_v4 VMs but they are deployed to Standard_DS2_v2 VMs.

So what does same hardware profile mean exactly in this case? Are you not following the recommended practises from the documentation, or do you have more information why this switch is safe?

[miketimofeev]

@stefanes hi! We haven't found any issues using this option. We build images using V4 generation VMs and deploy to V2 generation without any issues.