From: Michael Raskin <7c6f434c@mail.ru>
To: hi@alyssa.is, devel@spectrum-os.org
Cc: hi@alyssa.is, jpo@vt.edu
Subject: [spectrum-devel] [PATCH www] design: state subdirectories, not block devices
Date: Wed, 16 Oct 2019 23:33:05 +0200 [thread overview]
Message-ID: <E1iKqnl-0007wp-78.7c6f434c-mail-ru@smtp29.i.mail.ru> (raw)
In-Reply-To: <20191016202845.21132-1-hi@alyssa.is>
> Each virtual machine will be generated by
> a <a href="https://nixos.org/nix/">Nix</a> derivation, and will have a
> completely immutable root file system. Persistent storage will be
>-provided by virtual block devices, that arbitrary paths on the system
>-can be mapped to from the host. There may be other writable mount
>-points inside the virtual machine, but these will not persist between
>-reboots of the VM. Using Nix to generate virtual machines allows them
>-to be reproducibly built, rolled back, edited, and migrated as source
>-code, rather than large, opaque virtual machine images.
>+provided by mounting subdirectories of the global state directory into
>+virtual machines. There may be other writable mount points inside the
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.
>+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.
>+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?
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.
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.
next prev parent reply other threads:[~2019-10-16 21:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 20:28 Alyssa Ross
2019-10-16 21:33 ` Michael Raskin [this message]
2019-10-16 23:15 ` [spectrum-devel] " Alyssa Ross
2019-10-17 7:47 ` Michael Raskin
2019-10-17 11:36 ` Alyssa Ross
2019-10-17 12:09 ` Michael Raskin
2019-10-18 18:51 ` Alyssa Ross
2019-10-18 18:56 ` Alyssa Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1iKqnl-0007wp-78.7c6f434c-mail-ru@smtp29.i.mail.ru \
--to=7c6f434c@mail.ru \
--cc=devel@spectrum-os.org \
--cc=hi@alyssa.is \
--cc=jpo@vt.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).