docs(posts): correct the V2V and Cirrus claims in the Windows post - #39
Merged
Merged
Conversation
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.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe 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. ChangesWindows on XCP-ng guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
vgakey 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 setsvga: stdwithvideoram: 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 thevgaandvideoramdefaults 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
hugonorasciidoctoris executable on the machine this was written on. Thelink:URL[text]macros and backtick code spans follow forms already used elsewhere in the same file, but someone should confirm the page builds.Summary by CodeRabbit