Deep Review: 20260519-183659-pr-4996

# Note that this script expects that you've already set Windows OS ISO (windows_server_2025.iso) and virtio-win ISO (virtio-win-0.1.285.iso) in ./images/

set -e

# Cleanup
rm -f images/windows.qcow2
rm -f images/win-cidata.iso

# Build win-cidata.iso
mkdir -p tmp/win-cidata
cp autounattend.xml ./tmp/win-cidata/
cp first_logon.ps1 ./tmp/win-cidata/

The README presents run.sh as the way to launch the VM. The first two lines unconditionally delete the installed qcow2 disk image, so the second invocation destroys the Windows install (and any data created in it) and forces a full reinstall. The cleanup block belongs in a separate rebuild mode, not at the top of the launch path.

Fix: gate the deletion behind a flag (--rebuild or similar), or only create the disk when absent.

-# Cleanup
-rm -f images/windows.qcow2
-rm -f images/win-cidata.iso
+# Build the cidata ISO fresh each run (small, regenerable)
+rm -f images/win-cidata.iso
+
+# Create disk only on first run; preserve installed state otherwise
+if [ ! -f images/windows.qcow2 ]; then
+    qemu-img create -f qcow2 ./images/windows.qcow2 40G
+fi

(and remove the unconditional qemu-img create further down).

# Create qcow2
qemu-img create -f qcow2 ./images/windows.qcow2 40G

# Run virtiofsd in background
virtiofsd --shared-dir=./ --socket-path=./virtiofsd.sock --sandbox none &

# Run QEMU
qemu-system-x86_64 \
    -name guest=win2k25,debug-threads=on \
    -machine pc-q35-noble,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on \

Three failure modes compound here. (1) QEMU starts immediately after the &, so if virtiofsd is still binding the socket QEMU's -chardev socket,...,path=./virtiofsd.sock can race and fail to connect. (2) When virtiofsd itself fails immediately (missing binary, bad arg, stale socket already bound), set -e does not catch background-process exits; the script continues into QEMU and prints a confusing "connection refused." (3) When QEMU exits — clean shutdown, Ctrl-C, or crash — virtiofsd is never killed and the socket is never removed; subsequent runs race against the orphan or fail with "address already in use."

Fix: store the PID, install an EXIT trap, remove stale sockets, and verify readiness before launching QEMU.

+rm -f ./virtiofsd.sock
+trap 'kill "${VFS_PID:-0}" 2>/dev/null || true; rm -f ./virtiofsd.sock' EXIT
 virtiofsd --shared-dir=./ --socket-path=./virtiofsd.sock --sandbox none &
+VFS_PID=$!
+while [ ! -S ./virtiofsd.sock ]; do kill -0 "$VFS_PID" || exit 1; sleep 0.1; done

The existing Lima QEMU driver under pkg/hostagent follows this pattern for its vhost sockets — reuse that lifecycle when this graduates from PoC.

    -blockdev driver=raw,file=cdrom2-storage,node-name=cdrom2,read-only=true \
    -device ide-cd,bus=ide.3,drive=cdrom2 \
    -netdev user,id=net0,net=192.168.10.0/24,dhcpstart=192.168.10.15,hostfwd=tcp:127.0.0.1:60022-:22 \
    -device virtio-net-pci,netdev=net0 \
    -chardev socket,id=chr-vu-fs0,path=./virtiofsd.sock \
    -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=hoge \
    -device virtio-rng-pci
```

#### Try SSH
```bash

# run.sh:47
-device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=lima \

hoge is a Japanese placeholder name, evidently leftover. The README's own sample output later shows Volume in drive Z is lima (README.md:104), so the documented command does not match the documented output. A reader who runs the manual block instead of run.sh gets a hoge tag, which the WinFSP service path (E:\viofs\2k25\amd64\virtiofs.exe) may or may not pick up — the result is silently inconsistent with what the README shows.

Fix: change README.md:87 to tag=lima.

$logfile = "C:\Users\limauser\lima-setup.log"

# Record logs
Start-Transcript -Path $logfile -Append

# Install OpenSSH server, then enable it
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

# Modify firewall rule
# Note that Windows server may have a firewall rule for SSH by default, but it doesn't work on my env.
# So I remove and recreate the rule.
Remove-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction Ignore
New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

# Set a public key. Since a user `lima` is in Administrators group,
# The pubelic key should be located under C:\ProgramData\ssh instead of under C:\Users\lima\.ssh.
$pubkey = Get-Content -Path F:\user.pub
$pubkeyLocation = 'C:\ProgramData\ssh\administrators_authorized_keys'
Add-Content -Force -Path $pubkeyLocation -Value $pubkey
icacls $pubkeyLocation /inheritance:r
icacls $pubkeyLocation /grant "SYSTEM:F"
icacls $pubkeyLocation /grant "Administrators:F"

