REQ-NFR-025 (#410) needs a cold-start figure from a machine that has never had OpenVSA installed,
and today that means Tony at a keyboard. It does not have to: VMware Workstation is on TG-INTEL and
every step is scriptable. This records what was established while trying, so the next attempt starts
from facts rather than from the same three dead ends.
What is already true
- VMware Workstation is installed on TG-INTEL with
vmrun at
C:\Program Files\VMware\VMware Workstation\vmrun.exe. It is not on PATH.
OpenVSA.vmx exists at C:\Users\Tony\Documents\Virtual Machines\OpenVSA\, guestOS = "windows11-64", and Tony reports a snapshot named "Updated" that is a clean OS.- The cold-start package is built and waiting:
artifacts/coldstart/OpenVSA-ColdStart-0.1.2.zip,
keyed, verified, carrying the repaired harness.
🔴 vmrun does not read Windows Credential Manager
Tested directly. The credential was added and is present:
Target: LegacyGeneric:target=VMware Encrypted VM: C:\Users\Tony\Documents\Virtual Machines\OpenVSA\OpenVSA.vmx
and vmrun -T ws listSnapshots still returns:
Error: Cannot open VM: ...\OpenVSA\OpenVSA.vmx, A password is required for this operation
The Workstation GUI reads the store and vmrun does not. That is the single fact that blocks
automation today, and it is worth writing down because the store being populated makes it look
solved from the GUI side.
The VM is genuinely encrypted — vmx.encryptionType, encryption.keySafe and encryption.data are
all in the .vmx.
The flags that would work
vmrun [-T ws] -vp <encryption password> -gu <guest user> -gp <guest password> <command> <vmx> ...
Two credentials, not one: -vp opens the encrypted .vmx at all, and -gu/-gp are a Windows
account inside the guest, needed by copyFileFromHostToGuest and runProgramInGuest.
Guest automation additionally needs VMware Tools running in the snapshot. Unverified for
"Updated" — check before relying on it, because without Tools the guest commands fail regardless of
credentials.
Handling the credentials without putting them in a transcript
Agreed approach, not yet used: a file on TG-INTEL holding three lines — encryption password, guest
user, guest password. It is read into PowerShell variables and only the variable names appear in
any command, so the values never enter the conversation log, which persists and syncs to other
devices. The file is deleted afterwards.
The alternative that needs no password at all
C:\Users\Tony\Documents\Virtual Machines\OS Images\Windows 10 and later x64\ is unencrypted,
windows9-64, and has one snapshot, "Snapshot for BT Test". REQ-NFR-025 asks for a 64-bit Windows
10 or 11 machine that has never had OpenVSA — it does not care which VM. vmrun can drive it
today.
Not used, because reverting a snapshot discards state and "BT Test" says that VM is somebody's. Take
a fresh snapshot first, run, then revert to it — reversible, but still Tony's call.
🔴 Do not run it against a busy machine
The cold-start figure and the bench suites are both timing measurements, and CPU and disk
contention corrupts the first. A VM cold-start run must not overlap a OpenVSA.Verify run or a
solution-wide build. This was nearly done twice today.
Related: #410, #441.
REQ-NFR-025(#410) needs a cold-start figure from a machine that has never had OpenVSA installed,and today that means Tony at a keyboard. It does not have to: VMware Workstation is on TG-INTEL and
every step is scriptable. This records what was established while trying, so the next attempt starts
from facts rather than from the same three dead ends.
What is already true
vmrunatC:\Program Files\VMware\VMware Workstation\vmrun.exe. It is not onPATH.OpenVSA.vmxexists atC:\Users\Tony\Documents\Virtual Machines\OpenVSA\,guestOS = "windows11-64", and Tony reports a snapshot named "Updated" that is a clean OS.artifacts/coldstart/OpenVSA-ColdStart-0.1.2.zip,keyed, verified, carrying the repaired harness.
🔴
vmrundoes not read Windows Credential ManagerTested directly. The credential was added and is present:
and
vmrun -T ws listSnapshotsstill returns:The Workstation GUI reads the store and
vmrundoes not. That is the single fact that blocksautomation today, and it is worth writing down because the store being populated makes it look
solved from the GUI side.
The VM is genuinely encrypted —
vmx.encryptionType,encryption.keySafeandencryption.dataareall in the
.vmx.The flags that would work
Two credentials, not one:
-vpopens the encrypted.vmxat all, and-gu/-gpare a Windowsaccount inside the guest, needed by
copyFileFromHostToGuestandrunProgramInGuest.Guest automation additionally needs VMware Tools running in the snapshot. Unverified for
"Updated" — check before relying on it, because without Tools the guest commands fail regardless of
credentials.
Handling the credentials without putting them in a transcript
Agreed approach, not yet used: a file on TG-INTEL holding three lines — encryption password, guest
user, guest password. It is read into PowerShell variables and only the variable names appear in
any command, so the values never enter the conversation log, which persists and syncs to other
devices. The file is deleted afterwards.
The alternative that needs no password at all
C:\Users\Tony\Documents\Virtual Machines\OS Images\Windows 10 and later x64\is unencrypted,windows9-64, and has one snapshot, "Snapshot for BT Test".REQ-NFR-025asks for a 64-bit Windows10 or 11 machine that has never had OpenVSA — it does not care which VM.
vmruncan drive ittoday.
Not used, because reverting a snapshot discards state and "BT Test" says that VM is somebody's. Take
a fresh snapshot first, run, then revert to it — reversible, but still Tony's call.
🔴 Do not run it against a busy machine
The cold-start figure and the bench suites are both timing measurements, and CPU and disk
contention corrupts the first. A VM cold-start run must not overlap a
OpenVSA.Verifyrun or asolution-wide build. This was nearly done twice today.
Related: #410, #441.