Disposable service VMs in 4.0rc1

瀏覽次數:114 次
跳到第一則未讀訊息

David Hobach

未讀,
2017年10月13日 上午8:24:122017/10/13
收件者:qubes-users
Hi all,

did anyone test disposable VMs for sys-net, sys-firewall and sys-usb in
4.0rc1 yet?

Especially since the installed defaults appear to be non-disposable if I
recall correctly.

According to [1] this is meant to be working though for at least sys-net
& sys-usb. It doesn't say anything about sys-firewall, i.e. I'm not so
sure whether that will break some Qubes core mechanics...

I'm also curious whether starting a VM with a dependency to a stopped
dvm-template will start a dvm or the template itself? What about VM
autostart during boot?

KR
David

[1] https://blog.invisiblethings.org/2017/10/03/core3.html
"This provides lots of flexibility, e.g. it’s easy to create a
customized DispVM for signing PDF documents, or various disposable
service VMs, such as Net- and VPN- VMs. One just creates a normal AppVM,
sets everything up there, e.g. loads keys, configures VPNs, connects to
known WiFi networks, and then shuts down the AppVM and in place of it
starts a DispVM based on that AppVM."

David Hobach

未讀,
2017年10月13日 上午8:49:032017/10/13
收件者:qubes-users
On 10/13/2017 02:24 PM, David Hobach wrote:
> Hi all,
>
> did anyone test disposable VMs for sys-net, sys-firewall and sys-usb in
> 4.0rc1 yet?
>
> Especially since the installed defaults appear to be non-disposable if I
> recall correctly.
>
> According to [1] this is meant to be working though for at least sys-net
> & sys-usb. It doesn't say anything about sys-firewall, i.e. I'm not so
> sure whether that will break some Qubes core mechanics...

Plus what happens with your network card when you start the second
instance of a sys-net dvm?

Marek Marczykowski-Górecki

未讀,
2017年10月13日 上午9:27:232017/10/13
收件者:David Hobach、qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Oct 13, 2017 at 02:48:59PM +0200, David Hobach wrote:
> On 10/13/2017 02:24 PM, David Hobach wrote:
> > Hi all,
> >
> > did anyone test disposable VMs for sys-net, sys-firewall and sys-usb in
> > 4.0rc1 yet?
> >
> > Especially since the installed defaults appear to be non-disposable if I
> > recall correctly.
> >
> > According to [1] this is meant to be working though for at least sys-net
> > & sys-usb. It doesn't say anything about sys-firewall, i.e. I'm not so
> > sure whether that will break some Qubes core mechanics...

This should work, but of course all changes in made directly there will
be lost after restart. So, for example setting wifi password using
network manager. This is one of the reasons why default setup still use
non-disposable VMs there.

> Plus what happens with your network card when you start the second instance
> of a sys-net dvm?

The second instance will not start. The point is in Qubes 4.0 you can
create DisposableVM, which have no persistent data (like private.img or
root.img), but is persistent in terms of metadata (name, devices etc).

> > I'm also curious whether starting a VM with a dependency to a stopped
> > dvm-template will start a dvm or the template itself? What about VM
> > autostart during boot?

This all should work like with any other VM. The only difference is that
VM restart revert VM data to the original state.

I haven't tried exactly this configuration, but it should be something
like this:

# allow to create DispVMs based on sys-net; you can also use other VM
# here, like fedora-25-dvm
qvm-prefs sys-net template_for_dispvms true

# create disposable netvm; all properties will be inherited from
# sys-net (including 'autostart', 'provides_network' etc)
qvm-create --class DispVM --template sys-net -l red disp-sys-net

# detach network devices from sys-net and attach to disp-sys-net
qvm-pci del sys-net dom0:02_00.0
qvm-pci add disp-sys-net dom0:02_00.0

# and set disp-sys-net as netvm, wherever you want
qvm-prefs sys-firewall netvm disp-sys-net


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZ3y3iAAoJENuP0xzK19csjlYIAIAZ42rTS8pQucjPCGRKdqx0
zq0TeDpFnbprfVhWKhjqpunwcycTYh+iNe/RaDUBF6gp07J2E6PKu1OYWGBLPuXx
pdh8LDXu9rldNkRAlc+oeFacnH6cK5lo46qwr90uD59SfXaJ36eTMJavwnHqDbE+
gvxJ3YzbtEM3NMl+IT4zm7jLMD78KG9LyttlWusibElEGPj0EL/+AKg74QzzI+qw
DPa5+uaBpEfjPKg6C9XVXgGri7CuqKrSQsZ0XmHL6F36ardMjLKztP1fJhyL426w
8Nfs3wvfyac+zOXezMEV4bP6TwdF9EeTUnjTJ1VI5kyPZLaRJsQDQEnN65l4Jb0=
=Am1Y
-----END PGP SIGNATURE-----

David Hobach

未讀,
2017年10月13日 下午3:06:162017/10/13
收件者:Marek Marczykowski-Górecki、qubes-users
On 10/13/2017 03:27 PM, Marek Marczykowski-Górecki wrote:
> On Fri, Oct 13, 2017 at 02:48:59PM +0200, David Hobach wrote:
>> On 10/13/2017 02:24 PM, David Hobach wrote:
> The second instance will not start. The point is in Qubes 4.0 you can
> create DisposableVM, which have no persistent data (like private.img or
> root.img), but is persistent in terms of metadata (name, devices etc).
>
>>> I'm also curious whether starting a VM with a dependency to a stopped
>>> dvm-template will start a dvm or the template itself? What about VM
>>> autostart during boot?
>
> This all should work like with any other VM. The only difference is that
> VM restart revert VM data to the original state.
>
> I haven't tried exactly this configuration, but it should be something
> like this:
>
> # allow to create DispVMs based on sys-net; you can also use other VM
> # here, like fedora-25-dvm
> qvm-prefs sys-net template_for_dispvms true
>
> # create disposable netvm; all properties will be inherited from
> # sys-net (including 'autostart', 'provides_network' etc)
> qvm-create --class DispVM --template sys-net -l red disp-sys-net
>
> # detach network devices from sys-net and attach to disp-sys-net
> qvm-pci del sys-net dom0:02_00.0
> qvm-pci add disp-sys-net dom0:02_00.0
>
> # and set disp-sys-net as netvm, wherever you want
> qvm-prefs sys-firewall netvm disp-sys-net

Thanks for the explanations!

So basically with 4.0rc1 uniquely named & single instance dispVMs were
introduced. That's awesome & quite some news by itself, thanks!

At first sight I hadn't noticed it as the term dispVM may refer to
generic dispVM instances disp[XYZ] or their templates as well.

回覆所有人
回覆作者
轉寄
0 則新訊息