yes, there are some cases that require qemu to run as root. another one is passthrough file ownership and permission of 9p mounts.

rebased and solved merge conflict

@peterhoeg this contributes to #41092 and has been around for a while so I would like to see it merged for 18.09. Any thoughts?

Does it work with DynamicUser = true; instead of the defined user?

No, qemu doesn't run as a systemd service. It is forked by libvirtd when a guest is started. Also, some persistent files (disk image, nvram, save files,...) will be owned by the user qemu runs as, so it must be static.

Yes, one-time manual intervention (chown) may be required. We can document this in release notes.

If we believe it's more important to avoid manual intervention, we can merge this with qemuRunAsRoot default to true. I'm fine with that. No problems but little impact. Most people won't even know the new option exists.

We could also change the default to false on new installs depending on stateVersion. Gives a smoother transition but is unnessarily complicated and can confuse people, so I don't really like it.

@volth good idea, thanks. So I'll change this PR to the non-breaking version and add the second one after this is merged.

The interactiosn between 9p/libvirt/qemu can be a real pain (dynamic_ownership being a false hope). After hours of fiddling the only configuration that worked for me to have the /nix/store owned by root while retaining the capaibily to share home folders with my VM was to mount these folders as mapped and run qemu as myself.

    qemuVerbatimConfig = ''
      namespaces = []
      user="teto"
      group="users"
      
      # Whether libvirt should dynamically change file ownership
      # to match the configured user/group above. Defaults to 1.
      # Set to 0 to disable file ownership changes.
      dynamic_ownership = 0
    '';

This PR prepends another user such that I have:

      user="qemu-libvirtd
      group="qemu-libvirtd"
      user="teto"
      group="users"

and apparently libvirtd only picks the first user since reverting the PR let my VM start contrary to the behavior with this PR:

[nix-shell:~/nixops]$ nxp start
main> starting...
libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2018-08-15T08:19:45.216208Z qemu-system-x86_64: -drive file=/var/lib/libvirt/images/nixops-11975c3a-9f99-11e8-b944-309c233b770e-main.img,format=qcow2,if=none,id=drive-ide0-0-0: Could not open '/var/lib/libvirt/images/nixops-11975c3a-9f99-11e8-b944-309c233b770e-main.img': Permission denied
error: internal error: process exited while connecting to monitor: 2018-08-15T08:19:45.216208Z qemu-system-x86_64: -drive file=/var/lib/libvirt/images/nixops-11975c3a-9f99-11e8-b944-309c233b770e-main.img,format=qcow2,if=none,id=drive-ide0-0-0: Could not open '/var/lib/libvirt/images/nixops-11975c3a-9f99-11e8-b944-309c233b770e-main.img': Permission denied

apparently libvirtd only picks the first user

Yes, that seems to be the case. A (somewhat non-intuitive) workaround for your config is to set qemuRunAsRoot = true;. This removes the first set of user/group="qemu-libvirtd", leaving only your user and group from qemuVerbatimConfig .

To make this case more intuitive we could put the user and group entries generated by qemuRunAsRoot = false; after the text from qemuVerbatimConfig in the config file to give settings in qemuVerbatimConfig priority.

haha right but doesn't look like a long term solution. some other modules allows to specify user/group so that might be better ?