Skip to content

docs(posts): correct the V2V and Cirrus claims in the Windows post - #39

Merged
gounthar merged 1 commit into
mainfrom
fix/windows-post-viridian-v2v-and-cirrus
Aug 26, 2026
Merged

docs(posts): correct the V2V and Cirrus claims in the Windows post#39
gounthar merged 1 commit into
mainfrom
fix/windows-post-viridian-v2v-and-cirrus

Conversation

@gounthar

@gounthar gounthar commented Aug 26, 2026

Copy link
Copy Markdown
Owner

Summary

Two claims in the published Windows post were wrong. A lab re-check on 2026-08-25 and 26 caught them, and this corrects both plus two smaller things.

The V2V claim was the one that mattered. The post ended the Viridian section with a flat "or migrated in from VMware", which asserts that guests migrated off VMware land in the one-flag-of-six state. The xcp-ng documentation says Viridian "is also enabled on V2V-migrated and Packer-created VMs if using the correct templates". That qualifier is the whole point, and dropping it inverts the advice for exactly the audience the post is aimed at. No V2V import has ever been measured in this lab, so the sentence now carries the documentation's wording and says plainly that I have not run one.

The Cirrus claim had the right noun and the wrong culprit. The post blamed the slow console on "the emulated Cirrus VGA that XCP-ng gives a fresh HVM guest". Measured on four running guests: every HVM guest whose platform map has no vga key is launched with -device cirrus-vga,vgamem_mb=4, so the noun holds. But a Windows Server 2025 template does exist on XCP-ng 8.3 and sets vga: std with videoram: 8. Cirrus is the cost of the "Other install media" template that this very post recommends — the same root cause as the Viridian gap explained one section later. The paragraph now hands off to that section, and the section names the vga and videoram defaults alongside the Viridian ones. Two apparently unrelated complaints become one thread.

Two smaller corrections came along with it. The PV driver version is now stated as an observation with its moment rather than a standing fact, since 9.2.350 shipped on 2026-08-06 and has not been tested here. And the post grumbles about the slow console twice without ever naming the remedy, so the guest-tools section now points at the XCP-ng Standard VGA Display Driver — scoped strictly to what the docs claim for it, screen resolution on a UEFI VM, and explicitly not to the "Getting ready" wait, which was not measured.

What is deliberately not here

Nothing about the Windows Production PCA 2011 expiry in October. Secure Boot was re-verified as still enforcing with two already-expired 2011 CAs in the chain, but that cert was valid throughout the run, so the measurement says nothing about what happens after it lapses.

Review

Prose-only diff, so the external review gate was skipped rather than run — there is no code here for it to reason about.

Test plan

  • Rendering is not verified: neither hugo nor asciidoctor is executable on the machine this was written on. The link:URL[text] macros and backtick code spans follow forms already used elsewhere in the same file, but someone should confirm the page builds.
  • Read the Cirrus paragraph and the Viridian section together and check the hand-off reads naturally rather than as two bolted-on sentences.

Summary by CodeRabbit

  • Documentation
    • Clarified why Windows virtual machines created with generic installation media may experience slow first-boot sysprep.
    • Documented the improved display and virtualization settings used by Windows templates.
    • Updated V2V migration guidance to recommend reviewing settings based on the selected migration template.
    • Added tested guest-tools driver details and clarified the UEFI requirement for changing display resolution.

Two claims in this post were wrong, and a lab re-check on 2026-08-25/26 is
what caught them. Both are corrected here rather than left standing, because
the post is published and these are the two sentences a VMware refugee would
act on.

V2V. The post ended the Viridian section with a flat "or migrated in from
VMware", asserting that migrated guests land in the one-flag-of-six state.
The xcp-ng docs say Viridian "is also enabled on V2V-migrated and
Packer-created VMs if using the correct templates". The qualifier is the
whole point, and dropping it inverts the advice. No V2V import has ever been
measured here, so the sentence now carries the docs' wording and says so.

Cirrus. The post blamed the slow console on "the emulated Cirrus VGA that
XCP-ng gives a fresh HVM guest". Measured on four running guests: every HVM
guest whose platform map has no vga key is launched with
-device cirrus-vga,vgamem_mb=4. The noun was right, the attribution was not.
A Windows Server 2025 template exists on XCP-ng 8.3 and sets vga: std with
videoram: 8. Cirrus is the cost of the "Other install media" template this
post recommends, which is the same root cause as the Viridian gap explained
one section later. Folding the two together turns two unrelated complaints
into one thread, so the Cirrus paragraph now hands off to the Viridian
section and that section names the vga and videoram defaults too.

Also: the PV driver version is now stated as an observation with its moment
("the current release when I tested") rather than as a standing fact, since
9.2.350 shipped on 2026-08-06 and has not been tested here. And the post
grumbles about the console twice without ever naming the remedy, so the
guest-tools section now points at the XCP-ng Standard VGA Display Driver,
scoped to what the docs actually claim for it: screen resolution on a UEFI
VM, explicitly not the "Getting ready" wait, which was not measured.

Rendering was not verified: neither hugo nor asciidoctor is executable on
this machine. The link macros and code spans follow the forms already used
elsewhere in the file.
@gounthar
gounthar merged commit 9a80d88 into main Aug 26, 2026
5 of 6 checks passed
@coderabbitai

coderabbitai Bot commented Aug 26, 2026

Copy link
Copy Markdown

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 78740d62-632a-43a6-b63c-4f7a6bc78179

📥 Commits

Reviewing files that changed from the base of the PR and between 5ad4c18 and e053aea.

📒 Files selected for processing (1)
  • content/posts/2026-06-29-fastest-windows-on-xcp-ng.adoc

📝 Walkthrough

Walkthrough

The post updates Windows VM guidance for XCP-ng. It documents generic and Windows template VGA settings, narrows V2V migration claims, and records tested PV driver and UEFI display-driver details.

Changes

Windows on XCP-ng guidance

Layer / File(s) Summary
Template display settings
content/posts/2026-06-29-fastest-windows-on-xcp-ng.adoc
The post explains that the generic template uses an emulated Cirrus adapter with 4 MB of video memory. It compares this with Windows templates using vga: std and videoram: 8.
Migration and guest-tools guidance
content/posts/2026-06-29-fastest-windows-on-xcp-ng.adoc
V2V guidance now states that settings depend on the selected migration template. The guest-tools section records PV driver version 9.1.200.0 and the UEFI requirement for the XCP-ng Standard VGA Display Driver.

Estimated code review effort: 1 (Trivial) | ~5 minutes

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/windows-post-viridian-v2v-and-cirrus

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@gounthar
gounthar deleted the fix/windows-post-viridian-v2v-and-cirrus branch August 26, 2026 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant