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>
Removed Optimized state and using I/O & Management instead (even for old VMs)
Changed messages to be different for old and new VMs instead of saying Tools or I/O drivers for instance
Removed the extra enum property from the VM class that had been added for search
Fixed code in GroupingTypes class (possible KeyNotFoundException)
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>
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.
Created ThinProvisioningParametersControl user control using existing code to have the thin provisioning settings at one place. It needs to be initialized by providing an SR and it will expose its internal state via NewSMConfig property that we need at other places.
This does not include refactoring of existing code or replacing existing code to use this new control, but the new Conversion dialog is using this. Next step would be to remove existing code and start using this new ThinProvisioningParametersControl instead.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- 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.
The unit of VBD IO throughput is changed to MiB after merged all
VBD related data sources from xcp-rrdd to rrdp-iostat,
Signed-off-by: Kaifeng Zhu <kaifeng.zhu@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.
- add the option on the destination page of the wizard
- for authentication purposes, MyCitrix credentials are required.
- these credentials are only used to obtain an upload token that will be used for the upload.
- the upload token expires in 24 hours and is not saved in the xapi database.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Check call home enrollment status on connecting to a pool: If status is unknown it means that the pool is not enrolled (enabled) and has never been (disabled). If that's the case, then show the Health Check Overview dialog with the pool selected
- "Enroll now" on Health Check Overview will try enroll the selected pool into call home using existing token authentication. If this is not possible, then a dialog will be presented for the user to perform the initial authentication.
Using ShowDialog() instead of Show()
Also removed unnecessary code that displayed the popup again
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.
- 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
