Having both default_netvm and default_fw_netvm cause a lot of confusion, because it isn't clear for the user which one is used when. Additionally changing provides_network property may also change netvm property, which may be unintended effect. This as a whole make it hard to: - cover all netvm-changing actions with policy for Admin API - cover all netvm-changing events (for example to apply the change to the running VM, or to check for netvm loops) As suggested by @qubesuser, kill the default_fw_netvm property and simplify the logic around it. Since we're past rc1, implement also migration logic. And add tests for said migration. Fixes QubesOS/qubes-issues#3247 |
||
|---|---|---|
| ci | ||
| contrib | ||
| doc | ||
| etc | ||
| linux | ||
| qubes | ||
| qubes-rpc | ||
| qubes-rpc-policy | ||
| qubespolicy | ||
| qvm-tools | ||
| relaxng | ||
| rpm_spec | ||
| templates | ||
| test-packages | ||
| tests | ||
| .coveragerc | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| installer.wxs | ||
| LICENSE | ||
| Makefile | ||
| Makefile.builder | ||
| README.md | ||
| run-tests | ||
| setup.cfg | ||
| setup.py | ||
| version | ||
Qubes core, version 3
This is master branch of the Qubes OS core.
API documentation is available: https://dev.qubes-os.org/projects/core-admin/en/latest/.