the spinner with the surrounding controls on a parent control/form.
Also, removed the icon from the spinner because in the
majority of implementations it was invisible and the extra space was just
complicating the alignment of the surrounding controls.
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>
- The value of the spinner control is rounded to the nearest, while the minimum is rounded up and the maximum down (or, in some cases, min and max are not rounded at all).
In most cases this is fine, but if the current value (in bytes) is equal to one of these ranges, by rounding this way we might end up with a value that is outside of the control's ranges (causing ArgumentOutOfRange exception).
Signed-off-by: Mihaela Stoica <mihaela.stoica@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>
Now we set Increment exactly as on other pages
when the unit is MB: the increment it will be calculated dynamically (1, 2, 4,...)
when GB, increment will be 1 GB for values >=10GB, 0.1GB otherwise
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Removed PV_DRIVERS_NOT_INSTALLED=0 from the VirtualisationStatus [Flags]enum - 0 will mean the same (to avoid bugs with enum.HasFlag(0) is always true)
Extracted common code to VMLifeCycleCommand.GetCantExecuteNoToolsOrDriversReasonCore() method (instead of defining overridden GetCantExecuteReasonCore() method at this level, because not all child classes need this...)
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Removed Optimized state and using I/O & Management instead (even for old VMs)
Changed messages to be different for old and new VMs instead of saying Tools or I/O drivers for instance
Removed the extra enum property from the VM class that had been added for search
Fixed code in GroupingTypes class (possible KeyNotFoundException)
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@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.
