The problem is that nextcloud runs inside microvm. so its /data dir will actually be a tmpfs. We need to share the hosts /data. for example as its done with /var right now in host_builder.nix
I currently see to possible solutions: either we only put the nextclouds data on storage, or we put all microvms /var on storage. that way current and future vms would not bloat fannys root drive. But it would be important to make this configurable, maybe even on the host because microvms that run on hetzner need to mount the /var dir as it is right now (there is no /data dir).
Maybe for simplicity we just go with the first option for now and implement something more sophisticated later on.
> Warning: I have not tested e94410ca54281a41b0d48cd82634d9560917cf03 yet
The problem is that nextcloud runs inside microvm. so its /data dir will actually be a tmpfs. We need to share the hosts /data. for example as its done with /var right now in [host_builder.nix](https://git.dynamicdiscord.de/kalipso/infrastructure/src/commit/362d9cf488e0daff72450871c5801a5debbd39f6/machines/modules/host_builder.nix#L66-L72)
```nix
{
source = "/var/lib/microvms/${hostName}/var";
mountPoint = "/var";
tag = "var";
proto = "virtiofs";
socket = "var.socket";
}
```
I currently see to possible solutions: either we only put the nextclouds data on storage, or we put all microvms /var on storage. that way current and future vms would not bloat fannys root drive. But it would be important to make this configurable, maybe even on the host because microvms that run on hetzner need to mount the /var dir as it is right now (there is no /data dir).
Maybe for simplicity we just go with the first option for now and implement something more sophisticated later on.
My idea is something like this edddfc5e3f but that doesn't work because of the imperative microvm workflow:
error:
Failed assertions:
- vm nextcloud: Fully-declarative VMs cannot also set a flake!
- vm nextcloud: Fully-declarative VMs cannot set a updateFlake!
My idea is something like this edddfc5e3fb199865fe17a6c984855ece78f845f but that doesn't work because of the imperative microvm workflow:
```
error:
Failed assertions:
- vm nextcloud: Fully-declarative VMs cannot also set a flake!
- vm nextcloud: Fully-declarative VMs cannot set a updateFlake!
```
This is actually a bit more complicated than expected. As you mentioned we cannot mix up declarative/imperative microvms. From the host side we cannot change the microvm shares at all. So a working approach would be add a share like that to all microvms (or only nextcloud for now):
And then on the host side we could just mount storage (or an extra dataset for that usecase) on /var/lib/microvms/data if we want. That way we can deploy microvms to any host we want, no matter if they have additional storage or not, and if they do just mount the storage to the data dir.
Another, way more simple approach would be to just create a microvm dataset on the storage pool and mount that to /var/lib/microvms on fanny. that way just all microvms data will live on storage without any changes neccesary to our vm implementations.
This is actually a bit more complicated than expected. As you mentioned we cannot mix up declarative/imperative microvms. From the host side we cannot change the microvm shares at all. So a working approach would be add a share like that to all microvms (or only nextcloud for now):
```nix
{
source = "/var/lib/microvms/data/${hostName}";
mountPoint = "/data";
tag = "data";
proto = "virtiofs";
socket = "var.socket";
}
```
And then on the host side we could just mount storage (or an extra dataset for that usecase) on `/var/lib/microvms/data` if we want. That way we can deploy microvms to any host we want, no matter if they have additional storage or not, and if they do just mount the storage to the data dir.
Another, way more simple approach would be to just create a microvm dataset on the storage pool and mount that to `/var/lib/microvms` on fanny. that way just all microvms data will live on storage without any changes neccesary to our vm implementations.
When setting malobeo.disks.encryption = false; (and setting reservation = 0G; but i think thats just cause my host has nearly no diskspace right now) iam able to run fanny with nix run .\#nixosConfigurations.fanny.config.system.build.vmWithDisko and it looks good. Sadly the microvms fail to boot (due to vmvariant issues i think) but iam confident the virtiofs mount should work without testing.
I think this can be merged.
When setting `malobeo.disks.encryption = false;` (and setting reservation = 0G; but i think thats just cause my host has nearly no diskspace right now) iam able to run fanny with `nix run .\#nixosConfigurations.fanny.config.system.build.vmWithDisko` and it looks good. Sadly the microvms fail to boot (due to vmvariant issues i think) but iam confident the virtiofs mount should work without testing.
I think this can be merged.
kalipso
requested review from kalipso 2025-02-06 17:40:43 +01:00
I've tested the configuration but the data mount doesn't show up. [malobeo@fanny:~]$ cat /nix/store/1wfvgdzxm3fxcxm6i8vlpdw012137rzv-durruti-virtiofsd-supervisord.conf
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
kalipso
For now this fixes #67 and parts of #69 (nice)
Warning: I have not tested
e94410ca54yetThe problem is that nextcloud runs inside microvm. so its /data dir will actually be a tmpfs. We need to share the hosts /data. for example as its done with /var right now in host_builder.nix
I currently see to possible solutions: either we only put the nextclouds data on storage, or we put all microvms /var on storage. that way current and future vms would not bloat fannys root drive. But it would be important to make this configurable, maybe even on the host because microvms that run on hetzner need to mount the /var dir as it is right now (there is no /data dir).
Maybe for simplicity we just go with the first option for now and implement something more sophisticated later on.
What do you think about a wrapper module like
options.malobeo.microvm.nextcloudthat enables the necessary options like a (configurable) share?My idea is something like this
edddfc5e3fbut that doesn't work because of the imperative microvm workflow:This is actually a bit more complicated than expected. As you mentioned we cannot mix up declarative/imperative microvms. From the host side we cannot change the microvm shares at all. So a working approach would be add a share like that to all microvms (or only nextcloud for now):
And then on the host side we could just mount storage (or an extra dataset for that usecase) on
/var/lib/microvms/dataif we want. That way we can deploy microvms to any host we want, no matter if they have additional storage or not, and if they do just mount the storage to the data dir.Another, way more simple approach would be to just create a microvm dataset on the storage pool and mount that to
/var/lib/microvmson fanny. that way just all microvms data will live on storage without any changes neccesary to our vm implementations.When setting
malobeo.disks.encryption = false;(and setting reservation = 0G; but i think thats just cause my host has nearly no diskspace right now) iam able to run fanny withnix run .\#nixosConfigurations.fanny.config.system.build.vmWithDiskoand it looks good. Sadly the microvms fail to boot (due to vmvariant issues i think) but iam confident the virtiofs mount should work without testing.I think this can be merged.
I've tested the configuration but the data mount doesn't show up.
[malobeo@fanny:~]$ cat /nix/store/1wfvgdzxm3fxcxm6i8vlpdw012137rzv-durruti-virtiofsd-supervisord.conf