- while upgrading a host, throw a HOST_OFFLINE ("Server could not be contacted") exception if the host can no longer be resolved (instead of HANDLE_INVALID)
- also corrected the parameters of the HANDLE_INVALID exception, as an extra parameter is needed for the friendly error name.
- in the UpdateManualHostPlanAction class I replaced Host with the private property _host in several places, so we are no longer trying to resolve the host each time we want to write something into logs
- added some null checks, to avoid reporting null reference exception
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- added some null checks
- in the Cross pool migrate wizard, add Transfer network page for all cases except intra-pool move (which is performed via VMMoveAction)
- added comments to VMCrossPoolMigrateAction constructor to make it cleared what the copy parameter means
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
-New Network Wizard: Changing the layout on the network type selection page to make this page "dpi aware" using FlowLayoutPanel. Additional info is shown on the bottom of the panel instead of tooltips, some code has been removed that used fix positions and moved controls around.
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.
- modified CopyTemplateCommand to launch a cross pool copy if permitted
- added CrossPoolCopyTemplateCommand which opens the Cross pool migration wizard in "copy" mode
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- added a "copy mode" page to the Cross pool migrate wizard (when in copy mode) where the user can select intra-pool or cross-pool copy
- If intra-pool option is selected, then the wizard will display a page similar to what we currently have in the Copy VM dialog
- If cross-pool option is selected, then the wizard will display all the cross pool migration pages
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- modified the VMCopyCommand to launch a cross pool copy if permitted
- added the CrossPoolCopyVMCommand which opens the Cross pool migration wizard in "copy" mode
- modified the cross pool migrate action with an extra "copy" parameter, which will add a copy option to the vm.migrate_send function call
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
