Some tests do not apply, as there is no savefile and attributes
propagation is much simpler. Dropped tests:
- test_000_firewall_propagation
- test_001_firewall_propagation
- test_000_prepare_dvm
QubesOS/qubes-issues#2253
- fix assigning 'template' property - do not do it if VM already have it
set
- cap default maxmem at 4000, as we clamp it to 10*memory anyway (and
default memory is 400)
- DispVM is no longer a special case for storage
- Add missing 'rw=True' for volatile volume
- Handle storage initialization (copy&paste from AppVM)
- Clone properties from DispVM template
QubesOS/qubes-issues#2253
It is useful on some cases to prevent talking to hypervisor.
Warning - it may have sense only when action do not access any runtime
VM status. For example running the domain will fail, but changing its
properties should work.
Do not access vm.libvirt_domain after it being already removed - this
will redefine it again in libvirt, just to undefine it in a moment.
On the other hand, few lines below there is fallback libvirt cleanup, in
case of proper one not working.
Since "qubes: fix event framework", handlers from extensions looks the
same as from the VM class itself, so it isn't possible to order them
correctly. Specification says:
For each class first are called bound handlers (specified in class
definition), then handlers from extensions. Aside from above,
remaining order is undefined.
So, restore this property, which is later correctly used to order
handlers.
When properly set, applications will have a chance to automatically
detect HiDPI and act accordingly. This is the case for Fedora 23
template and GNOME apps (maybe even all built on top of GTK).
But for privacy reasons, don't provide real values, only some
approximate one. Give enough information to distinguish DPI above 150,
200 and 300. This is some compromise between privacy and HiDPI support.
QubesOS/qubes-issues#1951
This commit is migrated from gui-daemon repository
(dec462795d14a336bf27cc46948bbd592c307401).
Otherwise qvm-create-default-dvm may fail to include it in
saved-cows.tar, which will lead to DispVM being not really disposable.
FixesQubesOS/qubes-issues#2200
If it fails - for example because of too restrictive volatile.img
permissions, subsequent DispVM will not be really disposable.
The original permissions issue should be fixed by previous commit, this
one makes sure that such errors will not be ignored.
FixesQubesOS/qubes-issues#2200
This is no longer necessary since volatile.img is formated inside the
VM. This also fixes DispVM creation if the user sets a restrictive umask
for root. Maybe related to #2200.
