* CA-257574: Manage vApps dialog is unusable with a vApp containing a large number of VMs
- In the VMAppliancesDialog, change event handlers to reduce the number of refreshes when something changes: only reload the appliances when the VM_appliance collection change; if a relevant property is changed (in VM_appliance or VM), then update only the affected rows.
- Improve the way we assign VMs to a group (AssignVMsToVMApplianceAction and AssignVMsToPolicyAction): only update the VMs that really changed.
- Also improve the way we update the VM startup options and HA restart priorities on a set of VMs
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* CA-257574: Manage vApps dialog is unusable with a vApp containing a large number of VMs: changes following code review
- reverted the changes to the AssignVMsToGroup actions that added the additional constructor
- changed the AssignVMsToGroup actions to calculate the set difference between two lists more efficiently
- added code to deregister PropertyChanged events on VM_appliances
- removed getCurrentSettings() method as it is not needed, GetChangedSettings can be used in all cases
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- Ensure that the disk-space plugin functions are not called on Ely or greater hosts, except for the 'get_avail_host_disk_space' function, which is still needed
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Due to a regression (introduced by [1]), XenCenter will not run delayed actions in the correct host-order at all times. This can cause the master to be not the first host to be rebooted what may result in connections being lost to slaves should the API change between restarts/updates in a way that it would not be compatible to the previous version. This would make the wizard fail and users would have to restart their master host manually to make it connect to its slaves again.
This commit fixes the order of the hosts when executing the delayed actions.
[1]: 15827512e1
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- removed unused methods and properties from the NewPolicyWizard class
- made the wizard pages private in the NewPolicyWizard class
- removed unused constructor from the NewPolicySnapshotTypePage class
- removed unused property from the PolicyHistory class
- removed the public properties TreeView and DataGridView from the SnapshotsPage
- removed the PolicyType from the PolicyAlert class and the constructor that is no longer used
- removed unused property from the VMSS class
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
In rare cases, the GetMaster could return null, causing the update progress to fail with "Pool_patch or Pool_update not found". (when the Cache hasn't been populated by the execution gets here)
This commit drops GetMaster and uses a pre-saved masterUuid instead of waiting for the Cache what would be the other way to solve this issue.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Moved "Legacy Windows" template to the bottom of the Windows templates
to discourage users from selecting it and avoid it being selected by default
at the top of the list as was the case.
Signed-off-by: Letsibogo Ramadi <letsibogo.ramadi@citrix.com>
Reset the PrecheckPage.PoolUpdate property on leaving the SelectPatch page, because it needs to be null for the Automated Updates mode and for the single update mode it will be updated on leaving the Upload page.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Perform all the prechecks on applicable hosts only (i.e. the hosts that don't have the update applied already), with the following exceptions:
- The HA check, which is performed on the pool master
- The server-side precheck (PatchPrecheckCheck) which will still be performed on all servers in the pool and will show the warning if the update has already been applied on some servers
This commit also adds an override to the HAOffCheck.SuccessfulCheckDescription to show the pool name instead of the master's if the check is successful.
Also, in the PatchPrecheckCheck, I had moved the code that checks if the patch is already applied to the very beginning (before the host liveness check), so it will return the warning that the server will be skipped even if the server is not reachable
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- set managed=true, otherwise the network creation fails with the error "The network is not managed by xapi"
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Also rearranged some code in PatchingWizard class, to keep all property assignments together for each wizard page
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Introduced the WizardMode enum and the WizardMode properties in several wizard pages (replacing the IsInAutomatedUpdates boolean property)
When in NewVersion mode, we show the same wizard pages as the AutomatedUpdates mode and we build the update sequence based on the selected update alert (which is an update to a new version)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
In the Updates wizard:
New versions that are available as updates will be listed in the "Download Updates from Citrix" section, before any other updates.
If XenCenter is not the latest version, these rows will be greyed out, with a tooltip.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
- On the Updates tab: for new versions, check that the version of XenCenter is at least the latest. If not, give an additional option to download a newer XenCenter (for both updates and upgrades), and not offer "Download and Install" (for updates).
- In the Patching wizard: if the update is a new version, we force the user to first update their XenCenter to the new version
- In the RPU wizard: if the server version is not the latest and their XenCenter version is not the latest from updates.xml, we assume that they want to upgrade to the latest XenServer version and we force the user to first update their XenCenter to the latest version.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
When a TargetInvocationException is raised, its InnerException property holds the underlying exception, which is what we should display.
Also ellipsise the action description (which could be an error thrown by the upload action) that is displayed on the Upload page.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
This commit fixes a bug in the Update Wizard that causes XenCenter to not restart Toolstack when it should in the following case: in Automated Mode, when the update sequence for a host has an update that contains live-patch with restartHost guidance (and guidance-mandatory=false) followed by an update with Toolstack restart guidance.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
Also changed ApplyPatchAction and ApplyUpdateAction to install a single update to a single host, so that the appropriate action title can be displayed if an action fails. And replaced 2 hardcoded strings with resource strings.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Disabled the ability to select unreachable hosts and in addition
added a try/catch block to hide error message resulting from trying
to clean up an unreachable host.
Signed-off-by: Letsibogo Ramadi <letsibogo.ramadi@citrix.com>
This change does not apply to supplemental packs, as we should be able to install supp packs to individual hosts in a pool.
Also, if the wizard is installing an update from disk and we cannot match it in updates.xml, then we will continue to allow host selection, because we can't tell whether it is a supp pack or a hotfix.
Plus fixing the bug where the "Select All" button is enabled even when all the selectable servers/pools are selected
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>