In the CrossPoolMigrateCanMigrateFilter a WebException can be raised if the host cannot be reached to execute the API call that asserts is the VM can be migrated there. With these changes, we catch any exception (not just Failure) and mark the VM as not migratable (because we couldn't assert if it can be migrated to that host).
Also fixed other places where the same error might occur.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- When asserting if a VM can be migrated to a pool we don't have to check all the hosts in the pool at this point, we can enable the pool when we find the first host where migration is possible; we will check the rest of the hosts only if that pool is selected.
- If the destination pool is older than the source, then we don't need to do any server calls because we know that migration to an older host is not allowed.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- with this change the user won't see the misleading "Moving VM to new storage" in History if they tried to move the VM inside the pool, but actually didn't select different SRs for the VM's disks.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- if a VM can migrate inside a pool, then we will allow it in the wizard, even if storage migration is not allowed
- If it is a intra-pool migration (without moving the disks), then use the VM migrate action (which does a VM.pool_migrate), not the cross pool migrate action.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
When XenCenter checks if a VM can be storage-migrated (including in the same pool), it only checks if migration is possible to one SR (the first SR from the SR list that supports vdi creation), which could be a GFS2 SR, where migration is not supported. With this fix, we will only consider the SRs which support migration (instead of vdi creation).
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
hidden and in all other cases it was set by the implementing control, i.e.
the label was not reusable, hence no reason to have it in the control and risk
layout issues. This means that the SrPicker does not need to be a control
encapsulating a CustomTreeVIew, but simply derive from the latter.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
PageLoaded override in derived classes, enforce it by wrapping the page specific
code in a new virtual method, which the derived classes can override and PageLoaded
can call after its own logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
override in derived classes, enforce it by wrapping the page specific code in
a new virtual method, which the derived classes can override and PageLeave can
call before its own logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
* CA-280329: Fix CrossPoolMigrateDestinationPage with Current Server showing
Signed-off-by: Kun Ma <kun.ma@citrix.com>
* CA-280329: Refine usage of CreateTargetServerFilterList
Signed-off-by: Kun Ma <kun.ma@citrix.com>
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>
prevent them from being serialised alongside the API properties. This will also
be useful for moving the API bindings out of XenModel.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
The resume on server uses the CrossPoolMigrateCommand to implement the migration of the VM to the desired host. Before this change that command had no support for resuming a VM after migrating it, so the VM was not resumed. With this change, the CrossPoolMigrateWizard can take an optional (default false) parameter to restart the VM after migration. When this is true, the migrate action becomes a MultipleAction, first migrating and then restarting the VM.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
is possible, because what it actually does is move. When asserting migration use
an SR other than the VDI's current SR for the check to ensure that both source and
target SRs are checked to see whether they support migration. Also, use the VM's
Home() instead of resident_on to ensure the current server cannot be selected as
target server. Some refactoring.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
because the differentiation was in the filters, which can be passed in as parameters
to the base class, and other than this they were only adding complexity.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
as move (halted) or migrate (suspended) destination; this was caused by using the
VM's resident_on instead of Home() host. Also, changed the disabled reason to be
a bit more generic and cover cases other than migration.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
Mostly just terminology changes from home server to target server in the CPM wizard. Changes in shared component SelectMultipleVMDestinationPage (shared with ImportWizard) to allow CPM wizard to rename the Home Server column (as it can the VM/template one - using the same pattern).
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
