The check DundeeOrGreater always returns true since we disallow connection to anything earlier than Havana.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Adding a disk on local SR to an HA protected VM was crashing.
- The user could not plug the disk to the VM even after providing credentials on the role elevation dialog.
- The user had to enter credentials for each of the sub-actions involved in adding a disk.
Signed-off-by: Konstantina Chremmou <Konstantina.Chremmou@cloud.com>
* Tidy up `SelectMultipleVMDestinationPage.cs`
* CA-375532 & CA-336510: Add warning when importing VMs with too many vCPUs
* CA-375532 & CA-336510: Prevent users from starting appliance if a VM has too many vCPUs
* Tidy up `Page_CpuMem`: use expression-bodied properties
* Tidy up `Page_CpuMem`: use conventional naming scheme
* Tidy up `Page_CpuMem`: use explicit modifiers
* Tidy up `Page_CpuMem`: use `en-US` locale for names
* Tidy up `Page_CpuMem`: use `var` when possible
* Tidy up `Page_CpuMem`: rename `Vcpus` to `VCpus`
* Tidy up `Page_CpuMem`: reorder elements
* Tidy up `Page_CpuMem`: revert class renaming and fix `vCpus` typos
* CA-375532: Prevent users from starting VM if they select too many vCPUs
* Tidy up `Page_Finish`: use expression-bodied properties
* Tidy up `Page_Finish`: fix typo
* Tidy up `Page_CpuMem`: rename `CanStartVM` to `CanStartVm`
* Remove unnecessary using directives
* Anchor warning icon to the top-left corner of its parent
* CA-375532 & CA-336510: Warn users when selecting more vCPUs than pCPUs in the Properties page
* CP-41825: Add warning for imported VMs with > 32 vCPUs
* CP-41825: Add warning for new VMs with > 32 vCPUs
* CP-41825: Add warning for existing VMs when selecting > 32 vCPUs
* CP-41825: Update wording used to alert users running VMs with > 32vCPUs
* Remove unused local variable in `VappStartCommand.cs`
* Reword some vCPUs messages
* Simplify assignment of `CanStartImmediately` in `Page_Finish.cs`
* Simplify assignment of `CanStartVmsAutomatically` in `ImportFinishPage.cs`
* Remove useless `Count` check in `VappStartCommand`
* Rename `pictureBox1` to `warningPictureBox` and change its `SizeMode`
* Separate CPU and memory warnings in `Page_CpuMem`
* Shorten warning messages shown in `Page_CpuMem`
* Disable option to start VM when memory configuration isn't valid
* Report number of vCPUs and pCPUs when showing warning in New VM wizard
* Tidy up `CpuMemoryEditPage`: rename elements
* Tidy up `CpuMemoryEditPage`: use explicity modifiers
* Tidy up `CpuMemoryEditPage`: Rename `CPUMemoryEditPage` to `CpuMemoryEditPage`
* Tidy up `CpuMemoryEditPage`: Miscellaneous renames and improvements
* Tidy up `CpuMemoryEditPage`: Fix whitespace
* Tidy up `CpuMemoryEditPage`: Use ReSharper code formatter
* Tidy up `CpuMemoryEditPage`: Move events to own region
* Tidy up `CpuMemoryEditPage`: Move `IEditPage` members to own region
* Tidy up `CpuMemoryEditPage`: Order members outside of regions
* Replace topology and vCPU warning labels with structured warnings
* Ensure warnings ends with a dot
* Allow multiple CPU warnings to show at the same time
* Remove warning link for vCPUS > pCPUS Option is not achievable
* Enable option to force unit used in `MemorySpinner`
* Replace `NumericUpDown` with `MemorySpinner` and show warnings at bottom of control
* Check destination pCPUs count when destination is not a pool
* Do not disable option to start VMs after import if user selects a shared SR
* Add memory warning when importing appliance with too much memory
* Sort vCPUs and memory warning strings
* Remove target from `ImportWizard`'s summary
Target is not useful and can cause confusion as appliance VMs could start on non-target hosts
* The home server is needed in the summary when importing XVA. The target server is not needed in the summary when migrating a VM.
* Update warnings when the server selection changes. Corrected memory calculation.
* Show all warnings for vCPUs. Moved topology warning to the bottom. Separated methods for showing memory and vCPU warnings.
* Removed the memory setting from the VM Properties dialog. Split running VM info to a separate panel.
* Corrections to the logic for starting the VM automatically. Also, Fixed a bit the layout of the Finish page to make better use of the available space.
* Corrections as per code review.
Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
Co-authored-by: Konstantina Chremmou <Konstantina.Chremmou@cloud.com>
* Prevent `long` overflow when VM has a very large amount of memory. Resulted in XenCenter hanging with a significant memory leak.
* Remove unused `label` parameter from `LabelShouldBeShown`
* Use `double` for increment variable when calculating increments in `ShinyBar`
* Use `Debug.Assert` call to avoid issues with `DrawGrid` in `ShinyBar`
Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
RBAC check sometimes runs after the action that is being checked. This results in the status bar being cleared if the RBAC check passes.
Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
When an instance of XenCenter is already running, the installer shows the `MsiRMFilesInUse` fragment. Pressing OK within that fragment with the `WixUIRMOption` property set to `UseRM` means that the `RMShutdownAndRestart` event kicks in at the end of the installation.
This happens at the same time as the existing "Launch XenCenter" event (if the matching checkbox is checked), causing in the executable being started twice at about the same time. My guess is that the pipe system is not initialised at that point, and that's how we get two applications.
To avoid this, this commit adds a new custom property: `XS_WixUIRMPressedOk`. This is set to `1` when the user clicks OK on the `WixUIRMOption`. It allows us to know whether or not that dialog was shown at all, as checking `WixUIRMOption` is not possible (it's already set to `UseRM` by default). By checking the value of this property we prevent the "Launch XenCenter" option to be shown if `MsiRMFilesInUse` was shown to the user (and they clicked OK). This applies both in case of a repair and an upgrade from a previous version.
Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
