Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah I make extensive use of this and it's absolutely fantastic.

I can write a config, very quickly check it seems correct on a QEMU guest, and then deploy "the same" config to a physical host (slower to boot, harder to debug, annoying to power cycle) and be highly confident it's gonna behave like the VM did. This is incredibly valuable!

But by "hard to know if it's gonna work" I was talking more about architecture-level concerns. Not "is my Nix code correct" but "is this thing I'm envisaging a thing that the ecosystem supports?" I usually just have to sit down and try coding it up, and there's always an element of uncertainty about whether I'll succeed. Whereas if I sit down to get something done in Ansible I don't really have any such doubts. (But the result will be dramatically worse).



Regarding how a bunch of the pieces go together, I found this blog post from Shopify quite useful: https://shopify.engineering/what-is-nix


how do you do this and what do you use? do you just manually trigger qemu? I'd love to be able to boot VM with different nix configurations.


Usually I just use `nix run .#nixosConfigurations.<my config>.config.system.build.vm`

This boots directly into the kernel with QEMU's '-kernel' option, and it mounts the host Nix store into the guest via Plan 9 FS. So there is some significant difference vs a full system, e.g. it's not possible to nixos-rebuild the VM. But if you're just testing high-level stuff it's totally fine.

Then there's also a .vmWithBootloader variant which behaves a bit more like a physical machine, IIUC it builds a disk image and boots it via Nixos' actual bootloader.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: