Hyper-V guest OS - PR review

PR #295 by Dr4inder · Follows #199 · Verdict: merge + fix

Hyper-V VMs now report their guest operating system, so the Guest OS column on Assets → Servers is filled for them as it is for the other sources. The collector scripts/Invoke-HyperVInventory.ps1 (now version 1.0.1) reads each host's integration-service data once, takes the guest's OSName, and sends it as each VM's os_name. The ingest and the REST API already accepted os_name; only the collector changed. User page: Hyper-V and Failover Clusters. Internals: Hyper-V discovery - Developer Guide.

How it works

• One read per host, not one remote call per VM: Get-CimInstance -Namespace root/virtualization/v2 -ClassName Msvm_KvpExchangeComponent.
• Each component's GuestIntrinsicExchangeItems is a list of small XML documents written by the guest. The one whose Name is OSName gives the Data value.
• Matched by VM Id. A component's SystemName is the VM's Id (the Msvm_ComputerSystem Name), not a display name. It is lower-cased and looked up against the VM's Id, the same key FreeITSM already uses to recognise a VM.
• No fallback. A VM with no readable guest data gets os_name null. The host's own OS is never used in its place.

What was checked

Question	How	Result
The PR said the tests were not run	Ran tests/hyperv-collector.php on the test install, against the mock driver	20/20, including the new cases
Can it put one VM's OS on another?	Read the matching; the test	Matched only by VM Id, case-insensitive. The test puts the matching component second, not first, so a "take the first one" bug would fail
Non-Windows guests	The test	A Linux guest's OSName comes through
Guest-written XML	Read; the test	Parsed with DtdProcessing = Prohibit and XmlResolver = $null on both the reader and the document. Malformed, blank and DTD-carrying items are skipped without hiding the VM or other items
What if the read is refused?	Read; the test (denied KVP)	The read is wrapped on its own. The host and its VMs are still inventoried, with os_name null, and the host is not marked unreadable - guest OS is optional data
Does anything leak in a redacted report?	The test's redaction case	No - the guest's FQDN does not appear
Does the server need a change?	Read the ingest	No. os_name was already accepted and stored

What was changed

• #2810 - the Hyper-V set-up help (asset-management ... setup_hosts) now ends: "A VM's guest OS comes from its integration services (the guest's own report to Hyper-V); a VM without them running shows no guest OS." - in all six languages. Without that, an empty Guest OS on one VM looks like a fault.

Merged with git merge --no-ff under the contributor's name (1072c4de3), then the follow-up commit (a2146d9b8).

Worth knowing

• Guest data is written by the guest. Treat it as untrusted text: keep the DTD and resolver settings, and keep each item in its own try, so one bad item cannot stop the rest.
• The KVP read must stay optional. Folding it into the host's required reads would mark a whole host Not confirmed since - and keep stale VMs - just because guest data was refused.
• An empty Guest OS is expected for a VM that is off, has no integration services, or whose host refused the read. It is not a reason to fall back to the host's OS.
• Still not run on a real estate. Like the rest of the collector, this is tested against mocked cmdlets; the warning at the top of the user page still stands.