You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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 ofnixosConfigurations.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 whatnixos-rebuild
does, but these should be equivalent since the latter is a symlink to the former.. This method would not work with thevmVariant
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 withhostname = "foo-vm"
. It works but it is a bit inconvenient:The text was updated successfully, but these errors were encountered: