- display the Provisioning entries in the General Tab only for iSCSI and LVM SRs
- also changed the checks in the ConvertToThinSRCommand to use SR.IsThinProvisioned property instead of SR.Provisioning
Signed-off-by: Mihaela Stoica <mihaela.stoica@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>
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>
- Not applied updates do not appear anymore in the General Tab of a pool. (Related to CA-180577)
- If we apply a patch that was already applied (happens when we take a file from disk that is not in the updates list taken from the Citrix website -> no metadata), on cancel we are now removing the uploaded patch from the host.
- 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.
Improves the centering of the warning messages in the Updates Tab, making the picture align with the text.
Corrects bug related to the visibility of the warning about automatic checks for updates.
CA-157785: Hotfix wizard forgets which servers should be greyed out.
When clicking Download and Install update in the Updates Tab, instead of opening a new dialog, it opens the Updates Wizard on the Select Servers Page and download the file in the Upload Page.
Fixes issue regarding the upload of the update every time that the user gets to Upload Page. Now it only uploads it if it has not been uploaded before.
Fixes issue regarding the download of the update every time the user goes back to the Select Patch Page. If the user goes back, but does not change the choice of the update, the download will not be done again.
- Added "FCoE Capable" column, showing FCoE capability as Yes/No values in the NICs grid
- This column is only visible for Dundee or higher hosts
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Added this information on the VM's general tab, and it could be one of the following:
- Operating mode: Paravirtualized (PV)
- Operating mode: Fully virtualized (HVM)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Fixed the bug by subscribing to events of all actions and not only to the
ones that are displayed in the grid.
Besides this, the visibility of the row is being used instead of removing and
re-adding rows on status changes.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
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.
