hidden and in all other cases it was set by the implementing control, i.e.
the label was not reusable, hence no reason to have it in the control and risk
layout issues. This means that the SrPicker does not need to be a control
encapsulating a CustomTreeVIew, but simply derive from the latter.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Allow move of multiple VDIs
- CA-187659: show better messages when batching move/migration of multiple VDIs.
- Show different tooltips for single vs. multiple VDI move/migration/deletion.
- Refactored the MoveDiskDdialog. Removed the inherited class VDIMigrateDialog and
the batching manager as it was not very different from its parent, it was registering
the events twice, and was batching migration of even single VDIs.
- Tidied up the Move- and MigrateVirtualDisk commands so they're easier to compare.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- when the user changes the disk size (or initial allocation), the selection in the SR list should not change and the list should not be automatically resorted
- users should not be allowed to create disks larger than the SR size (the SR is disabled and an explicit reason is displayed)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Add New Virtual Page (VDI):
By default, the SR's default initial size allocation percentage (that may be different for different SRs) is used.
Once the user has changed the initial allocation rate, the page would only use the custom value from that point.
New SR Wizard:
Minimal change in if statement and added comment in RunNextPagePrecheck
method for LvmoHba.
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.
