Bug 1472831

Summary: [v2v] Windows VM with scsi disk type is imported into IDE disk type.
Product: Red Hat CloudForms Management Engine Reporter: Ilanit Stein <istein>
Component: ProvidersAssignee: Martin Betak <mbetak>
Status: CLOSED DEFERRED QA Contact: Ilanit Stein <istein>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.8.0CC: gblomqui, istein, jfrey, jhardy, michal.skrivanek, obarenbo, oourfali
Target Milestone: GA   
Target Release: cfme-future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: rhev:v2v
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-20 14:25:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Bug
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: RHEVM Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virt-v2v_import_log
none
evm.log
none
automation.log
none
production.log
none
engine.log none

Description Ilanit Stein 2017-07-19 13:35:39 UTC 
Description of problem:
When trying to import a Windows 10 VM, with disk type SCSI,
The disk type, of the VM created on the RHV side is IDE,
though it should be VIRTIO.   

Version-Release number of selected component (if applicable):
CFME-5.8.1 + v2v bugs fixes/RHV-4.1.3

How reproducible:
Tried twice, and got the same result.

Expected results:
Imported Windows VM should have it's disk type VIRTIO, regardless to the source VM disk type

Additional info:
* When tracking the import on RHV UI, looking at the disk type, at first when the VM is created, the type displayed is VIRTIO, and at a later stage (after several minutes) it changes to IDE.   

* Same Windows VM was imported via 
RHV RESTAPI(without setting specifically disk type)/UI, 
and the disk of the created VM on RHV was VIRTIO, as expected.
Comment 2 Ilanit Stein 2017-07-20 06:23:44 UTC 
Created attachment 1301524 [details]
virt-v2v_import_log
Comment 3 Ilanit Stein 2017-07-20 06:34:17 UTC 
Created attachment 1301525 [details]
evm.log
Comment 4 Ilanit Stein 2017-07-20 06:34:45 UTC 
Created attachment 1301526 [details]
automation.log
Comment 5 Ilanit Stein 2017-07-20 06:35:08 UTC 
Created attachment 1301527 [details]
production.log
Comment 6 Michal Skrivanek 2017-07-20 06:57:47 UTC 
Please add RHV side logs and time&name of the attempted import
Comment 7 Ilanit Stein 2017-07-20 07:50:45 UTC 
Created attachment 1301562 [details]
engine.log

Source VM name: mb-win10
Destination VM name: win10_scsi_import
Time when import VM started: 3:39 PM
Comment 8 Martin Betak 2017-07-20 09:10:19 UTC 
@Ilanit that is a very strange behavior indeed. Can you please turn of the logging of RHV API requests and provide log/rhevm.log file. There we will find the concrete xml of the request to /externalvmimports endpoint which we can use in manual reproduction.

But I don't think anything on the MIQ level should be able to change the format of the disks. Was the "sparse" disk allocation (thin provisioning) enabled when submitting the operation?
Comment 10 Ilanit Stein 2017-07-20 14:25:01 UTC 
The bug was reported for a RHV with nested hosts.
It can't be reproduced on another RHV, with physical host.
Therefore, closing the bug.