[LCOW Builder] fix CPUGroup, VPMEM controller and StorageQoS parsing

[rawahars]

Summary

• The CPUGroup was being set unconditionally while it needs to be set only if the value is non-empty.

• StorageQoS was always set unconditionally but should only be set if IopsMaximum and BandwidthMaximum are both non-zero.

• If VPMEM count is greater than 0, we must initialize the controller.

• Unit tests are augmented to account for these changes.

[shreyanshjain7174]

nit

[shreyanshjain7174]

Verified this PR against our parity tests (test/parity/vm/). Pulled the fixes into the parity/lcow-permutations branch and ran all 24 tests as admin.

Results: 23/24 PASS (up from 21/24 before this fix)

Gap test	Before fix	After fix
gap: no CPUGroupID	FAIL	PASS ✅
gap: no StorageQoS	FAIL	PASS ✅
gap: initrd boot (VPMem)	FAIL	FAIL (partial fix — see below)

The VPMem controller fix works correctly — v2 now allocates the controller even for initrd boot. The remaining initrd failure is a kernel cmdline leading space difference in the legacy builder:

• Legacy: " initcall_blacklist=..." (leading space from create_lcow.go string concatenation)
• V2: "initcall_blacklist=..." (no leading space)

This is a harmless legacy quirk, not a v2 issue. HCS trims whitespace from kernel args.

Otherwise LGTM.

[shreyanshjain7174]

Adding the exact diff for the remaining initrd kernel cmdline failure:

Test case: gap: initrd boot (VPMem nil vs empty controller) with annotations PreferredRootFSType=initrd, KernelDirectBoot=true

Legacy KernelCmdLine:

" initcall_blacklist=virtio_vsock_init 8250_core.nr_uarts=0 panic=-1 quiet pci=off nr_cpus=2 brd.rd_nr=0 pmtmr=0 -- -e 1 /bin/vsockexec -e 109 /bin/gcs -v4 -log-format json -loglevel info"

V2 KernelCmdLine:

"initcall_blacklist=virtio_vsock_init 8250_core.nr_uarts=0 panic=-1 quiet pci=off nr_cpus=2 brd.rd_nr=0 pmtmr=0 -- -e 1 /bin/vsockexec -e 109 /bin/gcs -v4 -log-format json -loglevel info"

The only difference is the leading space in the legacy output. This happens in create_lcow.go because for initrd+KernelDirect boot, kernelArgs starts as an empty string (no root= prefix, no initrd=/ prefix), and then " initcall_blacklist=..." is appended with kernelArgs += " initcall_blacklist=..." — producing a leading space.

The v2 builder in kernel_args.go constructs the args without this leading space.

VPMem controller, StorageQoS, CpuGroup, and all other fields match perfectly after this fix PR.

[shreyanshjain7174]

LGTM!

[shreyanshjain7174]

Adding the exact diff for the remaining initrd kernel cmdline failure:

Test case: gap: initrd boot (VPMem nil vs empty controller) with annotations PreferredRootFSType=initrd, KernelDirectBoot=true

Legacy KernelCmdLine:

" initcall_blacklist=virtio_vsock_init 8250_core.nr_uarts=0 panic=-1 quiet pci=off nr_cpus=2 brd.rd_nr=0 pmtmr=0 -- -e 1 /bin/vsockexec -e 109 /bin/gcs -v4 -log-format json -loglevel info"

V2 KernelCmdLine:

"initcall_blacklist=virtio_vsock_init 8250_core.nr_uarts=0 panic=-1 quiet pci=off nr_cpus=2 brd.rd_nr=0 pmtmr=0 -- -e 1 /bin/vsockexec -e 109 /bin/gcs -v4 -log-format json -loglevel info"

The only difference is the leading space in the legacy output. This happens in create_lcow.go because for initrd+KernelDirect boot, kernelArgs starts as an empty string (no root= prefix, no initrd=/ prefix), and then " initcall_blacklist=..." is appended with kernelArgs += " initcall_blacklist=..." — producing a leading space.

The v2 builder in kernel_args.go constructs the args without this leading space.

VPMem controller, StorageQoS, CpuGroup, and all other fields match perfectly after this fix PR.

As this is an improvement in the newer v2 shim we are ignoring it in testing.

[helsaawy]

nit, but lgtm overall