* Tidy up `VM` extension: use `var`
* Tidy up `VM` extension: remove redundant initialisers
* Tidy up `VM` extension: use type keywords when possible
* Tidy up `VM` extension: merge conditional expressions
* Tidy up `VM` extension: remove redundant qualifiers
* Tidy up `VM` extension: remove redundant type arguments
* Tidy up `VM` extension: remove redundant `else`s and parentheses
* Tidy up `VM` extension: fix naming
* Tidy up `VM` extension: misc changes
* Tidy up `VM` extension: use `null` propagation
* Tidy up `VM` extension: fix whitespace
* Tidy up `VM` extension: apply ReSharper Code Cleanup utility
* Tidy up `VM` extension: Fix naming of private string array
* CP-44767: Ignore VM restriction when fetching `MaxVCPUsAllowed`
Instead, fetch the highest available value in all templates for the host.
This means that VMs imported from vhd won't automatically default to `DEFAULT_NUM_VCPUS_ALLOWED`, and that VMs that have been kept across XenServer upgrades won't be limited to the number of vCPUs in their own (possibly outdated) restrictions
* CP-44766: Use value in template with a matching `reference_label` when checking VM restrictions
* Move restriction getters to own region
* CP-44766: Use matching templates to fetch VM restrictions
- Rewrite `GetRestrictions...` methods to perform simpler operations
- Add `GetIntRestrictionValue` and `GetBoolRestrictionValue` wrappers to `GetRestrictionValueFromMatchingTemplate`
- Now all calls to a restrictions first check the template value, with a fall-back to defaults
* CP-44765: Export `reference-label` when generating OVFs
---------
Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
This is caused by the `waitingNtolUpdate.waitOne()` call being at the end of the loop, not the beginning. The reason is that the `waitingNtolUpdate` is set during the first iteration (before the thread even gets loaded) - because the setter for Settings in this file sets it (and that's set by the setter for AssignPriorites.Connection, which is set in the HAWizard constructor). So when the thread first spawns we do the calculations, then get to the `waitOne` lock, which is set so we go back around the loop and calculate everything again before returning to the lock and waiting to be triggered. The correct behaviour is to trigger only once on the page load, and then only when re-triggered. To achieve that I've moved the `waitOne` call to the beginning of the loop, so that (assuming the `waitingNtolUpdate` lock is set before the thread is first started) we immediately run the calculations and then stop at the beginning of the loop waiting to be triggered again. This means that on page load (and after each re-trigger) we only calculate once.
The assumption that the lock is set before the thread is triggered is currently valid, because as mentioned above it's currently set by the setter for Settings which is indirectly called by the wizard constructor. I don't want to rely on that behaviour though because it's very indirect, so just to be safe I've added an explicit set just before the thread is triggered so that it's guaranteed to run the calculations the first time. This isn't strictly necessary but seems better than relying on the existing implicit setting. Since we use the same mechanism just in a different place, all the existing code that sets `waitingNtolUpdate` continues to trigger this thread as expected.
We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.
The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).
This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
