- Changes to the the layout: order of radio buttons, removed group box around the manual setting of shadow multiplier;
- Shadow multiplier edit box no longer disabled when "Optimize manually" not checked
- Also changed the wording on the Name page of the new VM wizard
1. Check the Xenserver platform version and display the host disk read/write
threshold and metric weighting for Dundee or later XenServer.
2. Update the metric weighting page to make it autosize-able.
Signed-off-by: Hui Zhang <hui.zhang@citrix.com>
Dom0 memory alerts have to be configured in the other_config of the control domain (dom0) and not of the the host. This changeset implements this exception.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Creates a new function MemorySizeStringSuitableUnits that takes one more parameter that specifies the units that must be used when the number of bytes is 0.
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.
