Add put_file method - https://github.com/ManageIQ/manageiq-gems-pending/pull/426

Add CPU and network throttling in model - https://github.com/ManageIQ/manageiq/pull/18576

This is the associated UI PR for this BZ: https://github.com/ManageIQ/manageiq-v2v/pull/915

Fabien, I noticed that the UI change to add the CPU throttling field was not backported to hammer yet, because this BZ was moved to target 5.11. We also never merged a change to add the network throttling field because the last I heard, it was still not working in the backend.

1) Should the CPU throttling be backported now and only the network throttling be released in 5.11? or is it okay to wait and release both in 5.11? we may need to break this into two BZs with different target releases.
2) What is the status of the network throttling changes on the backend? Should we make the UI change to enable that in master? I ask because I notice this BZ is marked "Fixed in 5.11.0.1".

Oops, I retract my assumption that it wasn't backported because this is targeting 5.11, since I didn't notice the 5.10.7 BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1702085
The duplicate BZs for backporting still confuse me :)

I can see only 'Max CPU utilization per conversion host' in UI which is expected as per Comment #7 and validation is also working.

But I am not able to understand what to test here. I followed similar steps like https://bugzilla.redhat.com/show_bug.cgi?id=1702085#c6. I have set CPU to 10% and ran migration with 3 vms and 2 conversion host added but I did not saw any restriction/throttling working. What is the expected behavior here?

Moving back to ON_DEV until test scenario has been provided.

https://github.com/ManageIQ/manageiq/pull/19277

To test this feature:

1. Start a migration plan with only one VM
2. Check on the conversion host that the "qemu-img convert" process does consume more than 1% of CPU (top).
3. In Migration Settings, set the CPU limit value to 1.
2. Check on the conversion host that the "qemu-img convert" process does consume less than 1% of CPU (top).

Another test is that the migration task stores the limits.
For a migration task for a VM named 'test-vm', this could be tested like this:

irb> ServiceTemplateTransformationPlanTask.all.select { |t| t.source.name == 'test-vm' }.last.options[:virtv2v_limits]
=> {:cpu=>"1", :network=>"unlimited"}

Then, on the conversion host, the virt-v2v-wrapper state file would reflect that:

# cat /tmp/v2v-import-20190909T161150-5397.state | python -m json.tool
{
    "disk_count": 1,
    "disks": [
        {
            "path": "[NFS_Datastore] test-vm/test-vmvmdk",
            "progress": 49.2
        }
    ],
    "failed": false,
    "finished": false,
    "last_message": {
        "message": "Failed to set network limit",
        "type": "error"
    },
    "pid": 5507,
    "started": true,
    "throttling": {
        "cpu": "1%",
        "network": "unlimited"
    }
}

Fabien, is this BZ still only including CPU throttling, or is network throttling making a return? I was just confused by the title of the BZ. If we are reintroducing network throttling, we'll need to make a UI change.

It's only about CPU so far, as virt-v2v-wrapper doesn't handle network correctly yet. I updated the BZ title.

Fabien/Satoe,

Can this bug move to ON_QA please?

@Ilanit, this BZ is targeted for CFME 5.11.1 and there's no build so far. It will move to ON_QA once the build is available.