Host-to-guest storage module #656
Conversation
mbssrc
temporarily deployed
to
internal-build-workflow
GitHub Actions
Inactive
mbssrc
temporarily deployed
to
internal-build-workflow
GitHub Actions
Inactive
mbssrc
temporarily deployed
to
internal-build-workflow
GitHub Actions
Inactive
- System-wide service to configure shares for guest vms using virtiofs - Persistent fingerprint storage configured for gui-vm - Preparation for other services using this feature Signed-off-by: Manuel Bluhm <manuel@ssrc.tii.ae>
mbssrc
temporarily deployed
to
internal-build-workflow
GitHub Actions
Inactive
| if [ ! -d "${vmShare.vm-path}" ]; then | ||
| mkdir -p ${vmShare.vm-path} | ||
| fi | ||
| ${optionalString (vmShare.tmp-path != null) "cp -r ${vmShare.tmp-path}/* ${vmShare.vm-path}"} |
There was a problem hiding this comment.
The way I understand the semantic, I would expect the previous content to be removed.
Maybe using rsync with --delete would be than a better choice?
There was a problem hiding this comment.
Rsync, also would have an option to directly apply the right owner/group without an additional chown.
There was a problem hiding this comment.
The idea with this was that the host data remains present. This 'temporary' mountpoint option is intended for the use case where one wants to copy data from the host on VM boot, and apply specific permissions without changing the host permissions or rely on some UID mapping. Deletion could be added as an option as well.
There was a problem hiding this comment.
I was also looking into using the impermanence module instead of this script. At the moment, I am waiting for the storage vm implementation to see how to finally implement this
There was a problem hiding this comment.
As far as I know, impermanence doesn't provide copy semantics.
| with the default owner 'microvm' and group 'kvm'. | ||
| ''; | ||
| }; | ||
| tmp-path = mkOption { |
There was a problem hiding this comment.
| tmp-path = mkOption { | |
| tmp-mountpoint = mkOption { |
| default = null; | ||
| description = '' | ||
| (Optional) Temporary directory in the VM to mount the host directory. If this is set, | ||
| the folder from host-path will be recursively copied from 'tmp-path' to 'vm-path' and owner, group, |
There was a problem hiding this comment.
| the folder from host-path will be recursively copied from 'tmp-path' to 'vm-path' and owner, group, | |
| the folder from host-path will be recursively copied from 'tmp-mountpoint' to 'vm-path' and owner, group, |
| vm-path = mkOption { | ||
| type = types.str; | ||
| description = '' | ||
| Storage directory in the guest where the share is mounted to. |
There was a problem hiding this comment.
| Storage directory in the guest where the share is mounted to. | |
| Storage directory in the guest where the share is mounted or where the data is copied to if `tmp-mountpoint` is set. |
| type = types.str; | ||
| description = '' | ||
| Name of the VM the share is mounted into. The name must match the microvm | ||
| name in 'config.microvm.vms': e.g., "gui-vm" (note the '-'). |
There was a problem hiding this comment.
You can use assertions = [{}]; nixos option and config.microvm.vms ? ${target-vm} condition here to test if the microvm actually exists to check for misconfiguration.
There was a problem hiding this comment.
Yes will add assertions later if this is going to be used
| Restart = "no"; | ||
| StandardOutput = "journal"; | ||
| StandardError = "journal"; | ||
| ExecStart = "${prepStorage}/bin/storage_prep"; |
There was a problem hiding this comment.
I believe this will be re-runs whenever a new NixOS is deployed. Might be a bit disruptive if a VM gets part of the state wiped without when it's already running.
But I also don't know if life-updates is a requirement here.
There was a problem hiding this comment.
Good point - my assumption was that the VM service is restarted, but as we see with netvm now this may not necessary be the case. Adding restartIfChanged = false; should do the trick?
There was a problem hiding this comment.
Yes. restartIfChanged = false; would solve this.
Description of changes
Checklist for things done
x86_64aarch64riscv64nix flake check --accept-flake-configand it passesTesting