- Added check for Clearwater SP1 or greater to the gpu capability on the New VM wizard
- On the GPU tab, draw the grid on the shiny bar only if the capacity is greater than one
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Changes following code review:
- Added VM.CanHaveVGpu function (at the moment just returns CanHaveGpu, but it will change in the future)
- Added vGPU_type.IsPassthrough function and used it everywhere we needed to test for passthrough (max-heads==0)
- Simplified code in Helpers.GpuCapability, Helpers.VGpuCapability, NewVMWizard (gpuCapability), MainWindow and GpuRow
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
Correction following code review: When a host collection changes, update all rows containing the hosts changed. This will cover the case when the License Manager shows all members of a pool on separate rows for pre-6.2 versions of XenServer.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
The problem was that the License Manager was listening to PropertyChanged events on the master only, not on slaves.
When the master's properties change (e.g. edition) we update the row in the license manager; but in some cases a slave (or more) hasn't been updated yet (as it may be updated in another event.from) and we think that the pool is partially updated.
Our solution is to listen to Host BatchCollectionChanged event, which is triggered once per cache update for the host collection (it any property changed for any of the hosts).
The sleep in the ApplyLicenseEditionAction is not needed anymore, nor is the extra call to update the cell after the action is completed, because the cell is getting updated correctly on the BatchCollectionChanged event.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
The Free license never expires and is confusing to see "Unlicensed" or "Unsupported" hosts with expiry date "Never".
Added the ability to add "hidden" entries to the General tab sections and to update their visibility when needed without regenerating the whole section.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Changes to the License Manager dialog:
- Summary panel: show smaller icons for warning and information messages
- Summary panel: show license entitlements for all Creedence hosts (not eligible for support, eligible for support, enterprise features enabled, etc)
- for free Creedence or Clearwater hosts, the license status is Free (it used to be Expired for ClearwaterOrGreater)
and the text displayed is "Unlicensed" for Creedence and "Unsupported" for Clearwater;
the warning message is "Not eligible for support" (instead of "Your support and maintenance has expired")
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
In some cases calling Control.Invoke() from a background thread causes that thread to go in a "sleep, wait, or join" mode, while waiting for Invoke to happen, although the UI thread is running normally.
If the Control is the MainWindow, it works as expected, but we've seen it happening while connecting or disconnecting from a large pool, on calling Invoke on controls like NavigationView, AlertSummaryPage, HistoryPage, etc.
To fix this, we call the Invoke on the MainWindow in all the places where we've seen the issue.
With this changes, the previous fix for CA-148245 (call RequestRefreshTreeView on CacheClearing event) is not needed anymore, so I removed that call.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
