Extend dependency checking facilities

[RandyTheOtter]

Regarding QubesOS/qubes-issues#10860

As far as I can tell #469 fixes it on shutdown by retrying as many times as there are used vms, and it should be faster than vm_dependencies. I'm not sure how good that approach is from the design perspective considering that it handles all these errors and logs a lot.

My idea here is instead set up a facility for checking domain sets and use force on independent sets. I also plan to make vm_dependencies more efficient by creating necessary api for accessing e.g. qubes.vm.mix.net.NetVMMixin.connected_vms, but before any of that or proceeding with integration of this change I would like to show and receive feedback.

[RandyTheOtter]

Although code review is appreciated, could you please assess sanity of the idea? For now this is my main concern.

[ben-grande]

We cannot guarantee that the client is 100% certain of the state, the dependencies check on the client is more like a promise. If someone adds a new extension on the server that handles domain-pre-shutdown, the check on the client will not be able to know. One alternative is adapating the client's vm_depenencies, another alternative is asking the server for dependencies as you mentioned on the first post.

I don't think I have enough knowledge to tell you which way is right. I am not sure. QubesOS/qubes-issues#10860 (comment).

[RandyTheOtter]

Good point. I also realize that even if the server does the checking there is no mechanism to prevent race conditions between the original client acting on the result and another client changing a dependency.

Am I overthinking this?

[marmarek]

While some of the functions you changed might be useful (at least in theory), overall I don't like the idea. As Ben said, it duplicates the dependency check, but without full information and in an inherently racy way. Furthermore, with management qube (admin qube?) there may even be some more qubes that it doesn't see but have relevant dependencies.

Shutdown is handled by retry, which may indeed result in extra log lines, but does result in consistent result. Theoretically it may retry up to number of qubes, but in practice it's up to the longest dependency chain length (so, usually something like 2 or 3).

As for qvm-start, the backend actually starts needed qubes automatically, and the issue you hit isn't about missing dependencies, but failing due to qube already runinng. This could very well happen also if you run two qvm-start in parallel, and there is an option to not consider it a failure: qvm-start --skip-if-running.