Description of problem: When trying to migrate a VM and there is no available hosts to migrate to then a message of migrateVmNoAvailableHost [1] should be displayed. [1] migrateVmNoAvailableHost: { id: 'migrate.vm.noAvailableHost', defaultMessage: 'No available host to migrate VMs to', description: 'notification shown when there are no hosts the VMs can migrate to' }, But instead the migrate dialog is opened while both "Destination Host" pull-down menu field and the "Migrate" button are disabled. Version-Release number of selected component (if applicable): 4.4 master How reproducible: 100% Steps to Reproduce: 1.Choose a running VM contained in a cluster with only 1 host 2.Click the "Migrate" option Actual results: the Migrate dialog is opened with disabled fields so nothing the user can do except closing the dialog (see the attachment) Expected results: A notification message saying that "No available host to migrate VMs to" should be displayed
Created attachment 1635806 [details] Migrate VM dialog while there are no targeted hosts to migrate to
After checking, it seems that the reason for opening the dialog in any case is that once the user check the "migrate VMs in affinity" option, there might do exist available hosts to migrate to and the button will change to be enabled. We do need to verify it works like that and in this is the case then consider adding an info tooltip or explain that as an info text within the dialog.
Andrej, can you please verify if the scenario mentioned on comment 2 is valid? i.e. enabling the "migrate VMs in affinity" option on "Migrate VM" dialog might add existed available hosts for the vm to migrate to?
Yes, that is exactly why the dialog is shown even if there are no available hosts where the selected VM can be migrated. A user can decide if they want to migrate only the single selected VM, or the whole group of VMs that have positive enforcing affinity. In case a few VMs with positive enforcing affinity are running on a host, none of them can be migrated away individually, but the whole group can be migrated together. There is already a tooltip in the dialog, but maybe it is not clear enough.
(In reply to Andrej Krejcir from comment #4) rated together. > > There is already a tooltip in the dialog, but maybe it is not clear enough. The current label and tooltip's text are: "Migrate all VMs in positive enforcing affinity with selected VMs - VMs that are not listed below may also be migrated. VMs that are grouped by affinity may have log errors because of multiple migration attempts" The issue is that it's not clear enough when the migration is disabled due to positive enforcing affinity reasons (when in that case the text of "No available host to migrate VMs to", appearing as a reason for the disabling next to the hosts label, is inaccurate) and when it's really a question of hosts availability issue. In case it's an issue of hosts availability then enabling the affinity CB won't help. (In addition, the user won't know which VMs are going to be migrated as a group but that's a different issue to handle). So I think that if it's not straight forward to implement some kind of indication that the migration is currently disabled due to affinity reasons, at least let's add a short explanation to the tooltip/label/info text informing that it might be the reason while enabling the CB might enable the hosts availability in case it's disabled.
How big is the performance impact of checking for positive affinity? We could check the host availability (in parallel) twice: with and without the flag. Then we could display some meaningful message i.e. "more hosts will be available after enabling positive affinity" Alternatively we could just suggest enabling positive affinity if it's likely that it can make a difference for selected vm's. However it seems there is no API that could be used to check that. The closest I could find is: http://ovirt.github.io/ovirt-engine-api-model/4.4/#types/vm_affinity Unfortunately state "user_migratable" seems to be triggered by various conditions.
(In reply to rszwajko from comment #6) > How big is the performance impact of checking for positive affinity? > We could check the host availability (in parallel) twice: with and without > the flag. > Then we could display some meaningful message i.e. "more hosts will be > available after enabling positive affinity" We haven't done any performance measurements, so I don't know exactly how slower it would be. When affinity is considered, the query executes more DB operations, and a short algorithm. The performance of both depends on the number of affinity groups in the cluster and the number of VMs in those affinity groups. It does not depend on the number of selected VMs for migration. Yes we can try to do the check twice and see if the performance impact is noticeable. > > Alternatively we could just suggest enabling positive affinity if it's > likely that it can make a difference for selected vm's. We could do this check partially. Simply test if any of the selected VMs are part of any affinity group or affinity label. It would be expensive to do the check properly, it would need the same DB queries and algorithm as checking the host availability. > However it seems there is no API that could be used to check that. The > closest I could find is: > http://ovirt.github.io/ovirt-engine-api-model/4.4/#types/vm_affinity > Unfortunately state "user_migratable" seems to be triggered by various > conditions. There is no API to list all affinity groups for a VM, we would need to add it.
@akrejcir, after playing a bit with the "Migrate all VMs in positive enforcing affinity" option, it seems there are two issues. since you are most familiar with that, then I want to make sure before opening a separate bug: 1. If all VMs within the affinity group with positive enforcing are chosen to be migrated, the destination hosts list is still empty and migration is disabled. It is reproduced on both ui and rest api query. From user perspective this behaviour seems wrong since in that case the migration should be enabled without checking the "Migrate all VMs" option. Any reason for that? 2. This option is not working for me with affinity labels on both ui and rest api (while using both check_vms_in_affinity_closure and migration_target_of parameters of course). Any reason for that? Thanks
(In reply to Sharon Gratch from comment #8) > @akrejcir, after playing a bit with the "Migrate all VMs in positive > enforcing affinity" option, it seems there are two issues. > since you are most familiar with that, then I want to make sure before > opening a separate bug: > 1. If all VMs within the affinity group with positive enforcing are chosen > to be migrated, the destination hosts list is still empty and migration is > disabled. It is reproduced on both ui and rest api query. From user > perspective this behaviour seems wrong since in that case the migration > should be enabled without checking the "Migrate all VMs" option. Any reason > for that? > I agree that it is confusing from user's perspective. I have originally designed it this way, so that it is clear what the value of 'migrate_vms_in_affinity_closure' parameter should be when migrating the VMs[1]. There is no single API command to migrate multiple VMs, each migration is a separate API call. So the scheduler does not know if there are other VMs being migrated at the same time. We could change the API query which checks destination hosts[2] to behave this way, but then the caller would not know the value of 'migrate_vms_in_affinity_closure' to pass to the migration API call. You can open an RFE to make this more user friendly, but it will not be a simple change. To get rid of the parameter 'migrate_vms_in_affinity_closure' we would need an API command to migrate multiple VMs. [1] - http://ovirt.github.io/ovirt-engine-api-model/master/#services/vm/methods/migrate [2] - http://ovirt.github.io/ovirt-engine-api-model/master/#services/hosts/methods/list > 2. This option is not working for me with affinity labels on both ui and > rest api (while using both check_vms_in_affinity_closure and > migration_target_of parameters of course). Any reason for that? > > Thanks Affinity labels are part of affinity groups and they use the same algorithm, so this should work. Please open a separate bug for this.
(In reply to Andrej Krejcir from comment #9) > We could change the API query which checks destination hosts[2] to behave > this way, > but then the caller would not know the value of > 'migrate_vms_in_affinity_closure' > to pass to the migration API call. > > You can open an RFE to make this more user friendly, but it will not be a > simple change. > To get rid of the parameter 'migrate_vms_in_affinity_closure' we would need > an API command > to migrate multiple VMs. Can't we use a different approach and instead of getting rid of the 'migrate_vms_in_affinity_closure' parameter for api [2], we can maybe implemented it such that in case all VMs included on the 'migration_target_of' list are also included within the affinity group (i.e. no VM is missing from the list) then activating the api with/without the 'check_vms_in_affinity_closure' parameter will result the same. The logic behind that is that if all VMs within the affinity group are already included on the 'migration_target_of' list then there is no meaning to use the 'migrate_vms_in_affinity_closure'. You can either use or ignore the parameter. On UI level it will behave the same, the user won't have to click the checkbox for enable migration. opened bug 1862816 > > 2. This option is not working for me with affinity labels on both ui and > > rest api (while using both check_vms_in_affinity_closure and > > migration_target_of parameters of course). Any reason for that? > > > > Thanks > > Affinity labels are part of affinity groups and they use the same algorithm, > so this should work. > Please open a separate bug for this. Opened bug 1862818
What are the verification steps please? I'm lost in the scope of this bug.
Main scenario: 1. enter Virtual Machines screen 2. select vms that belong to an affinity group with positive enforcing affinity enabled. Other machines may be selected as well. 3. click Migrate 4. verify that: a) there is no available destination host b) helper text is displayed below the host dropdown explaining why there are no hosts available (vms with positive affinity enabled cannot be migrated individually) 5. check the 'Migrate all VMs ...' checkbox 6. verify that: a) some destination hosts show up (assuming that there are resources on the cluster) b) the helper text disappears c) there was no data loading after toggling the checkbox (assuming that the query done at startup was successful)
Verified in ovirt-engine-4.4.2.3-0.6.el8ev.noarch Verified by following steps in comment 12. The Migrate VM(s) dialog and the helper text behaves exactly as described in step 6.
This bugzilla is included in oVirt 4.4.2 release, published on September 17th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.