* 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>
Also, merged the methods calculating the virtualisation status and its friendly
string so as to simplify the logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
Override the polymorphic methods of XenTabPage on the ballooning wizard;
No need to exposed the memory values outside the VMMemoryControlsEdit class.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
property to the derived classes (they don't share much of it anyway) and the method
CalcMemoryUsed to the VMShinyBar class where it is needed. Also made the latter's
property Increment non-browsable.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
setting controls. Also removed the various types of ballooning dialogs since
the only thing changing was the contained memory settings control.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
prevent them from being serialised alongside the API properties. This will also
be useful for moving the API bindings out of XenModel.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Added Control Domain memory entry in the host memory control on Memory tab.
- Control domain memory is editable for Ely and greater hosts.
- Can be changed from a dialog that requires host to be in maintenance mode and triggers a host reboot after the memory is changed.
- This dialog is available from Server main menu and from the host memory tab.
- Also removed unused unit controls on host and VM memory bars.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Extended the enum, aimed for minimal changes, also using Flags on the enum now
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- Memory Tab uses GB units for values greater or equal to 1 GB, otherwise show in MB;
- Search Tab displays values in GB or MB in the same as the Memory Tab (e.g. 512 MB of 1 GB, 256 MB of 512 MB, 2.5 GB of 16 GB).
- The shiny bar present in the Memory Tab and in Memory Settings dialog shows the scaling in the following way: If smaller than 1 GB, then show as before, else show only labels with values multiples of half a GB.
- The units used in Memory Setting Dialog are set depending on the static_max. If it is greater or equal to 1 GB, then the units are GB, else MB. The user does not have the possibility of changing them.
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.
