on a background thread and show a spinner while this is going on. Also: run this
check only the first time the page is loaded; some refactoring, namely simplified
the code scanning for SRs by reducing the number of things each method does;
fixed column widths; removed unused property.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
Also changed the page to use different resource strings for the Storage type in the right hand panel (no hotkeys should be shown there)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Re-position the version radio-buttons, so that is clear that the selected version applies to both Create and Reattach
- Pass the selected version to the attach command in the device_config parameter
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Adds tab indexing to the control for allocation and changes label names.
Corrects mistake that led to exception being thrown when the Disk Size is decreased in the the New Disk Dialog.
- Thick provisioning - > Fully provisioned
- Subsequent allocations -> Incremental allocations
Also, updated the Next button on the Location page of HBA SR, to say "Next" for Dundee or greater and "Create" for pre-Dundee pools.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- show new NIC column on the Location page (visible for FCoE only)
- display the summary page
- resource strings for default SR name and the blurb on the first page in the wizard
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
-Changed code, because API needs 0-100 percent values as 0..1
-Code for HBA SRs
-Changed free space check for new VDIs to condider initial disk size only
when the SR is thin provisioned
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.
