this is more than just renaming

Well, technically, yes, you're right but this doesn't remove any functionality or change behavior. It only adds something which may be necessary to boot.

I have updated the PR title to be better reflect this.

@peterhoeg without having explicitly enabled vmw_pvscsi anywhere in my configuration.nix I see this module is loaded:

$ lsmod | grep vmw_pvscsi
vmw_pvscsi 28672 3
scsi_mod 225280 4 vmw_pvscsi,sd_mod,libata,sr_mod

What is the impact on a vmware client running NixOS that doesn't have this enabled? What is the impact if it is enabled?

Thanks!

If you did a normal install of NixOS, it would be auto-detected by the installer and placed in hardware-configuration.nix - did you check that file?

So as long as you run a local nixos-rebuild in the VM, this will not change anything. It becomes necessary when using something like nixops to push out changes where locally generated/installed .nix files are ignored.

@peterhoeg ah that makes sense now. I'm using nixops, but I had copied the contents of hardware-configuration.nix onto my nixops box which manages the machine. So I did add it via copy & paste as opposed to explicitly.

Are you deploying to vmware over ssh? If so, do you not copy relevant details of hardware-configuration.nix into your nixops server?

PS. sorry for thread hijacking...

Are you deploying to vmware over ssh?

Yes

If so, do you not copy relevant details of hardware-configuration.nix into your nixops server?

No, we just use a standard config.

@peterhoeg Could you please elaborate on this "standard config" point? Whenever I deploy a server with nixops to the "none" backend I have to fully specify hardware like fileSystems, boot.initrd.kernelModules, etc... Are you implying that you don't copy/paste hardware-configuration.nix from the target nixos machine onto your nixops machine and then deploy?

I would appreciate any details you could share as you're leaving me with the feeling i'm completely missing some very important concepts with nixops.

Are you implying that you don't copy/paste hardware-configuration.nix from the target nixos machine onto your nixops machine and then deploy?

That is correct.

I would appreciate any details you could share as you're leaving me with the feeling i'm completely missing some very important concepts with nixops.

It has nothing to do with any special nixops features but simply:

1. Modularize as much as possible, and
2. Convention over configuration

If the root FS always has the label "root", you can include a common profile like this (in this case called default_disk_layout.nix:

{ ... }:

{
  fileSystems."/" = {
    device = "/dev/disk/by-label/root";
    fsType = "btrfs";
    options = [ "subvol=nixos" "noatime" "compress=lzo" ];
  };
}

Pull in a shared profile for everything running on HyperV and another for everything running on ESX.

I thought there might have been some nixops magic I was missing, so thanks for clarifying!