Description of problem: provisions made against a rhev template are always thin / dependant and never clone/independant, a change in behaviour from 5.8 that generates a lot of extra work as converting the vm requires exporting and importing it. Version-Release number of selected component (if applicable): cfme 5.9.2 rhev 4.1.2 How reproducible: all the time Steps to Reproduce: 1. create a catalog item that will provision a rhel 7 template. there should be no snapshots. 2. make sure you have set the provision to be "native clone" and under hardware do a full copy of the storage, not thin 3. send the provision. Actual results: the resulting vm in the provider shows under "template" the info "thin/dependant" Expected results: the resulting vm in the provider shows under "template" the info "clone/independant" Additional info: - rhev 4.1 - behaviour introduced in 5.9 - documentation suggest this should be a full clone not a native clone as no snapshots are presents. - a service provision is used for the request
Please provide logs from that show the provision task it would be best if it includes "Clone Options:" and "Prov Options:" logging. There are flags in provisioning that control if it is a "linked_clone" https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/provision/cloning.rb#L41 and the disk_type: https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/provision/cloning.rb#L61
In the evm.log we log the parameters being passed to the provider using the header "Clone Options:" so I would suggest looking of that in the logs. The code that runs that is here: https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/provision/cloning.rb#L77 Then the same parameters are sent to the ovirt service a few lines down on line 84. https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/provision/cloning.rb#L84 There should be useful details in the rhevm.log on the appliance as well. The logging level for this file can be adjusted in the Advanced settings, the default value is "info". Depending on the level of output (I am not that familiar with it) you may need to specify "debug" here, but I would suggest trying with info first and changing if needed. Snippet for the Advanced settings of the UI: :log: :level_rhevm: info
https://github.com/ManageIQ/manageiq-providers-ovirt/pull/276
We have found out that this is UI only issue, because reporting of disk being thin or preallocated is based on sparseness feature instead of disk format (RHV webadmin has the same issue tracked in BZ1615287). So if you create a VM template with preallocated disk and then create VM from this template, VM's disk will be preallocated even though it's being reported as thin, because the reporting is bad. Because of that reducing severity to medium and targeting 5.9.5 (because customer ticket is attached).
New commit detected on ManageIQ/manageiq-providers-ovirt/master: https://github.com/ManageIQ/manageiq-providers-ovirt/commit/a0002db568b408bf57877489994465ecc6146909 commit a0002db568b408bf57877489994465ecc6146909 Author: Boris Odnopozov <bodnopoz> AuthorDate: Thu Aug 16 07:45:37 2018 -0400 Commit: Boris Odnopozov <bodnopoz> CommitDate: Thu Aug 16 07:45:37 2018 -0400 Fix disk_type attribute We were calculating the disk_type based on the sparse property of the disk. This is incorrect, it should actually be calculated based on the format property. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1598747 app/models/manageiq/providers/redhat/infra_manager/refresh/parse/parser.rb | 2 +- app/models/manageiq/providers/redhat/infra_manager/refresh/parse/strategies/vm_inventory.rb | 2 +- app/models/manageiq/providers/redhat/inventory/parser/infra_manager.rb | 2 +- spec/models/manageiq/providers/redhat/infra_manager/refresh/refresher_4_async_graph_spec.rb | 4 +- spec/models/manageiq/providers/redhat/infra_manager/refresh/refresher_4_async_spec.rb | 4 +- spec/models/manageiq/providers/redhat/infra_manager/refresh/refresher_target_vm_4_spec.rb | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-)
https://github.com/ManageIQ/manageiq-providers-ovirt/pull/277
New commit detected on ManageIQ/manageiq-providers-ovirt/master: https://github.com/ManageIQ/manageiq-providers-ovirt/commit/8dd133f077156f44b5fb17f4f9e9bc342f83e655 commit 8dd133f077156f44b5fb17f4f9e9bc342f83e655 Author: Boris Odnopozov <bodnopoz> AuthorDate: Mon Aug 20 05:03:05 2018 -0400 Commit: Boris Odnopozov <bodnopoz> CommitDate: Mon Aug 20 05:03:05 2018 -0400 Fix provisioning independent VM We ignored the clone_type parameter during provisioning from template. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1598747 app/models/manageiq/providers/redhat/infra_manager/ovirt_services/strategies/v4.rb | 2 +- app/models/manageiq/providers/redhat/infra_manager/provision/cloning.rb | 14 +- spec/models/manageiq/providers/redhat/infra_manager/provision_spec.rb | 19 +- 3 files changed, 32 insertions(+), 3 deletions(-)
https://github.com/ManageIQ/manageiq-providers-ovirt/pull/282
New commit detected on ManageIQ/manageiq-providers-ovirt/master: https://github.com/ManageIQ/manageiq-providers-ovirt/commit/e22fe21c86d8a40b94b66c59003caf25aa731ea3 commit e22fe21c86d8a40b94b66c59003caf25aa731ea3 Author: Boris Odnopozov <bodnopoz> AuthorDate: Wed Aug 29 03:59:42 2018 -0400 Commit: Boris Odnopozov <bodnopoz> CommitDate: Wed Aug 29 03:59:42 2018 -0400 Fix setting storage attributes during vm provision We did not pass the sparse and storage_domain parameters when provisioning a VM using version 4 of the sdk. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1598747 app/models/manageiq/providers/redhat/infra_manager/ovirt_services/strategies/v4.rb | 43 +- spec/models/manageiq/providers/redhat/infra_manager/ovirt_services/strategies/v4_spec.rb | 67 + 2 files changed, 103 insertions(+), 7 deletions(-)
Verified on CFME-5.10.0.14/RHV-4.2.5.3-0.1.el7ev. Tested the attached NFS/ISCSI options: 'clone_bug_1598747_verification.png'
Created attachment 1481260 [details] verification_details