Aspects of this have been discussed.
Based on what’s been said and what I’ve personally seen inside of the Qubes system, I don’t think there is any built-in way to switch to static networking for ProxyVM networking.
Xen network devices are simple point-to-point connections (no multi-node "internal networks" like in VirtualBox). It consists of two ends:
1. frontend - ethN interface in one VM
2. backend - vifX.N interface in other VM (X is VM Xen ID, N is the same as in frontend).
With HVMs, I was able to manually do static networking, but ProxyVM networking is a different animal, fundamentally based on dynamic networking.
Here’s how I understand it:
All VMs are given an underlying ID number by Xen.
Xen VM network interfaces connect through frontend/backend interfaces, which can either be an “eth” or “vif” inside the VM’s OS.
Qubes AppVMs use frontend eth interfaces that connect to ServiceVM/ProxyVM backend vif interfaces.
Qubes AppVM eth interfaces that are frontends to ServiceVMs/ProxyVMs are named: ethN (where N is the incremented interface). Typically just a single eth0 interface in AppVMs unless customized.
Qubes ServiceVM/ProxyVM vif interfaces that are backends to AppVMs are named: vifX.N (where X is Xen VM ID and N is same as ethN. Typically vif.0
Qubes ServiceVMs/ProxyVMs dynamically generate multiple vif interfaces as AppVMs boot up and connect to them.
Qubes ServiceVM/ProxyVM IP addresses are allocated as: 10.137..
Qubes AppVM IP addresses are allocated as: 10.137..
As an example layout:
netvm <-- firewallvm (ProxyVM): XENID=2, IP=10.137.1.3
| | <-- fedoravm (AppVM): XENID=5, IP=10.137.2.4, ProxyVM=vif5.0
| | <-- debianvm (AppVM): XENID=7, IP=10.137.2.5, ProxyVM=vif7.0
| | <-- othervm (AppVM): XENID=10, IP=10.137.2.6, ProxyVM=vif10.0
| <-- whonix-gateway (ProxyVM): XENID=15, IP=10.137.1.7, ProxyVM=vif15.0
| <-- whonix-workstation-1 (AppVM): XENID=21, IP=10.137.3.8, ProxyVM=vif21.0
| <-- whonix-workstation-2 (AppVM): XENID=24, IP=10.137.3.9, ProxyVM=vif24.0
| <-- whonix-workstation-3 (AppVM): XENID=32, IP=10.137.3.10, ProxyVM=vif32.0
One can observe the real-time allocation of “vif” interfaces between ProxyVMs and AppVMs inside their respective VM terminals with “sudo ifconfig”.
So everything seems inherently dynamic in the native ProxyVM + AppVM networking architecture of Qubes.
The Qubes VM Manager GUI is able to create and destroy multiple ProxyVMs and AppVMs on demand, so the networking architecture is dynamic along with this.
The IP and backend portion is done in dom0 by the Qubes system, so attempting to force static networking upon Qubes would likely:
a) Require modifying the underlying Qubes system in dom0, which is not user friendly.
b) Break the intended fluid GUI-based dynamic creation and removal of ProxyVMs and AppVMs, which is not user friendly, and a big reason for going beyond our current HVM setup.