docs(virtualization): guide for building a Windows golden image with Packer - #665
docs(virtualization): guide for building a Windows golden image with Packer#665scooby87 wants to merge 5 commits into
Conversation
…Packer Add a Virtualization guide covering how to build a customized Windows Server golden image with Packer against the KubeVirt builder, harden it, capture the disk, and register it in Cozystack — either as a cloneable vm-disk (copy-clone) or, for a bare URL-reachable base, via vm-default-images. Complements the manual "Running Windows VMs" guide and cross-links Cloneable Virtual Machines and Golden Images. Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Expand the Windows golden-image guide with the actual Packer usage: installing the community KubeVirt builder plugin, a complete windows.pkr.hcl (source + build with WinRM communicator and provisioners), the variables file, and the role of autounattend.xml in enabling WinRM for the build. Previously the guide only showed `packer build` without the configuration. Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
…ric) Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
Andrei Kvapil (kvaps)
left a comment
Andrei Kvapil (kvaps)
left a comment
There was a problem hiding this comment.
Useful addition — the gap is real: windows.md covers installing by hand and vm-image.md covers URL-cached images, and neither describes baking a customized Windows disk once and cloning from it. The framing at the top makes that distinction clear, and I am glad to see the security guidance in a public guide rather than left implicit: harden.ps1 as the mandatory final provisioner, the "never bake credentials or licences" alert, and the evaluation-media caveat (sysprep/spopk.dll, shared SID when generalize is skipped, purchased licence required for production).
I checked the technical claims against the charts and the site. u1.large and windows.2k22.virtio both exist, and all three {{% ref %}} targets (windows.md, vm-image.md, cloneable-vms.md) resolve. Three things need fixing before this lands, though — the first two are things a reader hits immediately.
cloneType: copy is not a knob Cozystack exposes
Use
cloneType: copy(not snapshot) so each VM gets an independent disk.
There is no cloneType field in the vm-disk application: the only clone-related value is source.disk.name ("Name of the vm-disk to clone"), and cloneable-vms.md does not mention it either. cloneType is the CDI annotation cdi.kubevirt.io/cloneType on the DataVolume, which a VMDisk author cannot set through the app's values today.
The concern behind the sentence is legitimate and worth keeping — a CSI smart-clone can report Succeeded while leaving the target PVC empty on some storage backends, which is a nasty silent failure. So rather than dropping it, I would state it accurately: describe that cloning goes through CDI, that the clone strategy is chosen by the storage backend, and what to check (or how to force a host-assisted copy) — without implying there is a cloneType value to set in the manifest.
The VMInstance example produces a mis-tuned Windows VM
spec:
disks:
- name: windowsinstanceProfile defaults to ubuntu and instanceType to u1.medium in the chart, so this example boots Windows with the Ubuntu preference: sata and e1000e instead of virtio, none of the hyperv enlightenments, no TPM or SecureBoot — and, because the Windows node affinity keys off the windows prefix in the profile name, it also opts the VM out of the dedicated-Windows-node scheduling. It contradicts the Packer source above it, which correctly sets preference = "windows.2k22.virtio".
Please set both explicitly in the example, e.g. instanceProfile: windows.2k22.virtio alongside a suitable instanceType.
Step one cannot be completed as written
The plugin section says, correctly, that the KubeVirt builder is a community plugin, not published by HashiCorp, and that packer init cannot resolve it. But the template then keeps source = "github.com/hashicorp/kubevirt" with the advice to "keep the source matching your local install path", and the guide never says where to obtain the plugin — no repository, no build instructions.
As it stands a reader cannot get past the first step, and the hashicorp/ namespace attributes a community plugin to HashiCorp. Either link the actual upstream repository (with the revision it was built against, plus go build and where to drop the binary), or use an unmistakable placeholder such as github.com/<org>/kubevirt and say explicitly that the reader must substitute the plugin they installed.
Smaller
kubectl apply -f win2022-iso-dv.yaml appears in both Prerequisites and Run the build — harmless, but one of the two can go.
…ofile - Plugin: the KubeVirt builder is the published github.com/hashicorp/kubevirt plugin, installed with `packer init` — drop the incorrect "community / install manually / cannot packer init" wording and the misattribution. - Register: describe the CDI-based clone flow (capture a vm-image DataVolume in cozy-public, clone per VM via source.image.name, verify it actually has data) instead of a non-existent cloneType field. - VMInstance example: set instanceProfile: windows.2k22.virtio and instanceType explicitly, so the VM does not fall back to the ubuntu profile. - Fix invalid HCL in variables (comma-separated attributes) and remove the duplicated ISO DataVolume apply. Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
|
Thanks for the thorough review — all four addressed in the latest push. 1. `cloneType: copy`. Removed — you are right, it is not a 2. Mis-tuned 3. The plugin step. You were right that the old wording was both wrong and dead-ended — and it turns out the premise was stale: the builder is the published 4. Smaller. Removed the duplicated Ready for another look. |
…empty smart-clones Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
|
Follow-up on point 1: added the concrete remedy you suggested — if a smart-clone comes up empty, set |
2 participants
What
Adds a Virtualization guide, Building a Windows Golden Image with Packer (
content/en/docs/next/virtualization/windows-golden-image.md).It covers building a customized Windows Server image (Windows + pre-installed software + autologon + RDP) with Packer against the KubeVirt builder, hardening it before capture, and registering the captured disk in Cozystack — either as a cloneable
vm-disk(copy-clone) or, for a bare URL-reachable base, viavm-default-images.Why
Cozystack already documents booting/installing a Windows VM by hand ([Running Windows VMs]) and caching URL-reachable images ([Golden Images]). What was missing is the automated path: baking a customized Windows disk once and cloning many VMs from it. This guide fills that gap.
Notes
next/per the versioning model; can be copied to current stable versions if desired.windows.md,cloneable-vms.mdandvm-image.md(all{{% ref %}}targets exist in the same directory).win2022-iso-dv.yaml,autounattend.xml,hardenetc. are described as standard Packer artifacts.{{% alert %}}blocks kept with blank lines inside so they render and pass the hardwrap check.