[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] DispVM design decisions for Qubes 4.0
From:       Chris Laprise <tasket () openmailbox ! org>
Date:       2016-05-12 15:24:42
Message-ID: 5734A03A.4000205 () openmailbox ! org
[Download RAW message or body]

1. Probably the most manageable way is to have a boolean property for 
templatevms like 'Use local dispvm based on this template'. Then there 
is potentially just one dispvm per template. The default template would 
have this property always set, and other templates could be either 'on' 
or 'off'.

Other templates would have the property default to 'off', which means 
that derivative vms are using the 'global' dispvm derived from the 
default template until a user or admin changes this property in a given 
template.

For example, if I have template vms A, B and C with A the system 
default, then by default all vms will use a default dispvm generated 
from template A. Assuming I have appvms Aardvark, Bonobo and Cat 
(derived from templates A, B and C respectively) and turn on the 'Use 
local dispvm' property for template B, then the Bonobo appvm (and any 
other appvms dependent on B) will begin using a dispvm derived from B 
instead of A.

This arrangement has several advantages over a free-form assignment of 
dispvms to appvms:

    A. It keeps the amount of time waiting for dispvms to regenerate
    down to the same level we currently see, unless someone takes steps
    to change the settings.

    B. It also helps reduce confusion, because there are two very simple
    possibilities for a dispvm spawned by an appvm: One from the default
    template, or one from the appvm's own template.

    C. Dependency resolution while maintaining vms or restoring from
    backup is straightforward, requiring no additional user input.

Overall, I think this strikes a good balance between flexibility and 
complexity.

2. Just a bit more flexibility is called-for with networking... Allow 
the user to choose 'no networking' for dispvms, or make this the default 
_for_appvm_launched_dispvms_ and let users enable networking if they wish.

3. This is partly answered by my response in #2. I would prefer having 
dispvms launched from dom0 launcher to have networking, and dispvms 
spawned from appvms to not have it by default. There should also be a 
dom0 CLI utility to launch dispvms with a switch to disable networking.

Chris

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/5734A03A.4000205%40openmailbox.org. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]