Bug 1472831 - [v2v] Windows VM with scsi disk type is imported into IDE disk type.
Summary: [v2v] Windows VM with scsi disk type is imported into IDE disk type.
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: GA
: cfme-future
Assignee: Martin Betak
QA Contact: Ilanit Stein
URL:
Whiteboard: rhev:v2v
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-19 13:35 UTC by Ilanit Stein
Modified: 2017-08-16 10:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-20 14:25:01 UTC
Category: Bug
Cloudforms Team: RHEVM
Target Upstream Version:
Embargoed:


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

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.


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