VM shutdowns: do not block the calls to the domains prematurely

[psafont]

I'm opening the PR to comment on this behaviour, since this should make possible to shutdown FreeBSD kernels.

The crux of the matter is that Just because a domain is not advertising it can shutdown cooperatively doesn't mean it can't at all. Doing it in any case would make it work with FreeBSD kernels, but I don't know whether this can break some expectations in xencenter about other guests.

[andyhhp]

The feature-$foo flags were added a decade after Xen support had found its way into various open source kernels.

While the presence of explicit =1 or =0 values in the feature flags does indicate a guest aware of the new scheme, the absence of features does not indicate that the guest is Xen-unaware.

[lindig]

I believe the commit should explain the semantics of the strict flag; what happens in both cases and what we are using now.

[psafont]

I can add an explanation to the strict mode in the call. I believe it's misnamed, the parameter enforces that the guest is actively advertising support for the feature using an appropriate xenstore key. This is not required by the spec, and it's not clear whether not enforcing could break windows guests, hence the PR being in draft.

[robhoes]

I guess the question is: what will happen if the VM is not capable of shutting down cleanly? I think xenopsd would wait 30 seconds for the shutdown request to be acknowledge, after which it would return a "failed to acknowledge shutdown request" error. This is in contrast to a clearer immediate error that says that the VM does not support clean shutdown.

This is also relevant for Windows VMs that have not (yet) had the agent installed. This PR would change the behaviour for this case. This is somewhat mitigated by the fact that the clean_shutdown feature would still not be advertised in the VM.allowed_operations field, even with this change.

[lindig]

To Rob's point: the problem exists for guests that don't explicitly advertise their capabilities. How many guests are in this category? Is this the case for Windows before the guest agent is installed? I do think a delayed failure when no explicit capability is announced (i.e. - it's best effort) is acceptable. I would agree that this could be a breaking change

[psafont]

How many guests are in this category?

FreeBSD is affected, this means netscaler.

I'll close it for now