[spectrum-devel] Re: [PATCH www] design: state subdirectories, not block devices

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

Michael Raskin <7c6f434c@mail.ru> writes:

> I guess in the eventual design we want VM-in-jail, i.e. the VM process
> itself (and the corresponding FS daemon, if separate from the VM) should
> not have any access to the resources not intended for the application.

Yes.  Layers are good.

>>+State directories and applications will be <var>m</var>:<var>n</var>.
>
> Note (probably not affecting the design right now): this can also be
> a source of annoyance with running everything under unique single-use
> UIDs: to have multiple UIDs access the same resource, setting ACLs is
> a natural idea. It works well, but might require some cleanup of 
> obsolete ACLs for a workflow with a large churn of instances ??? the 
> maximum length of an ACL is limited.

Yeah, we'll need something like that.  ACLs sound sensible.

>>+Some virtual machines may have no persistent storage, or even write
>>+access to a disk, at all.  In other cases, it might be desirable for
>>+multiple applications to be able to access the same device, such as a
>>+local mail store being shared by two mail clients.  Other resources
>>+and permissions, such as network cards and USB controllers, will
>>+similarly be defined in Nix.  There are three logical sections for the
>>+Nix configuration -- applications, which are just packages, resources
>> (virtual or physical devices), and <i>application instances</i>, which
>> are mappings between applications and accessible resources.  This
>> structure allows users to have multiple instances of the same
>
> Given that it is sometimes convenient to spawn multiple VMs with almost 
> identical settings on the fly (e.g. Firefox instances but with different
> state directories for downloads/uploads), should we commit to define
> a CLI layer for starting VMs (probably similar to the underlying VMM
> software CLI, but adapted to the notions we want to use), with the 
> Nix-based management of VM fleet built on top of this CLI?

Yeah, I've been thinking about this too and agree.  We should have a nix
run analogue for temporary VMs.  It would be nice for scripts that use
multiple VMs to be able to start them on the fly as well.  (But we
should definitely not have a nix-env -i analogue, because there should
be no hidden state on a host.)>

> I suspect that building things the other way round is not much simpler,
> but building a single VM image usable with slightly different settings
> will have smaller overhead than evaluating a Nix expression for each
> extra VM.

Maybe.  I'll have to think more about that.  tbh I think we can assume
that the evaluator will get faster at some point (because there's big
potential for optimisations and caching in safe mode).  It might be nice
to invent yet another way to do options, and just keep that in Nix.  But
I could be swayed either way.

> I guess it didn't make any difference in the previous design version
> where the maximum goal was a VM per application, not per application
> instance. It does matter now.

Just to clarify, this was always the goal -- I just wrote the wrong
thing when I was banging out the website initially.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]