Instead of showing the cross-pool migration upsell dialog, we now show the wizard, where user can try to perform an intra-pool copy (the cross-pool option is disabled with an explanatory message displayed)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* L10n: Inverness
build_chm # 24
* Revert "L10n: Inverness"
This reverts commit 8b41bb8c79cd4d73ed6021a5533cf7624a5421c4.
* L10n: Inverness
CHMs from build_chm master-l10n #24
Second attempt at checkin with a merge conflict resolve. (I hope)
We always add the VM wizard button to the migrate dropdown, but it's
currently not added until the end of the enable loop - after we've
calculated whether we can boot on each host. There's no reason to wait
until we've done all that before showing the wizard, so add it straight
away to the end of the list before the loop.
Signed-off-by: Callum McIntyre <callum.mcintyre@citrix.com>
When we right click migrate a VM we load all the hosts in the pool into
a dropdown, and then one-by-one assert whether the selected VM can boot
on that host, enabling each option where this is positive. If the
dropdown is exited then nothing stops these assert calls from
continuing, and looking at the logs we can see that they do.
With a large pool this is problematic because the UI basically locks up
until it's completed all these asserts, even if we've already selected a
host to migrate to. If we try to migrate another host then we see in the logs that both the old thread and new
thread are making `assert_can_boot_here` calls, and the UI for the new
thread doesn't function until the old one has finished.
This commit adds a new property `_isDropDownClosed`, which is set by the
new `OnDropDownClosed` event handler. In the loop enabling dropdown
items, each iteration we check this property - and if it is true then
the dropdown is no longer showing so we stop the loop and thus don't
call any more `assert_can_boot_here` commands. This stops the UI locking
up after the dropdown is closed.
Signed-off-by: Callum McIntyre <callum.mcintyre@citrix.com>
When trying to import a default template from xva, xapi notices that it is a default template, finds an existing one on the host and returns that one.
With these changes, XenCenter handles this case and displays an error, instead of waiting for the returned VM to be linked to the import task (which never happens).
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
