Conversation
Capacity and physical geometry come free from the OPEN_FILE reply: found via an SSL-hook capture of VixDiskLib_GetInfo that dumped every byte of the reply rather than just the fields an earlier Open-only capture had labeled. Offset 28 (uint64, bytes) matches VixDiskLibInfo.capacity; offsets 40/44/48 match physGeo exactly. No extra NFC round trip needed for these two fields. biosGeo, adapterType, and uuid come from DDB_GET (a generic VMDK descriptor key/value NFC message, implemented here too): request is a 16-byte fixed payload plus the key name as a raw ASCII extra; reply is 16 bytes plus a value extra that is ASCII text on the wire (not binary) -- geometry.cylinders comes back as the literal bytes b"2088", matching how a VMDK descriptor's DDB section stores key/value pairs as plain text. VixDiskLibHandle.get_info() now issues the same 5 DDB_GET round trips real VDDK's VixDiskLib_GetInfo pays on every call, matching its behavior and cost exactly (previously it only returned the two free OPEN_FILE-derived fields). Adds unit tests for the OPEN_FILE reply parsing, the DDB_GET wire format, and query_full_info's field combination/fallback logic -- no lab needed. Validated against a live standalone ESXi 8.0.3 host: output matches native VDDK's own GetInfo on the same disk exactly (adapterType=3 <-> "lsilogic", same uuid string, same zeroed biosGeo). Full protocol details in docs/nfc_open.md.
This was referenced Sep 19, 2026
doccaz
marked this pull request as ready for review
September 19, 2026 18:18
petrutlucian94
approved these changes
Sep 23, 2026
We're currently hitting the following mypy error: ``` tests/unit/test_nfc_open.py:107: error: Argument "sock" to "NfcDisk" has incompatible type "_FakeSocket"; expected "socket" [arg-type] ``` `typing.Protocol` is a convenient way of addressing this. https://typing.python.org/en/latest/spec/protocol.html
petrutlucian94
added a commit
to doccaz/OpenVixDiskLib
that referenced
this pull request
Sep 23, 2026
We'll use the same typing.Protocol approach as cloudbase#4, minimizing merge conflicts.
petrutlucian94
added a commit
to doccaz/OpenVixDiskLib
that referenced
this pull request
Sep 24, 2026
We'll use the same typing.Protocol approach as cloudbase#4, minimizing merge conflicts.
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
2 participants
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
VixDiskLib_GetInfo: capacity and physical geometry come free from theOPEN_FILEreply — found by dumping every byte of that reply during aGetInfocapture rather than just the fields an earlier Open-only capture had labeled. Offset 28 (uint64, bytes) matchesVixDiskLibInfo.capacity; offsets 40/44/48 matchphysGeoexactly. No extra NFC round trip needed for these two fields.DDB_GET: a generic VMDK descriptor key/value NFC message, implemented as its own thing too. Request is a 16-byte fixed payload plus the key name as a raw ASCII extra; reply is 16 bytes plus a value extra that's ASCII text on the wire (not binary) —geometry.cylinderscomes back as the literal bytesb"2088", matching how a VMDK descriptor's DDB section stores key/value pairs as plain text.VixDiskLibHandle.get_info()now issues the same 5DDB_GETround trips (biosGeo,adapterType,uuid) real VDDK'sVixDiskLib_GetInfopays on every call — matching its behavior and cost exactly.Full protocol details are in
docs/nfc_open.md.Test plan
OPEN_FILEreply parsing,DDB_GETwire format,query_full_infofield combination/fallback logic) — no lab needed,pytest tests/unitGetInfoon the same disk exactly (adapterType=3↔"lsilogic", sameuuidstring, same zeroedbiosGeo)test_get_info) plus the existing suite passNote on PR sequencing
Second of 4 focused PRs splitting up the original combined PR #2 (now closed). Independent of #3 (direct-ESXi fix), #? (
QueryAllocatedBlocks/NFC_DELTA_DISK), and #? (CBT) — can merge in any order. (This PR was validated live by temporarily stacking it on the direct-ESXi fix locally, since our test lab happens to be a bare ESXi host that needs that fix to connect at all — a normal vCenter-backed lab wouldn't hit that.)🤖 Generated with Claude Code