docs(virtualization): guide for building a Windows golden image with Packer - #666
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>
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>
…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>
…empty smart-clones 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 |
…lume name Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
d168452 to
b63b492
Compare
Andrei Kvapil (kvaps)
left a comment
Andrei Kvapil (kvaps)
left a comment
There was a problem hiding this comment.
Re-reviewed after the rework — the three points from #665 are properly addressed, and one of them turned out to be my mistake rather than yours.
The plugin. I pushed back originally on the claim that this is a community plugin packer init cannot resolve. You were right to change it: hashicorp/packer-plugin-kubevirt is genuinely published — releases.hashicorp.com/packer-plugin-kubevirt/ serves 0.9.0 and 0.8.0, and it is listed in the integrations registry — so packer init does install it and the github.com/hashicorp/kubevirt source string is correct. (Its GitHub releases carry no assets, which is what misled the earlier note I was working from; official plugins ship through the HashiCorp release channel instead.) Linking the upstream Windows kubevirt-iso example is a good addition.
The clone flow. The new wording is accurate: the strategy is chosen by CDI and the storage backend rather than set in the manifest, with the cdi.kubevirt.io/cloneType: copy annotation given as the remedy when a smart-clone reports Succeeded over an empty target. Describing it as an annotation on the DataVolume rather than a vm-disk value is exactly right.
The VM example now sets instanceProfile: windows.2k22.virtio and instanceType: u1.large, with a sentence explaining why leaving them out lands you on the ubuntu profile. Both values exist in the shipped instancetypes/preferences.
One fix pushed on top: the golden-image DataVolume was named vm-image-<name>, which is the pre-rename prefix. vm-disk resolves source.image.name to vm-default-images-<name> in cozy-public, platform migration 38 renames older vm-image-* volumes to that form, and the sibling Golden Images page documents the same — so the old name would point readers at a volume vm-disk never looks up.
Also checked: all three {{% ref %}} targets resolve, and i18n-lint is green. Merging.
cc3859e to
b63b492
Compare
The vm-disk chart resolves source.image.name to vm-default-images-<name> in cozy-public, and platform migration 38 renames older vm-image-* DataVolumes to that prefix. The sibling Golden Images page documents the same name. Pointing readers at vm-image-<name> would name a DataVolume vm-disk never looks up. Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Andrei Kvapil (kvaps)
left a comment
Andrei Kvapil (kvaps)
left a comment
There was a problem hiding this comment.
Re-approving after the prefix fix (the earlier approval was dismissed by the push). Content unchanged from the review above: vm-default-images-<name> now matches what vm-disk resolves, DCO and i18n-lint are green.
2 participants
This adds a guide for building a Windows golden image with Packer on KubeVirt, superseding the closed #665 (its fork head branch was deleted, so it could not be reopened — this is a fresh PR from a branch pushed directly to the upstream repo).
It already addresses the three points from the #665 review: (1) it drops the non-existent
cloneTypevm-disk field and instead describes the CDI clone flow, noting that the clone strategy is chosen by CDI and the storage backend rather than set in the manifest, with thecdi.kubevirt.io/cloneType: copyannotation offered as a remedy when a smart-clone reportsSucceededbut leaves the target empty; (2) theVMInstanceexample now setsinstanceProfile: windows.2k22.virtioandinstanceType: u1.largeexplicitly; (3) the plugin is the publishedgithub.com/hashicorp/kubevirtbuilder, declared inrequired_pluginsand installed withpacker initrather than any manual/community install.The guide is fully generic with no client-specific content.