The links should be resolved in the guest, so if they point to /nix/store, and the host’s /somePath/nix/store is what’s mounted there, then they should point correctly into the same store, even if they look broken on the host.
Unless the method you’re using to mount the host’s filesystem into the guest is pre-resolving symlinks on the host side for some reason, in which case you need to figure out how to stop it from doing that. It’ll mess up a lot of things.
I’m not doing anything fancy. Just changing the mount path for the qemu vm run script for the nix store. Stage 1 works fine which means that the mount works and the files are found, but then stage 2 fails with the error above. The only difference I could find was the one I mentioned about the symlinks. Not sure what else to look at at this stage.
Well stage 1 runs out of an initrd, so I believe it wouldn’t mean anything about whether the mount is working as intended.
with initrd being in the ‘/somePath/nix/store’
It feels like the method above gets the process near from the desired state of having a separate store for the built VM’s, but it fails on stage 2 of the guest VM boot process when it tries to access some files from the store (it still seems to me that this happens due to the files being symlinked to the hosts ‘/nix/store’, but couldn’t confirm 100%).
I’ve moved on from this path as I wasn’t able to progress any further.
We just released a project that does exactly this. Images that only reference Nix packages but does not contain them, then the container runtime is extended in a first-class way to bind mount all the packages into the container and nothing else.
See: Nix-snapshotter: Native understanding of Nix packages for containerd