Bug 1468535 - Device.map can't be updated to vda if import rhel7.4 guest from kvm source at rhv4.1
Device.map can't be updated to vda if import rhel7.4 guest from kvm source at...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.4
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
V2V
: Reopened, TestOnly
Depends On: 1484199
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-07 07:04 EDT by mxie@redhat.com
Modified: 2018-06-21 01:59 EDT (History)
10 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-08-22 22:27:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rhel7.4-import-kvm (300.01 KB, image/png)
2017-07-07 07:04 EDT, mxie@redhat.com
no flags Details
vdsm.log (413.13 KB, text/plain)
2017-07-07 07:04 EDT, mxie@redhat.com
no flags Details
import.log (13.15 KB, text/plain)
2017-07-07 21:33 EDT, mxie@redhat.com
no flags Details
KVM-SATA (67.82 KB, image/png)
2018-05-02 03:11 EDT, mxie@redhat.com
no flags Details

  None (edit)
Description mxie@redhat.com 2017-07-07 07:04:08 EDT
Created attachment 1295256 [details]
rhel7.4-import-kvm

Description of problem:
Device.map can't be updated to vda if import rhel7.4 guest from kvm source at rhv4.1

Version-Release number of selected component (if applicable):
rhv:4.1.3-0.1.el7
vdsm-4.19.20-1.el7ev.x86_64
virt-v2v-1.36.3-6.el7.x86_64
libguestfs-1.36.3-6.el7.x86_64
libvirt-client-3.2.0-14.el7.x86_64
qemu-kvm-rhev-2.9.0-14.el7.x86_64
libguestfs-winsupport-7.2-2.el7.x86_64
virtio-win-1.9.1-0.el7.noarch.rpm

How reproducible:
100%

Steps to Reproduce:
1.Log in rhv and import guest from kvm
Open virtual machine option at rhv4.1 -> click import button -> choose source as vmware->input URL:qemu+tcp://ip/system, username/password->Load guests successfully-> select guest "rhel7.4" to import


2.After finishing import, power on the guest but find device.map is not updated to vda, pls refer to screenshot"rhel7.4-import-kvm"

Actula results:
As above description

Expected results:
Device.map can be updated to vda if import rhel7.4 guest from kvm source at rhv4.1


Additional info:
1.Device.map can be updated to vda if import rhel7.4 guest from vmware source at rhv4.1
2.Device.map can be updated to vda if import rhel7.3 guest from kvm source at rhv4.1
3.Device.map can be updated to vda if convert rhel7.4 guest to rhv by virt-v2v on v2v conversion server
Comment 2 mxie@redhat.com 2017-07-07 07:04 EDT
Created attachment 1295257 [details]
vdsm.log
Comment 3 Richard W.M. Jones 2017-07-07 07:51:53 EDT
This can't be debugged without the virt-v2v log, which VDSM
doesn't preserve.
Comment 4 Richard W.M. Jones 2017-07-07 07:53:12 EDT
According to the resolution for
https://bugzilla.redhat.com/show_bug.cgi?id=1350465

"Previously, when importing a Virtual Machine, if the import failed, the output of the virt-v2v tool was not available for investigating the reason for the failure, and the import had to be reproduced manually. In this release, the output of virt-v2v is now stored in the /var/log/vdsm/import directory. All logs older than 30 days are automatically removed."

Can you see if the virt-v2v log file is present there?
Comment 5 mxie@redhat.com 2017-07-07 21:33 EDT
Created attachment 1295423 [details]
import.log
Comment 6 Richard W.M. Jones 2017-07-08 02:44:36 EDT
Same comment as:
https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6
Comment 7 Pino Toscano 2017-08-14 11:22:38 EDT
Hi Ming Xie,

were you able to get verbose logs for this conversion?
Comment 8 mxie@redhat.com 2017-08-21 09:52:35 EDT
Hi Pino,

   As https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6 said, vdsm can't collect virt-v2v logs properly at /var/log/vdsm/import/* sometimes, so I can't provide verbose log of this bug for you, but I still could reproduce this bug with below latest builds, do you think bug 1350465 should be reopened?

