Bug 1472831 - [v2v] Windows VM with scsi disk type is imported into IDE disk type.
[v2v] Windows VM with scsi disk type is imported into IDE disk type.
Status: CLOSED DEFERRED
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
5.8.0
Unspecified Unspecified
unspecified Severity high
: GA
: cfme-future
Assigned To: Martin Betak
Ilanit Stein
rhev:v2v
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-19 09:35 EDT by Ilanit Stein
Modified: 2017-08-16 06:23 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-20 10:25:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: Bug
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: RHEVM


Attachments (Terms of Use)
virt-v2v_import_log (369.95 KB, text/plain)
2017-07-20 02:23 EDT, Ilanit Stein
no flags Details
evm.log (4.68 MB, application/x-gzip)
2017-07-20 02:34 EDT, Ilanit Stein
no flags Details
automation.log (254.82 KB, application/x-gzip)
2017-07-20 02:34 EDT, Ilanit Stein
no flags Details
production.log (92.90 KB, application/x-gzip)
2017-07-20 02:35 EDT, Ilanit Stein
no flags Details
engine.log (1.48 MB, application/x-gzip)
2017-07-20 03:50 EDT, Ilanit Stein
no flags Details

  None (edit)
Description Ilanit Stein 2017-07-19 09:35:39 EDT
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 02:23 EDT
Created attachment 1301524 [details]
virt-v2v_import_log
Comment 3 Ilanit Stein 2017-07-20 02:34 EDT
Created attachment 1301525 [details]
evm.log
Comment 4 Ilanit Stein 2017-07-20 02:34 EDT
Created attachment 1301526 [details]
automation.log
Comment 5 Ilanit Stein 2017-07-20 02:35 EDT
Created attachment 1301527 [details]
production.log
Comment 6 Michal Skrivanek 2017-07-20 02:57:47 EDT
Please add RHV side logs and time&name of the attempted import
Comment 7 Ilanit Stein 2017-07-20 03:50 EDT
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 05:10:19 EDT
@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 10:25:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.