MTV-1211 Max concurrent virtual machine migrations

[RichardHoch]

MTV 2.7

Resolves https://issues.redhat.com/browse/MTV-1211 by adding information about controller_max_vm_inflight (shown in the UI as Max concurrent virtual machine migrations).

Previews:

• https://file.corp.redhat.com/rhoch/max_concur_vm/html-single/#configuring-mtv-operator_mtv [first bullet in list and first item in Table 3.1]
• https://file.corp.redhat.com/rhoch/max_concur_vm/html-single/#max-concurrent-vms_mtv [new section]
• https://file.corp.redhat.com/rhoch/max_concur_vm/html-single/#mtv-settings_mtv [first item in Table 4.1]

[nunzy1]

Your call as to what you incorporate. :-)

I might change:

"Maximum number of virtual machines (VMs) or disks per plan that can be migrated simultaneously."
To:
"Maximum number of virtual machines (VMs) or disks per plan that can migrate simultaneously."

(---unless “can be” means that you may decide not to and have that option)

"The maximum number of disks that can be transferred simultaneously."
To:
"The maximum number of disks that can transfer simultaneously."

"The maximum number of VMs that can be migrated simultaneously."
To:
"The maximum number of VMs that can migrate simultaneously."

"…can be transferred simultaneously. In these migrations, the disks are migrated in parallel. This means that if the combined number of disks that you want to migrate is greater than the value of the setting, additional disks wait until the queue is free without regard for whether a VM has completely finished being migrated."
To:
"…can be transferred simultaneously. In these migrations, the disks migrate in parallel. If the combined number of disks that you want to migrate is greater than the value of the setting, additional disks migrate only once the queue is free, without regard for whether a VM has finished migrating."

"Once any of them has migrated, the 16th disk can be migrated, whether or not all the disks on VM A and VM B have finished migrating."
To:
"Once any of them has migrated, the 16th disk migrates, whether or not all the disks on VM A and VM B have finished migrating."

(-- unless “can be migrated” means that it’s an option to migrate the disk)

[RichardHoch]

@mnecas @sgratch Please review this PR. Thanks.

[sgratch]

@RichardHoch @mnecas
Isn't it worth renaming the parameter to reflect its meaning to something like:
Max concurrent virtual machine or disks migrations?

[RichardHoch]

@sgratch Changing the name of the parameter is up to @mnecas as far as I am concerned. But if we do it, I would suggest controller_max_vm_disk_inflight and Max concurrent virtual machine or disk migrations [drop the "s" in "disks" -- English is weird]. Does the PR look OK otherwise?

[sgratch]

LGTM except the comments below.
But let's wait for @mnecas final approval as well.

[sgratch]

For all occurrences of remote cold migrations:
I suggest to explain what does "remote migration" mean and therefore rephrase to something like:
cold migrations to a remote OpenShift cluster

[sgratch]

For all occurrences of local cold migrations:
I suggest to explain what does "local migration" mean and therefore rephrase to something like:
cold migrations to a local OpenShift cluster

[mnecas]

It does not apply for all local cold migrations but afaik only for virt-v2v related migrations.

[sgratch]

Changing the name of the parameter is up to @mnecas as far as I am concerned. But if we do it, I would suggest controller_max_vm_disk_inflight and Max concurrent virtual machine or disk migrations [drop the "s" in "disks" -- English is weird].

Sounds good to me to change it. @mnecas ?

[mnecas]

Changing the name of the parameter is up to @mnecas as far as I am concerned. But if we do it, I would suggest controller_max_vm_disk_inflight and Max concurrent virtual machine or disk migrations [drop the "s" in "disks" -- English is weird].

Sounds good to me to change it. @mnecas ?

I am a bit afraid that we would lose the previous settings during the upgrade.
I don't want to change it to the "or" as we might even change the logic to always transfer disks.

[sgratch]

Changing the name of the parameter is up to @mnecas as far as I am concerned. But if we do it, I would suggest controller_max_vm_disk_inflight and Max concurrent virtual machine or disk migrations [drop the "s" in "disks" -- English is weird].

Sounds good to me to change it. @mnecas ?

I am a bit afraid that we would lose the previous settings during the upgrade. I don't want to change it to the "or" as we might even change the logic to always transfer disks.

OK, so let's leave it as is for now.

[RichardHoch]

@sgratch @mnecas I made the change Sharon suggested. Please review this PR again. Thanks.

[sgratch]

@RichardHoch did you miss those 2 comments ? :)
#580 (comment)
#580 (comment),

[RichardHoch]

@sgratch @mnecas I made some more changes to the PR. Please review them. Thanks.
@sgratch I think I included both your changes -- let me know if I missed something.

[duduvaa]

The 'controller_max_vm_inflight' parameter is related to simultaneous migration.
While using VMware as the source provider:
COLD migration - VMs per ESXi host that can migrate simultaneously
WARM migration - Disks per ESXi host that can migrate simultaneously

[anarnold97]

Suggested change

	* {rhv-full} migrations, {osp} migrations, VMware warm migrations, _or_ cold VMware migrations to a remote {ocp} cluster: The maximum number of disks that {project-short} can transfer simultaneously.
	* OVA migrations or cold VMware migrations using `virt-v2v` to a local {ocp} cluster: The maximum number of VMs that {project-short} can migrate simultaneously.
	* For {rhv-full} migrations, {osp} migrations to a remote {ocp} cluster: The maximum number of disks that {project-short} can transfer simultaneously.
	* For OVA migrations using `virt-v2v` to a local {ocp} cluster: The maximum number of VMs that {project-short} can migrate simultaneously.
	* For VMware simultaneous migration:
	** Cold migration: VMs for each ESXi host that can migrate simultaneously
	** Warm migration: Disks for each ESXi host that can migrate simultaneously

@rhoch @duduvaa - please can you have a look at this and see if it would be ok? i am trying to synthesize what has been approved with David's comments

[RichardHoch]

Thanks, @anarnold97 -- should be {osp} migrations, without a qualifier.

@duduvaa Martin said that for VM cold migrations, there was a difference between migrations to a local cluster and to a remote cluster. Do you see a difference in your tests?

[mnecas]

For cold remote we use the CNV CDI so the max in flight references the number of disks.