As part of experimenting I want to run my system configuration in a QEMU VM, using nixos-rebuild build-vm.
The configuration is mostly identical to my real system, but I can customize some bits using NixOS's vmVariant option:

virtualisation.vmVariant = {
    # customize the machine, only for the VM variant
};

however if I enable comin and have it redeploy onto the VM, it will not pick up the VM variant, and instead deploys the standard config, without the customization. In order to get the VM variant, one needs to deploy nixosConfigurations.HOSTNAME.config.virtualisation.vmVariant.system.build.toplevel, instead of nixosConfigurations.HOSTNAME.config.system.build.toplevel.

I think the comin binary should have a way to configure the toplevel path instead of only allow the hostname portion to be configured. Then either users can configure that themselves, or the comin could add a default for the vmVariant to automatically pick the alternative toplevel.

There's also a similar "specialisation" concept in NixOS, which creates new configurations that can be deployed using nixosConfigurations.HOSTNAME.config.specialisation.foo.configuration.system.build.toplevel. Again, if the comin binary accepted an arbitrary top-level, then it would be very easy to support these at the module level.

An alternative way of supporting specialisations is to build the full system, but uses a different switch-to-configuration path. It's what nixos-rebuild does, but these should be equivalent since the latter is a symlink to the former.. This method would not work with the vmVariant though.

There is a workaround to both of these, which is to define a new nixosConfigurations.foo-vm entry that points to this modified configuration, and then configure comin with hostname = "foo-vm". It works but it is a bit inconvenient:

nixosConfigurations = rec {
  foo = ...;
  foo-vm.config = foo.config.virtualisation.vmVariant;
}