Installing Windows Server on OpenStack: The Manual Approach That Actually Works

Most cloud documentation tells you to use Packer to build Windows images for OpenStack. It is the right answer eventually. It is rarely the right answer the first time.

I spent the better part of two days fighting Packer's OpenStack builder before I gave up, opened a QEMU window, and built the image by hand in about an hour. The hand-built image worked on the first boot. That experience is the real reason this post exists not because manual image building is inherently good, but because the gap between "the tooling is supposed to work" and "the tooling actually works" is wider on Windows than almost anywhere else I've shipped.

Why Windows on OpenStack Is Harder Than It Should Be

Linux distributions ship cloud-ready. Cloud-init is baked in, VirtIO drivers are in the kernel, and the image boots without ceremony.

Windows ships none of that. Before a Windows image is usable on OpenStack you need:

• VirtIO drivers injected during install (storage and network will not work otherwise)
• CloudBase-Init configured to handle metadata, hostname, password, and RDP setup
• A clean Sysprep at the end so each instance gets a fresh SID and unique state

Each of those steps has timing-sensitive behavior, and any of them can fail silently. That is the part Packer struggles with.

Where Packer Falls Down

Packer's OpenStack builder is fine for Linux. For Windows it has to:

1. Boot a local QEMU VM with the right VirtIO and floppy device layout
2. Drive an unattended install via an Autounattend.xml it generates
3. Inject WinRM credentials, wait for the network to come up, and connect
4. Run provisioner scripts over WinRM
5. Sysprep, shut down, and snapshot the disk for upload

Any one of those stages can break in a way that surfaces as "WinRM connection timed out" the most useless error message in cloud tooling. The actual failure could be a missing driver, a misordered boot device, an Autounattend typo, an unsigned driver warning blocking the install, a Sysprep that ran too early, or a firewall rule that did not get disabled. Packer does not tell you which.

So the debug loop becomes: change one variable, wait fifteen minutes for the build to fail, read inscrutable logs, change another variable. Two days disappear fast.

Why Building Manually Is Sometimes the Faster Answer

When you build the image by hand, every step is observable.

You watch the Windows installer run. You see which drivers Device Manager lists. You log into the box and click through the CloudBase-Init installer yourself. You run Sysprep manually and watch it complete.

If something goes wrong, you see it the moment it happens. You also end up with a known-good reference image that you can use as the answer key when you go back to writing the Packer template.

This is the operational philosophy worth keeping: automate after you understand, not before. Packer is a force multiplier on a process you have already validated. It is not a substitute for validating the process in the first place.

When to Use Packer Anyway

Manual builds are fine when you build images rarely quarterly, or when Microsoft ships a new Server release. They stop scaling the moment you need:

• A new image every patch cycle
• Multiple Windows versions kept in lockstep
• Reproducible builds for compliance auditing
• Anything that has to live in CI

For any of those, eat the two days, get Packer working, and treat the manual build as your reference. The known-good image gives you something to diff against when the Packer template misbehaves which it will.

What to Do Right Now

If you are hitting the Packer wall today and you have a Windows server that needs to be running this week, build the image by hand. The full procedure VirtIO injection, CloudBase-Init configuration, Sysprep, Glance upload, instance launch, and first-boot RDP is documented step by step in our support guide: Deploying Windows Server on InMotion Cloud.

The support guide is the canonical reference. This post is the case for using it.