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.
- Show ports as: Address: 0.0.0.0; Public port: 8088; Private port: 8088; Protocol: tcp (multiple lines if more than one set)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Implemented changes as follows (copied from ticket):
"I'd suggest the following use-ability/homogeneity fixes for the new container management tabs, if they are quick and easy:
Combine "Docker Version" and "Docker Information" on the VM-General-tab into "Container Management - Docker Status" with the following fields only:
API version
Version
Git Commit
Driver
Index Server Address
Execution Driver
IPv4 Forwarding
In the "Processes" tab, change the name from "Docker Processes" to "Container Processes"
In the "Details" tab, change the name from "Docker Detail" to "Container Details"
In the "Details" tab, drop the top level element "docker_inspect" (XML requires a single root-node, afaik the Windows form treenode does not), or alternatively open the root node by default and rename it to "Inspect Result"
In the "Details" tab, add the "Details"-headline in black on white - just like on the "Processes"-tab
Also, on the container's General tab, show Properties button disabled, instead on hiding it (to be consistent to other cases, e.g. disconnected servers)
"
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- Disable the Refresh button while a refresh is in progress.
- Introduced ExecuteContainerPluginAction - an action that stores the container it was called for, so that on completion we can decide whether to update the view or not (if the container displayed has changed, then we shouldn't update the view with the results from a previously selected container).
These changes apply to container Processes and Details tabs.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- also made Refresh buttons the same size on Details and Processes page and changed Details tab caption from "Detail" to "Details"
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Show a “Read Caching” section on the General Tab of a VM when the VM is running on a Cream or greater host
- When the Read Caching is enabled, the “Read Caching” section will contain two entries: Status and Disks (list of disks with RC enabled)
- When the Read Caching is disabled, the “Read Caching” section will contain two entries: Status and Reason
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Instead of calling the plugin on the UI thread, we call it through an action that we execute asynchronously and on completion update the UI.
- Pause the refresh timer on leaving the page and resume it when entering the page again.
- We do this for both Processes and Details page.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Showing all detailed information from a docker_inspect call
- The information refresh/polls every 20s while it's open
- Button “Refresh” add, so user can refresh the result. Also shows time when the last refresh happens.
- Add TabPageDetails as value 9903 in HelpManager.resx
Signed-off-by: Cheng Zhang <cheng.zhang@citrix.com>
This fixes the following issue: when displaying the General tab of a container, the Properties button is hidden, but not made visible again when switching to another object type (e.g. VM)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
1.Add ports and command in DockerContainer object
2.All labels in General box are internationalized.
3.Add UUID, command, ports in General box
4.Export DockerContainer in ICache
5.Modify tab title to "Container General Properties"
6.Remove properties button
Signed-off-by: Cheng Zhang <cheng.zhang@citrix.com>
The 'Updates' section on host's General tab displays which packs have been installed onto a host, including the version number
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- In the case that there are two hosts in a pool, one with GPU and one without, then the one without will display a text saying "There are no GPUs on this server".
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
New properties:
- Pool.HasGpu = Pool has at least one PGPU
- Pool.HasVGpu = Pool has at least one PGPU that HasVGpu
- PGPU.HasVGpu = PGPU has at least one supported_VGPU_type that is not pass-through
New or modified helper functions:
- Helpers.GpuCapability = GPU feature not restricted (by licensing) and Pool.HasGpu
- Helpers.VGpuCapability = vGPU feature not restricted (by licensing) and Pool.HasVGpu
- Helpers.ClearwaterSp1OrGreater = API version is 2.1 or greater
The GPU dialogs are displayed as follows:
- GPU page on VM properties dialog: Visible only if VM.CanHaveGpu and the GPU feature not restricted (by licensing)
- GPU page on New VM Wizard: Visible only if VM.CanHaveGpu and the pool has GPU capability (Helpers.GpuCapability)
- GPU page on Pool properties dialog: Visible only if the pool has vGPU capability (Helpers.VGpuCapability)
- GPU tab: Visible only if the pool has GPU capability (Helpers.GpuCapability) and is Clearwater SP1 or greater
- On the GPU tab, the "Placement policy" panel: Visible only if the pool has vGPU capability (Helpers.VGpuCapability)
- On the GPU tab, the "Edit" button on the "vGPU types" panel: Visible only if the PGPU.HasVGpu and vGPU feature not restricted (by licensing)
Also:
- VM.CanHaveVGpu function renamed to CanHaveGpu
- On the GPU tab, renamed "Allowed vGPU types" to "vGPU types