# Install chocolatey for installing WinFSP.
# WinFSP can be installed through winget as well, but currently winget is unstable in Windows Server Core
# See: https://github.com/microsoft/winget-cli/discussions/5230
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# Install WinFSP for VirtioFS
C:\ProgramData\chocolatey\choco.exe install winfsp -y --pre

# Create VirtioFs service from virtio-win, and enable it
# By default, the host directory is mounted on Z:
New-Service -Name VirtioFsSvc -BinaryPathName 'E:\viofs\2k25\amd64\virtiofs.exe' -DisplayName VirtioFsSvc -StartupType Automatic
Start-Service -Name VirtioFsSvc

# Finish recording logs
Stop-Transcript

PowerShell does not stop on cmdlet failure by default, and native commands (choco.exe, icacls) are not checked through $LASTEXITCODE. If Add-WindowsCapability fails with a transient network error pulling FoD from Microsoft, Start-Service sshd runs anyway and produces a separate, unrelated error; the VM boots into a half-provisioned state where SSH never works. The same applies to chocolatey install failure (no WinFSP → New-Service succeeds but the service binary is missing → Start-Service VirtioFsSvc silently fails). The transcript log captures everything but a user has to scroll through hundreds of lines to notice.

Fix: set strict error handling at the top of the script, wrap the body in try/finally, and check $LASTEXITCODE after each native command.

+$ErrorActionPreference = 'Stop'
+try {
   # ... existing body ...
+  if ($LASTEXITCODE -ne 0) { throw "choco install winfsp failed: $LASTEXITCODE" }
+} catch { Write-Error $_; exit 1 }
+finally { Stop-Transcript }

# Create qcow2
qemu-img create -f qcow2 ./images/windows.qcow2 40G

# Run virtiofsd in background
virtiofsd --shared-dir=./ --socket-path=./virtiofsd.sock --sandbox none &

# Run QEMU
qemu-system-x86_64 \
    -name guest=win2k25,debug-threads=on \
    -machine pc-q35-noble,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on \

The shared directory is the PoC root, which contains images/ (the Windows ISO, the virtio-win ISO, and the live windows.qcow2 that QEMU is using as the guest disk), autounattend.xml (with the plaintext password), first_logon.ps1, and the virtiofsd.sock itself. The README's dir Z:\ screenshot at line 109-119 confirms — the guest can list and modify its own backing disk. Combined with --sandbox none (no chroot/user-namespace isolation), this gives the guest a direct path to corrupt its own VM image and tamper with the installation media. For a PoC this is tolerable, but the default share root should be a dedicated subdirectory.

Fix:

+mkdir -p ./shared
-virtiofsd --shared-dir=./ --socket-path=./virtiofsd.sock --sandbox none &
+virtiofsd --shared-dir=./shared --socket-path=./virtiofsd.sock --sandbox none &

and a note in the README that --sandbox none plus a parent-directory share means the guest can tamper with its own VM image.

icacls $pubkeyLocation /grant "Administrators:F"

# Install chocolatey for installing WinFSP.
# WinFSP can be installed through winget as well, but currently winget is unstable in Windows Server Core
# See: https://github.com/microsoft/winget-cli/discussions/5230
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# Install WinFSP for VirtioFS
C:\ProgramData\chocolatey\choco.exe install winfsp -y --pre

# Create VirtioFs service from virtio-win, and enable it

