'qubesdb-read /qubes-vm-type' should not output 'DisposableVM'

[adrelanos]

Qubes OS version (e.g., R3.1):

R3.1

Affected TemplateVMs (e.g., fedora-23, if applicable):

Probably all.

---

Expected behavior:

qubesdb-read /qubes-vm-type should output either:
AppVM, ProxyVM, NetVM, TemplateVM'

Actual behavior:

qubesdb-read /qubes-vm-type does output either:
AppVM, ProxyVM, NetVM, TemplateVM, DisposableVM

Steps to reproduce the behavior:

Run qubesdb-read /qubes-vm-type in a DisposableVM.

General notes:

qubesdb-read /qubes-vm-type should not output DisposableVM. This is what qubesdb-read /qubes-vm-persistence is for, which outputs either full (TemplateVM or Standalone), rw-only (TemplateBasedVM) or none (DispVM). qubes-vm-type is being overloaded. There could be in future a disposable ProxyVM. At that point, there would be two ways to find out it's a disposable VM, but no way (using qubesdb-read) to find out it's a ProxyVM.

[marmarek]

This is for compatibility with configuration/scripts created before /qubes-vm-persistence was introduced. So, I'd call it a feature request, not a bug. For Qubes 3.2.

[marmarek]

And BTW - the case when it will be a problem with be possible only in Qubes 4.0 or later. Before that we don't support disposable ProxyVMs.

[marmarek]

In the future (Qubes 4.0), there will be no separate type ProxyVM or NetVM - it will be just VM property (provides_network). How it should be handled there? I guess possible values for qubes-vm-type reduces to AppVM and TemplateVM. Any better idea?

[andrewdavidwong]

I think @adrelanos was right to say that TemplateBasedVM is a more precise descriptor in this case. AppVM really just means "a VM which is meant for running apps." But that could be a TemplateBasedVM or a StandaloneVM, so it's ambiguous. By contrast, TemplateBasedVM unambiguously means "a VM based on a TemplateVM."

[marmarek]

TemplateBasedVM and StandaloneVM serve the same purpose - running apps. Differs only in persistence (rw-only vs full).

[marmarek]

This somehow diverge from class names in core scripts - where (in Qubes 4.0) the only think distinguishing classes is persistence, not purpose. There is TemplateVM, StandaloneVM, DisposableVM etc. Whether VM provides network to other VMs is just a property (provides_network). Also running as HVM is just a property (hvm).

[marmarek]

@adrelanos does it block any Whonix-related task? If not, I'd postpone it until Qubes 4.0, where VM types will be greatly simplified.

[adrelanos]

Marek Marczykowski-Górecki:

@adrelanos does it block any Whonix-related task? If not, I'd postpone it until Qubes 4.0, where VM types will be greatly simplified.

Qubes 4.0 is fine. (I was just forward thinking making a disposable
sys-whonix possible.)

[adrelanos]

Disp3030:

qubesdb-read /qubes-vm-type shows AppVM.
qubesdb-read /qubes-vm-persistence shows rw-only (#4007)
qubesdb-read /type shows DispVM.

whonix-ws-14-dvm:

qubesdb-read /qubes-vm-type shows AppVM.
qubesdb-read /qubes-vm-persistence shows rw-only
qubesdb-read /type shows AppVM.

Therefore we can consider this issue solved?