Packages:
virt-v2v-1.36.3-6.el7_4.3.x86_64
libguestfs-1.36.3-6.el7_4.3.x86_64
vdsm-4.19.28-1.el7ev.x86_64
libvirt-client-3.2.0-14.el7_4.2.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.4.x86_64
rhv:4.1.3-0.1.el7
Comment 9 Pino Toscano 2017-08-22 02:45:15 EDT
(In reply to mxie@redhat.com from comment #8)
>    As https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6 said, vdsm
> can't collect virt-v2v logs properly at /var/log/vdsm/import/* sometimes, so
> I can't provide verbose log of this bug for you, but I still could reproduce
> this bug with below latest builds, do you think bug 1350465 should be
> reopened?

Tomáš, do you have further ideas about this?
Comment 10 Tomáš Golembiovský 2017-08-22 04:39:59 EDT
This is not a virt-v2v issue. For importing from KVM sources we have our own tool called kvm2ovirt. It is rather crude tool that basically only copies the disks. It does not alter the guest in anyway.
Comment 11 Pino Toscano 2017-08-22 06:30:40 EDT
Ah I see, thanks for the information (I didn't know about that, I assumed v2v was used also in that case).

In that case, and considering that reassigning bugs to oVirt does not work: Ming Xie, please report the issue for oVirt, so they can track, and hopefully fix this issue (either by doing simple manipulations on the guest, or using v2v).
Comment 12 mxie@redhat.com 2017-08-22 22:27:18 EDT

*** This bug has been marked as a duplicate of bug 1484199 ***
Comment 14 mxie@redhat.com 2018-04-26 02:38:28 EDT
Verify the bug with below builds
vdsm-4.20.22-1.el7ev.x86_64
rhv:4.2.3.2-0.1.el7

Steps:

Scenario1:import linux guest from kvm on rhv4.2 GUI
1.Import a linux guest from kvm on rhv4.2.
2.Check disk type after finishing importing

Result:
  1.When KVM guest's disk type is SCSI Although guest's disk shows virtio-scsi in disk->interface option, the disk isn't updated to vda and device.map also isn't updated to vda in OS
  2.When KVM guest's disk type is SATA, guest's disk shows virtio-scsi in Disk->Interface option, the disk isn't updated to vda and device.map also isn't updated to vda in OS
  3.When KVM guest's disk type is IDE, guest's disk shows IDE in Disk->Interface option, the disk isn't updated to vda and device.map also isn't updated to vda in OS


Scenario2:import linux guest from VMWARE on rhv4.2 GUI
1.Import a linux guest from vmware on rhv4.2.
2.Check disk type after finishing importing
 
Result:
   Guest's disk shows virtio in Disks->Interface option, the disk is updated to vda and device.map also is updated to vda in OS



Scenario3:import linux guest from XEN on rhv4.2 GUI
1.Import a linux guest from XEN on rhv4.2.
2.Check disk type after finishing importing
 
Result:
   Guest's disk shows virtio in Disks->Interface option, the disk is updated to vda and device.map also is updated to vda in OS



Scenario4:import linux guest from ova file on rhv4.2 GUI
1.Prepare a ova and import it on rhv4.2.
2.Check disk type after finishing importing
 
Result:
   Guest's disk shows virtio in Disks->Interface option, the disk is updated to vda and device.map also is updated to vda in OS


Hi Sharon,

   I am confused about the fix result of bug1484199.According to comment19 of bug1484199,for KVM provider,the imported VM's disk interface type was always set to VIRTIO, regardless to source VM's disk interface types, but as above test result, if kvm guest's disk type is IDE guest's disk shows IDE in Disk->Interface option after importing on rhv4.2.
   
   And KVM guest disk and device.map are not updated to vda in os after importing on rhv4.2, so the bug1484199 is not fixed actually, could you please help to check?

Thanks
Comment 15 Sharon Gratch 2018-05-01 07:08:07 EDT
(In reply to mxie@redhat.com from comment #14)
> Hi Sharon,
> 
>    I am confused about the fix result of bug1484199.According to comment19
> of bug1484199,for KVM provider,the imported VM's disk interface type was
> always set to VIRTIO, regardless to source VM's disk interface types, but as
> above test result, if kvm guest's disk type is IDE guest's disk shows IDE in
> Disk->Interface option after importing on rhv4.2.

Hi Mxie,
That was the behavior for KVM import before the fix. The patch fixes that so that in case of importing from KVM provider, the target disk interface type of imported VM will be the same as the source. Isn't that the case in your tests?
>    
>    And KVM guest disk and device.map are not updated to vda in os after
> importing on rhv4.2, so the bug1484199 is not fixed actually, could you
> please help to check?

What do you mean by "KVM guest disk..in os"? Can you send me an example? Please note that after this bug fix we are not changing the interface type for KVM provider from source to destination, so:
For importing from KVM provider-
if source disk interface was vdx (VIRTIO), then target should stay vdx.
if source disk interface was hdx (IDE), then target should stay hdx.
if source disk interface was sda (SCSI), then target should stay sdx.

> 
> Thanks
Comment 16 mxie@redhat.com 2018-05-02 03:11:00 EDT
> What do you mean by "KVM guest disk..in os"? Can you send me an example?
> Please note that after this bug fix we are not changing the interface type
> for KVM provider from source to destination, so:
> For importing from KVM provider-
> if source disk interface was vdx (VIRTIO), then target should stay vdx.
> if source disk interface was hdx (IDE), then target should stay hdx.
> if source disk interface was sda (SCSI), then target should stay sdx.

Hi Sharon,
  
   Thanks for your explanation, I have understood the fix and rhv4.2 has changed the strategy of importing guest from kvm source for disk interface type, but I think guest's disk type is not correct after importing from kvm source on rhv4.2.
   According to my test result on comment14, when source KVM guest's disk type is SCSI or SATA,guest's disk type shows virto-scsi after importing on rhv4.2, pls refer to screenshot'KVM-SATA'.
   By the way, the Israel's test result at https://bugzilla.redhat.com/show_bug.cgi?id=1484199#c20 confused me,for example, SATA mappaed to VIRTIO which maybe not a expected result.
  
Thanks
Comment 17 mxie@redhat.com 2018-05-02 03:11 EDT
Created attachment 1429732 [details]
KVM-SATA
Comment 18 Sharon Gratch 2018-05-08 12:40:26 EDT
(In reply to mxie@redhat.com from comment #16)
> Hi Sharon,
>   
>    Thanks for your explanation, I have understood the fix and rhv4.2 has
> changed the strategy of importing guest from kvm source for disk interface
> type, but I think guest's disk type is not correct after importing from kvm
> source on rhv4.2.
>    According to my test result on comment14, when source KVM guest's disk
> type is SCSI or SATA,guest's disk type shows virto-scsi after importing on
> rhv4.2, pls refer to screenshot'KVM-SATA'.
Hi mxie,

This means the same thing since the string representation of a disk's scsi interface is "VIRTIO_SCSI". So scsi and virtio-scsi represents the same.

>    By the way, the Israel's test result at
> https://bugzilla.redhat.com/show_bug.cgi?id=1484199#c20 confused me,for
> example, SATA mappaed to VIRTIO which maybe not a expected result.

You are definitely right that this is a problem. There is a limitation for KVM provider that both  VIRTIO_SCSI and SATA disk interfaces are mapped and reported as 'sdx' by VDSM and therefore the engine can't identify which interface to choose, and since SATA wasn't really supported till now, the engine choose VIRTIO_SCSI as a default in such a case. So for KVM, SATA is imported as VIRTIO_SCSI.

In 4.3 we plan to support SATA and this should be fixed.

Regarding Israel Pinto's test at https://bugzilla.redhat.com/show_bug.cgi?id=1484199#c20, , I guess he meant VIRTIO_SCSI instead of VIRTIO. This also fits your tests.

Thanks, Sharon

>   
> Thanks
Comment 19 mxie@redhat.com 2018-05-08 23:54:44 EDT
Hi Sharon,

   So summary the result of importing guest from kvm to rhv4.2 as below
 
     Original kvm guest              After importing
     IDE                             IDE
     SATA (not support on rhv4.2)    virtio-scsi
     SCSI                            virtio-scsi


   But I still have a question, in general, if guest has virtio-scsi disk type,the disk should be updated to vda in guest, but as comment14, guest disk is still sda after importing from kvm on rhv4.2 although its disk type is virtio-scsi, I think virtio-scsi will confuse customer what is real disk type of guest, why not rhv map SCSI to SCSI directly?

Thanks
Comment 20 Sharon Gratch 2018-05-31 06:37:56 EDT
(In reply to mxie@redhat.com from comment #19)
> 
>    So summary the result of importing guest from kvm to rhv4.2 as below
>  
>      Original kvm guest              After importing
>      IDE                             IDE
>      SATA (not support on rhv4.2)    virtio-scsi
>  
    SCSI                            virtio-scsi
Correct. And there is also VIRTIO (block) interface which should be mapped to VIRTIO.
       
> 
> 
>    But I still have a question, in general, if guest has virtio-scsi disk
> type,the disk should be updated to vda in guest, but as comment14, guest
> disk is still sda after importing from kvm on rhv4.2 although its disk type
> is virtio-scsi, I think virtio-scsi will confuse customer what is real disk
> type of guest, why not rhv map SCSI to SCSI directly?
> 
> Thanks

I'm not sure I understand the question.
The mapping between disk interface type to disk name is as follows:
Disk interface type             Disk name
VIRTIO                          vdX (X can be a-z)
SCSI / SATA                     sdX 
IDE                             hdX

So if a guest has SCSI disk type then disk name can be sda and that seems to fit comment 14.

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