add the ability to supply a config instead of just a nixosConfigurations flake

[bolives-hax]

Hey as of the way my nixos configurations are structured. It is not possible for me to supply the system configuration for the vm over the route below.

{
vms.${name}.flake = self;
}

as of the following line of code it seems

microvm.nix/nixos-modules/host.nix

Line 122 in d578ed4

microvmConfig = flake.nixosConfigurations.${name}.config;

Why could this matter?. Let me suggest a use case:

Lets say I want to supply certain information to my "vm_httpd" vm definition. Such as a domain names it makes use of when generating http. Instead of declaring that in /etc/nixos#nixosConfigurations.vm_httpd it would seem much more cool to generate it from within my primary config /etc/nixos#nixosConfigurations.bigServer via a convenience function called

mkHttpdConfig = {domainName}: {
   config."...".domain = domainName;
} 

or something like that. This starts being useful as soon as one wishes to spawn multiple vm with nearly identical configuration values. Below can be seen how id roughly imagine that and how I already do it for my containers at least:

{
inputs.myWebsite.url = "github:user/repo";
# ...
nixosConfigurations.bigServer = nixosSystem {
   system="x86_64-linux";
   modules = let
        webDomain = "www.domain.de";
        templates = import ./templates; 
   in [
       microvm.host
       ({...}: {
          micro.vms.httpd_a.config = (templates.vm_httd_public {
            inherit domain;
            serveData = myWebsite;
          });
          micro.vms.httpd_a.config = (templates.vm_httd_tor {
             serveData = myWebsite;
             torConfig = secrets.torCreds01;
          });
       })
   ];
}

Being able to express large parts of my nixos configurations as functions that then end up producing valid configurations to actually be build would allow for much more dynamic configuration approaches. Less duplication and cleaner code.

I personally don't seem to see any issues with implementing this alternative behavior, though maybe im missing something or it goes against the design decisions taken by the author so I'd rather be interested in the current take on my suggestion. If there is any interest in this feature and the option of a potential change being merged exist I would also make the change myself.

[bolives-hax]

I looking trough the source a little I think that adding a config option along side the flake option
in

microvm.nix/nixos-modules/host.nix

Line 22 in d578ed4

options = {

and applying it at(below)

microvm.nix/nixos-modules/host.nix

Line 122 in d578ed4

microvmConfig = flake.nixosConfigurations.${name}.config;

As this should enable the user to not be restricted to the prefix of nixosConfigurations.
but instead be able to provide any config to be found within the flake not just these that follow the previously described prefix pattern of nixosConfiguration.${name}. ....

By using the ? operator it would also be possible to maintain backwards compatibility, as one could just unless config is set revert to the default behavior.

Though as of the way the microvm-command tool [below] is build ... it sadly would break as it expects the path the flakes contents to follow that name pattern I suggested changing above. So that tool would also need to be modified

https://github.com/astro/microvm.nix/blob/d578ed45d3528c42ab4b12edf6d1512a7bd35714/pkgs/microvm-command.nix

As for now these seem to be the only things that would need to be changed to adapt to the behavior I desire.

[oddlama]

@bolives-hax I just had the same problem and implemented this quickly. If you are open to trying the liked PR, I'd appreciate your feedback and whether it works as you expect it to.

[astro]

In my opinion this is not 100% done yet. It would be really nice to pass a configuration.nix to the microvm command just like it is supported with nixos-containers.