Change:
}; system.nssModules = optional (cfg.nss.enable or cfg.nss.enableGuest) cfg.package; <del> system.nssDatabases.hosts = builtins.concatLists [ (optional cfg.nss.enable "libvirt") (optional cfg.nss.enableGuest "libvirt_guest") </del> <ins> system.nssDatabases.hosts = mkMerge [ # ensure that the NSS modules come between mymachines (which is 400) and resolve (which is 501) (mkIf cfg.nss.enable (mkOrder 430 [ "libvirt" ])) (mkIf cfg.nss.enableGuest (mkOrder 432 [ "libvirt_guest" ])) </ins> ]; }; }

Discussion:
I was happy to learn that in NixOS 24.05 the virtualization module gained . However, I found it not working: does not resolve to an IP address, even though the VM host name and IP is present in libvirt. With the following NixOS configuration: The following entry in is correctly created: The path to and is also correctly to the environment variable of the , as evidenced by : The data source of in , which makes it a lot easier to reproduce the issue because no actual VMs have to be created using libvirt. Here are two files that can be used for reproduction (Note: The below is significant, and should lie in your future, otherwise the name lookups will not work.) : : The actual querying of the name can now be done with . This does not return a result (exit code 2). should return the IP address . Having more than one directory in does not work. Having just one directory in , the libvirt one, does work. To verify those two statements, do the following steps as . Please take extra care below to distinguish between and . In a different terminal, the name resolution is successful: in the first terminal shows that the data source is actually consulted: Now, repeat the same experiment, but add the second path to (the actual value from ), e.g. to the invocation. This time, does not match any lines and does not return a result. Note: If you pass (or similar) to , this will bypass the call to nscd and attempt to go to the libnss libraries directly, so this will always fail on NixOS (unless the needed shared libraries are in scope). I do not know enough about the actual NSS mechanism inside glibc to understand why and are not consulted. Since does not do actual lookups, and only calls into glibc ( or such), this looks to me like a glibc issue, but this is currently out of my depth to analyze. In any case, the NixOS feature as I think it was intended to work, does not, hence I think that this is a bug. I'm happy to provide more details if needed. Sorry for notifying so many of you but this issue looks like it could be interconnected between several parts.

nsncd: libvirt: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Interesting. FWIW, it works for me on (I use it with regularly) but it's likely that I've done it wrong and it's only working by accident on my machines. I did modify to make use of the NSS module as well, to help ensure it does not accidentally break. I wonder how this can be reliably reproduced.
The following flake declares a system that exhibits the issue: I can't attach , so here quoted for full reproducibility: On the host, build the image and start the VM: In the VM:
This seems to be an issue with . I don't know how to fix it, but disabling should fix the repro. I suspect there is no problem with the NSS module; has all kinds of unusual behaviors and is known to have trouble with bare single-label domains among other things. edit: This message is a bit confused (see next reply) but for posterity sake the problems I am referring to here (which might be relevant for trying to make a similar thing work in a pure setup) are ; long story short, it may be necessary to set and disable LLMNR for to properly resolve a bare single-label domain like .
After thinking about it more, I realized what I am saying is a bit off. When I typed this I was thinking for some reason that would impact the way NSS worked but of course it doesn't, is just another NSS module. The real trouble is what NixOS does when is enabled: That is a problem. Per the man page: So, as long as can be reached, none of the other NSS modules will be consulted. This makes sense: supports a lot of the functionality normally handled by multiple NSS modules (like mDNS) and so it doesn't really make sense to run the vast majority of NSS modules. I don't really know what the best thing to do here would be. I'm pretty sure we don't really want the libvirt NSS modules to be higher priority than resolved, and we also don't want the fallback NSS modules to run if resolved is working. I don't think the file has advanced enough syntax to support this.

Really, I think the best bet would be to add an assertion to the libvirt NSS module that ensures it is not enabled with resolved, at least for now. Assuming there's no more obvious better solution here, the better way to go is probably to just avoid the NSS modules altogether and integrate with more directly somehow. Sorry for the confusion, I always get tangled up in the details with these things.
I think the best workaround I can come up with for now is to manually add the NSS module(s) you want at a higher priority than . This may have some negative implications depending on your DNS configuration, but after playing around with things none of my other ideas worked well. (Another idea I had was to have appear twice in the list, but I wasn't able to get the desired result, and doing something like that would be a potentially gnarly breaking change, too.) For the previous reproduction, something like this should work as expected: It's unfortunate that there is no "nicer" solution here, but hopefully this at least helps. I think I have hit a stopping point finally, sorry about sending a bunch of replies.
Thanks for your viewpoints. This is indeed how NixOS currently writes , but this explicitly and practically prevents all current and future resolving methods other than , which cannot be the goal. But I might have found the original reason for coding it like this in NixOS. From (my emphasis): So far, NixOS got that right: is before the module. However, the module is conceptually very close -- or even identical -- to (because "hostnames given to local VMs"). So I would argue that the "workaround" that you suggested is the actual solution that should be permanently implemented in NixOS, iow. that and should be right next to . Note that the man page (just) recommends "early" and means with this "before the 'files' entry", but it does not insist on being first or excluding other modules. That internal domains take precedence over the DNS is pretty much expected.
Yeah, I think pretty much all documentation shows the NSS modules early in the chain, so it seems safe enough. We can solve this pretty easily in NixOS by using . The NSS module is put at such a priority that it will always come just after 'd NSS modules.

I'll make a new PR when I get a chance.
Sounds good. It should be also performant because libnss_libvirt just reads local files, there is no network involved. While reading code, I saw that the entries in are actually sorted by priorities: is 400, and is 501; so values for libvirt would lie somewhere in between.
is 501 because it's the number directly after (500): . So, I think making libvirt NSS modules is the right way to go. Not sure if it's worth adding a NixOS test for, but it wouldn't be hard.
With (prio 500), there would be no slot left between and (prio 501) to insert other modules; this would go against the Open-Closed Principle. I would choose priority 450 so that there is enough space on both sides; or even 430 because it's conceptually closer to than to . Choosing a prio would also be explicit, which is good. It would also be consistent with other modules who also picked and coded a priority explicitly.
I created a PR and successfully tested it using the flake from above.