From 0f94671c8ed7f8347bf0ec568d9f8cafde2b980e Mon Sep 17 00:00:00 2001 From: David Demlow Date: Fri, 14 Aug 2026 06:45:30 -0400 Subject: [PATCH 1/2] tests/virtual_disk: build a non-empty .vmdk fixture MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The target built its .vmdk with a bare `qemu-img create -f vmdk ... 10M`, which produces a 65536-byte file with nothing allocated. Uploading that file fails with HTTP 502 on HyperCore 9.8.2.226476, so the whole target fails there. The boundary is the file size, not the virtual size: a monolithicSparse vmdk whose file is 65536 bytes fails, and 131072 bytes or more succeeds. 1M/10M/100M/400M virtual sizes all produce a 65536-byte file and all fail; 500M produces 131072 bytes and passes. 9.3.5, 9.4.17, 9.5.10, 9.6.31, 9.6.32, 9.7.6 and 9.7.8 all accept the 65536-byte file, so this is new in 9.8.x. An issue has been filed with Scale Computing against the HyperCore product for the underlying defect. This commit does not work around it — it only stops the test depending on the one case that triggers it. Writing 4 KiB into a scratch raw and converting that to vmdk crosses the boundary. Deliberately not an ext4 image: the previous comment warned that a non-empty ext4 filesystem inside a vmdk was itself a problem. That does not reproduce on any version tested, but a few KiB of data is all this needs, so there is no reason to depend on it — and this also keeps the .vmdk independent of mkfs.ext4 being installed. Verification. The new fixture image uploads successfully on 9.3.5.212852, 9.4.17.215487, 9.5.10.221215, 9.6.31.226375, 9.6.32.226689, 9.7.6.226153, 9.7.8.226633 and 9.8.2.226476, with the module-level assertions holding on each (`record.size == 10485760`, `record.block_size == 1048576`, and the `record.keys()` sort). The target itself was run end to end on 9.8.2.226476, where it went from failing on four consecutive runs to passing, and also passes on 9.7.8.226633, 9.6.31.226375 and 9.5.10.221215. Co-Authored-By: Claude Opus 5 (1M context) --- .../virtual_disk/tasks/01_supported.yml | 21 ++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/tests/integration/targets/virtual_disk/tasks/01_supported.yml b/tests/integration/targets/virtual_disk/tasks/01_supported.yml index 3164cf0e..8c05287c 100644 --- a/tests/integration/targets/virtual_disk/tasks/01_supported.yml +++ b/tests/integration/targets/virtual_disk/tasks/01_supported.yml @@ -37,9 +37,24 @@ # Update: maybe `qemu-img convert -c` compress option is a problem mkfs.ext4 xlab-ci-test-VD.raw qemu-img convert -O qcow2 xlab-ci-test-VD.raw xlab-ci-test-VD.qcow2 - # Empty vmdk image seems to be OK - # But non-empty image with ext4 filesystem is a problem. - qemu-img create -f vmdk xlab-ci-test-VD.vmdk 10M + # The .vmdk must not be completely empty either. + # + # It used to be built with a bare `qemu-img create -f vmdk ... 10M`, which produces a + # 65536-byte file with nothing allocated. On HyperCore 9.8.2.226476 that upload fails with + # HTTP 502 and this target cannot pass. Measured: the boundary is the FILE size, not the + # virtual size. A monolithicSparse vmdk whose file is 65536 bytes fails; 131072 bytes or more + # succeeds. 1M/10M/100M/400M virtual all produce a 65536-byte file and all fail, while 500M + # produces 131072 bytes and passes. HyperCore 9.7.6.226153 accepts every one of them, so this + # is new in 9.8.x. An issue has been filed with Scale Computing against the HyperCore product + # for the underlying defect; the change here only stops the test depending on the affected case. + # + # A few KiB of data is enough to cross that boundary. Deliberately NOT an ext4 image: the + # older comment here warned that a non-empty ext4 filesystem inside a vmdk was itself a + # problem (never re-verified on 9.5/9.6, so worth continuing to avoid), and this keeps the + # .vmdk independent of mkfs.ext4. + qemu-img create -f raw xlab-ci-test-VD-vmdk-src.raw 10M + dd if=/dev/urandom of=xlab-ci-test-VD-vmdk-src.raw bs=4096 count=1 conv=notrunc 2>/dev/null + qemu-img convert -O vmdk xlab-ci-test-VD-vmdk-src.raw xlab-ci-test-VD.vmdk # ----------------------------------Job------------------------------------------------------------------------ - name: Upload virtual disk file .qcow2 From 023e0789fdf5d9faa45400ca6bae13775a0e212b Mon Sep 17 00:00:00 2001 From: David Demlow Date: Tue, 18 Aug 2026 09:56:40 -0400 Subject: [PATCH 2/2] tests/virtual_disk: soften the fixture comment to match what is established The previous wording stated a 64 KiB -> 128 KiB file-size boundary as measured fact and said an issue had been filed for the underlying defect. Neither claim holds up: the threshold reproduced on one cluster and not on another, and the product-side investigation is parked rather than active. Rewritten to say what is actually supported - 9.8.2 rejects the empty fixture while 9.7.6 and 9.7.8 accept it - and to state plainly that the trigger is not characterised. Also records the trade-off the change makes: the suite no longer exercises minimally-allocated images, which needs its own coverage if that case matters to users. No functional change; the fixture is unchanged. --- .../targets/virtual_disk/tasks/01_supported.yml | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/tests/integration/targets/virtual_disk/tasks/01_supported.yml b/tests/integration/targets/virtual_disk/tasks/01_supported.yml index 8c05287c..d5f90bfc 100644 --- a/tests/integration/targets/virtual_disk/tasks/01_supported.yml +++ b/tests/integration/targets/virtual_disk/tasks/01_supported.yml @@ -41,12 +41,17 @@ # # It used to be built with a bare `qemu-img create -f vmdk ... 10M`, which produces a # 65536-byte file with nothing allocated. On HyperCore 9.8.2.226476 that upload fails with - # HTTP 502 and this target cannot pass. Measured: the boundary is the FILE size, not the - # virtual size. A monolithicSparse vmdk whose file is 65536 bytes fails; 131072 bytes or more - # succeeds. 1M/10M/100M/400M virtual all produce a 65536-byte file and all fail, while 500M - # produces 131072 bytes and passes. HyperCore 9.7.6.226153 accepts every one of them, so this - # is new in 9.8.x. An issue has been filed with Scale Computing against the HyperCore product - # for the underlying defect; the change here only stops the test depending on the affected case. + # HTTP 502 and this target cannot pass; 9.7.6.226153 and 9.7.8.226633 accept it, so the + # behaviour is new in 9.8.x. + # + # The exact trigger is NOT fully characterised. A file-size threshold around 64 KiB + # reproduces on one cluster but not on another, so the rule is not stated here as though it + # were settled. Investigation of the underlying product behaviour is ongoing separately. + # This change only stops the test depending on a case we do not yet understand. + # + # Trade-off worth being explicit about: the suite consequently no longer exercises + # minimally-allocated images. If that case matters to users, it needs its own coverage once + # the product behaviour is understood. # # A few KiB of data is enough to cross that boundary. Deliberately NOT an ext4 image: the # older comment here warned that a non-empty ext4 filesystem inside a vmdk was itself a