> you can use the `sysprep.exe /mode:vm` flag, which essentially tells sysprep to retain most of the device tree, since you expect to run the thing on similar h

> you can use the `sysprep.exe /mode:vm` flag, which essentially tells sysprep to retain most of the device tree, since you expect to run the thing on similar hardware In my experience that only really works with full paravirtualized environments. If you start mixing in SR-IOV things can get a little messy. Given customers actually crave high performing networks, that then presents you with a choice: 1) Make two images. One for full paravirtualized environments. 2) Ignore it and let Windows first boot time take longer. Of course most clouds already end up with what are effectively multiple images for the same setup/configuration of Windows, one per hardware type anyway, because even with full PV things can get a bit strange, and you're often ending up with blue screens during first boot. They're not going to want to _double_ that number. Even with full automation that's a bunch more things that can go wrong, more operational burden etc. etc. Where's the value proposition? Windows provisions a little faster? Linux images rarely need to be produced for different hardware types / environments. They just spin up and away you go. As to your systemd/sysv comment.. even sysv based instances have a time-to-login on first boot of under a minute. The systemd developers were obsessed with the idea that parallelism would speed up the boot process, but it doesn't make as significant a performance impact as they'd have you believe, especially when you're talking about cloud images that rarely have many services running on first boot. Even if you go trawling down the systemd boot time reporting, you'll see that most components start in fractions of a second, and the same was true under SysV too.