This is the canonical iex (DownloadString …) supply-chain anti-pattern: every VM provisioning run executes whatever code currently lives at community.chocolatey.org/install.ps1, as Administrator, with no checksum and no pinned commit. A compromise of the chocolatey CDN (or a man-in-the-middle between the guest and the CDN — the guest does its first network reach through QEMU's user-mode NAT) is full code execution on every Lima Windows guest provisioned from this PoC. WinFSP is the only package needed; downloading the MSI directly from github.com/winfsp/winfsp releases and verifying a pinned SHA-256 removes both the chocolatey dependency and the unpinned-fetch risk.

Fix:

$winfspUrl    = 'https://github.com/winfsp/winfsp/releases/download/v2.0/winfsp-2.0.23075.msi'
$winfspSha256 = '<sha256-of-the-msi>'
$msi = "$env:TEMP\winfsp.msi"
Invoke-WebRequest -Uri $winfspUrl -OutFile $msi -UseBasicParsing
$got = (Get-FileHash -Algorithm SHA256 $msi).Hash
if ($got -ne $winfspSha256) { throw "winfsp checksum mismatch: $got" }
Start-Process msiexec.exe -Wait -ArgumentList "/i `"$msi`" /qn"

    <component name="Microsoft-Windows-PnpCustomizationsWinPE" publicKeyToken="31bf3856ad364e35"
        language="neutral" versionScope="nonSxS" processorArchitecture="amd64"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
        <DriverPaths>
            <PathAndCredentials wcm:action="add" wcm:keyValue="2">
                <Path>E:\viostor\2k25\amd64</Path>
            </PathAndCredentials>
            <PathAndCredentials wcm:action="add" wcm:keyValue="3">
                <Path>E:\NetKVM\2k25\amd64</Path>
            </PathAndCredentials>
            <PathAndCredentials wcm:action="add" wcm:keyValue="4">
                <Path>E:\viofs\2k25\amd64</Path>
            </PathAndCredentials>
            <PathAndCredentials wcm:action="add" wcm:keyValue="5">
                <Path>E:\Balloon\2k25\amd64</Path>
            </PathAndCredentials>
            <PathAndCredentials wcm:action="add" wcm:keyValue="6">
                <Path>E:\viorng\2k25\amd64</Path>
            </PathAndCredentials>
        </DriverPaths>
    </component>

    <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <InputLocale>en-US</InputLocale>

Two failure surfaces share one cause. At install time, the answer file driver paths (autounattend.xml:9-22), the cidata first_logon.ps1 invocation (autounattend.xml:134), and the cidata user.pub read (first_logon.ps1:19) all assume E: = virtio-win ISO and F: = cidata ISO. That mapping comes from the cdrom0/ide.1 → D:, cdrom1/ide.2 → E:, cdrom2/ide.3 → F: Windows convention — not a contract. Reorder the -device ide-cd,bus=ide.N lines in run.sh, or add another removable device, and every reference silently breaks.

At runtime, first_logon.ps1:36 registers VirtioFsSvc with its BinaryPathName on the virtio-win CD-ROM. The service persists across reboots, but its binary lives on removable media — detaching the ISO or any drive-letter reshuffle leaves the service registered with a missing binary.

# Install WinFSP for VirtioFS
C:\ProgramData\chocolatey\choco.exe install winfsp -y --pre

# Create VirtioFs service from virtio-win, and enable it
# By default, the host directory is mounted on Z:
New-Service -Name VirtioFsSvc -BinaryPathName 'E:\viofs\2k25\amd64\virtiofs.exe' -DisplayName VirtioFsSvc -StartupType Automatic
Start-Service -Name VirtioFsSvc

# Finish recording logs
Stop-Transcript

Fix: copy the service binary to C:\ before registering, and locate the cidata ISO by volume label (Get-Volume -FileSystemLabel autounattend) rather than by drive letter.

-New-Service -Name VirtioFsSvc -BinaryPathName 'E:\viofs\2k25\amd64\virtiofs.exe' -DisplayName VirtioFsSvc -StartupType Automatic
+Copy-Item -Path 'E:\viofs\2k25\amd64\virtiofs.exe' -Destination 'C:\Windows\System32\virtiofs.exe'
+New-Service -Name VirtioFsSvc -BinaryPathName 'C:\Windows\System32\virtiofs.exe' -DisplayName VirtioFsSvc -StartupType Automatic

virtiofsd --shared-dir=./ --socket-path=./virtiofsd.sock --sandbox none &

# Run QEMU
qemu-system-x86_64 \
    -name guest=win2k25,debug-threads=on \
    -machine pc-q35-noble,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on \
    -accel kvm \
    -cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \
    -m size=2048 \
    -object memory-backend-memfd,id=pc.ram,share=true,size=2048M \
    -overcommit mem-lock=off \

The pc-q35-noble alias ships with Canonical's Ubuntu 24.04 ("noble") QEMU package. On Fedora, Arch, Debian-stable, RHEL, or any non-Ubuntu host, QEMU rejects this with unsupported machine type before Windows setup even starts. The README's "Tested on Ubuntu 24.04" note understates the constraint — this is a hard prerequisite, not a "tested on" annotation. The portable name q35 selects the newest variant available on every distro.

Fix:

-    -machine pc-q35-noble,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on \
+    -machine q35,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram,hpet=off,acpi=on \

Apply the same change in README.md:67.

Severity note: Gemini ranked this as Important on portability grounds; Claude and Codex ranked it as a Suggestion since the README explicitly says Ubuntu 24.04 was used. Settling on Important here because the script fails immediately on non-Ubuntu hosts, which is the first thing many readers will try.