Conversation
Reverse-engineered and implemented against a live standalone ESXi 8.0.3 host (no vCenter), closing most of the gap versus the proprietary VDDK: - Direct ESXi (no vCenter) connectivity: nfc_service() previously hardcoded the NfcService moref as "nfcService" (vCenter's name), which fails on bare ESXi (moref is "ha-nfc-service" there). Now resolved dynamically via RetrieveInternalContent, same as VDDK itself does. Also fixes connect_authd() for tickets that omit `host` (implicit on a direct-ESXi ticket). - VixDiskLib_GetInfo: capacity and physical geometry come free from the OPEN_FILE reply (offsets already in the wire frame). biosGeo, adapterType, and uuid are fetched via DDB_GET, matching real VDDK's behavior and cost exactly. - DDB_GET (VMDK descriptor lookups): generic key/value NFC message, values are ASCII text on the wire (not binary), matching how a VMDK descriptor's DDB section is stored. - VixDiskLib_QueryAllocatedBlocks: allocated-block bitmap query. Verified against a live disk to exactly match native VDDK's output, including two non-obvious wire details: a field-order swap that's invisible in a zero-offset capture, and 4-byte bitmap padding that only shows up for small chunk counts. - Changed Block Tracking: turned out to need no NFC work at all -- VirtualMachine.QueryChangedDiskAreas is public VIM API. Added thin wrappers (enable_change_tracking / disk_change_id / query_changed_disk_areas) and documented real-world characteristics (extent granularity, wildcard changeId semantics) from live testing. - Investigated NFC_DELTA_DISK: found it's an optional VMFS-only VDDK client optimization (per `strings` on libvixDiskLib.so), not a correctness requirement -- reading, writing, and querying allocated blocks on an actual snapshot delta file already work with the existing NFC_DISK-only implementation. Documented a real gotcha found along the way: querying allocated blocks on the same still-open handle a write just went through can see stale data. Adds unit tests (bitmap decode/merge, DDB_GET wire format, CBT dataclass conversion, validation errors) and integration tests (GetInfo, QueryAllocatedBlocks, CBT full cycle, delta-disk read/write/ query) validated against a live ESXi 8.0.3 lab. Full protocol details and the reverse-engineering process are in docs/nfc_auth.md, docs/nfc_open.md, docs/nfc_read.md, docs/cbt.md, and docs/reverse_engineering_procedure.md.
Investigated the "encrypted disks" backlog item by building a vCenter + Native Key Provider lab from the existing bare-ESXi host, encrypting a test VM/disk, and capturing native VDDK opening it with the SSL hook. Found no extra key-provisioning calls in the wire capture, and proved via openvixdisklib itself (zero encryption-specific code) that a known byte pattern round-trips correctly through normal NFC read/write while the bytes on disk are genuine ciphertext at rest. ESXi's storage stack handles VM disk encryption entirely below the NFC layer whenever the serving host already holds the key -- the only case a single-host lab can exercise, and, per the VDDK binary's own strings, likely the only case that needs no extra provisioning step at all. Same treatment as the earlier NFC_DELTA_DISK finding: documented as an "investigated, not needed" note rather than a new feature, plus a regression test against the lab's persistent encrypted VM (skips if not configured). Also wrote up the lab-building procedure itself (VCSA deploy, cluster + Native Key Provider setup, encrypting a VM) since none of it was straightforward and all of it is reusable.
doccaz
marked this pull request as ready for review
September 19, 2026 23:55
4 tasks
…tion The one case the original encryption investigation couldn't test -- a host that doesn't already have an encrypted disk's key cached -- became testable once a second ESXi host existed (built for the host-switch investigation). Cold-relocated the encrypted test VM (compute and disk together) to that host, then read its disk from there: it just worked, decrypting correctly, via both openvixdisklib and cross-checked native VDDK. vCenter pushes the key to the destination host automatically as part of any relocation of an encrypted VM. There is nothing for OpenVixDiskLib to implement -- the "host doesn't have the key yet" case can't arise for a client reading through an already-completed migration, since vCenter resolves it before the migration finishes.
doccaz
marked this pull request as draft
September 20, 2026 14:25
doccaz
marked this pull request as ready for review
September 20, 2026 14:54
| "vcenter_host", | ||
| "vcenter_username", | ||
| "vcenter_password", | ||
| "encrypted_vm_moref", |
Member
There was a problem hiding this comment.
It would be nice if we could spin up an encrypted vm on the fly instead of requiring a pre-existing one.
Member
|
This will have to be rebased once the other PRs merge. |
Reuse the standard vCenter keys from .test_config.yaml in the encryption test, document the extra keys it needs, note that the san and hotadd transports were not covered, and soften the lab wording.
Author
|
Thanks for the review. I pushed changes for these:
|
Member
|
Thanks for updating the PR. No worries about the encrypted VM test, I'd say it's ok for now to use an existing vm. |
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
Investigated the "encrypted disks" backlog item by building a vCenter + Native Key Provider lab from the existing bare-ESXi host, encrypting a test VM/disk, and capturing native VDDK opening it with the SSL hook (
docs/ssl_hook.md).Found no extra key-provisioning calls in the wire capture, and proved via
openvixdisklibitself (zero encryption-specific code) that a known byte pattern round-trips correctly through normal NFC read/write while the bytes on disk are genuine ciphertext at rest. ESXi's storage stack handles VM disk encryption entirely below the NFC layer whenever the serving host already holds the key.Update: the one case this originally couldn't test — a host that doesn't already have the key cached — became testable once a second ESXi host existed (built for the related host-switch investigation, PR #9). Cold-relocated the encrypted VM (compute + disk) to that host and read its disk from there: it just worked, via both
openvixdiskliband cross-checked native VDDK. vCenter pushes the key to the destination host automatically as part of any relocation — nothing for this project to implement. That was the last open question; encryption support needs no code at all, full stop.Same treatment as the earlier
NFC_DELTA_DISKfinding (PR #5): documented as an "investigated, not needed" note rather than a new feature, plus a regression test against the lab's persistent encrypted VM (skips if not configured). Also wrote up the lab-building procedure itself (VCSA deploy, cluster + Native Key Provider setup, encrypting a VM) since none of it was straightforward and all of it is reusable.docs/encryption.md— the investigation and evidence, including the cross-host resolutiondocs/encryption_lab_setup.md— the lab methodology, gotcha by gotchadocs/reverse_engineering_procedure.md— new "investigated, not needed" note, same pattern asNFC_DELTA_DISKtests/integration/test_encryption.py— regression testTest plan
openvixdisklib— matches, and the raw on-disk bytes are confirmed ciphertexttests/integration/test_encryption.pypassing against the live labNote on PR sequencing
Stacked on top of the unmerged direct-ESXi/GetInfo/QueryAllocatedBlocks/CBT work (PRs #3–#6) — this branch's history includes their combined commit, so the diff shown here will shrink to just the two new commits (
9e7670c,e762597) once those merge. No code changes at all in this PR, only docs + one new test file, so there's no actual dependency to worry about when reviewing.